On the Move to Meaningful Internet Systems: OTM 2009 Workshops: Confederated International Workshops and Posters, ADI, CAMS, EI2N, ISDE, IWSSA, MONET, ... Applications, incl. Internet Web, and HCI)

Lecture Notes in Computer Science 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 University of Dortmund, 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 of Computer Science, Saarbruecken, Germany

5872

Robert Meersman Pilar Herrero Tharam Dillon (Eds.)

On the Move to Meaningful Internet Systems: OTM 2009 Workshops Confederated International Workshops and Posters ADI, CAMS, EI2N, ISDE, IWSSA, MONET, OnToContent, ODIS, ORM, OTM Academy, SWWS, SEMELS, Beyond SAWSDL, COMBEK 2009 Vilamoura, Portugal, November 1-6, 2009, Proceedings

13

Volume Editors Robert Meersman Vrije Universiteit Brussel (VUB), STARLab Bldg G/10, Pleinlaan 2, 1050 Brussel, Belgium E-mail: [email protected] Pilar Herrero Universidad Politécnica de Madrid, Facultad de Informática Campus de Montegancedo S/N, 28660 Boadilla del Monte, Madrid, Spain E-mail: [email protected] Tharam Dillon Curtin University of Technology, DEBII - CBS De Laeter Way, Bentley, WA 6102, Australia E-mail: [email protected]

Library of Congress Control Number: 2009937453 CR Subject Classification (1998): H.4, H.2, H.3, H.5, C.2, D.2, I.2, K.4 LNCS Sublibrary: SL 3 – Information Systems and Application, incl. Internet/Web and HCI ISSN ISBN-10 ISBN-13

0302-9743 3-642-05289-4 Springer Berlin Heidelberg New York 978-3-642-05289-7 Springer Berlin Heidelberg New York

This work is subject to copyright. All rights are reserved, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, re-use of illustrations, recitation, broadcasting, reproduction on microfilms 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. springer.com © Springer-Verlag Berlin Heidelberg 2009 Printed in Germany Typesetting: Camera-ready by author, data conversion by Scientific Publishing Services, Chennai, India Printed on acid-free paper SPIN: 12779987 06/3180 543210

Volume Editors Robert Meersman Pilar Herrero Tharam Dillon ADI Stefan Jablonski Olivier Cur´e Christoph Bussler Beyond SAWSDL Jacek Kopecky Carlos Pedrinaci Karthik Gomadam Maria Maleshkova CAMS Annika Hinze George Buchanan COMBEK Pieter De Leenheer Martin Hepp Amit Sheth EI2N Herv´e Panetto Ricardo Goncalves Peter Bernus Ted Goranson ISDE Alok Mishra Deepti Mishra Ozlem Albayrak

VI

Volume Editors

IWSSA Lawrence Chung Nary Subramanian Manuel Noguera Jos´e Luis Garrido MONET Patrizia Grifoni Fernando Ferri Irina Kondratova Arianna D’Ulizia ODIS Matt-Mouley Bouamrane Christophe Gravier OnToContent Paolo Ceravolo Mustafa Jarrar Andreas Schmidt ORM Terry Halpin Herman Balsters OTM Academy Peter Spyns Anja Schanzenberger SEMELS Elena Simperl Reto Krummenacher Fran¸coise Baude Philippe Merle Jean-Pierre Lorr´e SWWS Tharam S. Dillon Ernesto Damiani Elizabeth Chang Paolo Ceravolo Chen Wu

General Co-chairs’ Message for OTM 2009

The OnTheMove 2009 event in Vilamoura, Portugal on 1-5 November, further consolidated the growth of the conference series that was started in Irvine, California in 2002, and held in Catania, Sicily in 2003, in Cyprus in 2004 and 2005, in Montpellier in 2006, a first time in Vilamoura in 2007, and in Monterrey Mexico in 2008. The event continues to attract a diversified and representative selection of today’s worldwide research on the scientific concepts underlying new computing paradigms, which, of necessity, must be distributed, heterogeneous and autonomous yet meaningfully collaborative. Indeed, as such large, complex and networked intelligent information systems become the focus and norm for computing, there continues to be an acute and even increasing need to address and discuss face to face in an integrated forum the implied software, system and enterprise issues as well as methodological, semantical, theoretical and applicational issues. As we all know, email, the Internet, and even video conferences are not sufficient for effective and efficient scientific exchange. The OnTheMove (OTM) Federated Conferences series has been created to cover the scientific exchange needs of the community/ies that work in the broad yet closely connected fundamental technological spectrum of Web-based distributed computing. The OTM program every year covers data and Web semantics, distributed objects, Web services, databases, information systems, enterprise workflow and collaboration, ubiquity, interoperability, mobility, grid and high-performance computing. OnTheMove aspires to be a primary scientific meeting place where all aspects of the development of such Internet- and Intranet-based systems in organizations and for e-business are discussed in a scientifically motivated way. This eighth edition of the OTM Federated Conferences event again provided an opportunity for researchers and practitioners to understand and publish these developments within their individual as well as within their broader contexts. Originally the federative structure of OTM was formed by the co-location of three related, complementary and successful main conference series: DOA (Distributed Objects and Applications, since 1999), covering the relevant infrastructure-enabling technologies, ODBASE (Ontologies, DataBases and Applications of SEmantics, since 2002) covering Web semantics, XML databases and ontologies, and CoopIS (Cooperative Information Systems, since 1993) covering the application of these technologies in an enterprise context through, e.g., workflow systems and knowledge management, and in 2007 IS was added (Information Security). In 2006 GADA (Grid computing, high-performAnce and Distributed Applications) was added to this as a main symposium but unfortunately this year attracted too few submissions to guarantee both representativity and quality; a new GADA edition is, however, planned for 2010. Both IS and GADA started as successful workshops at OTM, the first covering the issues of security in complex

VIII

Preface

Internet-based information systems, the second covering the large-scale integration of heterogeneous computing systems and data resources with the aim of providing a global computing space. Each of these four conferences encourages researchers to treat their respective topics within a framework that incorporates jointly (a) theory, (b) conceptual design and development, and (c) applications, in particular case studies and industrial solutions. Following and expanding the model created in 2003, we again solicited and selected quality workshop proposals to complement the more “archival” nature of the main conferences with research results in a number of selected and more “avant-garde” areas related to the general topic of Web-based distributed computing. For instance, the so-called Semantic Web has given rise to several novel research areas combining linguistics, information systems technology, and artificial intelligence, such as the modeling of (legal) regulatory systems and the ubiquitous nature of their usage. We were glad to see that ten of our earlier successful workshops (ADI, CAMS, EI2N, SWWS, ORM, OnToContent, MONET, SEMELS, COMBEK, IWSSA) re-appeared in 2008 with a second, third or even fifth edition, sometimes by alliance with other newly emerging workshops, and that no fewer than three brand-new independent workshops could be selected from proposals and hosted: ISDE, ODIS and Beyond SAWSDL. Workshop audiences productively mingled with each other and with those of the main conferences, and there was considerable overlap in authors. We were also happy to see that in 2009 the number of quality submissions for the OnTheMove Academy (OTMA, formerly called Doctoral Consortium Workshop), our “vision for the future” in research in the areas covered by OTM, took off again. We must thank the new OTMA Dean, Erich Neuhold, and his team of collaborators led by Peter Spyns and Anja Schanzenberger, for their gallant efforts in implementing our interactive formula to bring PhD students together: research proposals are submitted for evaluation; selected submissions and their approaches are (eventually) presented by the students in front of a wider audience at the conference, and intended to be independently and extensively analyzed and discussed in public by a panel of senior professors. As said, all four main conferences and the associated workshops shared the distributed aspects of modern computing systems, and the resulting applicationpull created by the Internet and the so-called SemanticWeb. For DOA 2009, the primary emphasis stayed on the distributed object infrastructure; for ODBASE 2009, it became the knowledge bases and methods required for enabling the use of formal semantics; for CoopIS 2009, the focus as usual was on the interaction of such technologies and methods with management issues, such as occur in networked organizations, and for IS 2008 the emphasis was on information security in the networked society. These subject areas overlap in a scientifically natural fashion and many submissions in fact also treated an envisaged mutual impact among them. As for the earlier editions, the organizers wanted to stimulate this cross-pollination by a “shared” program of famous keynote speakers: this year we were proud to announce Wolfgang Prinz in Computing Science at the

Preface

IX

University of Bonn, Santosh Shrivastava in Computing Science at the University of Newcastle upon Tyne, Kai Hwang in Electrical Engineering and Computer Science and Director of Internet and Cloud Computing Lab at the University of Southern California (USC) and last but not least Alejandro Buchmann of the Department of Computer Science at Technische Universit¨ at Darmstadt where he heads the Databases and Distributed Systems Group. The registration fee structure again wanted to strongly encourage multiple event attendance by providing “all” main conference authors with free access or discounts to “all” other conferences or workshops (workshop authors paid a small extra fee to attend the main conferences). We received a total of 234 submissions for the four main conferences and 131 submissions in total for the workshops. The numbers are about 25% lower than for 2008, not unexpected because of the prevailing economic climate. But, not only may we indeed again claim success in attracting an increasingly representative volume of scientific papers, many from the USA, Central and South America, but these numbers of course allow the Program Committees to compose a high-quality cross-section of current research in the areas covered by OTM. In fact, in spite of the number of submissions, the Program Chairs of each of the three main conferences decided to accept only approximately the same number of papers for presentation and publication as in 2007 and 2008 (i.e., average 1 paper out of 3-4 submitted, not counting posters). For the workshops, the acceptance rate varies but the aim was to stay as strict as before, consistently about 1 accepted paper for 2-3 submitted. We have separated the proceedings into three books with their own titles, two for the main conferences and one for the workshops, and we are grateful to Springer for their suggestions and collaboration in producing these books and USB sticks. The reviewing process by the respective Program Committees was again performed very professionally, and each paper in the main conferences was reviewed by at least three referees, with arbitrated email discussions in the case of strongly diverging evaluations. It may be worthwhile emphasizing that it is an explicit OnTheMove policy that all conference Program Committees and Chairs make their selections completely autonomously from the OTM organization itself. The OnTheMove Federated Event organizers again made all proceedings available on a CDROM to all participants of the conferences and workshops, independently of their registration to a specific conference or workshop. Paper proceedings were on request this year, and incurred an extra charge. The General Chairs are once more especially grateful to the many people directly or indirectly involved in the setup of these federated conferences. Few people realize what a large number of people have to be involved, and what a huge amount of work, and in 2009 certainly also financial risk, the organization of an event like OTM entails. Apart from the persons in their roles mentioned above, we therefore wish to thank in particular our 17 main conference PC Co-chairs: DOA 2009: Mark Little, Jean-Jacques Dubray, Fabio Panizeri, ODBASE 2009: Avigdor Gal, Annika Hinze, Sharma Chakravarthy, CoopIS 2009: Ted Goranson, Hai Zhuge, Moira C. Norrie, IS 2009: Gritzalis Stefanos, Xueqi Cheng;

X

Preface

and the Workshop PC Co-chairs: Stefan Jablonski, Olivier Cur´e, Christoph Bussler, Annika Hinze, George Buchanan, Herv´e Panetto, Ricardo Goncalves, Peter Bernus, Ted Goranson, Alok Mishra, Deepti Mishra, Ozlem Albayrak, Lawrence Chung, Nary Subramanian, Manuel Noguera, Jos´e Luis Garrido, Patrizia Grifoni, Fernando Ferri, Irina Kondratova, Arianna D’Ulizia, Paolo Ceravolo, Mustafa Jarrar, Andreas Schmidt, Matt-Mouley Bouamrane, Christophe Gravier, Frederic Cuppens, Jacques Fayolle, Simon Harper, Saturnino Luz, Masood Masoodian, Terry Halpin, Herman Balsters, Tharam S. Dillon, Ernesto Damiani, Elizabeth Chang, Chen Wu, Amandeep Sidhu, Jaipal Singh, Jacek Kopecky, Carlos Pedrinaci, Karthik Gomadam, Maria Maleshkova , Reto Krummenacher, Elena Simperl, Fran¸coise Baude, Philippe Merle, Ramonville SaintAgne, Pieter De Leenheer, Martin Hepp, Amit Sheth, Peter Spyns, Erich J. Neuhold and Anja Schanzenberger. All, together with their many PC members, performed a superb and professional job in selecting the best papers from the harvest of submissions. We are all grateful to Ana Cecilia Martinez-Barbosa and to our extremely competent and experienced Conference Secretariat and technical support staff in Antwerp, Daniel Meersman, Ana-Cecilia (again), and Jan Demey, and last but not least to our two editorial teams, one in Perth (DEBII-Curtin University) and one in Madrid (Quoriam Ingenieros). The General Chairs gratefully acknowledge the academic freedom, logistic support and facilities they enjoy from their respective institutions, Vrije Universiteit Brussel (VUB), Curtin University, Perth Australia, and Universitad Polit´ecnica de Madrid (UPM), without which such an enterprise would not be feasible. We do hope that the results of this federated scientific enterprise contribute to your research and your place in the scientific network... We look forward to seeing you again at next year’s event! August 2009

Robert Meersman Pilar Herrero Tharam Dillon

Organization

Executive Committee OTM 2009 General Co-chairs

Robert Meersman (VU Brussels, Belgium) and Tharam Dillon (Curtin University, Perth, Australia)

Workshops General Chair

Pilar Herrero (Universidad Polit´ecnica de Madrid, Spain)

DOA 2009 PC Co-chairs

Mark Little (Red Hat, UK), Jean-Jacques Dubray (Premera, Mountlake Terrace, WA, USA) and Fabio Panzieri (Bologna University, Italy)

IS 2009 PC Co-chairs

Gritzalis Stefanos (University of the Aegean, Greece) and Xueqi Cheng (Chinese Academy of Science, China)

ODBASE 2009 PC Co-chairs

Avigdor Gal (Technion, Israel Institute of Technology), Annika Hinze (University of Waikato, New Zealand) and Sharma Chakravarthy (The University of Texas at Arlington, USA)

ADI 2009 PC Co-chairs

Stefan Jablonski (University of Bayreuth), Olivier Cur´e (Universit´e Paris Est) and Christoph Bussler (Merced Systems, Inc.)

Beyond SAWSDL 2009 PC Co-chairs

Jacek Kopecky (STI Innsbruck, University of Innsbruck), Carlos Pedrinaci (Knowledge Media Institute, The Open University), Karthik Gomadam (Kno.e.sis Center, Wright State University) and Maria Maleshkova (Knowledge Media Institute, The Open University)

CAMS 2009 PC Co-chairs

Annika Hinze (University of Waikato, New Zealand) and George Buchanan (Swansea University, UK)

COMBEK 2009 PC Co-chairs

Pieter De Leenheer (Vrije Universiteit Brussel STARLab, Pleinlaan 2, 1050 BRUSSEL, Belgium), Martin Hepp (E-Business and Web Science Research Group, Bundeswehr University, Germany) and Amit Sheth (Kno.e.sis Center, Wright State University, USA)

XII

Organization

EI2N 2009 PC Co-chairs

Herv´e Panetto (Nancy University, France), Ricardo Goncalves (New University of Lisbon, Portugal), Peter Bernusand (Griffith University, Australia) and Ted Goranson (Earl Research, USA)

ISDE 2009 PC Co-chairs

Alok Mishra (Atilim University, Turkey), Deepti Mishra (Atilim University, Turkey) and Ozlem Albayrak (Bilkent University, Turkey)

IWSSA 2009 PC Co-chairs

Lawrence Chung (University of Texas at Dallas, USA), Nary Subramanian (University of Texas at Tyler, USA), Manuel Noguera (University of Granada, Spain) and Jos´e Luis Garrido (University of Granada, Spain)

MONET 2009 PC Co-chairs

Patrizia Grifoni (Istituto di Ricerche sulla Popolazione e le Politiche Sociali, Italy), Fernando Ferri (Istituto di Ricerche sulla Popolazione e le Politiche Sociali, Italy), Irina Kondratova (NRC Institute for Information Technology, Canada) and Arianna D’ Ulizia (Istituto di Ricerche sulla Popolazione e le Politiche Sociali, Italy)

ODIS 2009 PC Co-chairs

Matt-Mouley Bouamrane (University of Manchester, UK), Christophe Gravier (Telecom Saint-Etienne, Universit´e de Saint-Etienne, Universit´e de Lyon, France), Frederic Cuppens (Telecom Bretagne, France), Jacques Fayolle (Telecom Saint-Etienne, Universit´e de Saint-Etienne, Universite de Lyon, France), Simon Harper (University of Manchester, UK) Saturnino Luz (Trinity College Dublin, Ireland) and Masood Masoodian (University of Waikato, New Zealand)

OnToContent 2009 PC Co-chairs

Paolo Ceravolo (Universit` a degli Studi di Milano, Italy), Mustafa Jarrar (University of Cyprus) and Andreas Schmidt (FZI, Germany)

ORM 2009 PC Co-chairs

Terry Halpin (LogicBlox, Australia) and Herman Balsters (University of Groningen, The Netherlands)

Organization

XIII

OTM 2009 Academy PC Co-chairs

Erich J. Neuhold, OTM Academy Dean (University of Vienna, Austria), Peter Spyns (Vrije Universiteit Brussel, Belgium), Anja Schanzenberger (University of Applied Sciences Augsburg, Germany), Alfred Holl (Georg Simon Ohm University of Applied Sciences, Nuremberg, Germany), Maria Esther Vidal (Universidad Simon Bolivar, Caracas, Venezuela), Adam Wierzbicki (Polish-Japanese Institute of Technology, Warsaw, Poland) and Josefa Kumpfm¨ uller (European Patent Office, Austria)

SEMELS 2009 PC Co-chairs

Elena Simperl (Semantic Technology Institute STI, University of Innsbruck, Austria), Reto Krummenacher (Semantic Technology Institute STI, University of Innsbruck, Austria), Fran¸cois Baude (INRIA, Univ. of Nice Sophia-Antipolis I3S CNRS, Sophia Antipolis Cedex, France), Philippe Merle (INRIA ADAM - Lille, Lille, France) and Jean-Pierre Lorr´e (eBM WebSourcing, Ramonville Saint-Agne (Toulous), France)

SWWS 2009 PC Co-chairs

Tharam S. Dillon (DEBII, Curtin University of Technology, Australia), Ernesto Damiani (Computer Science Department, Milan University, Italy), Elizabeth Chang (DEBII, Curtin University of Technology, Australia), Paolo Ceravolo (Computer Science Department, Milan University, Italy), Chen Wu (DEBII, Curtin University of Technology, Australia) and Jaipal Singh (DEBII, Curtin University of Technology, Australia)

Publication Chairs

Houwayda Elfawal Mansour (Curtin University, Perth, Australia), Eva L´ opez Mar´ı (Universidad Polit´ecnica de Madrid, Spain) and Jos´e Mar´ıa Est´evez Canales (Universidad Polit´ecnica de Madrid, Spain)

Local Organising Chair

Ricardo Goncalves (New University of Lisbon, Portugal)

Publicity & Sponsorship Chair Ana-Cecilia Martinez Barbosa (DOA Institute, Belgium) and Gonzalo Mendez (Universidad Complutense de Madrid, Spain) Logistics Team

Daniel Meersman (Head of Operations), AnaCecilia Martinez Barbosa and Jan Demey

XIV

Organization

DOA 2009 (Distributed Objects, Middleware, and Applications) Program Committee Giorgia Lodi Subbu Allamaraju Mark Baker Judith Bishop Gordon Blair Harold Carr Geoffrey Coulson Frank Eliassen Patrick Eugster Pascal Felber Benoit Garbinato Medhi Jazayeri Eric Jul

Nick Kavantzas Joe Loyall Frank Manola Gero M¨ uhl Nikola Milanovic Graham Morgan Rui Oliveira Jose Orlando Pereira Francois Pacull Fernando Pedone Arno Puder Michel Riveill Luis Rodrigues

IS 2009 (Information Security) Program Committee Alessandro Acquisti Gail-Joon Ahn Vijay Atluri Joonsang Baek Manuel Bernardo Barbosa Ezedin Barka Elisa Bertino Yu Chen Bruno Crispo Gwenael Doerr Josep Domingo Ferrer Nuno Ferreira Neves Simone Fischer-Huebner Clemente Galdi Aiqun Hu Jiankun Hu Hai Jin Christos Kalloniatis Maria Karyda Stefan Katzenbeisser Hiroaki Kikuchi Spyros Kokolakis Wei-Shinn Ku Kwok-Yan Lam Costas Lambrinoudakis Xiaodong Lin Ling Liu

Evangelos Markatos Sjouke Mauw Chris Mitchell Yi Mu Barry Clifford Neuman Yi Pan Jong Hyuk Park Guenther Pernul Milan Petkovic Frank Piessens Bhanu Prasad Bart Preneel Rodrigo Roman Pierangela Samarati Biplab K. Sarker Haiying (Helen) Shen Weisong Shi Mikko T. Siponen Diomidis Spinellis Pureui Su, Luis Javier Garcia Villalba Cheng-Zhong Xu Yixian Yang Alec Yasinsac Moti Yung Wei Zou Andre Zuquete

Organization

XV

ODBASE 2009 (Ontologies, DataBases, and Applications of Semantics) Program Committee Karl Aberer Harith Alani Mar´ıa Auxilio Medina Renato Barrera Sonia Bergamaschi Leopoldo Bertossi Alex Borgida Mohand Boughanem Paolo Bouquet Christoph Bussler Silvana Castano Paolo Ceravolo Oscar Corcho Ernesto Damiani Aldo Gangemi Benjamin Habegger Mounira Harzallah Bin He Andreas Hotho Jingshan Huang Farookh Hussain Prateek Jain Maciej Janik Vana Kalogeraki Dimitris Karagiannis Uladzimir Kharkevich Manolis Koubarakis Maurizio Lenzerini Juanzi Li Alexander L¨oser Li Ma Vincenzo Maltese

Maurizio Marchese Gregoris Metzas Riichiro Mizoguchi Peter Mork Ullas Nambiar Anne Ngu Sandeep Pandey Adrian Paschke Peter R. Pietzuch Axel Polleres Wenny Rahayu Rajugan Rajagopalapillai Sudha Ram Satya Sahoo Pavel Shvaiko Sergej Sizov Il-Yeol Song Veda C. Storey Umberto Straccia Eleni Stroulia Heiner Stuckenschmidt Vijayan Sugumaran York Sure Robert Tolksdorf Susan Urban Yannis Velegrakis Guido Vetere Kevin Wilkinson Baoshi Yan Laura Zavala Jose Luis Zechinelli Roberto Zicari

ADI 2009 (Ambient Data Integration) Program Committee Christoph Bussler Olivier Cur´e Mathieu D’aquin Wolfgang Deiters Stefan Jablonski Robert Jeansoulin

Fabrice Jouanot Roland Kaschek Myriam Lamolle Richard Lenz Sascha Mueller Erich Ortner

XVI

Organization

Gatan Rey Riccardo Rosati

Kurt Sandkuhl Pierre Senellart

Beyond SAWSDL 2009 (The Next Steps After SAWSDL) Program Committee Rama Akkiraju Carine Bournez John Domingue Karthik Gomadam Laurent Henocque Jacek Kopecky Holger Lausen Freddy Lecue Maria Maleshkova David Martin

John Miller Barry Norton Massimo Paolucci Carlos Pedrinaci Ajith Ranabahu Dumitru Roman Brahmananda Sapkota Kaarthik Sivashanmugam Ioan Toma Tomas Vitvar

CAMS 2009 (Context-Aware Mobile Systems) Program Committee Pilar Herrero George Buchanan Trevor Collins Keith Cheverst Dan Chalmers Gill Dobbie Tiong Goh Annika Hinze Reto Krummenacher

Johan Koolwaaij Diane Lingrand Kris Mihalic Gero Muehl Jason Pascoe Michel Scholl Goce Trajcevski Katarzyna Wac

COMBEK 2009 (Community-Based Evolution of Knowledge-Intensive Systems) Program Committee Stijn Christiaens Tanguy Coenen Aldo de Moor Alicia Diaz Davide Eynard Juan Carlos Fernandez-Ramil Alois Ferscha Dragan Gasevic Andreas Hotho Konstantinos Kotis Filippo Lanubile

Tom Mens Igor Mozetic Natalya Noy Marta Sabou Andreas Schmidt Katharina Siorpaes Christopher Thomas Matthias Trier Denny Vrandecic Valentin Zacharias

Organization

XVII

EI2N 2009 (Enterprise Integration, Interoperability and Networking) Program Committee Berio Giuseppe Bernus Peter Chen David Chapurlat Vincent Curaj Adrian Dassisti Michele Johnsson Charlotta Garcia Higuera, Andres Goncalves Ricardo Goranson Ted Gu Xinjian Jochem Roland Katzy Bernhard Luzeaux Dominique Mendez Juan-Carlos Majstorovich Vidosav D. Mezgar Ivan Molina Arturo

M¨ uller J¨ org Nof Shimon Noran Ovidiu Ortiz Angel Panetto Herv´e Park Jin woo Li Qing Smutnicki Czeslaw Stanescu Aurelian Mihai Szpytko Janusz Turner Pat Vallespir Bruno Vernadat Fran¸cois B. Weichhart Georg Whitman Lawrence Zelm Martin Zhou Xuan

ISDE 2009 (Information Systems in Distributed Environment) Program Committee Amar Gupta Allen E. Milewski Anil Kumar Tripathi Antti Valimaki Barbara Carminati Biplab Kumar Sarker Cagatay Catal Bernard Wong Brahim Hnich Charles Wallace Darja Smite Deo Prakash Vidyarthi Eyas El-Qawasmeh Fatma Cemile Serce Hazim El-Baz Ian Allison Ita Richardson Ivan Lukovic Jeffrey Carver

Jukka K¨ aa¨ri¨ ainen Kassem Saleh M. Ali Babar M. Rehan Mahmood Niazi Mitko Mitev Nilay Oza Nils. B. Moe June Verner J¨ urgen M¨ unch Orit Hazzan Pierre F. Tiako Rajnath Singh Randy Weinberg Qing YAO Silvia Abrahao Stanislaw Wrycza Tom Gilb

XVIII

Organization

IWSSA 2009 (System/Software Architectures) Program Committee Philippe Aniorte Hern´ an Astudillo Doo-Hwan Bae Joseph Barjis Jaelson Castro Roger Champagne Francois Coallier Kendra Cooper Rafael Corchuelo Lirong Dai Sergiu Dascalu Yannis A. Dimitriadis Jing Dong Jes´ us Favela Juan Fern´ andez-Ramil Rub´en Fuentes Paul Gruenbacher Lars Grunske Fred Harris Michael Hinchey Mar´ıa V. Hurtado

Stan Jarzabek Li Jiang Carlos Juiz Pericles Loucopoulos Mar´ıa D. Lozano Chung-Horng Lung Stephen J. Mellor Tommi Mikkonen Masaki Murakami Sergio F. Ochoa Patricia Paderewski Sooyong Park ´ Oscar Pastor Fabio Patern` o Mar´ıa Luisa Rodr´ıguez Gustavo Rossi Vespe Savikko Michael Shin Yeong Tae Song Andrea Zisman

MONET 2009 (MObile and NEtworking Technologies for Social Applications) Program Committee Kevin C. Almeroth Frederic Andres Russell Beale Yiwei Cao Tiziana Catarci Richard Chbeir Karin Coninx Simon Courtenage Juan De Lara Anna Formica C.-C. Jay Kuo Peter Leijdekkers Stephen Marsh Rebecca Montanari Michele Missikoff

Nuria Oliver Marco Padula Manish Parashar Andrew Phippen Nitendra Rajput Tommo Reti Ahmed M. Safwat Nicola Santoro Tim Strayer Henri Ter Hofte Thanassis Tiropanis Yoshito Tobe Riccardo Torlone Mikael Wiberg Adam Wojciechowski

Organization

ODIS 2009 (Ontologies in Distributed and Interactive Systems) Program Committee Ahmed Alasoud Mariano Alcaniz Alberto Anguita Sanchez Mikel Egana Aranguren Mikael Ates Soren Auer Leif Azzopardi John Breslin Tobias Buerger Luis Carrico Smitashree Choudhury Alfredo Cuzzocrea Maciej Dabrowski Bertrand David Kerstin Denecke Gavin Doherty Piotr Gawrysiak Chirine Ghedira Mahmoud Ghorbel Andrew Gibson Ralf Heese Dennis Hooijmaijers Pokorny Jaroslav Nophadol Jekjantuk Simon Jupp Rachid Kadouche

Shuaib Karim Jay Kola Harald Kosch Frederique Laforest Dave Lambert Jiangang Ma Kristina Masuwa-Morgan Mounir Mokhtari Zeljko Obrenovic Martin O’Connor Federica Paganelli Jeff Pan Eric Pardede Vassilios Peristeras Bram Pellens Pit Pichappan Michel Plantie Daniele Radicioni Thomas Risse Sebastian Ryszard Kruk Aman Shakya Victoria Uren Thierry Villemur Pinar Wennerberg Yeliz Yesilada Fouad Zablith

OnToContent 2009 (Ontology Content) Program Committee Abder Koukam Aldo Gangemi Alessandro Oltramari Alia Abdelmoty Andreas Wombacher Antonio Zilli Barry Smith Chen Wu Christophe Roche Davy Monticolo Eva Blomqvist Fabio Vitali

Fausto Giunchiglia Franckie Trichet Geert Poels Giancarlo Guizzardi Harith Alani Hyoil Han Jeff Pan Karl Reed Luk Vervenne Marcello Leida Martin Hepp Michael Brown

XIX

XX

Organization

Miguel Sicilia Mohand-Said Hacid N´ uria Casellas Paul Piwek Philippe Cudr´e-Mauroux Riccardo Albertoni

Robert Tolksdorf Sergio Tessaris Silvie Spreeuwenberg Stefano David Stijn Heymans

ORM 2009 (Fact-Oriented Modeling) Program Committee Dick Barden Herman Balsters Scott Becker Linda Bird Anthony Bloesch Peter Bollen Lex Bruil Andy Carver Donald Chapin Matthew Curland Dave Cuyler Necito Dela Cruz Olga De Troyer Jan Dietz Gordon Everest Ken Evans Mario Gutknecht John Hall Pat Hallock

Terry Halpin Clifford Heath Stijn Hoppenbrouwers Mike Jackson Mustafa Jarrar Inge Lemmens Tony Morgan Maurice Nijssen Baba Piprani Erik Proper Ron Ross Gerhard Skagestein Sylvie Spreeuwenberg Peter Spyns Kurt Stirewalt Serge Valera Jan Vanthienen Jos Vos Theo van der Weide

OTM 2009 Academy Program Committee Christoph Bussler Jaime Delgado Ling Feng Alfred Holl Fr´ed´eric Le Mou¨el Erich J. Neuhold

Anja Schanzenberger Peter Spyns York Sure Maria Esther Vidal Adam Wierzbicki

Organization

XXI

SEMELS 2009 (Semantic Extensions to Middleware: Enabling Large-Scale Knowledge Applications) Program Committee Vidal Alexandre C.T. Esfandiari Babak Gandon Fabien Omicini Andrea Oliver Ian Bortenschlager Manfred Robertson David Faron Zucker Catherine

Tolksdorf Robert Bergamaschi Sonia Wei Chen Wutke Daniel Kopecky Jacek Pedrinaci Carlos Zaihrayeu Ilya Liquori Luigi Barczynski Wojciech

SWWS 2009 (Semantic Web and Web Semantics) Program Committee Aldo Gangemi Amandeep Sidhu Amit Sheth Angela Schwering Avigdor Gal Birgit Hofreiter Carlos Sierra Carole Goble Chris Bussler Claudia d’Amato David Bell Elena Camossi Elisa Bertino Elizabeth Chang Ernesto Damiani Farookh Hussain Feng Ling Grigoris Antoniou Hai Zhuge Jaiwei Han John Debenham John Mylopoulos Katia Sycara Krzysztof Janowicz Kokou Yetongnon Kyu-Young Whang Ling Liu Lizhu Zhou

Lotfi Zadeh Manfred Hauswirth Maria Andrea Rodr´ıguez-Tastets Masood Nikvesh Mihaela Ulieru Mohand-Said Hacid Monica De Martino Mukesh Mohania Mustafa Jarrar Nicola Guarino Paolo Ceravolo Peter Spyns Pieree Yves Schobbens Pilar Herrero Qing Li Rajugan Rajagopalapillai Ramasamy Uthurusamy Riccardo Albertoni Robert Meersman Robert Tolksdorf Stefan Decker Susan Urban Tharam Dillon Usuama Fayed Wil van der Aalst York Sure Zahir Tari

Table of Contents

Posters of the 2009 DOA (Distributed Objects, Middleware, and Applications) International Symposium Orchestration of Middleware Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Herv´e Paulino, Paulo Cancela, and Tiago Franco

1

Posters of the 2009 IS (Information Security) International Symposium Discontinuity of SVD Embedding Mapping Used for Watermarks . . . . . . Kazuo Ohzeki, Yuki Seo, and Engyoku Gi

4

Virtualization in Network Intrusion Detection Systems . . . . . . . . . . . . . . . . Monis Akhlaq, Faeiz Alserhani, Irfan U. Awan, Andrea J. Cullen, John Mellor, and Pravin Mirchandani

6

Posters of the 2009 ODBASE (Ontologies, DataBases, and Applications of Semantics) International Conference Pre-matching: Large XML Schemas Decomposition Approach . . . . . . . . . . Sana Sellami, A¨ıcha-Nabila Benharkat, and Youssef Amghar

9

Enriching and Answering Proteomic Queries Using Semantic Knowledges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Kunale Kudagba, Omar El Beqqali, and Hassan Badir

11

Ontology-Based Support for Graph Algorithms in Online Exploration Workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Thomas Hornung and Wolfgang May

13

Auto-updatable Index Approach for OODBMSs . . . . . . . . . . . . . . . . . . . . . . Tomasz M. Kowalski, Kamil Kuliberda, Jacek Wi´slicki, and Radoslaw Adamus

15

Workshop on Ambient Data Integration (ADI) ADI 2009 PC Co-chairs’ Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

Invited Talk Effective Ontology-Based Data Integration . . . . . . . . . . . . . . . . . . . . . . . . . . Riccardo Rosati

18

XXIV

Table of Contents

Modeling and Management of Data A Model Driven Engineering Approach Applied to Master Data Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ludovic Menet and Myriam Lamolle

19

Managing XML Schema Mappings and Annotations in P2P Data Integration Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tadeusz Pankowski and Magdalena Niwi´ nska

29

Managing Large, Structured, and Annotated Documents: A Study of Three Operational Cases in the Field of Environmental Legislation . . . . . Michel Treins, Carine Louvion, and Jacques Vaudelin

39

Data Integration Solution Merging Expressive Ontologies Using Formal Concept Analysis . . . . . . . . Olivier Cur´e Contemporary Challenges in Ambient Data Integration for Biodiversity Informatics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . David Thau, Robert A. Morris, and Sean White A Hierarchical Representation for Recording Semantically Condensed Data from Physically Massive Data Out of Sensor Networks Geographically Dispersed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MinHwan Ok

49

59

69

Workshop on Context Aware Mobile Systems (CAMS) CAMS 2009 PC Co-chairs’ Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

77

Models and Frameworks Rethinking Context Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Emiliano P´erez, Andr´es Fortier, Gustavo Rossi, and Silvia Gordillo A Framework for Decentralized, Context-Aware Mobile Applications Using Semantic Web Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . William Van Woensel, Sven Casteleyn, and Olga De Troyer

78

88

Context at Work Modeling Dynamic Context Awareness for Situated Workflows . . . . . . . . . Hannes Wolf, Klaus Herrmann, and Kurt Rothermel

98

Table of Contents

FleXConf: A Flexible Conference Assistant Using Context-Aware Notification Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Nikos Armenatzoglou, Yannis Marketakis, Lito Kriara, Elias Apostolopoulos, Vicky Papavasiliou, Dimitris Kampas, Alexandros Kapravelos, Eythimis Kartsonakis, Giorgos Linardakis, Sofia Nikitaki, Antonis Bikakis, and Grigoris Antoniou

XXV

108

Novel Contextual Technologies A Framework for Context-Aware Adaptation in Public Displays . . . . . . . Jorge C.S. Cardoso and Rui Jos´e

118

Location Based Application Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . Raja Naeem Akram, Konstantinos Markantonakis, and Keith Mayes

128

Workshop on Enterprise Integration, Interoperability and Networking (IFAC-IFIP EI2N) EI2N 2009 PC Co-chairs’ Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

139

Invited Talk Systems as Foundations for MBSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Claude Feliot

141

Enterprise Architecture and Networking High-Speed Access to RFID Data: Meeting Real-Time Requirements in Distributed Value Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Holger Ziekow, Benjamin Fabian, and Cristian M¨ uller Cross-Dimensional Modelling Patterns to Empower Pan-European Business to Government Services Interoperability . . . . . . . . . . . . . . . . . . . . Fenareti Lampathaki, Sotiris Koussouris, George Gionis, Yannis Charalabidis, and Dimitris Askounis

142

152

Architecting the Firm – Coherency and Consistency in Managing the Enterprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Patrick Turner, John Gøtze, and Peter Bernus

162

Aspects of the BPRIM Language for Risk Driven Process Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Amadou Sienou, Elyes Lamine, Herv´e Pingaud, and Achim Karduck

172

XXVI

Table of Contents

Enterprise Integration and Interoperability ProcessGene-Connect: SOA Integration between Business Process Models and Enactment Transactions of Enterprise Software Systems . . . . Avi Wasser and Maya Lincoln

184

Dynamic Business Networks: A Headache for Sustainable Systems Interoperability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Carlos Agostinho and Ricardo Jardim-Goncalves

194

On the Use of Description Logic for Semantic Interoperability of Enterprise Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Esma Yahia, Jing Yang, Alexis Aubry, and Herv´e Panetto

205

A Maturity Model for Enterprise Interoperability . . . . . . . . . . . . . . . . . . . . Wided Gu´edria, David Chen, and Yannick Naudet

216

Workshop on Information System in Distributed Environment (ISDE) ISDE 2009 PC Co-chairs’ Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

226

Tools and Task Allocation in Distributed Information System Development Systematic Task Allocation Evaluation in Distributed Software Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . J¨ urgen M¨ unch and Ansgar Lamersdorf Extending Global Tool Integration Environment towards Lifecycle Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Jukka K¨ a¨ ari¨ ainen, Juho Eskeli, Susanna Teppola, Antti V¨ alim¨ aki, Pekka Tuuttila, and Markus Piippola Dynamic SLA Negotiation in Autonomic Federated Environments . . . . . . Pawel Rubach and Michael Sobolewski

228

238

248

Requirement Validation in Distributed Information System Development Network Security Validation Using Game Theory . . . . . . . . . . . . . . . . . . . . Vicky Papadopoulou and Andreas Gregoriades

259

Process Management in Distributed Information System Development On the Use of Handover Checkpoints to Manage the Global Software Development Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Frank Salger

267

Table of Contents

XXVII

Exploiting Process Knowledge for Event Processing in Distributed Business Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Holger Ziekow

277

Distributed Information System Development: Review of Some Management Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deepti Mishra and Alok Mishra

282

Workshop on System/Software Architectures (IWSSA) IWSSA 2009 PC Co-chairs’ Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

292

Non-functional Requirements Towards a Fault-Tolerant Architecture for Enterprise Application Integration Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Rafael Z. Frantz, Rafael Corchuelo, and Carlos Molina-Jimenez

294

Architectural Stability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Rami Bahsoon and Wolfgang Emmerich

304

Connecting Architecture and Implementation . . . . . . . . . . . . . . . . . . . . . . . . Georg Buchgeher and Rainer Weinreich

316

Confirming and Reconfirming Architectural Decisions on Scalability: A Goal-Driven Simulation Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tom Hill, Sam Supakkul, and Lawrence Chung

327

Model-Driven Approaches Transforming Functional Requirements from UML into BPEL to Efficiently Develop SOA-Based Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Anisha Vemulapalli and Nary Subramanian Using an Architecture-Centric Model-Driven Approach for Developing Service-Oriented Solutions: A Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . Marcos L´ opez-Sanz, C´esar J. Acu˜ na, Valeria de Castro, Esperanza Marcos, and Carlos E. Cuesta Using AOSD and MDD to Enhance the Architectural Design Phase . . . . M´ onica Pinto, Lidia Fuentes, Luis Fern´ andez, and Juan A. Valenzuela

337

350

360

XXVIII

Table of Contents

A Model Transformation Approach to Derive Architectural Models from Goal-Oriented Requirements Models . . . . . . . . . . . . . . . . . . . . . . . . . . . Marcia Lucena, Jaelson Castro, Carla Silva, Fernanda Alencar, Emanuel Santos, and Jo˜ ao Pimentel

370

Evaluation, Verification and Validation Applying Formal Verification Techniques to Ambient Assisted Living Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Kawtar Benghazi, Mar´ıa Visitaci´ on Hurtado, Mar´ıa Luisa Rodr´ıguez, and Manuel Noguera Software Architecture Evaluation in Global Software Development Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Frank Salger

381

391

Design An Architectural Pattern for Mobile Groupware Platforms . . . . . . . . . . . . Andr´es Neyem, Sergio F. Ochoa, Jos´e A. Pino, and Dario Franco Refinement of Software Product Line Architectures through Recursive Modeling Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sofia Azevedo, Ricardo J. Machado, Dirk Muthig, and Hugo Ribeiro Designing and Supporting Cooperative and Ubiquitous Learning Systems for People with Special Needs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ´ Alvaro Fern´ andez L´ opez, Mar´ıa Jos´e Rodr´ıguez F´ ortiz, and Manuel Noguera Garc´ıa Software System Understanding via Architectural Views Extraction According to Multiple Viewpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Azadeh Razavizadeh, Sorana Cˆımpan, Herv´e Verjus, and St´ephane Ducasse

401

411

423

433

Workshop on Mobile and Networking Technologies for Social Applications (MONET) MONET 2009 PC Co-chairs’ Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

443

Social Networking SocioNet: A Context-Aware Approach for Lowering the Communication Barrier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Igor Pernek and Karin Anna Hummel

444

Table of Contents

Models of Charity Donations and Project Funding in Social Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adam Wojciechowski Mobile Context Provider for Social Networking . . . . . . . . . . . . . . . . . . . . . . Andr´e C. Santos, Jo˜ ao M.P. Cardoso, Diogo R. Ferreira, and Pedro C. Diniz

XXIX

454

464

Business Applications Personalized Services Oriented towards Commercial Establishments . . . . David Marin D´ıaz, Alejandro Rico Zuluaga, and Angela Carrillo-Ramos

474

CRM System Implementation in a Multinational Enterprise . . . . . . . . . . . Alok Mishra and Deepti Mishra

484

Mobile Applications and Services An Architecture for Dynamic Trust Monitoring in Mobile Networks . . . . Olufunmilola Onolaja, Rami Bahsoon, and Georgios Theodoropoulos

494

ME: Multimodal Environment Based on Web Services Architecture . . . . Maria Chiara Caschera, Alessia D’Andrea, Arianna D’Ulizia, Fernando Ferri, Patrizia Grifoni, and Tiziana Guzzo

504

Workshop on Ontology Content (OnToContent) OnToContent 2009 PC Co-chairs’ Message . . . . . . . . . . . . . . . . . . . . . . . . . .

513

Ontology Design Towards a Pattern-Driven Topical Ontology Modeling Methodology in Elderly Care Homes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Yan Tang, Peter De Baer, Gang Zhao, Robert Meersman, and Kevin Pudney

514

A Socio-semantic Approach to Collaborative Domain Conceptualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Carla Pereira, Crist´ ov˜ ao Sousa, and Ant´ onio Lucas Soares

524

Termontography and DOGMA for Knowledge Engineering within PROLIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Peter De Baer, Robert Meersman, and Rita Temmerman

534

XXX

Table of Contents

A Pattern-Based Framework of Change Operators for Ontology Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Muhammad Javed, Yalemisew M. Abgaz, and Claus Pahl

544

Business Model Ontologies A Simulation Model Articulation of the REA Ontology . . . . . . . . . . . . . . . Wim Laurier and Geert Poels

554

An Ontology for Modeling Complex Inter-relational Organizations . . . . . Yves Wautelet, Nicolas Neysen, and Manuel Kolp

564

Ontology Evaluation and Management Efficient Management of Biomedical Ontology Versions . . . . . . . . . . . . . . . Toralf Kirsten, Michael Hartung, Anika Groß, and Erhard Rahm

574

SemioSem: A Semiotic-Based Similarity Measure . . . . . . . . . . . . . . . . . . . . . Xavier Aim´e, Fr´ed´eric Furst, Pascale Kuntz, and Francky Trichet

584

Ontology Evaluation through Usability Measures: An Experiment with the SUS Scale in the Legal Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . N´ uria Casellas

594

Ontologies in Distributed and Interactive Systems (ODIS) Semantically Enhanced Recommender Systems . . . . . . . . . . . . . . . . . . . . . . Manuela Ruiz-Montiel and Jos´e F. Aldana-Montes

604

Photo-Based User Interfaces: Picture It, Tag It, Use It . . . . . . . . . . . . . . . . Geert Vanderhulst, Kris Luyten, and Karin Coninx

610

Ontology Based Proactive Design and Patterns towards the Adaptability of Knowledge Management Systems . . . . . . . . . . . . . . . . . . . . Yinglin Wang and Zheying Zhang ELDeR: An Ontology for Enabling Living inDependently of Risks . . . . . . Diana Salda˜ na-Jimenez, Marcela D. Rodr´ıguez, Juan-Pablo Garc´ıa-V´ azquez, and Ad´ an-No´e Espinoza

616

622

Workshop on Fact-Oriented Modeling (ORM) ORM 2009 PC Co-chairs’ Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

628

Table of Contents

XXXI

Business Service and Process Modeling Towards a Common Platform to Support Business Processes, Services and Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Baba Piprani

629

BPMN as a Communication Language for the Process- and Event-Oriented Perspectives in Fact-Oriented Conceptual Models . . . . . . Peter Bollen

639

A Model for Semantic Equivalence Discovery for Harmonizing Master Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Baba Piprani

649

An ORM-Driven Implementation Framework for Database Federations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Herman Balsters and Bouke Haarsma

659

ORM-Based Semantics of B2B Transactions . . . . . . . . . . . . . . . . . . . . . . . . . H. Balsters and F. van Blommestein

671

Language and Tool Extensions The Constellation Query Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Clifford Heath

682

A Role Calculus for ORM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Matthew Curland, Terry Halpin, and Kurt Stirewalt

692

Automated Test Input Generation for Software That Consumes ORM Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Matthew J. McGill, R.E. Kurt Stirewalt, and Laura K. Dillon

704

Development of Tooling to Support Fact-Oriented Modeling at ESA . . . . Inge Lemmens, Francesco Sgaramella, and Serge Valera

714

Predicate Reference and Navigation in ORM . . . . . . . . . . . . . . . . . . . . . . . . Terry Halpin

723

Positionalism of Relations and Its Consequences for Fact-Oriented Modelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C. Maria Keet

735

Industrial Case Studies Fact-Orientation Applied to Develop a Flexible Employment Benefits System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Maurice Nijssen, Inge Lemmens, and Ralph Mak

745

XXXII

Table of Contents

Business Semantics Management Supports Government Innovation Information Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Geert Van Grootel, Peter Spyns, Stijn Christiaens, and Brigitte J¨ org

757

Workshop on OTM Academy OnTheMove Academy 2009 Organizers’ Message . . . . . . . . . . . . . . . . . . . . .

767

Automatic Detection of Terminology Evolution . . . . . . . . . . . . . . . . . . . . . . Nina Tahmasebi

769

Ambient Information Systems to Support the Elderly in Carrying Out Their Activities of Daily Living . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Juan Pablo Garc´ıa-V´ azquez and Marcela D. Rodr´ıguez

779

K 4R – Knowledge to the Power of RESTful, Resourceful and Reactive Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ricardo Amador

789

Automatic Construction of a Semantic, Domain-Independent Knowledge Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . David Urbansky

800

Solving Identity Management and Interoperability Problems at Pan-European Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sergio S´ anchez Garc´ıa and Ana G´ omez Oliva

805

An Application Framework for a Situation-Aware System Support for Smart Spaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Arlindo Santos and Helena Rodrigues

810

Workshop on Semantic Web and Web Semantics (SWWS) SWWS 2009 PC Co-chairs’ Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

815

On Constructing, Grouping and Using Topical Ontology for Semantic Matching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Yan Tang, Peter De Baer, Gang Zhao, and Robert Meersman

816

Query Results Clustering by Extending SPARQL with CLUSTER BY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Agnieszka L  awrynowicz

826

An Agent-Based Data Mining System for Ontology Evolution . . . . . . . . . Maja Hadzic and Darshan Dillon

836

Table of Contents

XXXIII

A Hybrid Concept Similarity Measure Model for Ontology Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hai Dong, Farookh Khadeer Hussain, and Elizabeth Chang Semantic Wiki as a Basis for Software Engineering Ontology Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Natsuda Kasisopha, Pornpit Wongthongtham, and Farookh Khadeer Hussain

848

858

Semantic Extensions to Middleware: Enabling Large Scale Knowledge Applications (SEMELS) Implementation of a Service-Based Grid Middleware for Accessing RDF Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Isao Kojima and Masahiro Kimoto Towards a Reactive Semantic Execution Environment . . . . . . . . . . . . . . . . Srdjan Komazec and Federico Michele Facca Collaborative Building, Sharing and Handling of Graphs of Documents Using P2P File-Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Alan Davoust and Babak Esfandiari

866 877

888

The Next Steps After SAWSDL (Beyond SAWSDL) Management Tool for Semantic Annotations in WSDL . . . . . . . . . . . . . . . . Nicolas Boissel-Dallier, Jean-Pierre Lorr´e, and Fr´ed´erick Benaben

898

SAWSDL for Self-adaptive Service Composition . . . . . . . . . . . . . . . . . . . . . . Teodoro De Giorgio, Gianluca Ripa, and Maurilio Zuccal` a

907

Adapting SAWSDL for Semantic Annotations of RESTful Services . . . . . Maria Maleshkova, Jacek Kopeck´ y, and Carlos Pedrinaci

917

Community-Based Evolution of Knowledge-Intensive Systems (COMBEK) An Evolutionary Ontology Approach for Community-Based Competency Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Peter De Baer, Robert Meersman, and Gang Zhao MaSiMe: A Customized Similarity Measure and Its Application for Tag Cloud Refactoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . David Urdiales-Nieto, Jorge Martinez-Gil, and Jos´e F. Aldana-Montes Author Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

927

937

947

Orchestration of Middleware Services Herv´e Paulino1 , Paulo Cancela2 , and Tiago Franco2 1

CITI / DI - FCT - Universidade Nova de Lisboa, Portugal 2 Critical Software SA, Portugal

Abstract. In this paper we present OHMS, a platform that provides an easy and not resource consuming way of exposing a platform to the Web, thus enabling Web access, business-to-business interaction and service composition, by the means of orchestration.

1

Introduction

Many of the current Service-Oriented Architectures (SOA) are built on top of Distributed Object (DO) technologies, such as CORBA [1] or DCOM [2], that have not overcome two crucial aspects of today’s businesses: to port the SOA concept to the World Wide Web and to provide interoperability across many different platforms, enabling business-to-business transactions. By tackling both these issues, the Web Service technology (WS) has become the current standard for the development of SOA infrastructures. The porting of DO-based platforms to the WS technology is, however, a costly process that requires high investments of both time and money. Furthermore, there are performance issues at stake, the overhead introduced by the WS platform and language independence is not desired when it comes to the internals of a platform. On the other hand, moving to the WS world opens a new range of prospects, essentially motivated by: increased visibility; business-to-business interaction based on XML standards; and the use of service composition to deploy new services by composing platform and other Web available services. This paper bridges these two worlds by presenting OHMS (OrcHestration of Middleware Services), a framework to support the Web exposure and composition, concretely the orchestration, of services originating from distinct DO middleware technologies.

2

The OHMS Platform

The main goals of OHMS are: (1) to have a platform-centric approach, i.e., to focus on the bridging of service-oriented DO platforms, rather than individual services; (2) avoid, at all cost, the need to alter the platform’s implementation in order to be suitable for orchestration; and (3) to have a general solution that is not bound to any particular technology. To achieve such goals we designed an architecture composed of two independent modules: the name-service directory module bridges a DO platform, R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 1–3, 2009. c Springer-Verlag Berlin Heidelberg 2009 

2

H. Paulino, P. Cancela, and T. Franco

Fig. 1. Components of OHMS

Fig. 2. The name-service directory

partially or completely, by storing information on its name-server and the logistic required to expose its service registry; and the orchestration module provides the means for the actual orchestration of the exposed services. It is an platform-centered extension of the Eclipse BPEL plug-in [3] that provides a simple way to access and orchestrate services of previously bridged platforms. OHMS is not bound to any particular DO technology, thus providing full interoperability. From the directory’s point of view, a DO technology is a set of Java classes that encapsulate all the logic necessary to bridge a service of the given technology: (1) inspect the registry of a platform’s name-server, in order to extract the services to bridge; (2) generate the bridge for each of these services; and (3) register the resulting bridges in the UDDI registry, making them visible to the orchestration module. The overall architecture of the directory, presented in Fig. 2, embeds a Web server, the access point to the Web services that relay the incoming invocations to the target platform services; and a UDDI registry that holds the registry of these Web services, publishing them to the network and serving as glue to bind both modules of the architecture. A registration peer provides the means to register, update and unregister both DO technologies and platforms. By registering their name-server in OHMS, DO platforms automatically expose their set of services as Web services. The process is completely transparent to the platform, and thus no alterations on its implementation are required. The definition of which services to bridge is coded on a properties file supplied to the directory during the platform’s registry.

3

Conclusions and Future Work

OHMS’ directory is a compact engine that resorts to technology-dependent components, the bridging logic, to manage platform exposure. All of the work goes, thus, into developing the logistic from a given technology, something that must be done only once, and may be shared by the community. OHMS was validated in the context of COMCOP [4], a general purpose Command and Control (C & C) platform entirely developed in CORBA by Critical Software SA.

Orchestration of Middleware Services

3

References 1. Object Management Group: The Common Object Request Broker: Architecture and Specification. Object Management Group (2001) 2. Horstmann, M., Kirtland, M.: DCOM Architecture. Microsoft (1997) 3. BPEL Project, http://www.eclipse.org/bpel/ 4. Simoes, H., Carola, I., Franco, T.: C&C-Platform Reference Architecture. Technical report, Critical Software, S.A (2008)

Discontinuity of SVD Embedding Mapping Used for Watermarks Kazuo Ohzeki1, Yuki Seo2, and Engyoku Gi1 1

ISE,2 Liberal Arts,1,2 Shibaura Institute of Technology, 1 3-7-5,Toyosu, Koutouku, Tokyo, Japan 2 307, Fukasaku, Minumaku, Saitama, Japan {ohzeki, yukis, m108048}@sic.shibaura-it.ac.jp

Abstract. This paper presents a verification test on a quasi-one-way characteristic of SD watermarking. Norm of distance between tow matrices is one of measures for evaluating degree of computational burden against reverse analysis.The norm distance shows a kind of nonlinearity and even noncontinous phenominon, in spite of the norm is smooth quadratic function. Keywords: SVD, one-way function, mapping, norm, eigen-value.

1 Introduction Singular Value Decomposition (SVD) watermarking is one of fields of research now found in academic publications. Among them, a semi-blind SVD watermarking method [1] shows robustness with difficulty of inversion attacks because of its quasione-way characteristic. The same SVD water marking method is seen in [2]. The SVD is a specific operation, which maps image ‘G’ into SVD value matrix ‘S’ with positive values on the diagonal positions and all other zero values for off-diagonal positions. This specificity that all elements of the matrix S are non-negative prohibits using negative elements. This means that atleast on a superficial level subtraction does not exits in the SVD world. From this observation, evaluation of the degree of the one-way characteristic started [3]. It is difficult to prove one-way characteristic in fully mathematical point of view. It is not necessary to accomplish one-way for practical applications. For watermarking applications, some degree of computational difficulty is sufficient to preventing reverse analysis, which is to find embedding way or embedding key. In this paper, numerical evaluations for discontinuous characteristics and error characteristics between the original data and the embedded data are carried out.

2 Verification of Quasi-One-Way Characteristic Let us formalize the watermarking embedding procedure using SVD as a mapping. Embedding procedure is not a simple function that outputs a single value. So we call the procedure a mapping. Let m be a procedure mapping, m : G o G w . R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 4–5, 2009. © Springer-Verlag Berlin Heidelberg 2009

Discontinuity of SVD Embedding Mapping Used for Watermarks

5

Fig. 1. (a) (Left) Norm vs. embedded level. (b) (Right) Norm vs. embedded position.

For an image G, SVD results G U ˜ S ˜ V T For embedded image Gw, another T result is. G W U W ˜ S W ˜ VW . The Euclidean norm between U and Uw, or V and Vw is evaluated. Fig.1 (a) shows the Euclidean Norm difference between one of the decomposing matrices U and Uw, which depend on the embedding magnitudes. Although the difference increases as the watermark magnitude increases, the tendency is not proportional, but a staircase pattern can be seen as the watermark magnitude increases. This result indicates that, because the Euclidean Norm is continuous since it is a root of the sum of the squared differences of the elements, the SVD process causes discontinuity. Embedded watermark level is on the horizontal axis, and Norm of difference is on the vertical axis. Fig.1 (b) shows the Euclidean Norm of the difference between U and Uw versus the small difference of the watermark component. The positions of the embedded th watermark are in the 100 row of the singular matrix S. Norm vs. embedded position. Discontinuity can be read by viewing vertically at every position. Discontinuous points occasionally exist for specific level transition from a lower position to a higher.

3 Discussions and Future Work Without quantization, cause of the discontinuity can be from the change of elements of matirix U. Quantization in embedding may cause much discontinuous. Non-linear transform or decomposition will be more useful for quasi-one-way characteristic.

References 1. Ohzeki, K., Sakurai, M.: SVD-Based Watermark with Quasi-One-Way Operation by Reducing a Singular Value Matrix Rank. In: Proc. The Firste-forensics, Adelade, Australia, Technicalsession B4. Watermarking, 1 (January 22, 2008) 2. Qi, X., Brimley, B., Brimley, G.: Anadaptive QIM- and SVD-based digital image water marking scheme in the wavelet domain. In: Proc. ICIP, October 2008, pp. 421–424 (2008) 3. Ohzeki, K., Gi, E.: Quasi-One-Way Function and Its Application stoImage Watermarking. In: Proc. MMAP in IMCSIT, Wisła, Poland, pp. 501–508 (October 2008)

Virtualization in Network Intrusion Detection Systems Monis Akhlaq1, Faeiz Alserhani1, Irfan U. Awan1, Andrea J. Cullen1, John Mellor1, and Pravin Mirchandani2 1

Informatics Research Institute, University of Bradford, Bradford, BD7 1DP, United Kingdom {m.akhlaq2,f.m.f.alserhani,i.u.awan, j.e.mellor,a.j.cullen}@bradford.ac.uk 2 Syphan Technologies [email protected] www.syphan.com

Abstract. This research work has focussed on analysing the efficacy of the virtualization concept for Network Intrusion Detection Systems (NIDS) in the high-speed environment. We have selected an open source NIDS, Snort for evaluation. Snort has been evaluated on virtual systems built on Windows XP SP2, Linux 2.6 and Free BSD 7.1 platforms. Our results have identified a strong performance limitation of NIDS running on virtual platforms. This can be concluded that virtualization is not an ideal solution for NIDS in high-speed environments.

1 Introduction Our research work focuses on evaluating the virtualization concept for NIDS in highspeed networks. Virtualization has found its acceptance in NIDS; however no comprehensive evaluation has done before. Mostly, the concept has been debated on perceived logics of resource conservation in virtualization without any experimental proof. We have analyzed the concept by utilizing open source NIDS- Snort under high-speed multi-Gbps environment. Snort [1], an open source NIDS has been selected because of its popularity and status as a de facto IDS standard. Snort relies on the packet capturing libraries (libpcap and winpcap) [2]. Our concept is unique in the sense that we have incorporated three different OS platforms and the evaluation criteria are based on packet handling capacity of Snort. Our effort in [3] describes the comprehensive evaluation methodology with in-depth analysis of the factors responsible for virtualization limitation in NIDS in high speed environment.

2 Methodology The evaluation technique is based on analyzing the ability of virtual system in terms of their packet capturing capability. The test-bench is distributed into three parts: traffic generation, traffic reception and the Snort virtual platform configured on a dual quad-core processor. The system is built on the Windows 2008 Server platform and three separate virtual platforms have been created-Windows XP SP2, Linux 2.6 & R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 6–8, 2009. © Springer-Verlag Berlin Heidelberg 2009

Virtualization in Network Intrusion Detection Systems

7

Free BSD 7.1. Snort is running simultaneously on all the virtual machines and similar traffic-loads and types are injected onto all platforms.

3 Results 3.1 UDP Traffic – Packet Sizes 512 and 1024 Byte at 100 Mbps to 2.0 Gbps •

•

•

Linux shows quite good performance for traffic-load upto 500 Mbps for all packet sizes. The Linux however system found non responsive at traffic-loads of 1.0 Gbps and above for 512 Bytes packet sizes and at 2.0 Gbps for packet sizes of 1024 Bytes. Windows also performed satisfactorily at traffic-loads of 250 Mbps and 500 Mbps for packet sizes of 512 Bytes and 1024 Bytes respectively. The system found non responsive at traffic-loads of 1.0 Gbps and above for packet size of 512 Bytes and 2.0 Gbps for packet sizes of 1024 Bytes. Free BSD responds a bit better than Windows, the system found non responsive at traffic-loads greater than 1.0 Gbps for packet sizes of 512 Bytes and 2.0 Gbps for packet sizes of 1024 Bytes.

3.2 TCP Traffic – Packet Size 512 Byte for 100/ 200 Connections • • •

Linux exhibits quite good performance upto 250 Mbps loading with minimum packet loss, however, its response linearly declined for higher traffic-loads. Windows also exhibits a similar performance level upto 250 Mbps loading levels and its performance declined for higher traffic-loads. Free BSD performs a bit better than Windows.

4 Conclusion The results obtained have shown a number of significant limitations in the use of virtual NIDS, where both packet-handling and processing capabilities at different traffic loads were used as the primary criteria for defining system performance. We have confirmed that the underlying host hardware plays a prominent role in determining overall system performance. We have further shown that performance is further degraded as the number of virtual instances of NIDS is increased, irrespective of the virtual OS used. Furthermore, we have demonstrated a number of significant differences in the performance characteristics of the three different virtual OS environments in which Snort was run. This work has identified specific and replicable bottlenecks in commonly used implementations of virtualization for a widely used NIDS in high-speed networks. The results obtained can be taken as a benchmark for improving the performance of these systems in future research work. These shall also provide an experimental data to the researchers which were felt missing in the previous efforts.

8

M. Akhlaq et al.

References 1. Snort, http://www.Snort.org/ 2. Baker, A.R., Esler, J.: Snort IDS and IPS Toolkit. Syngress, Canada (2007) 3. Akhlaq, M., et al.: Virtualization Efficacy for NIDS in High Speed Environments. In: Information Security and Digital Forensics Conference 2009 to be held in City University London, September 7-8 (in press, 2009)

Pre-matching: Large XML Schemas Decomposition Approach Sana Sellami, Aïcha-Nabila Benharkat, and Youssef Amghar University of Lyon, CNRS, INSA-Lyon, LIRIS, UMR5205, F-69621, France {Sana.Sellami,Nabila.benharkat,Youssef.Amghar}@insa-lyon.fr

1 XML Schemas Decomposition Approach We propose a decomposition approach, as a pre-matching phase, which break down large XML schemas into smaller sub-schemas to improve the quality of large schema matching. Our approach identifies and extracts common structures between and within XML schemas (inter and intra-schemas) and finds the sub-schemas candidates for matching. As illustrated in Fig.1, our proposed approach is composed of three phases:

Fig. 1. Decomposition approach

(1) Converting XML schemas in trees: The goal of this initial phase is to transform XML schemas into trees and to find linguistic relations between elements. This aims at improving decomposition with considering not only exactly the same labels of elements but also the linguistic similar elements. We firstly need to parse the XML schemas and transforming them into trees. The main feature of these large schemas is that they contain referential constraints. Then parsing these schemas becomes a difficult exercise. To cope with these constraints, we duplicate the segment which they refer to resolve their multiple contexts. We notice that most previous match systems focused on simple schemas without referential elements. (2) Identifying and mining frequent sub-trees: The main goal of this phase is to decompose the input schemas into smaller ones. To this end, we identify and extract R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 9–10, 2009. © Springer-Verlag Berlin Heidelberg 2009

10

S. Sellami, A.-N. Benharkat, and Y. Amghar

the common sub-structures from XML schemas describing the same domains. We propose to use tree mining techniques to identify these structures. More precisely, we use the algorithm proposed in [2]. Tree mining is a classical pattern mining problem (an important class of data mining problem) which aims at discovering automatically sub-trees that appear frequently in a set of trees. (3) Finding relevant frequent sub-trees: The focus of this phase is to identify the sub-trees candidates for matching. This aims at reducing match effort by only matching relevant parts from the other schemas. These sub-schemas are then selected for matching. This pre-matching phase includes two main steps: selection of maximal sub-trees and finding the most similar ones.

2 Experimental Evaluation

F-measure

We conducted our experiments on real XML schemas (XCBL1 and OAGIS2). We have implemented the decomposition approach in our PLASMA (Platform for LArge Schema MAtching) prototype. We compared our decomposition results with those of fragmentation COMA++ approach [1]. Our results (fig.2) show that decomposition approach provides a better quality of matching in comparison to the fragmentation approach in COMA++.

schemas size

Fig. 2. F-measure obtained by decomposition approach in PLASMA and fragmentation approach in COMA++

References 1. Do, H.H., Rahm, E.: Matching large schemas: Approaches and evaluation. Journal of Information Systems, 857–885 (2007) 2. Termier, A., Rousset, M.A., Sebag, M.: DRYADE: a new approach for discovering closed frequent trees in heterogeneous tree databases. In: Proceedings of the 4th IEEE International Conference on Data Mining (ICDM), pp. 543–546 (2004) 1 2

www.xcbl.org www.oagi.org

Enriching and Answering Proteomic Queries Using Semantic Knowledges Kunale Kudagba1, , Omar El Beqqali1 , and Hassan Badir2 1

2

USMBA University, Computer Science Department, P.O. Box. 1796, 30000 Fes, Morocco {kkunale,oelbeqqali}@fsdmfes.ac.ma National School of Applied Sciences, Computer Science Department, P.O. Box. 1818, 45000 Tangier, Morocco [email protected]

Abstract. Querying and sharing Web proteomics is a challenging topic in Pharmaceutical Drug Discovery and Computational Biology. Given that, several data sources can be used to answer the same sub-goals in the Global query, it is obvious that we can have many different candidates rewritings. The user-query is formulated using Concepts and Properties related to Proteomics research (Domain Ontology). Semantic mappings describe the contents of underlying sources in order to reflect their query capabilities. In this work, we propose to enrich the user query using WordNet and we give a characterization of query rewriting problem using semantic mappings as an associated hypergraph. Hence, the generation of candidates rewrititngs can be formulated as the discovery of minimals Transversals associated with this hypergraph. We exploit and adapt algorithms available in Hypergraph Theory to find all candidates rewritings from a query answering problem. In this context, some relevant criteria could help to determine optimal and qualitative rewritings, according to user preferences, and sources technical performances. Keywords: Proteomics, Ontology, WordNet, XML, Trees, Semantic Web, ψ-terms, Query Rewriting, minimal Transversals.

1

Problem Formalization

Given a Global Query Q and a couple of semantic knowledges Sch O made by  of Oproteomics Ontology and a set M of all semantic mappings between pro teomic sources and Oproteomics , the Query Rewriting consists of computing two sub-queries Qinvalide and Qvalide on the basis of mappings set, such as: Q = Qvalide ∨ Qinvalide

(1)

Explicitly, we shall calculate: 1. Q = Qinvalide . Sub-Query Q can not be answered by underlying sources, at the moment of the sending of the Global Query Q. 

Corresponding author.

R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 11–12, 2009. c Springer-Verlag Berlin Heidelberg 2009 

12

K. Kudagba, O. El Beqqali, and H. Badir

2. Q = Qvalide is the part of that will be rewritten using semantic mappings. Sub-query Q can be answered by registered sources. Our final goal is to propose an intelligent subdivision of Q into sub-queries Q1 , Q2 ,. . ., Qm with 1 ≤ m ≤ n, So, we need to determine: – all candidates rewritings expressed as: Qreecriture = Q1 ∧ Q2 ∧ . . . ∧ Qm – and all partial queries Source Sj as follows:

Qj

(2)

composing these rewritings and answered by a

Qj =

k 

Cij

(3)

i=1

with k ≤ m and k denotes number of atomic constraints Ci satisfying by the partial query Qj de Q while m denotes number of atomic constraints in Q. The algorithm receives as input a global query Q, a schema Sch O and generate as output a set of all candidates rewritings ri (Q).

2

Rewriting Algorithm

The algorithm runs like that: 1. From a rewriting query problem, we need to give a mathematical characterization, by defining an associated Hypergraph HQ,M (V, E): – For every mapping mi , describing a local concept from M , as a logical  function of Oproteomics global concepts, we associate a vertice Vmi in the hypergraph HQ,M (V, E) and V = {Vmi , with 1 ≤ i ≤ n}. – For every constraint Ci of the Global query Q, we associate an hyperedge ECi in the hypergraph HQ,M (V, E). To simplify, we suppose that all these constraints are describing atomics goals. So, each hyperedge ECi is a set of mappings, calculated by considering those mappings which are relevant to answer these goals. 2. From this associated Hypergraph, we generate its minimal Transversals, correponding to all candidates rewritings. 3. Ranking of Candidate rewritings and Selection of best ones according to criteria specified by an online Biologist.

3

Conclusion

This paper shows briefly our current research Work that aims to provide a semantic-driven, user-centric and scalable framework integrate and query XML Proteomic Sources on the Web. A Test realized according to a scenario of six sub-queries and Three semantic mappings allow us to find 36 quadruplets, 6 Transversals but only 2 are minimals.

Ontology-Based Support for Graph Algorithms in Online Exploration Workflows Thomas Hornung1 and Wolfgang May2 1 2

Institut f¨ ur Informatik, Universit¨ at Freiburg [email protected] Institut f¨ ur Informatik, Universit¨ at G¨ ottingen [email protected]

Abstract. Application domains often include notions that are inherently based on graph structures. In this paper, we propose CGDT as a comprehensive generic ontology and API for graphs, which is geared towards online exploration of potentially large graphs.

1

Introduction

A recurring motive when designing informational workflows is the computation of (parts of) transitive closures in graphs. In the context of the Web these graphs are neither known nor materialized a priori, but can be explored only at runtime, using one or more Web data source. Often, even the graph data itself is dynamic, which does not allow for materialization or caching. These characteristics require completely different algorithms where the exploration and expansion strategy for the graph itself is the central issue. We present CGDT (Configurable Graph DataType) that provides an ontology and an API for configurable graphs. The design of CGDT combines generic graph behavior (insertion of edges etc.) with application-specific configurability. CGDT allows to encode the maintenance of the stored graph data inside the graph by (i) assigning properties to vertices, edges, and paths, and (ii) specifying how paths are obtained from existing edges and paths during the exploration process. For details and a sample use case refer to the long version of this paper1 .

2

An Ontology for Graphs in Online Algorithms

The basic notions of any graph ontology are vertices, edges, and paths. While in the usual notion of graphs, the set of paths is defined as the transitive closure of edges, the set P of relevant paths in a configurable graph is a certain subset of all existing paths in the graph that satisfy additional constraints. A central feature of CGDT is that vertices, edges and paths can be adorned with (typed) properties, which can optionally be specified in terms of view definitions over other properties, or by external queries. When new edges are added, 1

http://www.dbis.informatik.uni-goettingen.de/Publics/

R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 13–14, 2009. c Springer-Verlag Berlin Heidelberg 2009 

14

T. Hornung and W. May

the emerging new paths (wrt. the path insertion conditions) are computed, and their path properties are derived, e.g. by an inductive definition over the length of the path. To control the insertion of vertices and edges or the extension of paths, conditions can be stated that need to be satisfied. Signature and Operations. The operations of CGDT are divided into a Data Definition Language (DDL) where the properties and the constraints are defined, and a Data Manipulation Language (DML) that provides generic update and query operations. The DDL. While in SQL and related languages, the DDL has an own syntax, the DDL of CGDT is actually the ontology language RDF that declaratively specifies which properties exist, together with their definitions, and with the constraints how to expand the graph. In contrast to SQL, where the main notion of the schema is the table, CGDT is based on three subschemas each of which defines some properties and optionally some constraints that guide the exploration process (cf. Figure 1).

♦

hasV.I.C * VertexInsertionCondition



♦ ♦

1 VertexSchema

Schema  1 1

hasProperty *



GraphSchema

EdgeSchema

Property rdfs:label rdfs:range

PathSchema

hasE.I.C hasP.E.C * * conditions and EdgePathdefinitions are InsertionExtensionCondition Condition expressed based on properties 

  Condition

definition

0,1

Expression  language specification

Fig. 1. Basic Notions of the CGDT Ontology

A concrete application-specific CGDT specification then defines – the names and datatypes of the application-specific properties, – the definitions of the derived properties, – conditions to configure the exploration process. The DML. The DML is also independent from the actual application domain (similar to e.g. SQL as DML for relational databases). The modifiers allow to add items to the graph and the accessors return newly reachable vertices based either on breadth-first or A∗ best-first search.

Auto-updatable Index Approach for OODBMSs Tomasz M. Kowalski, Kamil Kuliberda, Jacek Wiślicki, and Radosław Adamus Computer Engineering Department, Technical University of Lodz, Poland {tkowals,kamil,jacenty,radamus}@kis.p.lodz.pl

Abstract. The paper contains a short introduction to robust approach (including architecture) for realisation of auto-updatable indexing of data in OODBMS, i.e. maintaining cohesion between data and indices. The authors work is based on the Stack-Based Query Language (SBQL) and has been implemented and verified in the ODRA (Object Database for Rapid Applications development) OODBMS prototype. Keywords: automatic index updating, triggers, OODBMS, SBA, SBQL.

1 Indexing in ODRA OODBMS The general idea of indexing in object-oriented databases does not differ from the one in relational systems [5]. Database indices ought to ensure two important properties: transparency and automatic updating. Indices, like all redundant structures, can lose cohesion if the data stored in the database are modified. Thus, to ensure validity of indices, the update of data has to be combined with rebuilding of appropriate index structures. The rebuild process should be transparent to abstract a programmer of this inconvenient and error prone task. Furthermore, additional time required for an index update in response to data modification should be minimised. To achieve this, database systems should efficiently find indices which became outdated due to performed data modification. Next, the appropriate index entries should be corrected. Such index updating routines should not influence performance of retrieving information from the database and the overhead introduced to writing data should be minimal. The theoretical idea for query optimisation using indices was developed and presented in [3]. The implementation of indexing is based on Linear Hashing structures which can be easily extended to its distributed version SDDS [2]. Moreover, the implementation provides extensive query optimisation supported by enabling: (1) support for optimising dense and range queries on integer, real, string and date keys, (2) dense indexing for reference key values, (3) indexing using multiple keys, (4) special support facilitating indexing of integer, real, string, date, reference and boolean keys (enum key type) with a countable limited set of values (low key value cardinality) giving additional possibility in applying multiple keys. The architectural view of the proposed index update process is presented in Figure 1.We assume that an administrator adds an index, Triggers Definitions (TDs) are created before Index Update Triggers (IUTs) – see (1a) and (1b) in Figure 1. Index Manager (IM) initialises a new index and issues Triggers Manager (TM) a message to build TDs, next, the TM activates the Index Updating Mechanism (IUM) R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 15–16, 2009. © Springer-Verlag Berlin Heidelberg 2009

16

T.M. Kowalski et al.

which basing on the knowledge about indices and TDs proceeds to add IUTs – a Root-IUT for the databases root entry, while a Non Key-IUT is added to an indexed non-key object; then a key value is evaluated and an adequate entry is added to the created index.

Fig. 1. Index Updating Engine architecture

Removing an index causes removal of IUTs (together with NK-IUTs corresponding index entries are deleted) and TDs. The mediator managing addition and removal of IUTs is a special extension of the CRUD interface. The other case is when the IUM is activated and when the stored CRUD interface receives a message to modify an object which is marked with one or more IUTs (see (2) in Figure 1). CRUD notifies the IUM about forthcoming modifications and all necessary preparation before database alternation are performed. After gathering required information, CRUD performs requested modifications and calls IUM to work. A significant element used by the Index Updating Mechanism is the SBQL interpreter – see [1, 4] for details (out of scope of the paper). For implementation details see [1].

References 1. Kowalski, T.M., Wislicki, J., Kuliberda, K., Adamus, R., Subieta, K.: Optimization by Indices in ODRA. In: First International Conference on Object Databases, Berlin, pp. 97– 117 (2008), ISBN 078-7399-412-9 2. Litwin, W., Nejmat, M.A., Schneider, D.A.: LH*: Scalable, Distributed Database System. ACM Trans. Database Syst. 21(4), 480–525 (1996) 3. Płodzień, J.: Method in Object Query Languages. PhD Thesis. IPIPAN, Warszawa (2000) 4. SBA & SBQL Web pages, http://www.sbql.pl/ 5. Elmasri, R., Navathe, S.B.: Fundamentals of Database Systems, 4th edn. Pearson Education, Inc., London (2004)

ADI 2009 PC Co-chairs’ Message Welcome to the proceedings of the second International Workshop on Ambient Data Integration (ADI 2009). The workshop was held in conjunction with the On The Move Federated Conference and Workshops (OTM 2009), November 1-6, 2009 in Vilamoura, Portugal. This workshop provides a forum for discussing relevant aspects for the success of data integration systems with a focus on the ubiquity, management and conceptualization of these systems. We expect that ambient issues in data integration are going to challenge system designers for quite some time and significant effort is needed in order to tackle them. This workshop brings together researchers and practitioners to share their recent ideas and advances towards this emerging and important problem. The papers accepted at ADI 2009 can be divided into two groups: innovative data integration solutions and modeling and management of data. Concerning data integration solutions, the talk of Riccardo Rosati presents an approach for effective ontology-based data integration. Also dealing with ontologies, the paper of Olivier Curé proposes a solution based on formal concept analysis to merge knowledge bases. MinHwan Ok's paper presents a method for condensing data in a large sensor network organized in a hierarchy of databases. Finally, the paper of David Thau et al. highlights concrete challenges in ambient data integration applied to the domain of biodiversity informatics. Three papers were selected considering modeling and management of data. Tadeusz Pankowski's paper presents an approach to the (semi) automatic generation of schema mappings in XML data integration. The paper of Ludovic Menet et al. addresses the federation of data sources and the definition of unified data models based on XML architecture and the concept of master data management. Finally, the paper of Michel Treins et al. proposes a concept for managing large structured and annotated documents in the field of environmental legislation. We would like to thank Riccardo Rosati for his keynote lecture, the authors for their submissions, the Program Committee members for their excellent work, and the conference organizers for their great support in setting up the workshop. November 2009

Olivier Curé Stefan Jablonski Christoph Bussler

R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, p. 17, 2009. © Springer-Verlag Berlin Heidelberg 2009

Effective Ontology-Based Data Integration Riccardo Rosati Dipartimento di Informatica e Sistemistica Sapienza Universit` a di Roma Via Ariosto 25, 00185 Roma, Italy [email protected]

The goal of data integration is to provide a uniform access to a set of heterogeneous data sources, freeing the user from the knowledge about where the data are, how they are stored, and how they can be accessed. One of the outcomes of the research work carried out on data integration in the last years is a clear conceptual architecture, comprising a global schema, the source schema, and the mapping between the source and the global schema. In this talk, we present a comprehensive approach to ontology-based data integration. We consider global schemas that are ontologies expressed in OWL, the W3C standard ontology specification language, whereas sources are relations, managed through a data federation tool that wraps the actual data. The mapping language has specific mechanisms for relating values stored at the sources to objects that are instances of concepts in the ontology. By virtue of the careful design that we propose for the various components of a data integration system, answering unions of conjunctive queries can be done through a very efficient technique which reduces this task to standard SQL query evaluation. Finally, we present a management system for ontology-based data integration, called MASTRO-I, which completely implements our approach.

R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, p. 18, 2009. c Springer-Verlag Berlin Heidelberg 2009 

A Model Driven Engineering Approach Applied to Master Data Management Ludovic Menet1,2 and Myriam Lamolle1 1

Laboratoire d’Informatique Avancée de Saint Denis (LIASD) IUT of Montreuil, University of Paris 8, 140 rue de la nouvelle France, 93100 Montreuil, France {l.menet,m.lamolle}@iut.univ-paris8.fr 2 Orchestra Networks, R&D department, 75 boulevard Haussmann, 75008 Paris, France [email protected]

Abstract. The federation of data sources and the definition of pivot models are strongly interrelated topics. This paper explores a mediation solution based on XML architecture and the concept of Master Data Management. In this solution, pivot models use the standard XML Schema allowing the definition of complex data structures. The introduction of a MDE approach is a means to make modeling easier. We use UML as an abstract modeling layer. UML is a modeling object language, which is more and more used and recognized as a standard in the software engineering field, which makes it an ideal candidate for the modeling of XML Schema models. In this purpose we introduce features of the UML formalism, through profiles, to facilitate the definition and the exchange of models. Keywords: MDE, MDA, Master Data Management, Metamodel, UML, XML Schema.

1 Introduction The evolution of networks and of systems of data management led to the rise of wide scale Information Systems within companies. These systems using increasingly the Web to share and propagate information are characterized by data sources of very different kinds. Indeed, these sources can be distributed, heterogeneous and autonomous. Consequently, information management becomes complex, inefficient, costly and of uncertain quality. Concerning the heterogeneity of data sources, three needs appear: (i) to integrate data to unify the different sources, (ii) to use a unified data model federating the different models associated to data sources, (iii) to minimize the number of data management tools in order to take advantage of them efficiently. Master Data Management (MDM) is an emerging discipline focusing on these three points. MDM aims at integrating data split in multiple systems by defining a master repository formatted as a data warehouse. This master repository centralizes data structures, thanks to the data warehouse model, the contents as well as the R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 19–28, 2009. © Springer-Verlag Berlin Heidelberg 2009

20

L. Menet and M. Lamolle

implementation of management tools via a unique application, thus ensuring the data lasting application systems quality. Our MDM approach is based on XML standard recommended by the W3C [15], since the standardization of the XML language made it a suitable technology for data integration systems. In our architecture, the unified data model (or pivot) that we call “adaptation model”, is an XML Schema document [16] allowing the definition of complex, structured, typed and rich models. However, even though the use of XML is suitable for the definition of models, it requires a thorough knowledge of this language by the different actors involved in the definition process of the pivot data model. This problematic led us to introduce a thought process to guide data model designers, in order for them to concentrate solely on data modeling and integration rather than on the technology to use. The selection of an object and standard approach to improve the model understanding and associated semantics (MDM semantics in our perspectives), seems to be a simple and efficient way. Therefore, the principal objective of our works is to follow a Model Driven Engineering (MDE) approach to ignore the technological layer (physical) for the benefit of the functional layer (logical). The functional aspect is delegated to UML [14] and completed by UML profiles to define specific semantics to our MDM and XML research domains. The change-over from the functional solution to the technological solution is ensured by model transformation processes based on standard formalisms such as Meta Object Facility [11] and XMI [8]. In this paper, we present an application of the MDE concepts to the MDM domain dedicated to data integration. The continuation of this article is organized as follows: section 2 presents the data integration approach by Master Data Management; section 3 details our XML architecture for data integration; section 4 presents the introduction of an MDE approach applied to the MDM domain.

2 Data Integration by Master Data Management In the context of interoperability of heterogeneous data sources, two principal approaches to data integration exist, namely the virtual approach (or by mediator) [5], and the materialized approach (or by warehouse) [2]. Master Data Management is an emerging method for data integration based on the materialized approach. As a recent discipline, very few works exist on MDM to date (iWays Master Data center, Oracle MDM suite, IBM MDM, OrchestraNetworks MDM). MDM was defined as a method focused on data integration and centralization, models and tools within an Information System. Currently, the majority of Information Systems is characterized by heterogeneity in terms of data and settings solutions. Indeed, this heterogeneity is present within different aspects: diversity of storage systems (databases, files, directories, etc.), of data formats (tables, owner files, XML documents, etc.), of solutions offered for managing different data types, of actors taking advantage of the reference data (functional users or not), of application domains (CRM1, ERP2, etc.), of activities (called “vertical” for activities such as production or supplying, or “horizontal” for activities such as marketing or human resources), etc. 1 2

Customer Relationship Client. Enterprise Resource Planning.

A Model Driven Engineering Approach Applied to Master Data Management

21

This heterogeneity in the data, in the existing solutions on the market and in the application domains, results in making the implementation and exploitation of these data heavy, complex and costly by the applications of the company. Using a set of different applications to manage this diversity in the types of data, inevitably leads to redundancy both at the data and tools level . In the absence of MDM, the propagation of data updates is carried out without any central repository or joint information model, with an architecture style often qualified as “peer to peer”. This style is relatively common in ETL3/EAI4 base architecture, without MDM. Two conditions are necessary for a centralized MDM architecture: (i) to have a generic MDM tool capable of hosting the joint information model for all kinds of data. Without this genericity level, MDM should be accepted as silos organized around information domains (Client, Product, Organization, functional settings, technical settings, etc.), harmful consequences in terms of duplication of repositories (which is what we seek to avoid) and of duplication of governance functions (versions management, human-to-administration machine interface, etc.). (ii) A method for modeling and negotiating the joint information model is needed which would ignore the “owners” formats of the different systems. The first point is ensured by our MDM solution that we present in section 3. The introduction of an IDM approach (section 4) to define the pivot data models is a solution possible for the second point.

3 EBX.Platform as a MDM Solution Based on the XML Schema standard, EBX.Platform5 simplifies the definition of models aimed at unifying the reference data of a company. Using the XML Schema technology, these models can be of any type (simple, complex) and any nature (business, technical, graphical). One of the main advantages of XML Schema is to allow the definition of structured and typed data models, with powerful validation properties. Compared to existing integration systems [2] [17] our solution also deals with important aspects of data federation: data life cycle handling multiple "branches" in a repository and making possible to perform concurrent changes on a repository and to compare/merge them; data inheritance to avoid data duplication between instances; access rights based on a directory (internal or external - for example LDAP), EBX.Platform allows to define access profiles to the MDM and to configure rights on each action, each object or even each attribute; data quality using a powerful incremental validation framework ; a unique Web-based tool which dynamically generates the Graphical User Interface from Master Data models. It means that once a Master Data model has been designed, users are able to create instances, edit values and validate data content in a single application. 3.1 Concepts EBX.Platform is based on two principles namely: (i) adaptation models that are XML Schema documents defining the structure of reference data, and (ii) adaptations that 3

Extraction Transformation Loading. Enterprise Application Integration. 5 Online documentation available at http://doc.orchestranetworks.com/ 4

22

L. Menet and M. Lamolle

are XML instances of adaptation models representing the content of reference data. The use of XML Schema enables us to specify that each node of the data model corresponds to an existing type of data and conforms to the W3C standard. On the other hand, the formalism of XML Schema allows constraints (enumerations, length, inferior and superior bounds, etc.), An adaptation is an instance of the adaptation model. For any node of the adaptation model declared as recoverable corresponds a node in the adaptation. It is often found that more than three quarters of reference data are identical between two instances (for example a products catalog between a head office and a subsidiary). It is important to avoid the duplication of these data in order to prevent long input procedures that are often tedious and sources of errors. To do so, EBX.Platform relies on an inheritance technology. In this management model, each instance inherits from its parent. When an adaptation model owns several adaptations, we consider that an adaptation tree is handled. 3.2 Adaptation Model Example This section describes how to build an adaptation model starting from a sample relational database called publications, containing data that represent a fictitious publishing business. This database contains the following tables: Publishers table contains the identification numbers, names, cities, and states of publishing companies ; Authors table contains an identification number, first and last name, address information, and contract status for each author ; Titles table contains the book ID, name, type, publisher ID, price, advance, royalty, year-to-date sales, comments, and publication date for each book ; Royalties table lists the unit sales ranges and the royalty connected with each range. The royalty is some percentage of the total sales. Figure 1 presents the XML Schema structure, corresponding to the Publisher table of the publications database. <xs:complexType name="Publisher"> <xs:annotation><xs:appinfo> <primaryKeys>/pub_id <xs:sequence> <xs:element name="pub_id" type="xs:string"/> <xs:element type="name"/> <xs:element name="city" type=”xs:string”/> Fig. 1. A table within an adaptation model defined with XML Schema

A Model Driven Engineering Approach Applied to Master Data Management

23

The use of XML seems to be adapted to the definition of models, indeed XML Schema to define complex data structures with powerful constraints, however as we can see in figure 2 it implies an extensive knowledge of this language. A lot of software such as Altova XML Spy [1] have been developed to model graphically XML Schema models as trees. These software allow optimizing the modeling of XML schemas but each of them proposes a different formalism of representation, thus creating some confusion during the modeling of these schemas. A Model Driven Engineering (MDE) approach appears to be a solution to the difficulties encountered during the modeling of such data structures. The objective of a MDE approach is to move the complexity of the realization of an application to the specification of this one. It is then a question of making an abstraction of the programming language using an abstract modeling process. The next section deals with a MDE approach applied to the Master Data Management.

4 MDE Approach Applied to Master Data Management The introduction of an IDM approach applied to Master Data Management aims to make the definition process of a pivot data model generic and standard. To achieve this, we introduce an abstraction layer by UML meta-modeling enabling an adaptation model to be represented regardless of its application domain. 4.1 Meta-modeling of Adaptation Models Meta-modeling of adaptation models is a first step to the introduction of an IDM approach. Meta-modeling was standardized by the OMG [4] who recommended the use of Meta Object Facility (MOF) for the definition of meta-models. Meta-modeling of an adaptation model aims at abstractly representing the semantics dedicated to the representation of a pivot data model associated to the MDM domain. The OMG recommends using UML formalisms to define a meta-model and Object Constraint Language [12] to specify the constraints between its elements. However, these two formalisms are not sufficient and present a limited number of entities for representing models, called Platform Specific Model (PSM), associated with a particular technology. To overcome these limitations, it is possible to specialize the UML metamodel by adding supplemental elements and constraints. This specialization is possible through UML Profiles. To implement our solution, we focus essentially on the M2 layer of the MOF architecture to “meta-model” an adaptation model with UML profiles. 4.2 Meta-models Enrichment Using UML Profiles Our objective is to facilitate and to standardize modeling of adaptation models based on the XML Schema formalism and dedicated to the MDM domain. Up to now, graphical modeling of XML Schema models is not standardized. Tools for modeling

24

L. Menet and M. Lamolle

XML models certainly exist but they are restricted to the semantics of XML Schema. Indeed, these tools are unable to guide the user in using the concepts introduced by adaptation models, and more generally in using specific extensions. Moreover, these modeling tools offer graphical representations differing from one solution to another, which represents a potential source of confusion during modeling phases when different actors may intervene. The introduction of a standard formalism of model definition is a way to standardize and to make modeling more accessible. UML is an object modeling language increasingly used and recognized nowadays as a standard in the domain of software engineering, which makes it an ideal candidate for modeling adaptation models. The specialization of the UML language through profiles is a way of standardizing and making the definition of adaptation models generic. These models being initially defined with XML Schema and dedicated to the Master Data Management domain, we define two UML profiles with the former is dedicated to the semantics of XML Schema, and the latter is applied to the semantics of Master Data Management. 4.2.1 XML Schema Profile UML is an object modeling formalism that defines notions such as generalization, composition and aggregation. Firstly, we introduce meta-data materializing these object specificities in the XML Schema meta-model (noted as name_concept_object_UML on line 3 of Figure 2). The addition of these notions “object” is a first step to homogenizing UML and XML Schema formalisms. To do so, we use extensions mechanisms recommended by XML Schema, i.e., for each meta-knowledge, a description in the form of the following extension: …<xs:annotation>

[1]

<xs:appinfo>

[2]



[3]

…

[4] [5]

Fig. 2. XML Schema extension representing a meta-knowledge object

The addition of these meta-data in adaptation models allows UML object specificities to be included and relations between some concepts highlighted. Beyond our mapping process between XML Schema and UML, these meta-data contribute to optimizing processes such as the factorization of data, tree optimization, and removal of instances that have become useless. After introducing the UML object specificities in the XML Schema meta-model, we can define the corresponding UML profile. The UML extension mechanism enables us to extend its formalism to the semantics of XML Schema. This extension is defined by stereotypes and marked values. The

A Model Driven Engineering Approach Applied to Master Data Management

25

stereotypes are used to define a new type of element from an existing element of the UML meta-model. Marked values are interpreted as attributes of a UML meta-class and allow predefined values to be associated to a stereotype instance. Figure 3 presents an extract of the XML Schema profile that we defined.

Fig. 3. XML Schema6 profile sample

Stereotypes of Figure 3 (named « Stereotype ») inherit respectively from the elements Class, Attribute, Association and Specialization of the UML meta-model. Therefore, each of these stereotypes will be instanced by the meta-model builder in the same way as the elements Class, Attribute, Association or Specialization. Moreover, some marked values can be associated to some stereotypes. They specify keys-to-values pairs to fix a set of existing element properties or defined stereotypes. The definition of these stereotypes allows the introduction of more semantics, exterior to UML, enabling us to represent an XML Schema model with UML diagrams. However, the use of class diagrams imposes the application of restrictions concerning their definition. Indeed, some UML concepts such as operations, interfaces or internal classes, cannot be represented with XML Schema and must therefore be excluded during the definition of an XML Schema model via our UML profile. From this profile, it is possible to define an XML Schema model with a class diagram. The second step of specialization of the UML meta-model consists in defining a profile dedicated to the semantics of Master Data Management. 4.2.2 Master Data Management Profile We build a profile dedicated to Master Data Management relying on the properties defined in our MDM EBX.Platform solution7. Figure 4 presents an extraction of our UML profile representing the MDM meta-model:

6 7

See XML Schema specification for more informations http://www.w3.org/TR/xmlschema-0/ Online documentation available at http://doc.orchestranetworks.com/

26

L. Menet and M. Lamolle

Fig. 4. MDM profile sample

Stereotypes of Figure 4 inherit from meta-classes Class, Attribute, Package and Association of the UML meta-model. The Table stereotype applied to the Class element enables us to indicate that a class must be interpreted as a table in the meaning of DBMS8 and will have the associated properties (primary key, indexation, etc.). The PrimaryKey and AutoIncrement stereotypes applied to an element of type Attribute indicate respectively that an attribute is a primary key or is autoincremented in the meaning of DBMS. The AdaptationModel stereotype applied to an element of type Package indicates that this element represents an adaptation model. The TableRef stereotype specify that an association materializes a “foreign key” constraint in the meaning of DBMS. The Selection stereotype is used to materialize a inversed relation of foreign key between two entities. For example, if we consider that a book is written by an author, which is made explicit by means of a foreign key, the inverse relation (an author wrote some books) is expressed with this stereotype. Through these two profiles, we introduce an abstraction layer enabling us to represent an adaptation model independently of an application domain. 4.2.3 UML Modeling of Adaptation Models In [10], we presented mappings enabling bidirectional transformations between UML and XML Schema to be realized. These mappings take advantage of the elements of the UML and XML Schema meta-models, and are implemented by transformation rules. Our IDM approach allows moving in an automatic manner from an abstract model (UML) to a productive model (XML Schema) interpretable by our MDM EBX.Platform solution. To apply our approach, we have developed a modeling tool that we named ArgoXSD, enabling to define adaptation models by extension of the XML Schema models. The tool us that we have developed is based on the IDE (Integrated Development Environment) ArgoUML [3]. ArgoUML is an open source tool for UML modeling. Based on ArgoUML, we developed a module including the UML profiles previously presented, and the functionalities for importing and exporting from XML Schema models. The import function allows us to generate a UML class diagram from a XML Schema model. The export function enables us to generate the XML Schema code of a class diagram defined with our UML profiles. Figure 5 presents the UML modeling for a simplified train network: 8

DataBase Management System.

A Model Driven Engineering Approach Applied to Master Data Management

27

Fig. 5. Adaptation model defined with a UML class diagram

This diagram is composed of different concepts and relations between them. This example illustrates the relations of association, composition, aggregation, and derived type. We have defined the concept of train as composed of an engine, wheels (notion of composition), that may own cars (notion of aggregation), and having properties such as a type and a trademarks. We associate a driver of Person type to a train. The concept has properties such as name, first name and date of birth represented by a UML base data type. We defined an Email property representing the use of a type of redefined data. The Email class has the SimpleType stereotype enabling us to indicate that it is a redefined type in the XML Schema sense. The properties of this redefined type are contained in a UML annotation specifying values for SimpleType::base, SimpleType::pattern and SimpleType::whitespace. The root of the schema is materialized by the stereotype “Root”, applied to the NetworkTrain class.

5 Conclusion In this paper, we have presented how to introduce a Model Driven Engineering approach to optimize and standardize the definition of data models. The approach that we have used by defining two distinct UML profiles is applicable in a broad sense to all modeling of XML Schema models and can also be applied to the specialized Master Data Management domain. Coupled with transformation methods, the use of our UML profiles enables abstraction of all technical specificities linked to the definition of XML Schema models applied to the MDM to be made. Later in our works, we will tackle problems of incremental validation of models in order to optimize the validation processes during the conception phases. The quality of MDM linked data is an aspect that we have to consider as data quality management

28

L. Menet and M. Lamolle

solutions work even better when they run from a unified data repository, constructed from a joint information model, i.e. from MDM. The task of meta-modeling of this model imposes itself as an essential step both for data quality and for MDM.

References 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.

11. 12. 13. 14. 15. 16. 17.

Altova XMLSpy, http://www.altova.com/xmlspy Abiteboul, S., Cluet, S.: The Xyleme Project. Computer Networks 39 (2002) ArgoUML (2002), http://argouml.tigris.org/ Cattell, R.G.G., Barry, D.: The Object Data Standard: ODMG 3.0. Morgan Kauffman Publishers, San Francisco (1999) Garcia-Molina, H., Papakonstantinou, Y., Quass, D.: The STIMMIS approach to mediation: Data Models and Languages (1995) IBM MDM, http://www-01.ibm.com/software/data/ips/products/masterdata/ iWays Master Data Center, http://www.iwaysoftware.com Iyengar, S., Brodsky, A.: XML Metadata Interchange (XMI) Proposal to the OMG Object Analysis & Design Task. Object Management Group (1998), http://www.omg.org Orchestranetworks, http://www.orchestranetworks.com Menet, L., Lamolle, M.: Towards a Bidirectional Transformation of UML and XML Models. In: Proceedings of the 2008 E-Learning, E- Business, Enterprise Information System and E-Government, EEE 2008, Las Vegas, Nevada, USA, July 14-17 (2008) MOF, MetaObject Facility 2.0 (2006),http://www.omg.org/mof/ OCL. Response to the UML 2.0 OCL.(2006) http://www.omg.org/spec/OCL/2.0/ Oracle MDM suite, http://www.oracle.com/master-data-management/ UML, Unified Modeling Language (2009),http://www.omg.org/spec/UML/2.2/ W3C, EXtendible Markup Language (2000), http://www.w3.org/TR/REC-xml W3C, XML-Schema (2004), http://www.w3.org/TR/xmlschema-1 Garcia-Molina, H., Papakonstantinou, Y., Quass, D.: The STIMMIS approach to mediation: Data Models and Languages (1995)

Managing XML Schema Mappings and Annotations in P2P Data Integration Systems Tadeusz Pankowski and Magdalena Niwi´ nska Institute of Control and Information Engineering, Pozna´ n University of Technology, Poland [email protected]

Abstract. The crucial problem in semantic data integration is creating and maintaining mappings between heterogeneous, independently designed data sources. To deal with the problem we can enrich XML schemas with semantic information from a domain ontology by annotating the schema. In this paper we discuss how the annotation establishing matches between XML schema components and the ontology, and the ontological knowledge itself, can be used to (quasi)automatic creation of mappings between schemas. A special attention is paid to the original concept of conditional annotations which occur in modeling of specialization.

1

Introduction

Schema matching and schema mapping are two crucial steps in developing data integration and data exchange systems, especially when schemas evolve and the data sources are considered in dynamic P2P data integration systems. In this paper we discuss the problem of automatic creation of schema mappings based on matches provided by XML schema annotations into a domain ontology, and on the ontology itself. We identify a class of XML schemas which model specialization, the data modeling abstraction known in conceptual database modeling. The specialization can be disjoint or overlapping. These kinds of specialization can be modeled by variety of XML schemas. To cope with the problem, so called conditional annotations are needed. We formalize the notion of XML schema annotation (conditional and unconditional) and propose a formalism for specifying schema mappings. Based on these notations we propose rules for representing information provided by the annotation in a form of RDFS triples. A pair of sets of RDFS triples (of the source and the target schemas) are then the input to the GenM ap algorithm that generates the mapping between the source and the target schemas. Annotations are commonly used to enrich semantics of XML schemas [2,13]. Schema matching techniques received a great deal of attention and were reported in many papers and surveys ([11,5,7]). Matches create a key input to the creation of schema mappings. A formal foundation of mapping specification for relational data was proposed in [6]. An adaptation of this concept to XML data integration was discussed in [1]. R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 29–38, 2009. c Springer-Verlag Berlin Heidelberg 2009 

30

T. Pankowski and M. Niwi´ nska

In this paper we discuss an approach to manage schema mappings using a domain ontology that is used for annotating XML schemas. The information provided by the mapping, as well as the ontological knowledge, are used to infer mappings for a class of XML schemas. The existence of semantic annotation of schemas can be extensively used for many purposes concerning reorganization of mappings in response to changes in the system. New mappings can be inferred and the consistency of the set of mappings can be checked. The contribution of this paper is the following: (1) we propose and discuss conditional annotation in the context of XML schema integration (the approach is rooted in ideas proposed in [3]), we study XML schema annotation as a way for enriching semantics of XML schemas and a way of organizing and using this knowledge; (2) we design and describe algorithms for creating XML schema mappings using the information provided by the annotation and the ontological knowledge. The paper is organized as follows: In Section 2 we discuss and illustrate by examples the ideas underlying the research in particular the need of conditional annotations. Rules for developing RDFS triples representing the annotation are given in Section 3. The main algorithm for generating XML schema mappings is proposed in Section 4. Section 5 concludes the paper.

2

Ontology-Based XML Schema Matching – Motivating Examples

The idea of using a global domain ontology to support creation of mappings between XML schemas is depicted in Figure 1. This approach is applied in implementation of SixP2P system [4,10,9]. We assume that there is a global domain ontology containing all the information of interest to the user. Each of the sources in a P2P data integration system is understood as a local view over this ontology. The matching between XML schema elements in local sources is defined by the annotation. In Figure 1 there are two XML schema trees, S1 and S2 , located at different peers, and examples of their annotations. We assume that the global domain ontology is defined in OWL Lite [8] and consists of: class names, object property names, datatype property names, and axioms. Simple type names are primitive and user-defined simple types of XSD [12]. In SixP2P we extend the ontology with two additional construct: (1) signatures of value-conversion functions (f ullN , f irstN , and lastN in Figure 1), and (2) definition of composed properties (not shown in Figure 1). In Figure 1 there is an example of unconditional annotation. However, there is often necessity for conditional annotation. Consider the problem of finding a mapping between schemas S3 and S4 (with instances I3 and I4 , respectively) in Figure 2. In both we have information about papers which are divided (specialized) into two classes: conference papers and journal papers. In I3 the type subelement of paper indicates whether the paper element is a conference paper (type = ”c”) or a journal paper (type = ”j”). In I4 , information about conference and journal papers are organized in separate subtrees (cP aper and jP aper,

Managing XML Schema Mappings and Annotations Class Names

ObjectProperty Names

Authors Author Paper Publications Publication Writer Conference …

Contains AuthorOf WrittenBy PresentedAt …

DatatypeProperty Names

31

Simple Type Names

Full Name String First Name UnivName Last Name … Title Axioms Name Author P Writer Organizer Paper P Publication … Author Of P inverseOf(Written By) … Conversion functions Full_Name=fullN(First_Name, Last_Name) First_Name=firstN(Full_Name) Last_Name=lastN(Full_Name) … S2: pubs

S1: authors author* name

pub* title year

paper* year

title

conf writer*

fName

conf

name org

lName

name org

Fig. 1. Unconditional annotation of XML schema trees S1 and S2 with terms from a global domain ontology

S3:

pub

S4:

paper id

type

cPaper title+

type "c"

num plTitle? enTitle? num plTitle?

pub paper title

enTitle?

title

lan titleNat lan "en" "ent1" "pl"

bib

I4:

paper id "1"

jPaper

titleNat

lan I 3:

bib

id "2" titleNat "plt1"

type "j"

cPaper title

num plTitle "a" "plt1"

jPaper

enTitle num "ent1" "b"

enTitle "ent2"

lan titleNat "en" "ent2"

Fig. 2. Sample XML schemas and their instances

respectively). A paper can have the title written in many languages. In I3 the value of lan child of title indicates the language (”pl” for Polish and ”en” for English), and titleN at stores the title in this language. In S4 there is a separate element (i.e. plT itle and enT itle) for the title written in the corresponding language. Papers in S3 are identified by integer values of id while in S4 by character strings being values of the num element. In Figure 3 there are annotations of S3 and S4 . Note that annotations of S3 are conditional. The paper label is unconditionally annotated with the class

32

T. Pankowski and M. Niwi´ nska Paper

S3:

ConfPaper JournalPaper type="c" S4:

pub

type="j"

paper id

type

jPaper

num plTitle? enTitle? num plTitle?

title+ lan

cPaper

bib

enTitle?

titleNat Title lan="pl" Title_in_Polish Title_in_English lan="en"

Fig. 3. Annotation of schemas S3 and S4

name P aper, and additionally may have many conditional annotations (e.g. Conf P aper under the condition type = ”c”). The paper element models disjoint specialization, since Conf P aper and JournalP aper are names of disjoint classes. The title element in S3 models overlapping specialization, since a title can belong to many subclasses of the class T itle, e.g. to T itle in P olish, T itle in English, etc. A national representation of the title is stored in separate instance of the tree rooted in title (in I3 ) or within the same instance of the subtree cP aper (or jP aper) (in I4 ).

3

Generating RDFS Triples from Schema Annotation

An XML schema can be defined by DTD (Document Type Definition or by XSD (XML Schema Definition) proposed by W3C [12]. In this paper, we assume that attributes are represented by so called terminal elements labeled with terminal labels and having simple types. Simple types are primitive types (e.g. xsd:string or simple user-defined types, e.g. titleType). Let Lab be a set of non-terminal labels, Ter be a set of terminal labels, Lab ∩ Ter = ∅, and root ∈ Lab be a root label. Let STypes be a set of simple type names. Definition 1. A tuple S = (root, Lab, Ter , STypes, ρ) is an XML schema, where ρ is a function assigning regular expressions over Lab − {root} ∪ Ter to nonterminal labels, and simple type names to terminal labels, i.e. – ρ : Lab → Reg, – ρ : Ter → STypes, – the set Reg of regular expressions is defined by the grammar: e ::= A | l | e? | e∗ | e+ | e, e | e + e, where l ∈ Lab − {r}, A ∈ Ter .

Managing XML Schema Mappings and Annotations

33

An XML schema can be annotated in a domain ontology O. We will use names of three OWL categories: classes, objectP roperties, and datatypeP roperties. The following rules are obeyed: – Non-terminal labels are annotated with OWL class names; the annotation may be constrained by a simple condition of the form: A = const or A = const, built out from a terminal label going out from the annotated label and a constant const. – Edges between two non-terminal labels are annotated with OWL object property names, where the predecessor is the domain and the successor – the range of the property. – Edges between non-terminal and terminal labels are annotated with OWL datatype property names, where the domain is a non-terminal label and the range is a terminal label. Let S be an XML schema, CN ames, OP N ames and DT P N ames be sets of, respectively, class names, object property names and datatype property names in O. Definition 2. A (conditional) annotation of S with ontology O is a tuple AS,O = (Cond, {λα }α∈Cond ), where: (1) Cond is a set of simple conditions over S, (TRUE ∈ Cond), (2) λα is a conditionally annotating function (λTRUE is referred to as the unconditional annotation) i.e.: – λα : Lab → CN ames, – λTRUE : Lab × Lab → OP N ames, – λTRUE : Lab × Ter → DT P N ames. For Lab = {l1 , ..., lN }, let Cond(li ) be a set of conditions for annotating li , 1 ≤ i ≤ N . Then σ = (σ[l1 ], ..., σ[lN ]) consisting of single conditions (possibly TRUE) for any label, is called conditional tuple. Let σ be a conditional tuple. By TS (σ) we will denote the set of all RDFS triples created by means of rules given in Figure 4. The sets TS1 and TS2 of RDFS triples in Figure 5 are produced by means of rules in Figure 4 for schemas S1 and S2 from Figure 1. For annotation of S3 we have: (1) paper is annotated with disjoint classes, and Cond(paper) = {type = ”c”, type = ”j”}; (2) title is annotated with overlapping classes, and Cond(title) = {lan = ”pl”, lan = ”en”}. In general, if there are N conditionally annotated non-terminal labels l1 , ..., lN in a schema S, and the set Cond(li ) contains ki conditions, then the number of all unconditional annotations is K=

N 

ki .

i=1

Thus, there are four sets of triples, TS3 (α, β), derived from annotation of S3 , where α ∈ Cond(paper), and β ∈ Cond(title). For example, first of them can be:

34

T. Pankowski and M. Niwi´ nska

TS3 (type = ”c”, lan = ”pl”) : (1) {(P ublications, Contains, Conf P aper) (T 1) (2) (Conf P aper, P aperId, String) (T 3) (3) (Conf P aper, P aperT ype, ”c”), (T 4) (4) (Conf P aper, T itleInP olish, T itle in P olish), (T 2) (5) (T itle in P olish, LanguageOf T itle, ”pl”), (T 4) (6) (T itle in P olish, V alue, String), (T 3) (7) (Conf P aper, T itle in P olish, String) (T 5)} (T1) (Root, R, C) ∈ TS (σ), if λσ[root](root) = Root and ∃l ∈ Lab (λTRUE (root, l) = R and λσ[l] (l) = C); (T2) (C, R, C  ) ∈ TS (σ), if ∃( , , C) ∈ TS (σ) and ∃l, l ∈ Lab (λσ[l] (l) = C and λσ[l ] (l ) = C  and λTRUE (l, l ) = R); (T3) (C, D, t) ∈ TS (σ), if (C = Root or ∃( , , C) ∈ TS (σ)) and ∃l ∈ Lab, A ∈ Ter (λσ[l] (l) = C and λTRUE (l, A) = D and ρ(A) = t); (T4) (C, D, ”a”) ∈ TS (σ), if (C = Root or ∃( , , C) ∈ TS (σ)) and ∃l ∈ Lab, A ∈ Ter , A = ”a” ∈ σ[l] (λσ[l] (l) = C and λTRUE (l, A) = D); (T5) (C, D, t) ∈ TS (σ), if (C, R, C  ) ∈ TS (σ) and (C  , D , t) ∈ TS (σ) and D = R ◦ D ∈ O. Fig. 4. Rules deriving the set of RDFS triples from an annotated XML schema TS1 : (Authors, Contains, Author) (Author, F ull N ame, String) (Author, AuthorOf, P aper) (P aper, T itle, String) (P aper, Y ear, String) (P aper, P resentedAt, Conf erence) (Conf erence, N ame, String) (Conf erence, Organizer, String)

TS2 : (P ublications, Contains, P ublication) (P ublication, T itle, String) (P ublication, Y ear, String) (P ublication, W rittenBy, W riter) (W riter, F irst N ame, String) (W riter, Last N ame, String) (P ublication, P resentedAt, Conf erence) (Conf erence, N ame, String) (Conf erence, Organizer, String)

Fig. 5. RDFS triples derived from unconditional annotation of S1 and S2

Along with the triples, we write identifiers of the inferring rules, (T 1) − (T 5). The triple (7) can be derived in force of (T 5) if in ontology O the datatype property T itle in P olish is defined as the composition of the object property T itleInP olish and the datatype property V alue, i.e. T itle in P olish = T itleInP olish ◦ V alue ∈ O.

4 4.1

Generating Schema Mappings from Annotations and Ontology Tree Pattern-Based XML Schema Mappings

A schema mapping is a specification describing how data structured under a source schema is to be transformed into data structured according to a target

Managing XML Schema Mappings and Annotations

35

schema. To define such transformation we will use tree patterns (TPs) and treepattern formulas (TPFs) [1,10]. In fact, both TPs and TPFs are formulas in XPath so their standard semantics is precisely defined. We will say that a tree-pattern formula φ(u1 , ..., un ), where ui is a variable or a constant, is defined over XML schema S, if defines a subtree or a set of subtrees conforming to S. Mappings will be written in the datalog-like style. Definition 3. A schema mapping (or mapping) MS,T from a source XML schema S to a target XML schema T is a set of mapping rules, where a mapping rule is an expression of the form: ψ(u) :−[¬]φ1 (u1 ), [¬]φ2 (u1 ), ..., [¬]φk (uk ), χ(u1 , u2 , ..., uk ), where: – ψ(u), and φi (ui ) are TPFs over T and S, respectively, 1 ≤ i ≤ k, k ≥ 0; – var(u) ⊆ var(u1 )∪, ... ∪ var(uk ) – each variable occurring in u must occur in at least one of u1 , ..., uk ; – χ(u1 , u2 , ..., uk ) is a conjunction of atomic formulas over variables and constants, – the comma sign (,) between formulas denotes conjunction. Example 1. The mapping from S3 to S4 (Figure 2) includes among others the following two mapping rules: m1S3 ,S4 : bib[cP aper[num = f unN um(x1 ), plT itle = x2 , enT itle = x3 ]] :− pub[paper[id = x1 , type = ”c”, title[lan = ”pl”, titleN at = x2 ]], pub[paper[id = x1 , type = ”c”, title[lan = ”en”, titleN at = x3 ]] m2S3 ,S4 : bib[cP aper[num = f unN um(x1 ), plT itle = x2 , enT itle = x3 ]] :− pub[paper[id = x1 , type = ”c”, title[lan = ”pl”, titleN at = x2 ]], ¬pub[paper[id = x1 , type = ”c”, title[lan = ”en”]], x3 = ⊥ Function f unN um(x1 ) in heads of the rules converts value of x1 into the value of the type assigned to num. In the second rule, it is tested whether the conference paper has the title written in English, if not then the null (⊥) value is assigned to enT itle in the target instance. Semantics of a mapping is defined as the union of all sets of tuples of values produced by mapping rules constituting the mapping [10]. 4.2

Mapping Generating Algorithm

The following algorithm generates a mapping between two unconditionally annotated schemas S and T . Algorithm 1. (Generating a mapping, GenM ap(TS , TT )) Input: TS – a set of RDFS triples for a source schema S, TT – a set of RDFS triples for a target schema T , functions λS and λT annotating S and T in O. Output: A mapping MS,T , initially empty.

36

T. Pankowski and M. Niwi´ nska

(1) If all triples in TT are resolved then return MS,T and stop, otherwise go to step (2). (2) If all terminal triples in TT are resolved then go to step (3), otherwise get the first not resolved terminal triple and denote it τ . Mark τ as resolved. (2.1) if τ = (C, D, t), where C = λT (l) and D = λT (l, A), and t is a type, then (2.1.1) if (C  , D , t ) ∈ TS , C  = λS (l ) C and D = λS (l , A ) D then m := l[A = u] :−l [A = u], where u if a variable name if t is a type equal to t, and a constant ”a” if t is ”a”; (2.1.2) else if (C  , D1 , t1 ), . . . , (C  , Dn , tn ) ∈ TS , where C  = λS (l ) C and λS (l , A1 ) = D1 , . . . λS (l , An ) = Dn , D = f (D1 , . . . , Dn ) ∈ O then m := l[A = f (u1 , . . . , un )] :−l [A1 = u1 , . . . , An = un ], where ui is as was explained in (2.1.1); (2.1.3) else go to step (2); insert m into MST and go to step (2). (2.2) if τ = (C, D, ”a”), where C = λT (l) and D = λT (l, A), then m := l[A = ”a”] :−TRUE, insert m into MST and go to step (2). (3) If all elements in MS,T have been processed then go to step (1), otherwise: (3.1) if m1 = l[ψ1 ] :−l [φ1 ] ∈ MS,T and m2 = l[ψ2 ] :−l [φ2 ] ∈ MS,T then m := l[ψ1 , ψ2 ] :−l [φ1 , φ2 ]; (3.2) else if m1 = l[ψ] :−l [φ] ∈ MS,T and (C1 , R , C  ) ∈ TS and (C1 , R, C) ∈ TT and R = λS (l1 , l ) R = λT (l1 , l) ∈ O then m = l1 [l[ψ]] :−l1 [l [φ]]; (3.3) else if m1 = l1 [ψ1 ] :−l1 [φ1 ] ∈ MS,T , m2 = l2 [ψ2 ] :−l2 [φ2 ] ∈ MS,T and (C1 , R , C  ) ∈ TS and (C1 , R, C) ∈ TT and R = λS (l1 , l2 ) and R = λT (l1 , l2 ) and R insertOf (R) ∈ O then m := l1 [ψ1 , l2 [ψ2 ]] :−l2 [φ2 , l1 [φ1 ]]. (3.4) else if m1 = l[ψ] :−l [φ] ∈ MS,T and λT (l1 , l) = ”Contains” ∈ O m := l1 [l[ψ]] :−l [φ]. (3.5) else if m1 := l[ψ] :−l [φ] ∈ MS,T and λS (l1 , l ) = ”Contains” ∈ O m := l[ψ] :−l1 [l [φ]]. (3.6) else if m1 = l[ψ1 ] :−φ1 ∈ MS,T and m2 := l[ψ2 ] :−φ2 ∈ MS,T then m := l[ψ1 , ψ2 ] :−φ1 , φ2 ; insert m to MS,T , remove m1 or also m2 from MS,T , go to step (3). Let S be a conditionally annotated schema and AS,O = (Cond, {λα }α∈Cond) be an annotation of S, and T be a schema annotated unconditionally, i.e. AT,O = (λ). Then: 1. For any selection of conditions σ = (α1 , ..., αn ), αi ∈ Cond(li ), the set TS (σ) N of RDFS triples for the σ-selection of S is produced. There are i=1 mi such selections, where mi = count(Cond(li )). 2. The set TT of RDFS triples for T is computed.

Managing XML Schema Mappings and Annotations

37

3. The algorithm GenM ap(TS (σ), TT ) is used to generate N mapping rules from S to T . 4. The mapping rules are used to create the final mapping MS,T . The final mapping depends on the kinds of specializations determined by classes assigned to labels of S by the conditional annotations. We will define the mapping for the case when two labels in S are conditionally annotated: one label (say l1 ) defines a disjoint, and the other (say l2 ) an overlapping specialization. Let: Cond(l1 ) = {α1 , α2 }, Cond(l2 ) = {β1 , β2 }, and – mS,T (α, β) := ψα,β :−φα,β , where α ∈ Cond(l1 ), β ∈ Cond(l2 ), and mS,T (α, β) = GenM ap(TS (α, β), TT ). Then

MS,T = {ψα1 ,β1 ,β2 :− φα1 ,β1 , φα1 ,β2 , ψα1 ,β1 ,β2 :− φα1 ,β1 , ¬φα1 ,β2 , xβ2 ψα1 ,β1 ,β2 :− ¬φα1 ,β1 , φα1 ,β2 , xβ1 ψα2 ,β1 ,β2 :− φα2 ,β1 , φα2 ,β2 , ψα2 ,β1 ,β2 :− φα2 ,β1 , ¬φα2 ,β2 , xβ2 ψα2 ,β1 ,β2 :− ¬φα2 ,β1 , φα2 ,β2 , xβ1

= ⊥, = ⊥, = ⊥, = ⊥}

Every mapping rule involves one condition used in the annotation with a class name from a disjoint specialization, and all conditions applied in annotations with class names from an overlapping specialization. At least one component in the body is positive (indicating that an object can be specialized in at least one from all overlapping classes), and the rest can be negative (a negative component indicates that the corresponding class might not contain the object). If φα,β is negative and β corresponds to an overlapping specialization, then the conjunct xβ = ⊥ is added to the body. If β is of the form A = ”a”, then xβ is the variable associated with the path ending with A. The mapping from S3 to S4 considered in Example 1, consists of six mapping rules, i.e.: MS3 ,S4 = {m1S3 ,S4 , m2S3 ,S4 , m3S3 ,S4 , m4S3 ,S4 , m5S3 ,S4 , m6S3 ,S4 }. Two first of them were given in Example 1, and the third is: m3S3 ,S4 = bib[cP aper[num = f unN um(x1 ), plT itle = x2 , enT itle = x3 ]] :− ¬pub[paper[id = x1 , type = ”c”, [title[lan = ”pl”]]]], x2 = ⊥, pub[paper[id = x1 , type = ”c”, [title[lan = ”en”, titleN at = x3 ]]]] ··· In the similar way the remainder three mapping rules corresponding to the condition type = ”j” can be created. The mapping rules can be implemented by translating into XQuery programs. Such the translation was proposed, for example, in our previous papers [4,10].

5

Conclusion

In the paper we propose a method for managing XML schema mappings and annotations in data integration systems. The method is of special importance

38

T. Pankowski and M. Niwi´ nska

when the integration involves P2P connected sources and new peers can enter the system with new schemas and old schemas can evolve. We identified an important class of XML schemas for which a conditional annotation is necessary. We discussed constructs in a domain ontology which are needed to annotation of XML schemas in the context of data integration. Next, we used the ontological knowledge and the matches between schema components and terms in the ontology to derive conditional matches between schemas. The conditional and unconditional schema matches are the base for automatic generation of schema mappings. Acknowledgement. The work was supported in part by the Polish Ministry of Science and Higher Education under Grant 3695/B/T02/2009/36.

References 1. Arenas, M., Libkin, L.: XML Data Exchange: Consistency and Query Answering. In: PODS Conference, pp. 13–24 (2005) 2. Beneventano, D., Bergamaschi, S.: The MOMIS methodology for integrating heterogeneous data sources. IFIP Congress Topical Sessions, 19–24 (2004) 3. Bohannon, P., Elnahrawy, E., Fan, W., Flaster, M.: Putting Context into Schema Matching. In: Proc. of the 32nd International Conference on Very Large Data Bases, Seoul, Korea, pp. 307–318. ACM, New York (2006) 4. Brzykcy, G., Bartoszek, J., Pankowski, T.: Schema Mappings and Agents Actions in P2P Data Integration System. Journal of Universal Computer Science 14(7), 1048–1060 (2008) 5. Doan, A., Halevy, A.Y.: Semantic Integration Research in the Database Community: A Brief Survey. AI Magazine 26(1), 83–94 (2005) 6. Fagin, R., Kolaitis, P.G., Popa, L., Tan, W.C.: Composing Schema Mappings: Second-Order Dependencies to the Rescue. In: PODS, pp. 83–94 (2004) 7. Madhavan, J., Bernstein, P.A., Doan, A., Halevy, A.Y.: Corpus-based Schema Matching. In: Proceedings of the 21st International Conference on Data Engineering, ICDE, pp. 57–68. IEEE Computer Society, Los Alamitos (2005) 8. OWL Web Ontology Language Overview (2004), http://www.w3.org/TR/owl-ref 9. Pankowski, T.: Query propagation in a P2P data integration system in the presence of schema constraints. In: Hameurlain, A. (ed.) Globe 2008. LNCS, vol. 5187, pp. 46–57. Springer, Heidelberg (2008) 10. Pankowski, T.: XML data integration in SixP2P – a theoretical framework. In: EDBT Workshop Data Management in P2P Systems (DAMAP 2008), pp. 11–18. ACM Digital Library, New York (2008) 11. Rahm, E., Bernstein, P.A.: A survey of approaches to automatic schema matching. The VLDB Journal 10(4), 334–350 (2001) 12. W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes (2009), www.w3.org/TR/xmlschema11-2 13. Xiao, H., Cruz, I.F.: Integrating and Exchanging XML Data Using Ontologies. In: Spaccapietra, S., Aberer, K., Cudr´e-Mauroux, P. (eds.) Journal on Data Semantics VI. LNCS, vol. 4090, pp. 67–89. Springer, Heidelberg (2006)

Managing Large, Structured, and Annotated Documents: A Study of Three Operational Cases in the Field of Environmental Legislation Michel Treins, Carine Louvion, and Jacques Vaudelin INERIS, French National Institute for Industrial environment and Risks. Verneuil-en-halatte, France [email protected], [email protected], [email protected]

Abstract. Managing legal documents, in the specific context of European environmental legislation, raise specific problems like internationalization and version management of the contents and metadata, and the need to perform tasks as consolidation, annotation, and description of the contents, at the scale of elementary fragment (article or chapter), instead of the whole document. Current standards as METS, or more specialized formats like HL7 / CDA, are not well adapted to answer these specific problems. In this paper, we present a new data model and an innovative structure of document, based on the “object” concept of descriptor. This development is now fully operational, and serves three important knowledge bases totalizing more than 11 millions of requests during the past year. Keywords: Document management, life-cycle management, METS, CDA, HL7, environment, legislation, container, descriptor.

1 Introduction Legal documents (laws, decrees, circulars…) have specific characteristics which notably impact on their management and their storage within computerized information systems. The French national institute for industrial environment and risks (INERIS) plays a leading role in the assessment and prevention of technological and environmental risks in France and in Europe. One of the activities of the institute is the analysis and the periodic review of the legislation of the domain. Consolidated and annotated legal documents, collected in bases of knowledge, are made available on Internet to a large number of simultaneous users. In consequence, the constraints of keeping the availability, the consistency, the integrity of the documents and all their components, managing their complete life cycle, and their storage in relational databases, have to be handled. This paper presents the “document container” and the data models we developed to face these constraints. Our challenge was to make a simple, scalable, “object oriented” R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 39–48, 2009. © Springer-Verlag Berlin Heidelberg 2009

40

M. Treins, C. Louvion, and J. Vaudelin

model, interoperable with others documentary standards, and easily implementable in usual relational databases management systems. We took back some of the innovations brought by the HL7 / CDA [2][3] data model, in the medical domain, and by the “Metadata Encoding and Transmission Standard” (METS) [4], by simplifying them, and by bringing an important headway: the concept of "descriptor". In the sixth section, we present briefly the results of the implementation in three operational knowledge bases, published on Internet, equipped with powerful research functions, totalizing millions of requests during the past year. In conclusion, we stress future evolution of the model, notably the capability of XML serialization and exportation, complying with documentary standards as METS or DocBook[5].

2 Characteristics of Legal Documents A legal document (for example, a law) is a complete and inseparable entity: a persistent content established by an act of publication, fixed to a material support, bounded temporarily and spatially [6], tied to a specific context, having a robust logical structure [1], and referenced as a unique object. Usually, legal documents are constituted by a large and nested hierarchy of fragments, henceforth called “sections”: Titles, Chapters, Articles, and Paragraphs… This generic structure can sometimes present local variations. However, every section within a single document can deal with varied subjects and concepts, sometimes with no semantic link between them. In many cases, during years, the successive amendments of the text will entail the abrogation of several articles and their replacement by new versions. In consequence, the version of the whole document may be not equal to the version of its own sections. In addition, an amendment to a legal text is necessarily a legal text, too! These documents, in their different versions, are tied together by a semantic link, and create a “solidarity of documents” [8], within which the reader, especially the jurist, may browse hypertextually. Thus, because of these specificities, usual tasks as version management, consolidation, annotation, creation of relationships between parts (within the same document, or between different documents), and description of the contents (metadata, keywords…) must be done on the scale of the section, and not (only) on the whole document. All contributors, roles and organizations involved in the stewardship of the document and/or sections may be identified and authenticated. To face these constraints, it was important to use a robust container, having the ability: − − −

To embed all the different “expressions” of the content (e.g. internationalization), and how to read, play, or consult them. To describe the structure of the document and how the different fragments are organized and linked together. To describe the concepts pertained to the content (“what we are talking about?”) and in which fragment they are contained (“where do we talk about it?”)

Managing Large, Structured, and Annotated Documents

− −

41

To describe the semantic links between fragments or between a fragment and other objects: another document, or an external URI… To record information about life-cycle management, and administrative metadata.

We focused our study on the data models of two documentary standards: HL7 / Clinical Document Architecture (CDA) and Metadata Encoding and Transmission Standard (METS).

3 HL7 / RIM and « Clinical Document Architecture » The HL7 (Health Level 7) initiative plays a predominant role in the standardization and normalization of healthcare information systems. Among its standards, HL7 proposes the CDA (Clinical Document Architecture) which proposes the structure and the semantics of clinical documents for the purpose of exchange between health care actors. The second release of the CDA specifications became an American National Standards Institute (ANSI) approved standard in May 2005. CDA is based on a formal “Reference Information Model” (RIM). A CDA document has a header and a body. The header identifies and qualifies the document, and provides information on various participants, such as author, authenticator, encounter participants, informants, information recipients, and so on… The body contains the clinical report and can be either an unstructured blob, or can be composed by a nested hierarchy of sections, each of them containing several attributes, one “narrative” block, and a variable number of “entries”, which represent the coded semantics of medical statements: encounters, acts, observations, procedures, substance administrations, supplies, etc. A CDA document may include texts, pictures and all kind of multimedia contents. It can refer to external documents, procedures, observations, and acts. However, this structure presents several inconveniences which prevent its usage for our particular need: − − − −

A data model specifically oriented towards healthcare information management. This model is too specialized to be easily applicable to other domains. Only one “narrative” (human readable) block per section: no possibility to have simultaneously the same text in several languages. A “one level”, “flat” (non-recursive) concept of “Entries”, whose abstraction need to be improved, as we propose it in this document with our concept of “descriptor”. A lack of structural description of the document. A CDA document is not described by an explicit “structural map”. The logical structure is implicitly contained in the nested serialized hierarchy of XML nodes. In consequence, life cycle management of the document is done on the scale of the whole structure, and not on the scale of its elementary components.

42

M. Treins, C. Louvion, and J. Vaudelin

4 Metadata Encoding and Transmission Standard (METS) Metadata Encoding and Transmission Standard is a XML schema developed on the initiative of the Digital Library Federation (DLF), providing an encoding format for descriptive, administrative and structural metadata for textual and image-based electronic documents. METS is currently maintained by the US Library of Congress. A METS document describes a numeric objet, and is structured in seven sections, which may contain one or several sets of metadata [7]. Both fist ones are mandatory: − FileSection: list of numeric files constituting the object. − StructuralMap: presents the physical and/or logical structure of the object. The five others are optional and repeatable: − Header: metadata describing the METS document itself. − Descriptive Metadata: embedded or external descriptive metadata of the object. Multiple instances of both external and internal descriptive metadata may exist. − Administrative Metadata: information about authors, contributors, intellectual property rights, date of publication, revision, and so on. Administrative metadata may be encoded internally or external to the METS document. − Structural links: hyperlinks between elements of the structural map. − Behavior: association of a part of the content with executable code. METS allows a fine description of the physical and logical structure of the document, and of all of its contents. Each section of metadata is identified by a unique identifier, which can be used in the structural map to link a particular fragment of the document to a particular section of descriptive or administrative metadata. However, the fragments of document hierarchy, and the metadata pertained to them, are not considered as real objects, which may be specialized, aggregated, composed, especially in a recursive manner. This fact makes difficult certain operations on the document when the contents have multiple expressions, as well as the descriptions associated with these contents. We may take the example of a European legal directive. Although translated in 27 different languages, it remains the same document. All metadata (keywords, title, summary, date of publication, subject…) apply indifferently to all versions of the document. Furthermore, textual metadata may be expressed in several languages or by a formula (mathematics, chemistry…). They may be described recursively by others metadata (metadata of metadata…). Such a description is possible with METS, but remains rather heavy to implement.

5 A New Model of Document Container Because of these specific constraints, we decided to develop a new model of document container which would combine the advantages of the two formats. From

Managing Large, Structured, and Annotated Documents

43

HL7 – CDA, we kept the concept of a document’s body constituted by a nested hierarchy of sections. From METS, we kept the idea of the structural map. In our model, a document is composed by a header, a structural map, and a variable number of sections. Header and sections have their own small set of encoded attributes, necessary for managing the component’s identification, the confidentiality level, the context, and the lifecycle management (new versions, obsolescence…). Mechanisms of inheritance are implanted, so that contextual values can propagate from high level of hierarchy to the nested components. Descriptors are class of attributes which apply to documents, to sections, or to descriptors themselves, by a relation of aggregation. The application’s field of descriptors also extends to thesauri. Descriptors can be repeated, specialized, aggregated as needed. A descriptor is much more than a simple metadata. Descriptors contain the data, or the references to external data, whatever they are (texts, images, sounds, or any multimedia content, expressed in various encoding formats), AND the metadata associated to these data. For advanced management functions, metadata, which can be notably structured and complex, may be themselves described by others descriptors, without limit in the depth of this recursive schema. There are several types of descriptors: − The "narrative" descriptors, which contain the textual information of sections. These texts can be expressed in different languages, and according to different characters’ codes and styles. − “Metadata” and “Keywords” descriptors, which describe metadata used to qualify a document or a section: value of metadata, formalism (e.g. Dublin Core), reference to a specific taxonomy, etc. − “Annotations” descriptors, which contain notes on the document or the section, and the description of the semantic associations[8] which can exist between documents, sections, and/or external resources. Annotations are defined [9] as “particular notes attached to a target by an anchor”. Thus the target can be a section, a document, or another descriptor. Annotations may contribute to the content of the component itself [10][11] (for example, a comment or an explanation), or may rise the attention of the reader on a particular fact or information within the document [11]. Annotations are characterized by a “verb of action”, which expresses the semantic of the link established between the note and the target. The “note”, which is the heart of an annotation, is nothing less than a document [12]: as such, it can be constituted of nested sections, and may be described by a set of descriptors… − “Anchor” descriptors. This specific tagging allows identifying exactly the portion of text on which is attached the annotation. − “External reference”, which is a link towards an external element, described with sufficient level of formalism to permit semantic sharing. − “RenderMultimedia” (another “loan” of HL7 / CDA) which reference external multimedia content which is integral to the document, and must be rendered with the document. RenderMultimedia can reference a single ObservationMedia or one or more RegionOfInterests…

44

M. Treins, C. Louvion, and J. Vaudelin

− “Structural Map”: The nested hierarchy of sections is a kind of description of the document. For this reason, the structural map is a descriptor, too. Headers, sections, and descriptors (and their successive versions) are all “embedded” in the structure, and are not included in a separate notice.

6 Information Model Here is an extract of the diagram of class.

Fig. 1. Static view of the class diagram

6.1 Document / Section Relation The collection of texts to be set up contains essentially legal texts. The study of this repository put in evidence the logical organization of texts. A lot of them consist of a succession of titles, ordered in chapters divided themselves into articles. Texts are structured according to a hierarchical set of sections. A document consists of one or several sections. We made the choice to represent this structure with entities “Document” and “Section”. The class “Document” contains only one attribute ("Title") and the specific metadata needed for the management of the different versions of the document. “Document” is a virtual class and need to be

Managing Large, Structured, and Annotated Documents

45

specialized in several categories. “Text” represents the class of the corpus that we study. The class” Comment” represents a specific type of annotation. The sight presented here is incomplete because the virtual class “Document” can be specialized in various types such as “Images”, “Videos” … The representation of the internal structure of the document is symbolized by the class “Section”. This one contains a recursive relation which allows the management of the hierarchy of sections between them. The class Section is only constituted of information of versions.

Fig. 2. Part of the class diagram "descriptor"

6.2 Document – Section / Descriptor Relation The originality of this model is the class “Descriptor”. This class offers a very big flexibility, by allowing the description of all properties of any component (a document, a section, or another descriptor). There is virtually no limit for the different types of descriptors. A component, at instance level and not only at a class level, may be described by the exact number of instances of various classes of descriptors. If the descriptor exist, it is always relevant.

46

M. Treins, C. Louvion, and J. Vaudelin

The “Section” does not have any textual attribute. The narrative part is described by the eponymic specialization of the descriptor. Therefore, the management of the internationalization of the section is taken into account. In our application, the text can be presented in French or in English. Metadata may be coded in various formats, as Dublin Core, ISO 19115 [13], EXIF [14] (for the images)… Different instances of the “Metadata” class have been used: title, date of publication, editor (in our application – see below - the “official bulletin”), author, temporal extension… Document and section are also described by a set of keywords, coded and referenced in a thesaurus. This thesaurus is composed itself by a set of “narrative” descriptors, answering the same need of internationalization than the content of sections. 6.3 Annotation Relation The “Annotation” class qualifies, at semantic level, the associations between two references (for example, a “Text”, which represents the target, and a “Comment”, which is the note). The relation is characterized by a “verb of action” (“Is explained by”, “Is referenced by”, “Is overruled by”…). The target is a document or a section. The note is a document, a section, or an external URI.

7 Technical Implementation An important issue was the ability of the model to be implemented in a standard, operational, traditional web application, accessible by a very large number of simultaneous users over Internet. Too many systems, so clever and so innovative on the paper, are incapable to cross the threshold of the model, even the prototype, while our purpose was to develop several knowledge bases on environmental legislation, serving millions of requests a year. A Relational DataBase Management System (PostGre-SQL) was chosen for the technical implementation. Indeed, object-oriented databases and natively XML databases are attractive, but they encounter performances limitations and stability problems and remain quartered in niche markets. At the opposite, relational databases offer many advantages, especially in terms of integrity, safety, security, ability to treat large volume of information, handling complex and imbricated requests, and support of the major features of the standard SQL 2004, and ACID transactions (Atomicity, Consistency, Isolation, and Durability). However, flattening an object-oriented model in an relational model which ignores inheritance raised a lot of problems. We had to create tables for every specialization of our virtual classes. This method offered the best flexibility without using too many empty attributes. Based on this architecture, an operational application was developed, in the early 2008, as a java “REST” Web-Service within the X86 / Linux - virtualized infrastructure of the institute. This component serves three Web client applications,

Managing Large, Structured, and Annotated Documents

47

developed in Java (the first one), and in PHP (the two others), in the field of environmental legislation: − REACH-INFO (http://www.ineris.fr/reach-info). REACH is the Regulation for Registration, Evaluation, Authorization and Restriction of Chemicals. It entered into force on 1st June 2007 to streamline and improve the former legislative framework on chemicals of the European Union (EU). The text of REACH is complex; it concerns various categories of industries. National Helpdesk is an information department on REACH, whose mission is to guide companies on the text of REACH, helping them to conform to their obligations. − AIDA (http://www.ineris.fr/aida). AIDA supplies a selection of European legal texts (regulations, directives, decisions, recommendations, notices), published in the official bulletins, and relative to facilities presenting technological risks. − RGIE (http://www.ineris.fr/rgie). This site gives information on legislation relative to extractive industries: mines, careers… The knowledge base server is also indexed and used by a well-known commercial search engine, which builds its index by taking advantage of the specificities of the model (descriptors, metadata, annotations…), and provide more relevant results to user searches. During year 2008, more than 1.3 millions distinct sessions were counted for these applications, totalizing almost 11 millions of documents requests, and 1.3 Terabytes exchanged, without any problem, and with good performances, sustainability, and fault tolerance.

8 Conclusion We can ask ourselves on the interest of developing a new model of document – one more – while various standards already exist in this domain. Nevertheless, our model has no vocation to describe a new concept of representation of information, neither a new format of metadata, nor a new type of electronic book. Our model simply implements a “numeric envelope”, an electronic container having the ability to record and exchange various contents, in all their different expressions and versions. In this particular field, the normative initiative is not so dynamic, nor so advanced. Furthermore, the proposed formats, like METS or HL7/CDA, are often expressed in XML, even when natively XML database management systems have not yet the maturity of their relational counterparts. Usually, the actual standards are dumb on the problems of internal implementation, leaving these points with the discretion of developers or software editors. For these reasons, we were brought to develop a robust system, based on a very simple “object-oriented” model, capable of a real industrialization. Recently, a fourth application was added to the three first ones, proving the scalability, the extensibility, and the potential of this architecture.

48

M. Treins, C. Louvion, and J. Vaudelin

However, some issues remain to be handled in the next months: − Ability to export to and import from XML documentary standards, as METS (container for transfer and exchange), or DocBook (for contents themselves). − Ability of express the “anchor descriptor” in RDF/A, wrapped into the HTML code which usually compose the “narrative” part of the text.

References 1. Pedauque, R.: Document: Form, Sign and Medium, as reformulated for electronic documents. In: Working paper. STIC - CNRS 2003 (2003) 2. CDA, HL7 Clinical Document Architecture - Release 2.0, Committee Ballot. ANSI Standard, Health Level Seven, Ann Arbor, MI, USA (2005) 3. Dolin, R.H., Alschuler, L., Boyer, S., Beebe, C., Behlen, F.M., Biron, P.V., Shabo, A.: HL7 Clinical Document Architecture, release 2. Journal of the American Medical Informatics Association 13(1) (January,Febuary 2006) 4. Cantara, L.: METS: the encoding and transfer Standard. Cataloging & Classification Quarterly 40(3-4), 237–253 (2005) 5. DocBook V5.06b, working draft – june (2008) http://www.oasis-open.org/docbook/specs. 6. Bachimont, B.: Audiovisuel et Numérique. In: Calderan, L., Hidoine, B., Milet, J. (eds.) Métadonnées: mutations et perspectives. ADBS editions, pp. 195–222 (2008) 7. MetaData Encoding and Transfer Standard: Primer and Reference Manuel. Version 1.6 (September 2007), http://www.loc.gov/standards/Mets 8. Treins, M., Curé, O., Salzano, G.: Gestion des annotations dans le dossier médical informatisé. Analyse des apports des normes et standards et propositions pour la conception de solutions. In: Salembier, P., Zacklad, M. (eds.) Annotations dans les documents pour l’action. Hermes Publishing, Londres-Paris (2006) 9. Bringay, S., Barry, C., Charlet, J.: The annotation, a new type of document in electronic health record. In: DOCAM (2004) 10. Lortal, G., Lewkowicz, M., Todirascu-Courtier, A.: Annotation: Textual Media for Cooperation. In: Proceedings of Annotation for Cooperation Workshop, pp. 41–50, November 24-25 (2005) 11. Zacklad, M.: Vers le Web Socio Sémantique: introduction aux ontologies sémiotiques. In: Deuxième journée de la plate-forme de l’AFIA (2005) 12. Treins, M., Curé, O., Salzano, G.: On the interest of using HL7 CDA release 2 for the exchange of annotated medical documents. In: CBMS (2006) 13. ISO/TC 211 19115:2003 Geographic Information – MetaData, http://www.iso.org 14. Exchangeable Image File Format, a standard of Japan Electronics and Information Technology Industries Association (JEITA), http://www.exif.org

Merging Expressive Ontologies Using Formal Concept Analysis Olivier Cur´e Universit´e Paris-Est, IGM Terre Digitale, Marne-la-Vall´ee, France [email protected]

Abstract. In this paper, we propose a solution to the problem of merging ontologies when instances associated to two source ontologies are available. The solution we propose is based on Formal Concept Analysis (FCA) and considers that ontologies are formalized in expressive Description Logics. Our approach creates a merged ontology which captures the knowledge of the two source ontologies. Contributions of this work are (i) enabling the creation of concepts not originally in the source ontologies, (ii) providing a definition to these concepts in terms of elements of both ontologies and (iii) optimizing the merged ontology. We have studied our approach in the context of spatial information, a domain which exploits many existing ontologies represented with Description Logics.

1

Introduction

The information stored in current IT applications usually need to be exchanged and integrated. These tasks raise several important problems due to format heterogeneity and information uncertainty generally encountered in these applications. Henceforth, we concentrate on Geographical Information Systems (GIS) because they usually integrate ontologies, i.e. a possibly formal representation of a domain of interest, to structure their information. In this paper, we are interested in declarative and logic-based formalisms to represent ontologies. In fact, we consider one of the currently most popular formalism, i.e. Description Logics (DLs). Apart from being popular, and thus offering many open source ontologies on the Web, this representation formalism enables computarized reasoners to infer, usually with sound and complete methods, implicit knowledge from the explicitly represented one. With so many ontologies being produced, it is inevitable that some of their content overlap and possibly disagree on some concepts. In order to support ontology interoperability, it is required that these ontologies can be semantically related. Thus ontology mediation [7] becomes a main concern. Ontology mediation enables to share data between heterogeneous knowledge bases, and allows applications to reuse data from different knowledge bases. Ontology mediation takes two distinguished forms: (i) Ontology mapping, where the correspondences between elements of two ontologies are stored separately from the ontologies. The correspondences are generally represented using axioms formulated in a peculiar R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 49–58, 2009. c Springer-Verlag Berlin Heidelberg 2009 

50

O. Cur´e

mapping language. (ii) Ontology merging, which consists in creating a new ontology from the union of source ontologies. The merged ontology is supposed to capture all the knowledge of the sources. Ontology mediation is an active research field where many kinds of solutions have been proposed: schema-based, instance-based, machine learning-inspired, hybrid approaches; see [9] for a survey on this domain. In this paper, we propose a solution to the ontology merging problem which is based on the techniques of Formal Concept Analysis (FCA) [8]. It extends [3] by dealing with expressive ontologies and their concept descriptions. FCA algorithms are machine learning techniques that enable the creation of a common structure, which may reveal some associations between elements of the two original structures. Thus it requires that some elements from both ontologies can be attached to a same observable item. Starting from this assumption, the processing of our FCA-based algorithms provides a merged ontology. Our solution extends existing FCA-based systems for ontology merging in the following way: (i) we provide a method to create concepts not originally in the source ontologies, (ii) we define emerging concepts in terms of elements of both ontologies and (iii) we optimize the resulting ontology by eliminating redundant concepts. The step (i) is the classical approach named ontology alignment in FCA literature. The steps (ii) and (iii) are an extension of this alignment and exploit concept descriptions and DL reasoner functionalities. The paper is organized as follows: in Section 2, we present some basic notions about FCA, DLs and present the ALC description language. In Section 3, we detail our method which enables to create an expressive merged ontology. The main steps are: concept generation, axiomatization of emerging concepts and optimization of the resulting ontology. Section 4 relates our work with existing systems in ontology merging and collaborations between FCA methods and DLs. Section 5 concludes this paper.

2

Basic Notions

FCA is the process of abstracting conceptual descriptions from a set of objects described by attributes [8]. We use some of the methods associated to FCA to merge geographical ontologies. Intuitively, this means that we merge two ontologies in a context consisting of a set of objects, a set of attributes, one for each ontology, and a set of correspondences between objects and attributes. FCA is based on the notion of a formal context. Definition 1. A formal context is a triple K = (G, M, I), where G is a set of objects, M is a set of attributes and I is a binary relation between G and M, i.e. I ⊆ G × M . For an object g and an attribute m, (g, m) ∈ I is read as “object g has attribute m”. Given a formal context, we can define the notion of formal concepts: Definition 2. For A ⊆ G, we define A = {m ∈ M |∀g ∈ A : (g, m) ∈ I} and for B ⊆ M , we define B  = {g ∈ G|∀m ∈ B : (g, m) ∈ I}. A formal concept of K is defined as a pair (A, B) with A ⊆ G, B ⊆ M , A = B and B  = A.

Merging Expressive Ontologies Using Formal Concept Analysis

51

The hierarchy of formal concepts is formalized by (A1 , B1 ) ≤ (A2 , B2 ) ⇐⇒ A1 ⊆ A2 and B1 ⊆ B2 . The concept lattice of K is the set of all its formal concepts with the partial order ≤. DLs are a family of knowledge representation formalisms allowing to reason over domain knowledge, in a formal and well-understood way. Central DL notions are concepts (unary predicates), roles (binary predicates) and individuals. A concept represents a set of individuals while a role determines a binary relationship between concepts. DLs are a fragment of first-order logic and thus concepts and roles are designed according to a syntax and a semantics. Some of the main assets of this family of formalims are decidability, efficient reasoning algorithms and the ability to propose a hierarchy of languages with various expressive power. A key notion in DLs is the separation of the terminological (or intensional) knowledge, called a TBox, to the assertional (or extensional) knowledge, called the ABox. The TBox is generally considered to be the ontology. Together, a TBox and a ABox represent a Knowledge Base (KB), denoted KB = T Box, ABox . The TBox is composed of “primitive concepts” which are ground descriptions that are used to form more complex descriptions, “defined concepts” which are designed using a set of constructors of the description language, e.g. conjunction( ), disjunction (), negation (¬), universal (∀) and existential (∃) value quantifiers, etc. The description language we are using in this paper correspond to ALC (Attributive Language with Complements). Concept descriptions in this language are formed according to the following syntax rule, where the letter A is used for atomic concepts, the letter R for atomic roles and the letters C and D for concept descriptions: C, D ::= ⊥ |  | A | ¬C | C D | C  D | ∃R.C| ∀R.C The semantics generally adopted for the ALC language is based on Tarskistyle semantics and we invite the interested reader to study [1] for details. In DLs, the basic reasoning service on concept expressions is subsumption, written C  D. This inference checks whether the first concept always denotes a subset of the set denoted by the second one. We use this service on the optimization of merged ontologies. Both domains, FCA and DL ontologies, use the notion of concept. In the rest of this paper, concepts in the context of FCA (resp. DL ontology) are named formal concepts, resp. DL concepts. To clarify the distinction between them, we can state that DL concepts correspond to the attributes of K.

3

Ontology Merging Using FCA

Let consider 2 geographical applications that manipulate space parcel data. Each application uses an independent ontology formalism to represent the concepts related to its data. Also the teams of experts that designed each ontology may not agree on the semantics of some concepts. Anyhow, the 2 applications need to exchange information, and thus require that some correspondences are discovered

52

O. Cur´e

between their DL concepts. The following 2 ontology extracts, O1 and O2 , are used all along this paper. In order to ease the understanding and reading of our example, all concepts and roles are underscripted with the number of their respective ontology, i.e. 1 for O1 and 2 for O2 . Terminological axioms of ontology O1 1. CF1 ≡ F1 ∃vegetation1 .C1 2. BLF1 ≡ F1 ∃vegetation1 .M1 3. C1 M1  ⊥ This extract of ontology O1 defines 2 concepts, CF1 , standing for Coniferous Forest, and BLF1 , standing for Broad Leaved Forest, in terms of the concepts F1 (Forest), C1 (Coniferophyta) and M1 (Magnoliophyta). Line #1 states that the coniferous forest concept is defined as the intersection of the concept Forest of O1 and the concept having at least one vegetation being a coniferophyta. Line #2 defines the concept of a broad leaved forest accordingly with magnoliophyta. Line #3 states that the concepts coniferophyta and magnoliophyta are disjoint. Terminological axioms of ontology O2 4. 5. 6. 7.

CF2 ≡ F2 ∀vegetation2 .C2 ∃vegetation2 .C2 BLF2 ≡ F2 ∀vegetation2 .M2 ∃vegetation2 .M2 M F2 ≡ F2 ∃vegetation2 .C2 ∃vegetation2 .M2 C2 M2  ⊥

The study of O2 emphasizes that designers do not entirely agree on the semantics of forest related concepts of O1 . On line #4, the concept of a coniferous forest is defined has being a forest composed of at least coniferophyta vegetation and exclusively of this kind of vegetation. Line #5 defines the concept of broad leaved forest accordingly with magnoliophyta. In order to represent other kinds of forests, the designers of O2 define a mixed forest concept as the intersection of being a forest with at least one coniferophyta vegetation and at least one magnoliophyta vegetation. Finally Line #8 states that the concepts coniferophyta and magnoliophyta of O2 are disjoint. We consider DL knowledge bases with non-empty TBoxes and ABoxes. In a first step, we map the information of the 2 ABoxes on a common set of observed objects. The information of these ABoxes can be stored in a structured or unstructured format. It is interesting to note the activity of several research teams in the DL and Semantic Web community in studying cooperations between the domains of databases and knowledge bases represented in a DL. For instance, the authors of [13] recently claimed that the ideal solution would be to have the individuals of the ABox stored in a relational databases and represent the schema of this database in a DL TBox. Also tackling this same objective, the team supporting the Pellet reasoner, one of the most popular OWL reasoner, recently released OWLgres which is being defined by their creators as a ’scalable reasoner for OWL2’. A main objective of this tool is to provide a conjunctive query answering service using SPARQL and the performance properties

Merging Expressive Ontologies Using Formal Concept Analysis

53

of relational database management systems. Using such an approach, the set of observed objects may be retrieved from existing relational database instances using already existing tools of FCA adapted to relational databases. The mapping we propose between both ontologies can be represented by a matrix, either generated by a specific tool and/or by interactions with end-users. In order to map concepts of both ontologies via the selected set of observed objects, a reference reconciliation tool may be used [5]. We present a sample of this mapping in Table 1: the rows correspond to the objects of K, i.e. common instances of the KB’s ABox, and are identified by integer values from 1 to 6 in our example. The columns correspond to FCA attributes of K, i.e. concept names of the 2 TBoxes. In the same table, we present, side by side, the formal concepts coming from our 2 ontologies, i.e. CF1 , BLF1 , F1 from O1 , and CF2 , BLF2 , M F2 , F2 from O2 . 3.1

Generation of a Merged Lattice

The matrix is built using the information stored in the TBox and ABox of both ontologies: – first, for each row, mark the columns where a specific instance is observed, e.g. the object on line 1 is an instance of the CF1 and CF2 concepts. Thus ABox information is used in this step. – then, complete the row with the transitive closure of the subsumption relation between ontology concepts, e.g.: line 1 must be also marked for DL concepts F1 and F2 , as respective ontologies state that: CF1  F1 and CF2  F2 . Here, the concept hierarchy of TBoxes are exploited. It is interesting to note the lines #3 and #6 emphasize different assumption for their respective parcels. For instance, the parcel conrresponding to line #3 has been defined as a coniferous forest using the classification of O1 while, possibly due to a vegetation not limited to coniferophyta, it has been defined as a mixed forest using O2 . The same kind of approach applies to the parcel associated to line #6. Using Table 1 with the Galois connection method [4], we obtain the lattice of Figure 1, where a node contains two sets: a set of objects (identified by the integer values of the first column of our matrix) from K (extension), and a set Table 1. Sample dataset for our ontology merging example CF1 BLF1 1 x 2 x 3 x 4 x 5 x 6 x

F1 CF2 BLF2 M F2 x x x x x x x x x x x x

F2 x x x x x x

54

O. Cur´e

Fig. 1. Galois connection lattice

of DL concepts from the source ontologies (intension), identified by the concept labels of source ontologies. 3.2

Dealing with Emerging Concepts

We now consider that the extensional part is not useful to comprehend a node. Thus, we remove it from all the nodes of the lattice, and only concept names remain (the intensional part). Then, we can also remove the redundancy, by deleting repeated occurences of a given concept name along a path of the lattice. The approach that we use is based on a bottom-up navigation of the lattice nodes: start from the bottom (⊥) and navigate upwards. For each node, analyze the set of concept names, and eliminate names that are present in the set of one of its direct successor, i.e. node above it and reached using a unique edge. This method has been adopted due to the lattice structure obtained by applying the Galois connection method. Finally we obtain Figure 2 where lattice nodes contain a single set, corresponding to concept names from one of the two original ontologies. We now classify the kinds of node sets we encounter: 1. a singleton: a name of a concept from either original ontology, because it can be distinguished from any of its successors by this specific name, e.g.: {CF1 }. 2. an empty node, because it can’t be directly distinguished from any of its possible successors. We identify each of these nodes with a unique symbol disjoint from the concept symbols of the source ontologies. In Figure 2, we have 2 such nodes which are named α and β.

Merging Expressive Ontologies Using Formal Concept Analysis

55

Fig. 2. Galois connection lattice with “empty nodes”

3. a set of several names, all belonging to source ontologies, because the mediation based on the given two ABoxes, has not been able to split names. Indeed, it is as if the names are glued together in a single concept name. All singletons are maintained in the resulting merged ontology and we are now aiming to provide a concept description to the remaining concepts, case 2 and 3 of our node classification. The first step toward our solution is to expand the concepts of the merged ontology according to their respective TBoxes. That is, we replace each occurence of a name on the right hand-side of a definition by the concepts that it stands for. A prerequisite of this approach is that we are dealing with acyclic TBoxes. Thus this process stops and the resulting descriptions contain only primitive concepts on the right hand-side. We first deal with the nodes which are formed of several concept symbols, denoted σi , e.g. node labelled F1 , F2 in Figure 2. Due to the algorithm adopted from the generation of the Galois connection lattice [4], these nodes appear at the top of the lattice and do not have multiple inheritance to concepts that are not of this form. Thus we adopt a top-down approach from the top concept of our merged ontology. We consider that the concepts associated are equivalent, e.g. F1 ≡ F2 , propose a single concept symbol σ, e.g. F (Forest) for F1 , F2 , and associate information to this concept stating that this concept is equivalent to the original concepts for interoperability reasons, e.g. F ≈ F1 and F ≈ F2 . Now all occurences of the concept σi are translated into the concept symbol σ in the concept descriptions of the merged ontology. We can now concentrate on empty nodes, e.g. α and β. Again, according to the Galois based lattice creation, these nodes can not be at the root of the lattice. This means that they inherit from some other concept(s). We use the description

56

O. Cur´e

of these inherited concept(s) to provide a description. Using this method, the concepts α and β of Figure 2 have the following descriptions: α ≡ CF1 M F2 ≡ ∃vegetation1 .C1 ∃vegetation2 .C2 vegetation2 .M2 β ≡ BLF1 M F2 ≡ ∃vegetation1 .M1 ∃vegetation2 .C2 vegetation2 .M2 All concepts from the merged ontology have been associated to a concept description, except of course the primitive concepts. But we can do more and optimize the descriptions. This optimization operation is supported by the possible alignement we can perfom on the primitive concepts of both ontologies O1 and O2 . We mainly distinguish between 3 situations: – a situation where primitive concepts are coming from a single integrated ontology. In our example, this means that we can state that C1 ≡ C2 , M1 ≡ M2 and even vegetation1 ≡ vegetation2. – a situation where primitive concepts of source ontologies are not aligned natively. Then, we can use an external tool and/or interactions with end-users to align them. In our example, we would end up with the same equivalence relations as in the previous case. – no alignment on primitive concepts is possible and our merged ontology can not be optimized. In our example, for the first 2 situations the descriptions of the concepts of our merged ontology are (assuming a renaming of the primitive concepts, e.g. C ≡ C1 ≡ C2 and M ≡ M1 ≡ M2 ): 8. CF1 ≡ F ∃vegetation.C 9. BLF1 ≡ F ∃vegetation.M

Fig. 3. Galois connection lattice with generated labels

Merging Expressive Ontologies Using Formal Concept Analysis

10. 11. 12. 13. 14. 15.

57

CF2 ≡ CF1 ∀vegetation.C ∃vegetation.C BLF2 ≡ BLF2 ∀vegetation.M ∃vegetation.M M F2 ≡ F ∃vegetation.C ∃vegetation.M alpha ≡ F ∃vegetation.C ∃vegetation.M beta ≡ F ∃vegetation.C ∃vegetation.M C M ⊥

Our merged ontology can now be classified using a DL reasoner, e.g. Fact, Racer. This processing enables to find some new subsumption relations which enable to design the ontology of Figure 3. Figure 3 shows the merged ontology resulting from application of FCA.

4

Related Work

In this Section, we survey related works in ontology mediation solutions and in particular we present some solutions which exploit extensions of the ontologies, i.e. ABoxes. In the literature, two distinct approaches in ontology merging have been distinguished. In the first approach, the merged ontology captures all the knowledge of the source ontologies and replaces them. An example of such a system is presented in [12] with the PROMPT tool. In the second approach the source ontologies are not replaced by the merged, but rather a so-called ’bridge ontology’ is created. The bridge ontology imports the original ontologies and defines the correspondences using axioms which are called “bridge axioms”. An example of such an approach is the Ontomerge solution which has been described in [6]. The most relevant work related to our solution is the FCA-merge system [14]. It uses instances of ontology classes to exploit an FCA algorithm. The FCAmerge system produces a lattice of concepts which relates concepts from the source ontologies. This new concept lattice is then handed to the domain expert in order to generate the merged ontology. Thus we can consider FCA-merge to be a semi-automatic solution while our solution aims to generate the merged ontology automatically. So the main differences are that the FCA-merge is unable to propose concepts emerging from the fusion of the source ontologies and does not propose a label generation solution. Also, without the help of domain experts, the FCA-merge system is not able to refine the merged ontology. Considering works involving FCA methods and DLs, it is interesting to study [2]. In this paper the authors are concerned with the completeness quality dimension of TBoxes, i.e. they propose techniques to enable ontology engineers in checking if all the relevant concepts of an application domain are present in a TBox. Like our approach, one of their concern is to minimize interactions with domain experts. Hence FCA techniques are being used to withdraw trivial questions that may be asked to experts in case of incomplete TBoxes. The approach we presented in this paper is more concern with the generation and optimization of mediated ontology. And we can consider that our approach is more involved in the soundness quality dimension and tackles the issue of generating different forms of merged ontology.

58

5

O. Cur´e

Conclusion

In this paper, we presented an approach to merge ontologies based on the methods of FCA. Our main contribution enables (i) the creation of concepts not originally in the source ontologies, (ii) the definition of the concepts in terms of elements of both ontologies and (iii) the optimization of the resulting ontology by eliminating redundant concepts. Future work on this system are related to extracting automatically a valuable and minimal set of instances from ABoxes for the Galois connection matrix and studying expressive DL beyond the ALC language.

References 1. Baader, F., Calvanese, D., McGuinness, D.L., Nardi, D., Patel-Schneider, P.F.: The Description Logic Handbook: Theory, Implementation, and Applications. Cambridge University Press, New York (2003) 2. Baader, F., Ganter, B., Sertkaya, B., Sattler, U.: Completing Description Logic Knowledge Bases Using Formal Concept Analysis. In: Proc. IJCAI 2007, pp. 230– 235 (2007) 3. Cur´e, O., Jeansoulin, R.: An FCA-based Solution for Ontology Mediation. In: Proc. CIKM workshops (2008) (to appear) 4. Davey, B., Priestley, H.: Introduction to lattices and Order. Cambridge University Press, New York (2002) 5. Dong, X., Halevy, A., Madhavan, J.: Reference reconciliation in complex information spaces. In: Proc. SIGMOD 2005, pp. 85–96 (2005) 6. Dou, D., McDermott, D., Qi, P.: Ontology translation by ontology merging and automated reasoning. In: Proc. EKAW 2002, pp. 3–18 (2002) 7. Ehrig, M.: Ontology Alignment: Bridging the Semantic Gap. Springer, New York (2006) 8. Ganter, B., Wille, R.: Formal Concept Analysis: mathematical foundations. Springer, New York (1999) 9. Kalfoglou, Y., Schorlemmer, M.: Ontology mapping: the state of the art. Knowledge Engineering Review 18(1), 1–31 (2003) 10. Kanellakis, P.C.: Elements of relational database theory. In: Handbook of theoretical computer science. Formal models and semantics, vol. B, pp. 1073–1156. MIT Press, Cambridge (1990) 11. Motik, B., Horrocks, I., Sattler, U.: Bridging the gap between OWL and relational databases. In: Proc. WWW 2007 (2007) 12. Noy, N., Musen, M.: PROMPT: Algorithm and tool for automated ontology merging and alignment. In: Proc. AAAI 2000 (2000) 13. Poggi, A., Lembo, D., Calvanese, D., De Giacomo, G., Lenzerini, M., Rosati, R.: Linking Data to Ontologies. Journal of Data Semantics 10, 133–173 (2008) 14. Stumme, G., Maedche, A.: FCA-MERGE: Bottom-Up Merging of Ontologies. In: Proc. IJCAI 2001, pp. 225–234 (2001)

Contemporary Challenges in Ambient Data Integration for Biodiversity Informatics David Thau1 , Robert A. Morris2,3, and Sean White4,5 1

Dept. of Computer Science, University of California Davis, CA 2 University of Massachusetts Boston, MA 3 Harvard University Herbaria, Cambridge, MA 4 Dept. of Computer Science, Columbia University, NY 5 Dept. of Botany, Smithsonian Institution, Washington, D.C.

Abstract. Biodiversity informatics (BDI) information is both highly localized and highly distributed. The temporal and spatial contexts of data collection events are generally of primary importance in BDI studies, and most studies are focused around specific localities. At the same time, data are collected by many groups working independently, but often at the same sites, leading to a distribution of data. BDI data are also distributed over time, due to protracted longitudinal studies, and the continuously evolving meanings of taxonomic names. Ambient data integration provides new opportunities for collecting, sharing, and analyzing BDI data, and the nature of BDI data poses interesting challenges for applications of ADI. This paper surveys recent work on utilization of BDI data in the context of ADI. Topics covered include applying ADI to species identification, data security, annotation and provenance sharing, and coping with multiple competing classification ontologies. We conclude with a summary of requirements for applying ADI to biodiversity informatics.

1

Introduction

Biodiversity informatics (BDI) applies information technology to the acquisition, storage, access, distribution, and analysis of data concerning organisms, populations, and biological taxa and interactions between them. BDI research is carried out in many places, from using sound to identify species in remote biological field stations [1], to identifying trees in urban environments [2], to completing all taxa biological inventories (ATBIs) in national forests [3]. Biodiversity studies increasingly rely on sensor networks and other small devices for data collection and dissemination [4]. The strong spatial and temporal components of the data lend themselves naturally to the application of pervasive 

Work supported by NSF awards IIS-0630033 (David Thau), DBI-0646266 (Robert A. Morris), and IIS-03-25867 (Sean White). The first author would like to thank Shawn Bowers and Bertram Lud¨ ascher for many constructive conversations.

R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 59–68, 2009. c Springer-Verlag Berlin Heidelberg 2009 

60

D. Thau, R.A. Morris, and S. White

computing techniques. This paper discusses elements of biodiversity informatics that can benefit from pervasive computing, shows ways in which the BDI context can inform research in pervasive computing, and discusses challenges in data integration that arise for pervasive computing in the BDI context. Spatial and temporal contextualization. Biodiversity data are highly sensitive to spatial and temporal context. All aspects of data integration in biodiversity informatics are affected by this. When identifying specimens, the location and time of a study strongly constrain the types of biological taxa that may be found and their appearance. As discussed in Section 4, location and time may impact the integration of metadata about taxa. In addition, the geographic location of studies or species must often be protected, affecting how data are shared. Challenging environments. Much biodiversity research by necessity takes place far from an internet connection and power sources. This places constraints on how much data are brought into the field and how data are taken from the field. In addition, it constrains the types of analyses that may be done on site, which impacts how data collection occurs. These constraints argue for a division of labor among devices, which in turn drives the need for integrating the data that the disparate devices collect. Biodiversity studies also occur in environments that attenuate communication signals. For example, signals from GPS satellites are notoriously unreliable in rain forests and often too coarse in urban environments. In addition, certain environments preclude the use of specific frequencies for communication. All of these limitations point to the necessity for creative means of sharing data from sensors and other ambient-enabled devices. Dynamic teams. Teams engaging in biodiversity studies frequently comprise individuals from different countries, institutions and levels of expertise. In National Geographic Bioblitzes,1 e.g., thousands of volunteers and scientists gather for two days to complete an inventory. ATBIs of a region often span years and many groups of researchers. In all these cases, different individuals have different levels of knowledge and may bring different resources to the field. This kind of team-based data collection falls into the category of participatory sensing [5] where immediate data analysis and integration can drive additional collection behavior. In order to leverage the information stored on individual devices, data integration techniques must be applied to normalize differences in metadata. In addition, the contemporaneous existence of disparate user devices and on-site sensors requires sophisticated network security protocols. As described in Section 3, specific trust issues arise in biodiversity studies that may be less prevalent in other contexts. Finally, data sharing among independent teams requires a focus on the active management of data provenance and data ownership. 1

http://www.nationalgeographic.com/field/projects/bioblitz.html

Contemporary Challenges in Ambient Data Integration for BDI

61

Data Complexity. Biodiversity data have some unusual properties that set them apart from many other types of data. Perhaps the most significant such property is the complexity of naming the fundamental entities of study: observations, specimens, species, and other taxa. The primary system currently used for naming biological taxa has evolved from a standard described by Linnaeus in the middle of the 18th century. Over the subsequent 250 years, as information about biological taxa has accumulated, the names for species and the taxonomies relating them to each other have steadily changed. This change means that a species name used today may mean something different than it meant 5 years ago. One way to mitigate the problems caused by taxonomy evolution is to be clear about which version of the taxonomic name is meant when it is applied. In biology this is called the taxon’s “name authority,” and current BDI data exchange standards (e.g., the Darwin Core2 ) all support (or insist on) inclusion of a name authority. However, as we discuss in Section 4, specifying the name authority is only a first step in supporting data integration. Another challenge presented by biodiversity data is the amount and location of information that may be relevant to scientists while they perform their research in the field. Biodiversity data are highly distributed. For example, the Global Biodiversity Information Facility (GBIF)3 indexes over 174 million specimen and other georeferenced species-occurrence records from over 7000 data sets at 285 different data providers. The fastest growing type of such data comprises field observations, often by experienced lay observers (“citizen scientists” and parataxonomists). For example, the Avian Knowledge Network(AKN) e-Bird project4 provides nearly 23M bird occurrence observations of which 18M have geocoordinates, and AKN collects as many as 70 thousand North American checklists annually. By expanding its definition of what is a biodiversity datum (e.g., to include biodiversity multimedia metadata), GBIF has an ambitious plan to operate indexing and caching services for access to a billion biodiversity data items in a fully distributed fashion. The distribution and amount of biodiversity data that may be useful for data collection in the field, where connectivity may be limited, requires creative data management techniques. Road Map. The remainder of the paper discusses specific aspects of biodiversity studies, and shows how pervasive computing techniques can be used to better collect and manage the data at these stages, as well as how the BDI context impacts the requirements of data integration in a pervasive computing context. Section 2 focuses on the need for ADI in data collection. Section 3 describes specific trust and provenance issues that must be addressed when integrating BDI data. Section 4 focuses on the metadata involved in integrating BDI information and shows how the context sensitivity of BDI data impacts critical aspects of ADI. We conclude in Section 5 by describing several requirements for integrating BDI data in a pervasive computing context. 2 3 4

http://www.tdwg.org/activities/darwincore/ http://www.gbif.org/ http://www.ebird.org/

62

2

D. Thau, R.A. Morris, and S. White

Identification and Data Collection

Novel field sensors and sensor systems have enabled unique access to information about the environment, bringing useful data to and from the field while greatly expanding the spatial and temporal resolution of data collection [4]. Complementary to this are advances in hand-held mobile devices, which support supervised sensing through human interaction in the data collection process and novel interfaces to vast stores of biodiversity information for real-time analysis and synthesis. These field sensor systems and mobile devices improve existing field research practices and create opportunities for new practices, such as participatory sensing [5] and citizen science [6]. For example, a collaboration amongst Columbia University, University of Maryland, and the Smithsonian Institution has developed a series of mobile electronic field guides that aid in the identification of botanical species, provide access to digitized species information, and support specimen collection in the field [7,2]. Successive iterations of the prototype system, LeafView, run on Tablet PC, Ultra Mobile PC (UMPC) and mobile phone platforms. The system works by first taking a photograph of a leaf specimen. The photo is then analyzed using a custom computer vision algorithm to extract leaf shape [8]. Based on the shape of the photographed leaf, the system provides a visualization of the best matching species so the botanist can make a final visual identification. Contextual information including geolocation, collector, time, and date are saved along with the sample image and associated identification and all of this data is aggregated over the course of a collection. Access to the entire digitized image collection of the Smithsonian Herbarium supports detailed comparison of new samples with existing voucher specimens. The system has been used by Smithsonian botanists on Plummers Island, MD, and at the 2007 Rock Creek Park National Geographic Bioblitz in Washington, D.C. Use of the system has uncovered a variety of challenges related to ambient data integration. 2.1

Management and Integration of Identification Data

Expanding data sets are used both for automated identification and assisted matching. In the current LeafView system, data sets for a region are loaded prior to entering the field. While this works on a small scale, for larger scales and multiple taxa, larger data sets need to be moved in and out of the system, retrieved and cached, based on specific regions and tasks. For example, current data sets for identification include: – Flora of Plummers Island. 5,013 leaves of 157 species. Provides complete coverage of all vascular plant species of Plummers Island, MD, an island in the Potomac River near Washington, DC, which has long been studied by botanists. – Woody Plants of Baltimore-Washington, DC. 7,481 leaves of 245 species. Provides complete coverage of all native woody plants (trees and shrubs) of the Baltimore-Washington, DC area. – Trees of Central Park. 4,320 leaves of 144 species.

Contemporary Challenges in Ambient Data Integration for BDI

63

The computed feature distances necessary for automated identification are represented in an NxN matrix where N is the number of individual leaves in the data set. For the Woody Plants of Baltimore-Washington, D.C., this requires 400 MB of storage. Even with improvements to the algorithm, the feature sets for matching data promise to be large and grow with the number of species, requiring compartmentalization and filtering. In addition to these data sets, access to digitized images is necessary to visually match sample specimens with voucher specimens. The US National Herbarium Type Specimen Collection alone incorporates over 90,000 images, covering more than one quarter of all known plant species. Each specimen has been digitally photographed under controlled lighting to produce an 18 megapixel image. A decimated version of the voucher specimens for Woody Plants of Baltimore-Washington, DC (300K GIF images instead of 18 MB TIFF) requires 295 MB but a full resolution version of the data set would provide more detail and would require much more space. These data management issues are compounded when the data for an individual species is extended to alternative representations. For example, recent research in augmented reality uses situated visualization to superimpose relevant species information directly onto the physical scene [9]. In the presence of a robust network, processing and data necessary for identification and matching can reside on server systems. However, remote areas without connectivity require prediction about necessary data sets for identification so analysis and data sets can be moved to the device. Task and location context can help filter the search space and thus the data requirements. However, filtering and inaccuracies in matching can complicate use of the system. When a new specimen is not found through automated identification or keys, is it because the data is simply not in the current data set, is the identification tool failing, or is this a new species? 2.2

Collaborative Identification and Shared Collections

With similar issues to data management, collaborative identification requires sharing of collected specimen data and annotations in real-time. ADI issues arise in several situations. First, in the case of censuses, a shared collection list may be used. Synchronization of the collection list across multiple teams of collectors helps focus resources on finding species that have yet to be collected. Second, multiple sensing devices may be aggregated under a single processing unit. For example, in one collection, several cameras were connected to a single LeafView system, each able to send photographs for identification across a local ad-hoc wireless network. Third, the collected data itself may be shared to aid in identification. For example, collector A may be able to identify a particular species and share their history of collection with other team members. If the same species is observed by collector B, they can use the shared history of the collection to help identify the species. Finally, the data needs to be shared and used beyond any given field activity. In the current, non-networked device, data is simply exported at the end of a field study. In a networked version, collections should be opportunistically pushed to a proxy, mediator, or server.

64

2.3

D. Thau, R.A. Morris, and S. White

Observation Driven Data Collection

Data collection, mediated through human agency, can also be driven by immediate observations in the field. For example, reviewing a map of the locations of collected specimens in a given geographic region may reveal areas that have not yet been inspected. By creating shared models of data that reflect spatial and temporal histories of observations, individuals and groups iteratively navigate locations for collection of species. Such iteration requires real time data curation incorporating explicit and implicit association of metadata.

3

Data Sharing

There are benefits to sharing data between sensors and other ambient-enabled devices throughout the data collection process. Before data are collected, devices must have access to information that will assist in the identification of species. As the data are collected, the devices can inform each other about what has been collected so far. In addition, sensors and other data sources at the study location can supply data to inform and drive collection events. While BDI shares many features with other participatory sensing scenarios, there are a few differentiating aspects. Two of these are particular details about what data may be shared with whom, and how an ambient data integrating system should deal with evolving information about the objects being studied. 3.1

Access Control Issues

Security and access control are common problems in pervasive computing scenarios [10,11]. BDI has some additional security requirements. The most widely mentioned of these is the protection of sensitive geographic information, for example to defend the exact location of organisms of rare or endangered species, or to protect landowners who have given permission to use their land for biodiversity surveys but do not want uninvited guests wandering around their property looking for rare organisms. Unfortunately, professional practices can complicate attempts to protect such data. For example, rigorous collection or observation protocols require that collection and observation events have unique identifiers. A standard practice is to assign sequential integers as part of an otherwise constant event identifier. This causes problems for database systems that try to suppress geographical information for sensitive specimens. For example, imagine three records, r1 , r2 , r3 collected in the same location, the second of which is considered sensitive. A “smart” database system that suppresses information about r2 but returns the coordinates for r1 and r3 would give away r2 s location. A number of strategies are in use for protecting the geocoordinates of occurrences of endangered species while still making full resolution available to authorized users for such things as predictive range modeling. Among them are one or another form of generalizing the geocoordinates, wherein the location is given either at a low geo-resolution (e.g., to a 10 km square on a fixed grid) or a named geopolitical entity, such as a town, county, or province.

Contemporary Challenges in Ambient Data Integration for BDI

65

One controversial reason sometimes given for biodiversity access control is that some class of users may make use of the data in a way that is inappropriate in the eyes of the data holder. See Chapman and Grafton [12] for a more extensive review. Morris et al. [13] provided a fully distributed XACML-based access control system whose control policies can be defined or enforced by the original data provider or a host to which they delegate those services, and which meets many of the needs expressed by networks of distributed taxon occurrence data. Any of the access control services can be centralized and slowly migrated to network nodes as and when their operators acquire sufficient IT skills and resources to support such services. The filters are defined by XPath expressions on the data interchange schema expressed in XML-Schema. BDI access control per se does not give rise to different issues for ADI than for computing regimes that are not context aware. It is, however, an instance of challenges that arise in attempting to reason in dynamic contextual computing environments, whether that reasoning is statistical or logical; namely it may amplify imperfect context information. Henrickson and Indulska identify four types of imperfect context information: unknown, ambiguous, imprecise, and erroneous [14]. The first three of these correspond to examples of georeference access control mentioned above. The fourth, in the form of deception, is sometimes proposed for access control, but is notoriously subject to data mining techniques designed to find logical outliers. For example, a report of an arboreal animal swimming 100 km. off the coast of Portugal should usually be hypothesized to be erroneous. 3.2

Distributed Annotations for Quality Control

As in any scientific endeavor, the quality of the data acquired, stored and shared is of paramount importance. In general, data quality can be measured by comparison with similar data already collected. For example, Calder et al. describe a rule-based reasoning system targeted at sensor network data, that allows scientists to put forth hypotheses about possible explanations of their observations and have a reasoning engine select which of them are consistent with the currently accepted value of observation data [15]. Unfortunately, a substantial amount of primary biodiversity data that might drive reasoning about field or laboratory observations remains undigitized or is only partly digitized (e.g., to the level of scanned images with no OCR). There are estimates that the world’s natural history museums hold 3 billion specimens, of which fewer than 200 million have any kind of digital record. The Biological Heritage Library5 has scanned over 14 million pages of legacy taxonomic literature, much of which provides original taxonomic descriptions of newly discovered species over the last three centuries. Museum (and individual collector) specimen records and original literature represent part of the “ground truth” of species identification, but even after imaging, many of these documents are being incrementally made digitally useful by databasing, by rough machine-learning based automated markup, or by semiautomatic markup guided by humans6 . Most of these strategies result in an ever 5 6

http://www.biodiversitylibrary.org/ e.g., http://plazi.org/

66

D. Thau, R.A. Morris, and S. White

moving target of increasingly accurate and increasingly fine-grained knowledge content. This presents challenges and opportunities for individual or coupled ambient computing platforms to reason over the data and knowledge to which they have access for the purpose of assessing the quality of data they may hold, and the quality of data they may report. This post hoc analysis and digitization of historical biodiversity data adds special requirements to any system that attempts to collect, record and share new biodiversity data. First, provision should be made for data records to be annotated with record-level quality control metadata (or other annotations of interest). Second it must be possible for the annotations to circulate in communities of interest, along with notification mechanisms that attempt to provide the annotations and commentary upon them to human or software agents that express an interest. A team at Harvard and UMASS-Boston has designed and is implementing a “P2P Filtered Push (FP) Annotation Exchange” for such a purpose [16]. Its currently implemented prototype is dedicated to data of a special case, namely the digital form of accumulated annotations on related botanical specimens. (Conventionally, botanists collect multiple specimens from the same organism and circulate copies to multiple institutions for, usually, independent curation.) FP is built on the Apache Hadoop Map-Reduce framework together with the Apache ActiveMQ Java Messaging Service. FP is being extended to allow arbitrary workflows anywhere in the local community or the Cloud to generate and announce QC (or other) annotations.

4

Ontology-Based Data Integration

The importance of ontologies in pervasive computing is widely recognized [17]. When investigators from disparate organizations, nations, and levels of expertise collaborate in a BDI study, chances are they will bring with them a multitude of heterogeneous metadata standards. As we have seen, data collection and data sharing can be influenced by events that occur during and after a data collecting event. Before ambient-enabled devices can integrate their data, they must mitigate the differences in their metadata. In BDI, metadata differences can appear in the standards used to describe measurements [18], as well as to describe the things being measured. One particularly salient metadata issue in BDI revolves around the difficulties in naming biological entities. As mentioned in the introduction, multiple taxonomies may be used to classify a given set of biological taxa. Two groups using different field guides may use different names to identify the same specimen. To minimize the difficulties this inevitably creates when trying to integrate biodiversity data, experts create mappings between well-known taxonomies [19,20]. These mappings can be reasoned over to discover inconsistencies and new mappings [21], and may be used to integrate data [22]. A great deal of uncertainty may occur when integrating data sets under multiple taxonomies. Often, this uncertainty can best be resolved at the time of data collection. A challenge for ambient data integration is to integrate data collected by heterogeneous devices rapidly enough to discover when the results of the integration are uncertain, and to notify the data collectors while they are still in the field so that the uncertainties can be resolved.

Contemporary Challenges in Ambient Data Integration for BDI

67

An interesting extension of the work on mapping biological taxonomies that has not been addressed is the context specificity of the mappings. For example, in one spatial context, such as North America, two taxonomic names A (mentioned in one taxonomy) and B (mentioned in a different taxonomy) may refer to identical biological entities, while in another spatial context, such as South America, one of the taxonomic names may refer to a subset of the second taxonomic name. This might arise if specimens of taxon B that are not also in taxon A have been identified in South America, but in North America all specimens of taxon B are also specimens of taxon A. The discovery of a specimen of B that is not also a specimen of taxon A in North America would be especially interesting, either because it is new (possibly publishable) information about the taxa involved, or because it is a misidentification. The interestingness of the identification of a B that is not an A arises from the taxonomic mapping, which itself may only come into play when ambient-enabled devices are expected to integrate their data in the field. This again points to a challenge for ambient data integration: it needs to be sensitive to the context (e.g., geographic context) under which the integration occurs.

5

Conclusion

Biodiversity informatics presents several interesting challenges for data integration in ambient computing. First, connectivity in the field is reduced, creating an emphasis on device provisioning of data and clever means for sharing data between devices. Second, the data themselves are complex. Although most ADI applications need to perform some semantic mediation for mismatched metadata, the 250 year history of evolving taxon names presents a particularly extreme situation. Third, data integration occurring in real time can have immediate impact on collecting events. This, along with the attenuated connectivity, argues for intelligent ambient-enabled devices that can analyze data as they are collected and distribute information from these analyses. Finally, all aspects of a biodiversity informatics study are affected by the spatial and temporal context of the study. This includes the identification of species, the protection of sensitive data, and the application of semantic metadata mediation. In the future, as sensors and devices brought into the field are increasingly capable (e.g., identification via on site DNA sequencing), this sensitivity to context will continue to influence analyses and data dissemination.

References 1. Gage, S.H.: Observing the acoustic landscape. In: Estrin, D., Michener, W., Bonito, G. (eds.) Environmental Cyberinfrastructure Needs for Distributed Sensor Networks, August 2003, p. 64 (2003) 2. Belhumeur, P.N., Chen, D., Feiner, S., Jacobs, D.W., Kress, W.J., Ling, H., Lopez, I., Ramamoorthi, R., Sheorey, S., White, S., Zhang, L.: Searching the world’s herbaria: A system for visual identification of plant species. In: Forsyth, D.A., Torr, P.H.S., Zisserman, A. (eds.) ECCV 2008, Part IV. LNCS, vol. 5305, pp. 116–129. Springer, Heidelberg (2008) 3. Sharkey, M.J.: The all taxa biological inventory of the great smoky mountains national park. The Florida Entomologist 84(4), 556–564 (2001)

68

D. Thau, R.A. Morris, and S. White

4. Porter, J.H., Nagy, E., Kratz, T.K., Hanson, P., Collins, S.L., Arzberger, P.: New eyes on the world: Advanced sensors for ecology. BioScience 59(5), 385–397 (2009) 5. Burke, J., Estrin, D., Hansen, M., Parker, A., Ramanathan, N., Reddy, S.: Srivastava: Participatory sensing. In: WSW 2006: Mobile Device Centric Sensor Networks and Applications (2006) 6. Caruana, R., Elhawary, M., Munson, A., Riedewald, M., Sorokina, D., Fink, D., Hochachka, W.M., Kelling, S.: Mining citizen science data to predict revalence of wild bird species. In: KDD 2006, pp. 909–915. ACM, New York (2006) 7. White, S., Marino, D., Feiner, S.: Designing a mobile user interface for automated species identification. In: Rosson, M.B., Gilmore, D.J. (eds.) CHI, pp. 291–294. ACM, New York (2007) 8. Ling, H., Jacobs, D.W.: Using the inner-distance for classification of articulated shapes. In: CVPR (2), pp. 719–726. IEEE Computer Society, Los Alamitos (2005) 9. White, S., Feiner, S., Kopylec, J.: Virtual vouchers: Prototyping a mobile augmented reality user interface for botanical species identification. In: Proc. 3DUI 2006 (IEEE Symp. on 3D User Interfaces), pp. 119–126 (2006) 10. Walters, J.P., Liang, Z., Shi, W., Chaudhary, V.: Wireless sensor network security: A survey. In: Security in distributed, grid, mobile, and pervasive computing, p. 849. CRC Press, Boca Raton (2007) 11. Cuevas, A., Khoury, P.E., Gomez, L., Laube, A.: Security patterns for capturing encryption-based access control to sensor data. In: SECURWARE 2008, pp. 62–67 (2008) 12. Chapman, A.D., Grafton, O.: Guide to Best Practices For Generalizing Sensitive Species Occurrence, version 1. Global Biodiversity Information Facility (2008) 13. Dong, H., Wang, Z., Morris, R., Sellers, D.: Schema-driven security filter generation for distributed data integration. In: Hot Topics in Web Systems and Technologies, pp. 1–6 (2006) 14. Henricksen, K., Indulska, J.: Modelling and using imperfect context information. In: PERCOMW 2004, Washington, DC, USA, pp. 33–37. IEEE Computer Society, Los Alamitos (2004) 15. Calder, M., Morris, R.A., Peri, F.: Machine reasoning about anomalous sensor data (2009) (submitted for publication) 16. Wang, Z., Dong, H., Kelly, M., Macklin, J.A., Morris, P.J., Morris, R.A.: Filteredpush: A map-reduce platform for collaborative taxonomic data management. In: CSIE 2009. IEEE Computer Society, Los Alamitos (2009) 17. Ye, J., Coyle, L., Dobson, S., Nixon, P.: Ontology-based models in pervasive computing systems. Knowledge Engineering Review 22(4), 315–347 (2007) 18. Bowers, S., Madin, J.S., Schildhauer, M.P.: A conceptual modeling framework for expressing observational data semantics. In: Li, Q., Spaccapietra, S., Yu, E., Oliv´e, A. (eds.) ER 2008. LNCS, vol. 5231, pp. 41–54. Springer, Heidelberg (2008) 19. Koperski, M., Sauer, M., Braun, W., Gradstein, S.: Referenzliste der Moose Deutschlands, vol. 34. Schriftenreihe Vegetationsk (2000) 20. Peet, R.K.: Taxonomic concept mappings for 9 taxonomies of the genus ranunculus published from 1948 to 2004. Unpublished dataset (June 2005) 21. Thau, D., Ludascher, B.: Reasoning about taxonomies in first-order logic. Ecological Informatics 2(3), 195–209 (2007) 22. Thau, D., Bowers, S., Ludaescher, B.: Merging sets of taxonomically organized data using concept mappings under uncertainty. In: Meersman, R., Dillon, T., Herrero, P. (eds.) OTM 2009, Part II. LNCS, vol. 5871, pp. 1103–1120. Springer, Heidelberg (2009)

A Hierarchical Representation for Recording Semantically Condensed Data from Physically Massive Data Out of Sensor Networks Geographically Dispersed MinHwan Ok Korea Railroad Research Institute, Woulam, Uiwang, Gyeonggi, Korea [email protected]

Abstract. A number of sensor networks may produce a huge amount of data, and there has been a necessity the data are processed in a single system. However the data could early overwhelm the database of the system. This work introduces a condensing method to reduce the amount of data exploiting its semantics. The condensing reduces the amount of data to be transmitted and stored, by condensing the data according to semantics shared among servers. The briefed data could diminish the load of applications running on resourceconstrained devices in pervasive computing. Keywords: Sensor Network, Distributed Databases Application, Semantic Condensing.

1 Introduction Many attributes of the physical phenomenon surrounding people such as air temperature, humidity, and dust density in public facilities are becoming online by sensor networks in pervasive computing paradigm. Since those sensors are geographically dispersed and produce data at predefined rates, the sensor networks would require a distributed data management in a regional or nationwide scale. In these sensor networks, the sensor data is stored near its source, and data processing and filtering are pushed to the edges. Similarly, on the supposition the sensor nodes are tiny hardware suffering energy shortage or etc., queries for the data captured by sensor nodes are preferably processed the sink nodes. Such architecture reduces bandwidth requirements and enables parallel processing of sensor feeds[1]. While many distributed systems are geared toward workloads that are readintensive, low volume, or not time critical, the distributed systems with these sensor networks will be write-intensive, high volume, and often time critical. Since the volume of sensor data becomes enormous if they are congregated nationwide, those data do not seem accommodated in a few database systems, in the form of raw data. In this work, a condensing method is proposed to reduce the amount of data exploiting its semantics. The condensing reduces the amount of data to be transmitted and stored, by condensing the data according to semantics shared among servers. The R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 69–76, 2009. © Springer-Verlag Berlin Heidelberg 2009

70

M.H. Ok

building and updating processes are suggested for hierarchically distributed sensor databases, exploiting the merit of semantic condensing. The underlying database is a specific database including TinyDB, and COUGAR[2], which are the common database management systems for sensor networks. Distributed-stream-processing engines such as Aurora, Medusa, Borealis, Telegraph-CQ, and HiFi are the future candidates. An early system designed to provide a worldwide sensor database system is IrisNet[3]. It supports distributed XML processing over a worldwide collection of multimedia sensor nodes, and addresses a number of fault-tolerance and resourcesharing issues[4]. However there has not been any related work based on a concept similar to a condensing method to brief the original data, introduced in this work, in our best knowledge.

2 Condensing Ranges into Semantic Values from Linear Data The sensor captures the attribute states of a certain physical phenomenon by time, and nowadays, many applications use the sensors that produce a series of one variable such as temperature, humidity, density or pressure. The produced data are values captured according to time and this type of data is called linear data in this work, as continuous values constitute the data of one variable. Due to large amount of data, including that of energy consumption, etc., most sensors capture values between intervals, for specific durations, or at different rate along time. Although the capture time may not be continuous, the produced data is a linear data and it is stored in a database attached to the sensor network. Suppose there are several sensor networks an organization operates, and a number of the organizations are located in a region. Consider a sort of attribute of a certain physical phenomenon should be attended in a region, an air temperature higher than the 50 degrees centigrade in the rooms of the buildings for example, so the regional fire brigades could be notified and turn out. In this case the data produced in the region should be huge and if a database of the server covered the region, it would be early overwhelmed. If the regional server does not have its database but organizations’ databases only store the data, the regional server need query to every database of each organization or every organizational server should prepare their data to the regional server periodically, for the regional command of the fire brigades. It is impractical to have the region database in capacity equal to summated capacities of all the organization databases and thus the amount of the aggregate data should be reduced. In reducing the amount, some information may be lost but in a way maintaining the useful ones. Fig. 1 depicts the concept of condensing, reducing the amount, from the sink node of bottom sensor nodes to the topmost central server with the coverage of a nationwide. There could be three modes in capturing values at sensor nodes. The first mode is continuous capturing, which the sensor captures values continuously. The second mode is discrete capturing, which the sensor captures values at specific times,

A Hierarchical Representation for Recording Semantically Condensed Data

71

i.e. periodically. The third mode is the composite capturing, which the sensor captures values continuously for durations with time gaps between the durations. Continuous capturing causes early energy drain and the other mode is preferred in many cases. The sensors produce linear data in each mode, and their data are collected in a sink node of the sensor network. The sink nodes send their data to the organizational server that has the organization database of the sensor networks the organization operates. Fig.2 shows this procedure that a region database is updated every interval.

Data base

Central Level: DB of the top server DBMS

Condensing

Data base

Regional Level: DB of distributed organizations Condensing

Data base

From the nodes on sensor network

Congregational Level: DB in an organization

Condensing

Data base

Recording every Time-interval

Peripheral Level: DB in a sink node

Fig. 1. Hierarchically upward condensing

Measured values

Time-interval Fig. 2. Linear data from sensor node

In reality, all of the large amounts of data are not necessary for every query. Thus the top server may not have stored all the data. A sensor data is a series of values in domain the sensor is able to capture. A number of physical phenomena have a characteristic that the captured values has their semantics defined according to the degree they belong to. For the regional command of fire brigades, for example, it is normal temperature below 50 degrees centigrade, but abnormal temperature over 50 degrees centigrade. Therefore whether the air temperature is over or below 50 could be the only interest of the regional command and then the region database may merely stores NORMAL or ABNORMAL. Near the physical phenomenon, at the organization of the sensor network, more distinctions should be necessary to immediately cope with imminent fire, and the organization database might store 4 statuses, ORDINARY, NOTICE, WARNING, DANGER, which is less condensed data. Each status has a meaning of the contiguous range the captured value could

72

M.H. Ok

belong to. Further those statuses are not necessarily stored continually since the start time of the status and the status value compose a tuple as a sufficient data. In general,

Ti = {t S , S } , where

(1)

Ti is the tuple of the sensor node with ID i, S is the status value, and t S is the

start time of the status. This is named as Semantic Condensing by ranges of captured values. If the status values are binary, even the status value could be omitted from the tuple, resulting a more condensed form. The database of Central Level in Fig.2 could store such a special tuple in the assumption the status must be NORMAL in the beginning.

3 Hierarchically Distributed Sensor Databases The distributed databases of the organizations are the essential entities in comprising an entire sensor database system. According to the coverage of interest, i.e., nationwide, regional, or organizational, the client may make request on the aggregate data to the central server, a regional server, or an organizational server, respectively. In this system, either sink nodes or the organizational server should maintain its database with uncondensed data so it can reply to queries for more detailed data delivered from the higher level. In building the hierarchically distributed databases depicted in Fig. 4, the cooperation between databases of the higher-level and the lower level is as follows;

Server of Higher-level 1. Request Information of the sensor data to the lower. 3. If the response is No Content, wait until Information is ready. 3. Otherwise, request sensor data with a condensing specification. 6. Receive and record in its database.

Server of Lower-level 2. Respond with information of the sensor data, or with No Content. 4. In the case responded with No Content, request Information of the sensor data to the lower. 4. Otherwise, receive a condensing specification. 5. Start to condense and transmit.

Fig. 3. Building process of hierarchically distributed sensor databases

The information the server of the higher-level requests are an upper limit, a lower limit and the resolution of the variable. The requested data is sent after condensing at the server of the lower level with other upper limit, lower limit and resolution as specified from the server of the higher-level. The building process is initiated from the central level to the organizational or peripheral level, and completed from the lower-levels to the higher-levels, to build the hierarchically distributed sensor databases. Multiple hierarchies of databases could be built with other sets of condensing specifications, as shown in Fig. 4.

A Hierarchical Representation for Recording Semantically Condensed Data Central Level

Regional Level

73

Condensed Aggregate data

Condensing Aggregation

Congregational Level

Fig. 4. Building process is completed from the lower-levels

Captured Values

Fig. 5. Condensing captured values

Once a database of the higher-level is built out of the databases of the lower-level, updates for new data should follow. Basically the time to send the new data follows the expression (1) to the database of the higher-level, i.e., when the status has changed. In applications the time the status changes is not crucial, the new data could be sent every a certain time-interval. Since the data being condensed are linear data based on time, the time gap between the latest records increases between the levels as the level is closer to the central level. For this reason, the building process may be initiated more than once if the time of the latest record is far from current time in the database of the central level. Only records of the omitted time are appended during this partial building.

4 Reduced Data by Semantic Condensing along the Hierarchy For many applications, the range of values is equally significant with the raw data gathered from sensor networks. In the cases, the distinction between aggregated data has the meaning equal to the exact value. For example, what high the temperature is equally meaningful to the exact temperature for the fire brigades. Furthermore, there could be intrinsic errors in the values captured. It is more evident in the cases some actuators are connected to the sensor networks to autonomously react to the data, i.e., whether the temperature is over 50 degrees centigrade. Conventionally the organization in the higher level uses briefed data of the organizations in the lower level, since it should manage all the events concentrated from the lower level. As higher in the hierarchy, the data need be more condensed in a way not losing its semantic meaning. Either sink nodes or the organizational server should maintain its database with raw data. Consider r levels in the hierarchy of the databases and level r is the topmost. The reducing rate at level 2 is the resolution of condensing from the raw data. The reducing rate at level 3 is the ratio of the resolution of level 2 to the resolution of level 3, and so on. This reducing rate enlarges along the hierarchy, as shown in Table. 1, which is an example the resolution of condensing is requested by 50% at each level.

74

M.H. Ok Table 1. The reducing rate enlarges along the hierarchy Level of Database 1st-level 2nd-level

Resolution of Condensing 100% 50%

3rd-level

50%

M r th-level

50%

M

Reducing Rate

1 12 14

M

1 2 r −1

In general, the reducing rate of data to be transmitted and stored, at least, in the hierarchy of the distributed databases;

Sr , is as follows,

r

S r ≥ ∏ Rh ,

(2)

h =1

where

Rh is the resolution of data at the h-th rank in the hierarchy, supposing the

bottommost is the 1st rank and the resolution of higher-level is lower than that of lower-level, for every level. While the status value does not change, i.e., the newly captured value is still in the same range, the reducing rate gets much higher. The reducing rate is acquired at the cost of losing much data not interested. In addition, other parallel hierarchies could be necessitated for other interests. Assume a new application is required for other purpose to process data from the same sensor networks, as shown in Fig. 4. The new application requests different resolutions of condensing in the middle of the hierarchy, thus builds a new hierarchy different from the middle. The data of the new hierarchy of other interests also take place in the databases. In this scenario, the effect of semantic condensing decreases, however it should be efficient to condense the data semantically than not to condense, unless the amount of condensed data is larger than that of raw data by the number of hierarchies built excessively. Semantic condensing has another merit of indexing to the data, similar to Domain Name Service, which means faster access to the data.

5 Related Works The nationwide sensor database system of this work is similar with the concept of Virtual Sensor[5]. Virtual sensors abstract from implementation details of access to sensor data and define the data stream processing to be performed. Local and remote virtual sensors, their data streams and the associated query processing can be combined in arbitrary ways and thus enable the user to build a data-oriented ‘Sensor Internet’ consisting of sensor networks connected via a global sensor networks. The coalition of virtual sensors is Virtual Sensor Networks (VSN)[6] to provide protocol support for the formation, usage, adaptation and maintenance of subsets of sensors collaborating on specific tasks. Its example introduced the functionality including the support for nodes to join and leave VSNs, broadcast within a VSN, and merging of VSNs.

A Hierarchical Representation for Recording Semantically Condensed Data

75

While those works have proposed the concept, mechanisms, and benefits of using VSN, an XML extension technique called Stream Feed[7] has addressed the sensor data-stream and evaluated their technique against the large streaming data object. As the sampling interval decreases the number of clients reduced, and as the network is deeper the latency increased. They are natural results but a big obstacle in creating an application of sensor database with a nationwide coverage.

6 Summary with Future Work The hierarchically distributed databases store the condensed data of one kind of sensors. Some of servers could request exchanging their condensed data each other to form new data by combining the data of different kinds of sensors. The organization could operate the networks of other kind of sensors, i.e. the sensor for temperature and one for smoke. Captured data of smoke sensors should be helpful in detecting the occasion of fire, in the previously described example. The reduced amount of data lessens transmissions over network, and should be also helpful in exchanging the condensed data. A condensing method is proposed to reduce the amount of data to be transmitted and stored, by condensing the data according to semantics. The building and updating processes are suggested for hierarchically distributed sensor databases. Although only the method of condensing ranges into semantic values is addressed in this work, there could be another method of semantic condensing by purposes. If there is a set of specific thresholds on one variable and a semantic value is assigned when the value captured is greater than one of the threshold, the status value should be one of the semantic value. In this case the set of specific thresholds are the information for semantic condensing, not an upper limit, a lower limit nor the resolution. Semantic values resulted from a complex combination of conditions also possible, and thus this is why the semantic condensing is different from a generic coding. The reduced size of data becomes an advantage in pervasive computing. The briefed data could diminish the load of applications running on resource-constrained devices, such as handheld devices, by semantic condensing. It is also preferable in creating applications of nationwide smart space for use in pervasive computing.

References 1. Balazinska, M., Deshpande, A., Franklin, M.J., Gibbons, P., Gary, J., Nath, S., Hansen, M., Leibhold, M., Szalay, A., Tao, V.: Data Management in the Worldwide Sensor Web. IEEE Perv. Comp. 6(2), 10–20 (2007) 2. Henricksen, K., Robinson, R.: A Survey of Middleware for Sensor Networks: State-of-theArt and Future Directions. In: International workshop on Middleware for sensor networks, pp. 60–65. ACM, New York (2006) 3. Campbell, J., Gibbons, P.B., Nath, S.: IrisNet: An Internet-Scale Architecture for Multimedia Sensors. In: Annual ACM international conference on Multimedia, pp. 81–88. ACM, New York (2005)

76

M.H. Ok

4. Deshpande, A., Nath, S., Gibbons, P.B., Seshan, S.: Cache-and-query for wide area sensor databases. In: ACM SIGMOD international conference, pp. 503–514. ACM, New York (2003) 5. Aberer, K., Hauswirth, M., Salehi, A.: Infrastructure for Data Processing in Large-Scale Interconnected Sensor Networks. In: International Conference on Mobile Data Management, pp. 198–205. IEEE, Mannheim (2007) 6. Jayasumana, A.P., Han, Q.: Virtual Sensor Networks - A Resource Efficient Approach for Concurrent Applications. In: International Conference on Information Technology, pp. 111– 115. IEEE CS, Las Vegas (2007) 7. Dickerson, R., Lu, J., Lu, J., Whitehouse, K.: Stream Feeds - An Abstraction for the World Wide Sensor Web. In: Floerkemeier, C., Langheinrich, M., Fleisch, E., Mattern, F., Sarma, S.E. (eds.) IOT 2008. LNCS, vol. 4952, pp. 360–375. Springer, Heidelberg (2008)

CAMS 2009 PC Co-chairs’ Message

In the four years since the first CAMS workshop, context awareness has become an increasingly commonplace tool for mobile developers. The limited screen displays of many mobile devices mean that content must be carefully selected to match the user’s needs and expectations, and context provides one powerful means of performing such tailoring. Furthermore, increasing availability of additional hardware sensors has bolstered the use of context. GPS, Near-Field Communication, Bluetooth and WiFi have all been used to sense the general environment and to determine the devices’ location. Light and tilt sensors have also been used to tune simple features such as the strength of the display lighting, through to complex uses in game control. Context-aware mobile systems are becoming ubiquitous. With this hardware comes the opportunity for “on-board” applications to use location data to provide new services — until recently such systems could only be created with complex and expensive components. Furthermore, the current “mode” of the phone (e.g., silent, meeting, outdoors), contents of the built-in calendar, etc., can all used to provide a rich context for the user’s immediate environment. However, there is much to learn from a computer science perspective: context is a plastic and variable concept that can be realized in many ways — from the early notions of location-based services, through social navigation techniques based upon profiling of users, to concepts of work processes and information journeys. Together, these differing forms of context provide a challenging diversity of data which needs to be brought together and consistently and rapidly processed. These demands provide a strong testbed of contemporary techniques for modelling context, particularly when the network and processing capacities of mobile systems are considered. The Fourth Context Aware Mobile Systems (CAMS) workshop had a strong set of paper presentations. Papers covered the spectrum of context-aware mobile systems: the traditional basis of location, exploiting new sensor types, the processes of personalization and profiling, emerging areas such as interface design and ontologies, plus engineering requirements such as development models and architectural frameworks. The global nature of the research in this area is also reflected in the wide spread of countries represented by the authors. We selected the six best papers from an original array of over 30 expressions of interest. We are indebted to our review team, who helped us identify the very best outputs from the many submissions. Annika Hinze George Buchanan

R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, p. 77, 2009. c Springer-Verlag Berlin Heidelberg 2009 

Rethinking Context Models* Emiliano Pérez1, Andrés Fortier1,2,3, Gustavo Rossi1,3, and Silvia Gordillo1,4 1

LIFIA. Facultad de Informática. Universidad Nacional de La Plata, Argentina 2 DSIC. Universidad Politécnica de Valencia, Valencia, España 3 CONICET 4 CICPBA {eperez,andres,gustavo,gordillo}@lifia.info.unlp.edu.ar

Abstract. Since the first context-aware applications were designed, context modelling has played a central role. During the last decade many different approaches were proposed to model context, ranging from ad-hoc models to extensions to relational databases or ontologies. In this paper we propose to take a step back and analyse those approaches using the seminal views presented by Paul Dourish in his work (What we talk about when we talk about context). Based on that analysis we propose a set of guidelines that any context model should follow. Keywords: Context-awareness, context modelling, pervasive computing, software architectures.

1 Introduction The basic aim of a context-aware (CA) application is to adapt its behaviour in one or more aspects according to its context. Here, the word adaptation is used in a broad sense, comprising actions like changing the application’s presentation, the displayed content [1] and performing proactive [2] or reactive actions [3]. However, in order to perform some kind of adaptation, we must first have an internal representation of what is considered context by the application, which in other words means having a context model. This last issue is not a simple one, since the context model highly depends on the application’s requirements. In the extreme case, each application may need to define what context is and how it is represented to best suit its needs. On top of that, it is not possible to define beforehand what context will be used for; even the same context model can be used by two different applications to perform completely different things. As an example of these two issues, consider modelling a user’s location: while a smart home may need a model based on rooms (i.e. in which room the user is in) a friend finder may need a (latitude, longitude) model. On the other hand, an emergency system may reuse the context model used in the friend-finder application, but use it to send an ambulance instead of finding known people. Defining context is not simple job and many authors have already engaged in that assignment. As Paul Dourish states [4] “Context” is a slippery notion. Perhaps * This paper has been partially supported by the SeCyT under the project PICT 32536. R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 78–87, 2009. © Springer-Verlag Berlin Heidelberg 2009

Rethinking Context Models

79

appropriately, it is a concept that keeps to the periphery, and slips away when one attempts to define it. However the important part of his article is not the quote, but the two opposite views of context that Dourish describes. In short, while the “technical” view treats context as a representation issue (i.e. How do I represent context inside a computer program?), the “social” view treats it as an interaction issue (i.e. How does context emerge from the interaction?). Even though both views are presented as contrary, they are of great importance to CA software engineering, since their underlying nature can help us to model context in our programs and understand how that context is generated. The aim of this paper is to share our ideas regarding context models and to encourage the discussion around this topic. These ideas are the theoretical emergent of our previous works [5, 6, 7]. In this paper our contribution is two-folded: • •

We evaluate different context models types according to the concepts presented in Dourish’s article. We present a set of preliminary guidelines to be considered when defining context models.

2 What We Talk about When We Talk about Context In this section we will briefly summarise the two views presented by Dourish [4], since they will be referenced throughout the rest of the paper. The positivist view is maybe the one that most software developers consider as straightforward, since it attacks the context modelling problem on a concrete level. In this view the main concern is how to represent the context information in a computer, thus converting the problem of modelling context in a representational one. What context is and how will it be represented depends of the application requirements. We next summarise the four main aspects of the positivist view, as stated by Dourish: 1. Context is a form of information. It is encoded and represented as any other application data. 2. Context is delineable. The application requirements define what pieces of information will be considered as context. 3. Context is stable. As the elements that represent the context can be determined once and for all, the structure of the context doesn’t need to change. 4. Context and activity are separable. The approach is only concerned with capturing the data, without keeping a relationship to the action that generated it. The phenomenological view takes an opposite position, since it considers context as an interaction problem rather than a representation one. In this approach the information that represents the context of an entity is subject to the current situation and the point of view of the observer. Context becomes a subjective concept and it is no longer a predefined entity; the focus is now shifted to a contextuality relationship between two or more entities, where an entity becomes contextually relevant to the other in a given moment. In this view the four key aspects are: 1. Context is a relational property that holds between objects or activities. Something may or may not be contextually relevant to other entity or activity at a given time.

80

E. Pérez et al.

2. Context can’t be delineated beforehand, since it is constantly being redefined. 3. Context is particular to each activity or action. Contextual information is an occasioned property, relevant to particular settings, particular instances of action, and particular parties to that action. 4. Context arises from the activity. Contextual information is actively produced, maintained and enacted in the course of the activity at hand, thus context can’t be separated from the action(s) that created it. It is interesting to notice that different ways of defining context have been around for some time in the CA community. As a result two main trends appeared: one where the possible context data was explicitly enumerated [8] (e.g. context is location, time and activity) and a more general one, where any information that can be used to describe a subject’s or his medium can be considered context (maybe Dey’s [9] definition1 is the most popular in this area). Instead of advocating for a radical view we consider that a lot can be learned from trying to reach a balance between both approaches. The positivist view has the advantage of placing us (the architects, designers and developers) in a field that we are used to, where the requirements are stated and the problem boils down to design and implement an application. On the other hand, this approach looses many aspects of context interactions and becomes too rigid to finally achieve the original ideas behind UbiComp [10]. In this sense, the phenomenological view is better suited, since it focuses on relationships and how those relationships evolve with time. However, this view has a lack of formality, something required to design and implement an application. Thus a deeper analysis must be made to define the requisites for a context model that can be represented in a program while being flexible to easily accommodate changes.

3 Approaches for Context Modelling Since the first CA applications appeared the problem of modelling context has been attacked from different perspectives, each one with its specific trade-offs. To analyse them we will use the taxonomy presented in [11] and we will show how some of these categories relate to the presented views of context. 3.1 Key-Value Models Maybe a first step towards creating a structured context model is to represent context as a collection of key-value pairs. When using this approach the context in encoded in a set of pairs, whose key is generally a unique identifier and its value is the context aspect that the developer is trying to capture. Also, even though it is not a restriction, the context “values” are generally simple data types, like numbers, arrays or strings. A typical example of a user location using this approach would be .

1

Context is any information that can be used to characterise the situation of an entity. An entity is a person, place, or object that is considered relevant to the interaction between a user and an application, including the user and applications themselves.

Rethinking Context Models

81

Context tuples can be managed in different ways according to the architecture. In some cases the tuples are passed from the sensors straight to the upper layers (adaptation and reaction) [12] whereas in other cases tuples are sent to a tuple space that is shared among different processes or applications [13]. This approach for context modelling clearly fits the positivist view better than the phenomenological one, since: • • • •

Context is a form of information and is encoded in tuples. Context is delineable because it is explicitly represented by tuples. Context may not be stable. There is no structure of context and its shape may vary freely, especially when different providers feed a shared tuple space. Context and activity are separable. Most approaches take this assumption since there is no association between the tuples value and the process where this information emerged from. However, tuples could be tagged with metadata to keep the link between context data and the activity that produced it.

3.2 Markup-Based Models Evolving from the key-value approach we find several models that use variations of markup languages (such as XML) to represent contextual information [14, 15]. These models present an improvement over the tuple-based models since they allow hierarchical structures and the possibility to add extra information besides the keyvalue pair by means of specific tags or tag-attributes. Mostly, the markup documents (often called profiles [11, 15]) are used to store static information about an object. Because of their nature they are highly portable and thus especially adequate for distributed systems that use hybrid technologies (e.g. web services). On the other hand, profiles are defined as static structures, largely used to describe the capabilities of specific hardware or software components. Although this approach enhances the previous one form the phenomenological point of view, it is still associated to the positivist view: • • • •

Context is a form of information and is encoded in markup tags. Context is delineable because we can determine which aspects will be relevant to each profile following the XML schema. Although it may be built dynamically, context is well structured and usually stable since it is explicitly represented by serialised XML structures. Context and activity are separable. The profiles are independent tagged documents and are configured statically prior to its use.

3.3 Relational-Based Models Another widely used method for building context models is by using a relational database (RDB). This approach has the advantage of being a well-understood technology that is backward compatible with legacy data. Current RDB context models are used to store preconfigured preferences [16, 17] but have great capability to produce new context dependent information performing specialized queries. In approaches like [16] context is directly considered in the SQL clauses (using views or specifying it in the WHERE clause), while other models use

82

E. Pérez et al.

enhanced DBMS that support special context-dependent clauses (e.g. [17] uses OLAP operators to process CA queries). In general, RDBs store context information as attributes in relationships tables [17], which means that the context model structure is defined by the RDB layout. In order to change the context shape the database structure has to be modified and although it may not represent a major rewrite, it certainly cannot be done easily at runtime. Approaches like these are best suited for situations in which context relevancy is predefined (user preferences, device characteristics, etc.) or when the functionality of the application is limited to context-dependent data retrieval. Considering the main aspects of this approach we find that: • • • •

Context is a form of information stored in relational database tables. Context is delineable by the table structure that represents the relationship between the context information and the entities. Context structure is stable. Changing the context shape implies redefining the RDB structure, which is almost never done at run time. Context and activity are separable. Databases can only represent the context data in tables, thus losing the link to the activity that created it.

3.4 Ontology-Based Models Ontologies are used to define relationships between concepts and later use that information for reasoning. An ontology consists mainly of a knowledge base (KB) that represents the domain concepts and the relationships between them. The information in an ontology is accessed and processed by interpreters (also called reasoners or reasoning engine) [18] independent to the KB itself. Because of this decoupling, a specific KB can be used by different systems for different proposes. Ontologies support incremental modification of the KB in a collaborative fashion and allow for two main kinds of reasoning [19]. The first one is to infer new relationships from the existing ones (e.g. transitive relationships, inverse relationships, etc.) whereas the second is to express new rules in first order logic predicates (e.g. if a condition is met, a new relationship is created). For instance, an ontology that models the user location can be used to easily convert it between different representations using reasoners (e.g. from GPS coordinates to streets). The flexibility and benefits of ontologies come at a cost, since the concepts and relationships must be built and agreed by a set of users. Also, conflicts may arise regarding the ontology model. Because of this, to think of an ontology general enough to model any context domain that is effectively usable seems hardly feasible. However, we believe that once defined a particular context domain (such as location, activity, mood, etc) ontologies are of great help to develop CA systems. Regarding the use of ontologies for modelling context we can summarise it in the following statements: • •

Context is information and it is stored in dynamic documents or databases. Context is not necessarily delineable because context-relevancy can be determined dynamically by the use of reasoners.

Rethinking Context Models

• •

83

Context structure is not stable. The evolution capabilities of ontologies allow the structure of the context information to evolve from the use and configuration. Context can evolve from activity. This relationship can be expressed using reasoners that react upon the current situation.

3.5 Conclusion All these models present different characteristics, but in general they all describe the context as data somehow related with the domain model. Although they all aim to solve similar problems, each approach is intended for a particular setting and has a specific scenario for which it was developed. In Section 2 we presented the phenomenological view as an interesting way to think about what context is and how it is relevant to entities, while in this section we made a brief analysis on current ways to represent the context information in computing software. Most of the approaches revised take the positivist point of view, being the ontology-based models the ones that are closer to the phenomenological view. In the following section we will aim for a balance between the two interpretations in order to consider the philosophy behind the concept of context, without forgetting that we need to represent it as information usable by a program.

4 A Balance between Positivism and Phenomenology The phenomenological view seems to characterise context in a more realistic way than the positivist one. Consider a typical mobile user who is permanently exposed to social interactions. Such scenario is bound to have unpredictable and constantly changing contextuality relationships. However, in order to incorporate CA behaviour in our software we need some sort of formalisation; we must use a context representation that characterises these relationships between objects and situations. Ultimately we must cope with the tension between the phenomenological and positivist approaches, tackling the representational problem of context in a way that is as close as possible to the phenomenological approach. To perform this analysis we decided to restrict ourselves to the object oriented paradigm and evaluate how the phenomenological ideas could be applied to an OO context model. To keep things simple we use the “pure” definition of the OO paradigm [20], where an application can be seen, in a reductionist way, as a set of objects collaborating with each other by sending messages. Thus the behaviour of an application is scattered in a set of objects, which are responsible for implementing certain responsibilities [21]. This basic statement, which may seem trivial at first, it’s actually one of the cornerstones for our proposed guidelines. From the characterisation of the phenomenological approach we can see that context is not data floating around in our program or a row in a database. When we refer to context, we are referring to what is contextually relevant for someone (or something) at a given point. Here we would like to stress the mention of the subject (someone or something), which means that context can’t exist by itself. Translating this idea to the OO paradigm, modelling context becomes modelling what is

84

E. Pérez et al.

contextually relevant for a given object. This idea applies both to domain models that already exist (e.g. knowing the location of a student object in a university information system) or to entities that were not conceived before (e.g. to adapt our application to the network’s bandwidth we must model the network connection first). We consider this statement so important that is actually the first of our design guidelines: 1. Context information is always bound to an object. In order to manage context information, we must first define whose context it is. By applying this first guideline an interesting characteristic arises regarding how context information is arranged in an application: since the context is part of an object, there is no notion of a context repository or database. In fact, context appears as distributed information and “the context” (as referred to in many publications) is actually the aggregation of each object’s context. Thus, our second guideline states: 2. Context is not a monolithic piece of data, but information distributed across objects in our application. To clarify this first two guidelines consider a system where services are provided to a user. In such system we would find classes like User and Service. If we want to support location-based services (e.g. showing restaurants near the user) we would need to associate context information to the user object. Now suppose that we also want to support interaction with other users to provide location based services (e.g. sending an invitation for launch to a group of friends and finding the restaurant that is convenient for all of them). In our approach this requirement is satisfied naturally, since the group context is actually the aggregation of the individual context of each user. Both guidelines are addressed in our previous work [6] by aware objects and context features. Different applications may have different context requirements, even for the same application object. For example, the user’s location is a required feature for a route planner but for a CA agenda it may be an optional feature; since it can be useful to provide a better service, but it is not mandatory. Finally the user’s location may be of no use for an application whose adaptation behaviour is to be able to present information on different devices. However, all the applications mentioned before may have as a central actor the same user object (e.g. representing the owner of a PDA). These different ways of viewing a user’s context can be related to the work of Gershenson [22], who distinguishes the notions of absolute (a-being) and relative (rebeing) being. As defined by the author, the a-being is the absolute and infinite being, independent of the observer. On the other hand, the re-being is how an entity is represented and treated by an observer, shaped by the current context of the observer and the entity. Thus, when modelling an object’s context we are choosing a specific view of the subject and deciding what is contextually relevant. This leads to the third design guideline: 3. A context model should support different context representation of the same subject, according to the adaptation required.

Rethinking Context Models

85

This guideline is achieved in our prototypes [6, 7] by the use of adaptation environments. If we go back to Dourish’s work on context views, a conflicting issue arises: the positivist view assumes that the context “shape” (i.e. what do we consider to be context) is fixed while the application is running, whereas the phenomenological view argues that context is constantly being reshaped. This reshape can be the outcome of losing the means to acquire an existing context feature (e.g. losing a GPS signal tracking a location) or a change in the application functionality (e.g. adding time constraints to the location based services). As a result, we would expect the context of any object to be re-shaped due to different forces (sensor availability, privacy, contextual relevance, etc). From this observation we derive the fourth guideline: 4. The context shape associated to an object should be changeable at run time. From the designer point of view, context modelling is a difficult task since a balance between flexibility and reusability must be met. In other words, we would like to have a structured context model that allows high-reuse while at the same time we would like our context model to be as flexible as possible. To handle this issue (and taking into account our previous guidelines) the context model should allow different context-domains to be modelled with different approaches. Thus, we may find useful to model a user’s location with an ontology, while his (static) personal data is stored in a profile: 5. Context should be separable and modelled in a domain-basis, allowing each context domain to be realized using a different modelling technique. Finally, a topic that we must address is the second item in the positivist characterisation of context. This item states that context is delineable for an application and that this can be done in advance. This is another issue that we must balance, since we must have a set of fixed requirements to develop an application but we must be flexible enough to quickly accommodate new requirements. In our approach we consider that it is impossible to define in advance all the possible types of context an application can use. Each application will have its own context requirements and it is very likely that future killer applications make use of context information in novel ways. Thus, instead of trying to build the context ontology we rather prefer to mount a skeleton that allows new domains to be defined and quickly prototyped to suite the application’s needs. This leads to our sixth guideline: 6. A context model should define a basic structure and be extensible to accommodate new context requirements. In our approach [6] these last three guidelines are addressed by the relationship between the aware objects and the context features, since run-time changes are naturally supported and each context domain is encapsulated inside a context feature. The guidelines presented so far are the result of trying to reach a balance between the two views presented by Dourish. To end this section we will analyse our proposal in the same way we did with the other approaches:

86

E. Pérez et al.

1. Context is a relationship between objects. An object is, at a given time, contextually relevant to other object(s). 2. Context is delineable by accounting the relationship between objects. 3. Context may not be stable. There is no restriction regarding the lifetime of the relationship between objects. 4. Context and activity are separable. Even though this is true, what is not separable is the context from its subject. If needed, by using a Command [23] pattern we can even associate actions with context. By specifying our guidelines our aim is to take Dourish views of context to a more concrete level, where the requirements for context models can be stated. Since this is an ongoing work, these guidelines should not be considered as definitive principles, but as a starting point to define what we need to build scalable context models.

5 Discussion and Further Work In this paper we have presented a set of guidelines for creating flexible context models. These guidelines are not tied to a specific programming language or technology, since we aim to express them as universally as possible. Our only assumption throughout the paper is that the context model will be implemented using the object-oriented paradigm. The guidelines presented are the theoretical emergent of different applications and case studies we developed. We are currently working on a context model that follows these guidelines, which is based on a reflective layer that allows us to attach context information to any object in the application model and then build adaptation modules for different context-aware applications. On a more theoretical side we are currently analysing the relationship between the underlying application model and those objects that account as context. As Dourish states “The participants may change the subject or otherwise turn a matter from one of middling relevance to central relevance […]. They might turn the location of the conversation from “context” to “content” by remarking that it’s too public a place and perhaps they should move elsewhere. This means that, what is considered context at a given point, may be later considered as core application model (i.e. that the context has gained enough relevancy to become core behaviour) and vice versa. Coping with these changes is still and open issue for us.

References 1. Pascoe, J.: Adding generic contextual capabilities to wearable computers. In: IEEE International Symposium on Wearable Computers (1998) 2. Leonhardt, U.: Supporting Location-Awareness in Open Distributed Systems. PhD thesis, Dept. of Computing, Imperial College (1998) 3. Lamming, M., Flynn, M.: Forget-me-not: Intimate computing in support of human memory. In: Proceedings FRIEND21 Symposium on Next Generation Human Interfaces (1994)

Rethinking Context Models

87

4. Dourish, P.: What we talk about when we talk about context. Journal of Personal and Ubiquitous Computing 8(1), 19–30 (2004) 5. Rossi, G., Gordillo, S., Challiol, C., Fortier, A.: Context-Aware Services for Physical Hypermedia Applications. In: Meersman, R., Tari, Z., Herrero, P. (eds.) OTM 2006 Workshops. LNCS, vol. 4278, pp. 1914–1923. Springer, Heidelberg (2006) 6. Challiol, C., Fortier, A., Gordillo, S., Rossi, G.: Architectural and Implementation Issues for a Context-Aware Hypermedia. Journal of Mobile Multimedia (2008) 7. Challiol, C., Fortier, A., Gordillo, S., Rossi, G.: A flexible architecture for context-aware physical hypermedia. In: DEXA 2007: Proceedings of the 18th International Conference on Database and Expert Systems Applications, pp. 590–594. IEEE, Washington (2007) 8. Brown, P.J., Bovey, J.D., Chen, X.: Context-aware applications: from the laboratory to the marketplace. Personal Communications, 58–64 (1997) 9. Dey, A.K., Abowd, G.D., Wood, A.: Cyberdesk: a framework for providing selfintegrating context-aware services. Knowledge-Based Systems 11, 3–13 (1998) 10. Weiser, M.: The computer for the 21st century. In: Human-computer interaction: toward the year 2000, pp. 933–940. Morgan Kaufmann, San Francisco (1995) 11. Strang, T., Linnhoff-Popien, C.L.: A context modelling survey. In: Workshop on Advanced Context Modelling, Reasoning and Management. UbiComp, Nottingham, England (2004) 12. Samulowitz, M., Michahelles, F., Linnhoff-Popien, C.L.: Capeus: An architecture for context-aware selection and execution of services. In: New developments in distributed applications and interoperable systems (2001) 13. Schmidt, A., Van Laerhoven, K.: How to build smart appliances? Personal Communications, 66–71 (2001) 14. Han, J., Cho, Y., Choi, J.: A Workflow Language Based on Structural Context Model for Ubiquitous Computing. In: Yang, L.T., Amamiya, M., Liu, Z., Guo, M., Rammig, F.J. (eds.) EUC 2005. LNCS, vol. 3824, pp. 879–889. Springer, Heidelberg (2005) 15. WAPFORUM, User Agent Profile (UAProf), http://www.wapforum.org 16. Bolchini, C., Curino, C.A., Orsi, G., Quintarelli, E., Rossato, R., Schreiber, F.A., Tanca, L.: And what can context do for data? Communications of ACM (to appear) 17. Stefanidis, K., Pitoura, E., Vassiliadis, P.: On Supporting Context-Aware Preferences in Relational Database Systems. In: International Workshop on Managing Context Information in Mobile and Pervasive Environments (2005) 18. Chen, H., Finin, T., Joshi, A.: Using owl in a pervasive computing broker (2003) 19. Hong, M., Cho, D.: Ontology Context Model for Context-Aware Learning Service in Ubiquitous Learning Environments. International Journal of Computers 2(3), 172–178 (2008) 20. Kay, A.C.: The early history of smalltalk. SIGPLAN Not. 28, 69–95 (1993) 21. Wirfs-Brock, R., Mckean, A.: Object Design: Roles, Responsibilities and Collaborations. Addison-Wesley, Reading (2002) 22. Gershenson, C.: Contextuality: A Philosophical Paradigm, with Applications to Philosophy of Cognitive Science, POCS Essay, COGS, University of Sussex (2002) 23. Gamma, E., Helm, R., Johnson, R., Vlissides, J.: Design Patterns. Addison-Wesley Professional, Reading (1995)

A Framework for Decentralized, Context-Aware Mobile Applications Using Semantic Web Technology William Van Woensel, Sven Casteleyn, and Olga De Troyer Vrije Universiteit Brussel, Pleinlaan 2, 1050 Brussel, Belgium {William.Van.Woensel,Sven.Casteleyn,Olga.DeTroyer}@vub.ac.be

Abstract. The recent evolution in mobile devices, combined with rapid advancements in identification techniques, has lead to new opportunities for mobile application developers: mobile applications that can be made aware of their environment and the objects in it. Additionally, by combining mobile devices and identification technology with the Web, mobile applications can be developed that exploit services and information associated with nearby objects. In this paper, we present an application framework that supports the development of such mobile applications, without having to rely on a central service to provide information on the user’s environment. Furthermore, by deploying Semantic Web technology, the integration of information from various information sources is facilitated, allowing for expressive and powerful personalized information delivery. Keywords: Mobile Web, development framework, context-awareness, mobility, personalization.

1 Introduction In the current mobile Web, users typically use their mobile device (e.g., smart phone, PDA, portable game console) to access the Web using a dedicated mobile browser (e.g., Skyfire, Opera Mini). Although this makes the Web accessible anywhere and anytime, the limitations of mobile devices (e.g., small screen, limited input capabilities, processing power and bandwidth) still hinder the widespread mobile use of the Web. Furthermore, in a mobile setting (e.g., driving, walking, sightseeing), users are often unable or reluctant to spend large amounts of time browsing and locating the information or services they need at that particular moment and place. Nevertheless, modern mobile devices often have features that enable the tailoring of information and service delivery. For instance, GPS-enabled mobile devices offer the possibility to determine the user’s location, and current identification technologies (e.g., RFID technology) allow a mobile device to detect entities and other (mobile) users in the user’s environment. Furthermore, by combining these capabilities with some basic knowledge on the mobile user (i.e., background, preferences, etc.), it is possible to offer a fully personalized mobile experience. In this article, we present the mobile application development framework SCOUT (Semantic COntext-aware Ubiquitous scouT) that supports the development of context-aware mobile applications, which offer relevant information and services R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 88–97, 2009. © Springer-Verlag Berlin Heidelberg 2009

A Framework for Decentralized, Context-Aware Mobile Applications

89

depending on the mobile user’s environment and particular needs at a given time and place. In contrast to most existing approaches (see related work), SCOUT is a scalable, decentralized and distributed solution, where no single centralized server is required and where each identifiable entity is responsible to provide and manage its own data and services in the form of a Web presence [2-5]. These can range from simple Websites/Web services to online sources providing structured information (e.g., RDF files). Due to its open, decentralized and distributed nature (together with its ubiquitous availability), the Web is the ideal platform for deploying these presences, as it fits the desired properties of our framework perfectly. Furthermore, it allows re-use of the wealth of descriptive information already available online (e.g., existing Web pages, RDF information such as FOAF profiles) as Web presences. By employing Semantic Web standards and vocabularies to describe Web presences in a uniform and expressive way, the SCOUT framework allows seamless integration and querying of data from (several) different entities, thereby providing mobile applications with a richer and more complete view on the global environment. In this article, we illustrate the framework and its usage by means of a real-world scenario, consisting of a mobile user exploring the authors’ university campus using his/her mobile device. Here, we will focus only on the delivery of information. The remainder of this article is structured as follows. In the next section, we provide a global overview of the proposed SCOUT framework, and elaborate on each of the layers using our university campus scenario. In section 3, we present related work, and section 4 states conclusions.

2 SCOUT: An Overview The SCOUT framework uses a layered architecture, which clearly separates the different design concerns and thus assures independence between layers and from underlying technologies. Fig. 1 shows an overview of the architecture; each layer is explained in more detail in the subsequent subsections. 2.1 Detection Layer The Detection Layer is responsible for detecting identifiable physical entities in the vicinity of the user, and subsequently obtaining the reference to the corresponding Web presence. The Detection Layer thus contains components that encapsulate different detection techniques (e.g., RFID, NFC, Bluetooth, etc), which can extract references to Web presences for use by other layers. By encapsulating these components in a separate layer and by having them implement a uniform interface, the framework can transparently switch from one technique to another (or using several of them in parallel), depending on what detection techniques are available and which are supported by nearby entities. Consider our university campus scenario, where several points of interest and test subjects on the campus have been tagged with an RFID tag, which contains a reference to their corresponding Web presence (i.e., a URL). RFID detection is an example of a “direct” detection technique: the reference to the Web presence is

90

W. Van Woensel, S. Casteleyn, and O. De Troyer

directly obtained from the detected entity. In contrast, “indirect” detection techniques are used when the reference to the Web presence cannot be directly obtained, and a third party service needs to be accessed to obtain the Web presence. For instance, a remote location service can be deployed for a specific region, providing a set of URLposition bindings in a certain area around the user (respectively denoting the Web presence reference and the physical entity’s coordinates). SCOUT supports the aforementioned techniques, RFID and third party services, by means of dedicated components in the Detection Layer.

Fig. 1. SCOUT architecture layers

The direct detection technique has been implemented by a component that wraps an RFID reader; for the indirect detection technique, we have provided a component that frequently queries the location service for nearby Web presences, as well as the location service itself (i.e., a Web server application that serves URL-location bindings).

A Framework for Decentralized, Context-Aware Mobile Applications

91

2.2 Location Management Layer The responsibility of the Location Management Layer is to determine which entities are nearby (and no longer nearby) the user, based on information obtained from the Detection Layer. A “positional” relation is created when a detected entity is determined to be nearby. Once the relation is created, the Location Management Layer is responsible for maintenance of the relation; more specifically, to invalidate the relation when the related entity is no longer nearby. By providing positional information in this conceptual way, applications can abstract from the details of dealing with raw positional information. In order to determine when an entity is nearby or no longer nearby, the SCOUT framework deploys so-called nearness and remoteness strategies, respectively. Collectively, we call them proximity strategies. We now refer back to our university campus scenario where a mobile application, using the Detection Layer, is now able to determine which entities are in the user’s vicinity. Our mobile user walks past a physical entity, e.g., a reproduction of Rodin’s The Thinker statue on the university campus. As The Thinker statue is tagged with an RFID tag, it can be detected by a mobile device supporting RFID reading. Because the mobile device in our setup features a short-range RFID reader, nearness of the artifact can be directly inferred, as the detection range of our reader is smaller than the nearness distance. However, this also means that remoteness cannot be directly inferred (i.e., the fact that the entity cannot be detected does not necessarily mean it is no longer within the nearness distance). Therefore, we must deploy a remoteness strategy where the entities’ absolute positions are compared (namely the absolute position of the user and the entity’s position) and the positional relation in question is invalidated in case the difference exceeds the nearness distance. For non-stationary entities, this remoteness strategy is extended to allow for regular position updates of the detected physical entity. This scenario illustrates that the choice of remoteness strategy can be decoupled from the choice of nearness strategy; in this case, this allows us to cope with the limited range of our RFID reader. In the current version of our framework, we provide support for a variety of nearness and remoteness strategies. 2.3 Environment Layer The Environment Layer stores and integrates data about the entity and its current environment, and provides services to obtain information from nearby Web presences in both a push-and pull-based manner. As mentioned before, our framework leverages Semantic Web technologies to more easily and effectively combine information from different Web presences; additionally, the reasoning capabilities of the Semantic Web standards can be exploited to infer additional data.1 In the following subsections, we discuss the components from this layer in more detail. 2.3.1 Relation and Entity Models These models contain the basic information needed for personalization. The Relation Model provides fundamental environmental information by storing the positional 1

The latter is however outside the scope of this article.

92

W. Van Woensel, S. Casteleyn, and O. De Troyer

relations the entity is / has been involved in, along with references to the Web presence of the related entities. This information is provided by notifications of the Location Management Layer upon creation and invalidation of positional relations. The Relation Management component (see Fig. 1) provides a view on these relations, allowing both querying of and programmatic access to this information. Aside from currently active positional relations, this model also keeps all past relations the entity was involved in, along with creation and invalidation time stamps. The Entity Model is responsible for storing metadata on the entity. In most cases, the entity will be a person, in which case this model is commonly called the User Model (e.g., [16]) and stores certain preferences and characteristics of the user. Several existing ontologies can be reused to represent a person’s metadata: CC/PP2 to represent preferences and mobile device capabilities; FOAF3 or vCard4 for representing a person’s profile, DCMI5 to describe documents and items, etc. The Entity Management component (see Fig. 1) allows applications to pose queries over the Entity Model, and also provides the necessary API’s to programmatically access this information. 2.3.2 Query Service The core component of the Environment Layer is the Query Service, which allows client applications to query the models of Web presences of (nearby) entities. These queries can range from simple queries retrieving metadata to queries containing complex semantic conditions. These semantic conditions may also reference the user’s Entity Model, thus effectively personalizing information retrieval. Using the Web presence references provided by the Relation Management component, an application can use the Query Service to obtain (personalized) information on a nearby entity. Referring back to our campus scenario, we deploy an application that enables a mobile user to request relevant information on a nearby physical entity (e.g., The Thinker artifact). After obtaining the Web presence reference from the Relation Model, the application poses a query to the Web presence (consisting of an RDF file) using the Query Service. The query below requests general information (dcmi:description) on the entity, personalized to fit the mobile user’s education level (dcmi:educationLevel) and language (dcmi:language): SELECT ?descr WHERE { ?user rdf:type em:User ; ?entity rdf:type scout:WebPresence ; dmci:description ?descr . ?descr dcmi:language ?language ; dcmi:educationLevel ?level . ?user dcmi:language ?language . dcmi:educationLevel ?level . } 2

http://www.w3.org/TR/2007/WD-CCPP-struct-vocab2-20070430/ http://www.foaf-project.org 4 http://www.w3.org/TR/vcard-rdf 5 http://dublincore.org 3

A Framework for Decentralized, Context-Aware Mobile Applications

93

This query references both the user’s Entity Model and the Web presence of the nearby entity; in order to execute this query, the Query Service thus needs to integrate the data from user’s Entity Model, and the data from the remote Web presence. The em:User type is used to refer to the mobile user, while the scout:WebPresence type allows the query to reference the remote Web presence. In general, the “scout” namespace is used to describe resources and properties that are generated by the framework. The DCMI ontology is used here to represent the user’s language and education level. The above approach is clearly pull-based, as the client application queries information from the environment on the user’s request. However, many applications exhibit behavior that needs to be executed when certain changes occur in the environment, i.e., when certain entities become (or are no longer) nearby. If the pullbased approach is used in this case, the application developer is left with the burden of implementing a constant polling of the Relation Model for new positional relations, in order to cope with the mobile user’s volatile environment. As this is neither practical nor efficient, a Notification Service is provided that allows for selective, push-based information gathering. 2.3.3 Notification Service The Notification Service allows applications to obtain references of nearby entities in a push-based manner, thus allowing them to become responsive to changes in the mobile user’s environment. More specifically, an application can register itself with this service in order to automatically receive events when nearby entities are encountered, or are no longer nearby. By default, the application is simply notified of all nearby entities; additionally, the framework allows filtering by enabling the application to specify a condition (in the form of a SPARQL query) which must be satisfied by the nearby entity before the application is notified. As was the case with the Query Service, this filtering condition may also utilize information from the user’s own Entity Model, thus allowing for personalized filtering. In our campus scenario, we now deploy an application that automatically displays information on certain interesting entities as they become nearby. For this purpose, the application uses the Notification Service, and provides a condition specifying that for university students, only buildings (campus:Building) are to be displayed where the student takes courses (em:followsCourse). The following query represents this condition: SELECT ?entity WHERE { ?user rdf:type em:User ; em:followsCourse ?course . ?entity rdf:type scout:eventEntity ; rdf:type campus:Building ; campus:contains ?room . ?room campus:givenCourse ?course . }

The above query references both the user’s Entity Model (using the “em” namespace) and the Web presence of the nearby entity (using the “campus” namespace). The “campus” namespace is used to convey information on objects present in the VUB

94

W. Van Woensel, S. Casteleyn, and O. De Troyer

campus. The scout:eventEntity type allows a query to reference the entity that caused the event, in this case the entity that became nearby. The following line of code registers the application to receive events only in case the above query returns results, i.e., if the filtering condition is satisfied: service.registerForEvents(this, EventTypes.ENTITY_NEARBY, query, INTERESTING_BUILDINGS);

Note that the last argument in the method invocation represents an identifier for this specific registration (more specifically, an integer). The identifier is communicated back to the application upon notification, so that it knows for which registration it receives a given event. 2.3.4 Environment Management Until now, we have illustrated how queries, which integrate the mobile user's metadata (stored in the Entity Model) and the metadata of the nearby Web presence, can provide for personalized retrieval of information. However, the full strength of the SCOUT framework lies in combining metadata from multiple Web presences, obtained from both past and current positional relations, and integrating it with metadata of the mobile user. We call this integrated view on the environment the Environment Model, and it effectively allows the application developer to extensively query any piece of the user’s context and environment. In order to illustrate the benefits of this model, let us refer back to our campus scenario, where we further extend our application by referring to more than one entity in our personalization condition. The following query retrieves shops on campus and their sold items (campus:sells) in case they are related (campus:relatedTo) to either an interest of the user (em:hasInterest) or a building that the user spent a certain amount of time nearby (scout:wasNearby): SELECT ?entity ?item WHERE { ?user rdf:type em:User ; { ?user scout:wasNearby ?prevEntity . ?prevEntity scout:nearbyFrom ?from ; scout:nearbyUntil ?till . FILTER (?till - ?from > 900) ?prevEntity campus:relatedTo ?concept . } UNION { ?user em:hasInterest ?interest . ?interest campus:relatedTo ?concept . } ?entity rdf:type scout:eventEntity ; campus:sells ?item . ?item campus:relatedTo ?concept . }

In this query, information from the Entity Model (i.e., interests), Relation Model (i.e., nearby entities) and metadata of other Web presences (i.e., shops and sold items) is referenced. The benefit for the application developers thus lies in the fact that they

A Framework for Decentralized, Context-Aware Mobile Applications

95

can access this distributed information by posing a single query to the Environment Model. It should be noted that the push-based approach described in section 5.3 can also benefit from the Environment Model; for instance, we could pass the above query as an argument to the registerForEvents method of the Notification Service. As a result, our application will be notified in case a shop selling interesting items (defined by the user’s either explicit or implicit interests) is encountered.

3 Related Work As discussed in the introduction, our approach is based on the central notion of linking physical entities to their associated information, a concept first introduced by the HP Cooltown project [2-5]. Others have also since realized the potential of connecting physical objects to related online information. Touchatag6 from AlcatalLucent Ventures is a commercial initiative that uses RFID technology to connect objects to online applications. In [12], an open lookup framework is presented where objects tagged with RFID tags are linked to resource descriptions, allowing users to retrieve information on specific tagged objects. An important characteristic of our solution is its decentralized nature, which manifests itself in two ways: decentralized data storage and query resolving. In contrast, many existing approaches that focus on the location-specific retrieval of information (e.g., [9-11]) employ a centralized Information System (IS), which stores and maintains all location-specific information. Clearly, this requires significant effort to setup and keep up-to-date; moreover, such an IS mostly requires a pre-defined location model of the area (e.g., symbolic, geometric, etc [11]), linking absolute positions/identifiers/etc to the physical entity data, which is not very flexible or wellsuited for dealing with non-stationary entities (e.g., moving art exhibitions, persons, etc). In our approach, Web presences are put online and maintained by contentproviders themselves, thus also increasing control over their own data and significantly reducing the threshold for participation. Other approaches [6-8] provide a central service that acts as an integrated view over a set of distributed (context) data sources, and thus represents a centralized way to query resolving. Although it is clear that such an approach offloads a lot of work from the mobile devices themselves [8], it is also less scalable and flexible, as every single query needs to pass through this service and each data source needs to be registered with it. We also believe that the possibilities of mobile devices will keep increasing as it has been for the last decade, thus reducing the need for “thin” clients. An approach that also focuses on the decentralized, context-specific retrieval of data is Context-ADDICT [15]; however, this system only supports schema-based filtering and only very limited data-based filtering of information, and does not provide an event-based way of obtaining information from the environment (see below). Another feature that sets us apart from such centralized approaches ([6-8]) is our built-in support for providing location-specific information, allowing applications to get the information when and where they need it. More specifically, we separate the logic necessary to infer the “nearness” of an entity into separate layers; consequently, 6

http://www.touchatag.com

96

W. Van Woensel, S. Casteleyn, and O. De Troyer

different technologies and strategies can be used interchangeably. Additionally, most centralized approaches are not event-based, and do not alert applications when a certain a contextual configuration occurs. Two other approaches also provide eventdriven notification, namely GeoNotes [13] and Sentient Graffiti [14]. However, both are centralized solutions; furthermore, GeoNotes is not an application framework but rather a single application, and Sentient Graffiti does not focus on integration of different data sources.

4 Conclusions In this paper, we have presented the SCOUT framework, which allows for the development of personalized, context-aware mobile applications in a ubiquitous setting. The framework architecture is based on the separation of concerns, where each design concern is dealt with in a different layer. As elaborated in the paper, the framework supports a variety of different detection techniques and proximity strategies, which can be used transparently and interchangeably. The most important part of the framework is the Environment Layer, which (among other things) provides applications with an integrated view on the user’s physical environment, and allows the application developer to seamlessly combine and query information from different Web presences. By allowing applications to pose arbitrarily complex queries over the Environment Model, and by taking into account mobile user’s context and particularities, the SCOUT framework supports true context-aware, personalized mobile application development.

References 1. Debaty, P., Caswell, D.: Uniform Web Presence Architecture for People, Places, and Things. Personal Communications 8(4), 46–51 (2001) 2. Debaty. P., Goddi, P., Vorbau, A.: Integrating the Physical World with the Web to Enable Context-Enhanced Services. Technical report, Hewlett-Packard (2003) 3. Kindberg, T., Barton, J.: A Web-Based Nomadic Computing System. Computer Networks 35(4), 443–456 (2001) 4. Barton, J., Kindberg, T.: The Cooltown User Experience. In: CHI 2001 Workshop: Building the Ubiquitous Computing User Experience (2001) 5. Cappiello, C., Comuzzi, M., Mussi, E., Pernici, B.: Context Management for Adaptive Information Systems. Electronic Notes in Theoretical Computer Science 146, 69–84 (2006) 6. Xue, W., Pung, H., Palmes, P.P., Gu, T.: Schema matching for context-aware computing. In: 10th international conference on Ubiquitous computing, pp. 292–301. ACM, Seoul (2008) 7. Judd, G., Steenkiste, P.: Providing Contextual Information to Pervasive Computing Applications. In: 1st IEEE International Conference on Pervasive Computing and Communications, pp. 133–142. IEEE Computer Society, Fort Worth (2003) 8. Tummala, H., Jones, J.: Developing Spatially-Aware Content Management Systems for Dynamic, Location-Specific Information in Mobile Environments. In: 3rd ACM international workshop on Wireless mobile applications and services on WLAN hotspots, Mobility support and location awareness, pp. 14–22. ACM, Cologne (2005)

A Framework for Decentralized, Context-Aware Mobile Applications

97

9. López-de-Ipiña, D., Vazquez, J.I., Abaitua, J.: A Context-aware Mobile Mash-up Platform For Ubiquitous Web. In: 3rd IET International Conference on Intelligent Environments, pp. 116–123. IEEE, Ulm (2007) 10. Challiol, C., Rossi, G., Gordillo, S., De Cristófolo, V.: Designing and Implementing Physical Hypermedia Applications. In: Gavrilova, M.L., Gervasi, O., Kumar, V., Tan, C.J.K., Taniar, D., Laganá, A., Mun, Y., Choo, H. (eds.) ICCSA 2006 and UWSI 2006. LNCS, vol. 3983, pp. 148–157. Springer, Heidelberg (2006) 11. Roduner, C., Langheinrich, M.: Publishing and Discovering Information and Services for Tagged Products. In: Krogstie, J., Opdahl, A.L., Sindre, G. (eds.) CAiSE 2007 and WES 2007. LNCS, vol. 4495, pp. 501–515. Springer, Heidelberg (2007) 12. Espinoza, F., Persson, P., Sandin, A., Nyström, H., Cacciatore, E., Bylund, M.: GeoNotes: Social and Navigational Aspects of Location-Based Information Systems. In: Abowd, G.D., Brumitt, B., Shafer, S. (eds.) UbiComp 2001. LNCS, vol. 2201, pp. 2–17. Springer, Heidelberg (2001) 13. López-de-Ipiña, D., Vazquez, J.I., Abaitua, J.: A Context-aware Mobile Mash-up Platform For Ubiquitous Web. In: 3rd IET International Conference on Intelligent Environments, pp. 116–123 (2007) 14. Bolchini, C., Curino, C., Schreiber, F.A., Tanca, L.: Context Integration for Mobile Data Tailoring. In: 14th Italian Symposium on Advanced Database Systems, Portonovo (Ancona), Italy, pp. 48–55 (2006) 15. Brusilovsky, P.: Adaptive hypermedia. User Modeling and User-Adapted Interaction 11(12), 87–110 (2001) 16. Alain Barrat, A., Cattuto, C., Colizza, V., Pinton, J.: High resolution dynamical mapping of social interactions with active RFID. CoRR abs/0811.4170 (2008)

Modeling Dynamic Context Awareness for Situated Workflows Hannes Wolf, Klaus Herrmann, and Kurt Rothermel Institute of Parallel and Distributed Systems, Universit¨ atsstraße 38, D-70569 Stuttgart, Germany [email protected]

Abstract. A major challenge for pervasive computing is to support continuous adaptation of applications to the behavior of the user. Recent research has adopted classical workflows as alternative programming paradigm for pervasive applications and approaches for context aware workflow models have been presented. However the current approaches suffer from the low flexibility of classical workflow models. We present a solution that allows attaching workflows to real-world objects and defining relevant context dynamically in relation to those objects. The benefits are a dynamic, yet simple modeling of context constraints and events in pervasive workflows and a greatly reduced amount of context information that must be provided to the workflow.

1

Introduction

The great challenge of pervasive computing is the unobtrusive support of users in diverse tasks. New application paradigms have been developed to tackle this challenge. A key source of information for these applications is context information. A special kind of context aware mobile applications are situated applications introduced by Hull et al. [1]. This kind of applications is able to detect, interact and respond to the local (physical) context of the application itself or the user. This way the all the context information in the local environment is available for the application and it is up to the application programmer which context information is accessed. A context system that hosts context aware applications must be able to provide all the context information that any application is interested in, in a best effort manner. We refer to this as static context provisioning. We suggest that the Adaptable Pervasive Flow (APF or simply flow ) [2] is a suitable programming paradigm for optimizing the provisioning of context information. Our research on flows is conducted in the ALLOW project1 funded by the European Union. An Adaptable Pervasive Flow is a far reaching extension of the classical workflow paradigm that tackles adaptation, user interaction, security issues and context 1

This research has been supported by 7th Framework EU-FET project 213339 – ALLOW.

R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 98–107, 2009. c Springer-Verlag Berlin Heidelberg 2009 

Modeling Dynamic Context Awareness for Situated Workflows

99

recognition. This paper contributes to functional specification of APFs. The classical workflow paradigm is usually used for programming in the large and allows orchestration of a set of activities on a high level of abstraction. Activities in APF can call another flow or (web) service like in the classical workflow model or represent a task that is directly executed by a human user. In this paper we focus on three of the new aspects of the APF: First we show in detail how we extend the classical workflow model in order to make flows situated. Secondly we provide a modeling concept that allows the flow modeler to dynamically define what kind of context information is relevant during the execution, exploiting the situatedness. We show that our modeling concept enables the underlying context provisioning system to dynamically provide only the relevant context information to a single flow application. We call this dynamic context provisioning. The third contribution is a constraint and event handling mechanism that enables a flow directly to react to changes of the relevant context information appropriately. The rest of the paper is structured as follows. In section 2 we introduce our system model and the running example. The related work is discussed in section 3. We then present in detail our modeling extensions in conjunction with a scenario walkthrough in section 4. Finally, we discuss our approach in section 5 and conclude our work in section 6.

2

System Model and Application Scenario

Workflow models are modeled using a workflow modeling language. A common wide spread and standardized language is the Business Process Execution Language (BPEL). BPEL is based on XML, which easily allows extensions. In order to execute a workflow model, an instance of that model must be created and run on a workflow engine (WFE). Flows are considered mobile and can migrate from one WFE to another in order to optimize their execution. Classical workflows are usually created for scenarios that exhibit at least some degree of repetition. Following that we assume that some of the running flow instances in our system are created from the same flow model. Because situated flows must be context aware, our system provides a context access layer. The nodes that host this layer are connected in an overlay network with undirected links that significantly vary in bandwidth and latency. The representation of stored context information is based on our object-oriented entity model, which will be introduced in section 4.1 in more detail. We assume a system that hosts a large number of flows and spans a wider geographical region. In order to show the feasibility of our system, we will apply our concepts to an example real-world scenario from the domain of logistics. A truck delivers a box that contains frozen peas to a warehouse. The box should be unloaded and stored in the cold store of the warehouse before the cold chain is broken. The unloading and storing are handled by a warehouse worker. Because the peas are deep-frozen, it is important that they reach the cold store within a certain time frame when the unloading begins. This will be our running example for the rest

100

H. Wolf, K. Herrmann, and K. Rothermel

of the document. Figure 1 shows an illustration of the local environment and all participants, figure 2 the necessary activities as basic flow. The truck transports the box to the warehouse. A worker from the warehouse is responsible to unload the box from the truck. Finally the box is moved to the cold store by a warehouse worker. Pea Box

Truck

Warehouse Cold Store Worker

Fig. 1. Logistics Scenario overview

Basic Box Flow

…

Transport to Warehouse

Unload Box

Move to Cold Store

…

Fig. 2. The basic flow for storing the box

3

Related Work

We found two general approaches that enhance workflow modeling with context information: workflows with context integration [3,4,5,6,7] that allow to retrieve and react to context information and personal workflows [8,9,10] that are tailored to the actions of a single human user. The context integration approaches provide modeling mechanisms that allow to specify a context-aware transition conditions between the activities. An early approach based on BPEL and WebServices was proposed by Han et al. [3]. Their ubiquitous workflow description language (uWDL) adds triples consisting of subject, verb and object to a given transition in a workflow. When the context is matched the transition is taken. uWDL has developed to a complete framework [4] including modeling tools and support of context aware services [5]. With Context4BPEL [6] Wieland et al. allow the workflow to directly access context information and take decisions on that information. They further extend their system [7] to be able to process more complex queries and to facilitate a higher level of abstraction in context modeling. However uWDL as well as Context4BPEL rely on comprehensive modeling and provide no flexibility at modeling time, what kind of context information is relevant at runtime. In the area of personal workflows Hwang et al. [8] proposed a proprietary workflow format for personal processes that provides a great deal of flexibility for the individual tasks. On the downside the modeling of the flow as well as monitoring its state of execution rely mostly on direct user input. The sentient

Modeling Dynamic Context Awareness for Situated Workflows

101

processes [9] are also based on a proprietary language. Such a process is tailored to a single user that wants to execute a sequence of tasks in a pervasive environment. The later extension, PerFlows [10], allows the user to flexibly decide in which order he executes his tasks. They can be executed automatically, rolled back, skipped and are context aware to the behavior of the owner. However, the Personal Workflows as well as the PerFlows allow only the assignment of a single user to the flow. The user is static and the flow can only react on context information of that user or direct input. Both concepts do not consider additional context information that becomes relevant during execution. PerCollab [11] envisions another approach for pervasive human interaction. The authors extend the BPEL with a new activity that allows transparent user interaction using heterogeneous communication channels ranging from desktop PCs to PDAs and even mobile phones. This presents a convenient way to integrate human interaction into a workflow, but as the interaction is handled transparently the flow is not aware of its environment and thus cannot react to it.

4

Situated Workflows

In order to relate our application to the physical world, we must first create a formal model of the physical context. In the next section, we introduce a context model that is built on object-oriented entities. Given this formal representation, we can attach a flow to an entity creating a direct relation to a physical object. This Flow Attachment is explained in section 4.2. Using the attachment, we define the relevant context information in the local environment of the flow. We call this concept a Context Frame. During the runtime of the flow we enforce application constraints on the actual context and use available context to control the flows behavior when certain events in the relevant environment happen. The constraint handling is implemented with Context Constraints and the event handling with Context Events. 4.1

Entity Model

The entity model is our formal representation of the real world. Every real-world artifact that is considered in our system is encapsulated by an entity. Each entity has an identifier and an entity type. For our application scenario, we consider the following three entity types; ’truck’, ’box’, ’worker’. The relevant instances for our scenario are: 1. The box that contains the frozen peas. 2. The truck that transports boxes to the warehouse. 3. The worker who is able to carry boxes, unload them from the truck and put them to different storage places like the cold store. The type of the entity further determines which properties and events the entity has. An entity property is a variable in the entity type that represents a real-world property of the corresponding physical object. Examples for properties

102

H. Wolf, K. Herrmann, and K. Rothermel

are the temperature of the box, or the position of the worker. An entity event is generated when something happens at a certain point in time in the real world that causes a change for an entity. An example for this might be a worker that picks up a box which results in a pickedUp-Event for the box. We assume that the properties and events defined in the entity types can be sensed from the real world by appropriate context recognition systems that are integrated in the context access layer. For the sake of simplicity, the domain of values every attribute can have is known in advance. Whenever we refer to either an entity property or an entity event we also speak of an entity attribute. Entity types are organized in an entity type hierarchy and allow single-parent inheritance from other entity types similar to object-oriented programming. 4.2

Flow Attachment

Based on the entity model, we introduce the necessary extensions to the flow modeling language to create situated flows. We build our extensions using two properties of the flow modeling language. First, the flow modeling language provides scopes as a modeling element. A scope groups a subset of the activities in a workflow model employing visibility rules. Every information defined in a scope can only be accessed by the activities in the scope. We represent scopes as dotted rectangles around the activities. Secondly, the flow model is easily extendable with annotations that can be added to scopes. Given these two tools, we attach a flow to an entity, by adding an attachment annotation to a scope. In order to improve the flexibility, attachment happens in two distinct phases. In the first phase, during modeling time of the flow, the modeler adds the attachment annotation to a scope. Only the entity type of the attachment is defined at this point. In the second phase, when the flow is running the attachment is resolved to an entity, that is an instance of the entity type specified in the attachment. Then the flow is actually attached to that entity. Figure 3 shows an attachment of the box flow to the box. The small dotted rectangle (A) represents the attachment annotation, its code depicted in the box. The actual box instance is resolved at runtime. A single scope can have multiple attachments annotated, which allows a flow to be attached to multiple entities. The entity type of the attachment is static during runtime but the attached entity can be exchanged under certain conditions. For example, a flow could be attached to a worker and this worker finishes his shift while the flow is still running. Because the worker is unavailable, the flow needs to resolve another worker, to continue execution. When a flow is attached to an entity the flow becomes situated. It is logically co-located with the attached entity and the entity becomes a relevant part of the local environment the flow can respond to. It is also likely that the flow will access some of the context information of the attached entity. Because of this the context access layer can dynamically provide efficient access to the context information of attached entities to the flow.

Modeling Dynamic Context Awareness for Situated Workflows

Pea Box Attached Box Flow

…

Transport to Warehouse

A

Unload Box

103

Attachment { EntityType: box Entity: PeaBox }

Move to Cold Store

…

Fig. 3. Extension of the basic workflow model to a situated workflow

4.3

Context Frames

The environment of the flow might not only include attached entities but also other entities which are not known at design time. Those entities become relevant to the flow during its runtime because they have some contextual relation to the actual entity the flow is attached to. The modeler can add a Context Frame to the flow providing access to more entities in the flows local environment based on that contextual relationship. In our scenario, there is a worker responsible for unloading the box from the truck. But flow modeler cannot know the actual context of each worker in the warehouse. So the flow modeler adds a context frame that defines those workers as relevant that can assist the unloading and storing process. In Figure 4, the box flow is depicted including a Context Frame that defines the relevant workers for the flow. We add the Context Frame as new modeling element to the flow modeling language. Similar to the Flow Attachment, the Context Frame is annotated to a scope in the flow model. A Context Frame defines any number of so called entity sets that contain the entities that are relevant to the flow. The modeler can define an entity set either combining two existing ones using set operations (union, intersection, set theoretic difference) or create new entity sets using certain Filters.

Pea Box 15m

Context Frame

Box Flow A

…

Idle Worker

CF Transport to Warehouse

Unload Box

Move to Cold Store

…

ContextFrame { EntitySet worker_set { EntityType=worker; Range= occupation_status==idle, distance(position,PeaBox.position) < 15.0; } }

Fig. 4. Context frame that covers all free workers within 15m of the box

104

H. Wolf, K. Herrmann, and K. Rothermel

We propose the use of three different filters. The first one is a Type Filter that restricts the type of entities that can be in the set. The type filter in our example is set to worker so that only workers can be an element of the set and not other entities. The second one is an Attribute Filter. It lists the number of entity attributes that are considered relevant and only these attributes are updated by the context system. We apply this filter to further reduce the amount of context information that must be provided to the flow by the context access layer. The third filter is the so called Range Filter. The range filter removes the entities, whose attributes are not in range of a defined domain of values. It consists of a number of expressions and an entity must fulfill all these expressions in order to be a member of the entity set. In our example, we use two range filter expressions. As the box flow in Figure 4 is only interested in workers which are idle, occupied workers are filtered out. The second range filter expression removes all workers from the set that are not close enough to be relevant for further execution. The Context Frame can access the context information of the attached entities. The information is used to define the relation between the entities of the set and the attached entity. This way the content of the entity set is directly dependent on the actual context of the box. Because of the changing context of the attached entity, the actual elements of the entity set are calculated dynamically at runtime taking the relation into account. When a Range Filter is defined without a relation to an attached entity we call the enclosing Context Frame an absolute Context Frame. Otherwise it is a relative Context Frame. The context information in a Context Frame can be accessed, when the flow executes activities in the scope. 4.4

Context Constraints and Events

Context Constraints and Context Events are two mechanisms to utilize the context information provided from attachment and context frames. Both have a similar structure but different evaluation semantics. We first describe the common structure and then discuss the different semantics using the application scenario. Both, Context Constraints and Context Events, consist of a context condition and a handler. The context condition monitors the situation and invokes the handler when necessary. The condition itself consists also of two separate parts. A logical predicate in first order logic and an event qualifier. The predicate is defined over the entity properties from the attached entities and from the context frames. The evaluation rules of the context condition are controlled by the event qualifier. We provide two different event qualifiers. The onEvent qualifier evaluates the condition when a certain entity event (c.f. 4.1) is triggered. The betweenEvents qualifier evaluates the condition continuously during the specified events. The event qualifiers are defined on the available entity events. We also provide two special events to allow evaluation when a scope is entered or left. These two events are the onEntry-Event and the onExit-Event. Figure 5 shows the further extended box flow. We have annotated a Context Constraint (CC) and a Context Event (CE) to the inner scope that encloses the unloading task. The semantics for the Context Event are defined as follows.

Modeling Dynamic Context Awareness for Situated Workflows

Box Flow

A

CF

ContextEvent { ContextCondition { onEvent(entryEvent) Not isEmpty(worker_set) } Handler { EmitFlowEvent(WorkerAvailable) } } CE

…

105

Transport to Warehouse

CC Unload Box

Move to Cold Store

…

ContextConstraint { ContextCondition { betweenEvents(PeaBox.pickedUpEvent, exitEvent) PeaBox.temperature < -18.0 } Handler { EmitFaultMessage(TempExceeded) } }

Fig. 5. The box flow with a Context Event and a Context Constraint

When the context condition of a Context Event is evaluated and the predicate is true, then the handler is invoked. When the truck has reached the warehouse, the flow waits until a worker is close enough to the box. When the entity set in the Context Frame becomes non empty the handler is invoked. The flow gets a notification and can continue its execution, because a worker is available that can start the unloading task. The semantics for the Context Constraints are basically inverted. When the predicate evaluates to false the handler is invoked. While the box is being unloaded, the condition of the CC is evaluated, because the flow gets notified about the peaBox.pickedUp event. In our example scenario we consider a context constraint that monitors if the temperature of the box is always below -18 degrees Celsius so that the cold chain is maintained. If the predicate becomes false at any point in time until the task is completed the handler of the Context Constraint is invoked. The handler then tries to resolve the constraint violation. Additional information on integrated constraint handling in flows can be found in our previous work [12]. 4.5

Example

To demonstrate the effects of our extensions we show a walkthrough of our scenario pointing at the effects of our new modeling elements. The box flow handles the transport process of the flow. When the flow is invoked it is first attached to the pea box. The box is loaded on a refrigerated truck and transported to the warehouse where it should get stored for some time. On arrival of the truck the box flow waits until it gets notified that a worker has - literally speaking - entered the Context Frame, i.e. fulfills the range filter of the Context Frame. The worker gets notified about his next task and starts to unload the box from the truck into the warehouse. When the box flow receives the pickedUp event from the peaBox the Context Constraint starts monitoring the temperature of

106

H. Wolf, K. Herrmann, and K. Rothermel

the box. Note that the flow only knows and can subscribe to the pickedUp event and the temperature values because he is attached to the box. Without the attachment from this flow there might be no other application that is interested in context information about that box and the context access layer would not provide them. If the worker carries the box to the cold store in time the flow will continue normally. However, should the temperature rise above the value in the constraint, the system reacts to the change. The flow might be adapted to the new situation and activities could be added e.g. an additional quality check on the goods. But the constraint violation could also lead to the termination of this flow and trigger the removal of the box from the usual delivery.

5

Discussion

The extensions we provided for the flow modeling language enable a flow modeler to create situated workflows. He can describe the local environment of the flow based on Flow Attachment and Context Frames. The modeler can further apply our constraint and event handling mechanisms which allow the flow to adapt to the environment. The main advantage of our approach is the reduced amount of context information that is relevant and the fact that relevant context information can be determined at runtime. The context provisioning system only has to provide and maintain information that are relevant to the flow applications (i.e. attached entities and entities defined in Context Frames). The flow benefits from a much smaller range of context in its local environment it needs to monitor and adapt to. But our approach leaves some open challenges. Our approach relies on quite comprehensive knowledge about context information. Every context that is modeled in the flow should be available during runtime. Another aspect is the quite expensive dynamic calculation of the visible context for a single flow. We will investigate the use of aggregation techniques for entity sets based on the assumption that similar flows will have similar requirements on context information.

6

Conclusions and Future Work

In this paper we introduced a novel way to model context aware workflows. Our approach provides more flexibility in modeling than the existing approaches. We dynamically restrict the amount of context information so that the flow is only aware of relevant context. We further provided a constraint and event handling mechanism on top of our context modeling approach that allows to monitor the execution and to trigger adaptation. As we discussed above the provisioning of the entity sets may be rather expensive. We will investigate how to optimize the calculation of entity sets in a system that hosts a large number of situated workflows. This includes the adaptation of the context provisioning system to the needs of a single or similar situated flows.

Modeling Dynamic Context Awareness for Situated Workflows

107

References 1. Hull, R., Neaves, P., Bedford-Roberts, J.: Towards situated computing. In: ISWC 1997: Proceedings of the 1st IEEE International Symposium on Wearable Computers, Washington, DC, USA, p. 146. IEEE Computer Society, Los Alamitos (1997) 2. Herrmann, K., Rothermel, K., Kortuem, G., Dulay, N.: Adaptable pervasive flows an emerging technology for pervasive adaptation. In: Society, I.C. (ed.) Proceedings of the SASO 2008 Workshops (2008) 3. Han, J., Cho, Y., Choi, J.: Context-aware workflow language based on web services for ubiquitous computing. In: Gervasi, O., Gavrilova, M.L., Kumar, V., Lagan´ a, A., Lee, H.P., Mun, Y., Taniar, D., Tan, C.J.K. (eds.) ICCSA 2005. LNCS, vol. 3481, pp. 1008–1017. Springer, Heidelberg (2005) 4. Han, J., Cho, Y., Kim, E., Choi, J.: A ubiquitous workflow service framework. 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, pp. 30–39. Springer, Heidelberg (2006) 5. Shin, K., Cho, Y., Choi, J., Yoo, C.W.: A workflow language for context-aware services. In: MUE 2007: Proceedings of the International Conference on Multimedia and Ubiquitous Engineering, pp. 1227–1232. IEEE Computer Society, Los Alamitos (2007) 6. Wieland, M., Kopp, O., Nicklas, D., Leymann, F.: Towards context-aware workflows. In: Pernici, B., Gulla, J.A. (eds.) CAiSE 2007 Proceedings of the Workshops and Doctoral Consortium, Trondheim, Norway, June 11-15, vol. 2. Tapir Acasemic Press (2007) 7. Wieland, M., Kaczmarczyk, P., Nicklas, D.: Context integration for smart workflows. In: Proceedings of the Sixth Annual IEEE International Conference on Pervasive Computing and Communications, Hong Kong, pp. 239–242. IEEE Computer Society, Los Alamitos (2008) 8. Hwang, S.Y., Chen, Y.F.: Personal workflows: Modeling and management. In: Chen, M.-S., Chrysanthis, P.K., Sloman, M., Zaslavsky, A. (eds.) MDM 2003. LNCS, vol. 2574, pp. 141–152. Springer, Heidelberg (2003) 9. Urbanski, S., Becker, C., Rothermel, K.: Sentient processes - process-based applications in pervasive computing. In: PerCom Workshops, pp. 608–611. IEEE Computer Society, Los Alamitos (2006) 10. Urbanski, S., Huber, E., Wieland, M., Leymann, F., Nicklas, D.: Perflows for the computers of the 21st century. In: PerCom Workshops, pp. 1–6 (2009) 11. Chakraborty, D., Lei, H.: Pervasive enablement of business processes. In: PerCom, pp. 87–100. IEEE Computer Society, Los Alamitos (2004) 12. Eberle, H., F¨ oll, S., Herrmann, K., Leymann, F., Marconi, A., Unger, T., Wolf, H.: Enforcement from the Inside: Improving Quality of Business in Process Management. In: 2009 IEEE International Conference on Web Services (ICWS 2009). IEEE Computer Society, Los Alamitos (2009)

FleXConf: A Flexible Conference Assistant Using Context-Aware Notification Services Nikos Armenatzoglou, Yannis Marketakis, Lito Kriara, Elias Apostolopoulos, Vicky Papavasiliou, Dimitris Kampas, Alexandros Kapravelos, Eythimis Kartsonakis, Giorgos Linardakis, Sofia Nikitaki, Antonis Bikakis, and Grigoris Antoniou Institute of Computer Science, FORTH, Crete, Greece, and Department of Computer Science, University of Crete, Greece {armenan,marketak,kriara,ilapost,papavas,kampas,kapravel,kartson,linard, nikitaki,bikakis,ga}@csd.uoc.gr

Abstract. Integrating context-aware notification services to ubiquitous computing systems aims at the provision of the right information to the right users, at the right time, in the right place, and on the right device, and constitutes a significant step towards the realization of the Ambient Intelligence vision. In this paper, we present FlexConf, a semantics-based system that supports location-based, personalized notification services for the assistance of conference attendees. Its special features include an ontology-based representation model, rule-based context-aware reasoning, and a novel positioning system for indoor environments. Keywords: context awareness, location-based services, notification services, context ontology, rule-based reasoning.

1

Introduction

Context awareness and notification services have recently gained a lot of attention among researchers, and have been used in various application domains, including Ambient Intelligence. In brief, context awareness refers to the idea that computers can both access context information through sensors, and react to certain context changes based on policies or an intelligent stimulus [1]. On the other hand, notification systems use alert services in order to inform users about specific events or changes in the user’s context in a timely manner. The aim of Ambient Intelligence systems is to provide the right information to the right users, at the right time, in the right place, and on the right device. In order to achieve this, a system must have a thorough knowledge and, as one may say, understanding of its environment, the people and devices that exist in it, their interests and capabilities, and the tasks and activities that are being undertaken. All this information falls under the notions of context. In this paper, we describe FlexConf, a flexible Ambient Intelligence system, which combines context-awareness and notification services to cover the needs of conference organizers and attendees. Exploiting the advantages of Semantic R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 108–117, 2009. c Springer-Verlag Berlin Heidelberg 2009 

FleXConf: A Flexible Conference Assistant

109

Web technologies, such as Web ontology languages and rule languages and systems, the described system integrates various types of context information that is relevant to the organization of a conference, and provides personalized contextaware notifications via e-mail about upcoming events. Ontology languages have been argued to be the perfect choice for context representation in the Ambient Intelligence domain [2], mainly because they offer enough representational capabilities to develop a formal context model that can be shared, reused, extended, but also combined with data originating from various diverse sources. Moreover, the development of the logic layer of the Semantic Web has recently resulted in expressive rule languages and powerful rule systems that enable reasoning with the user’s needs and preferences and with the available ontology knowledge. Rule languages provide a formal model for reasoning on the context data, while rules are easy to understand and widespread used. Overall, the main contribution of the paper is twofold: (a) to demonstrate how the combination of Semantic Web technologies and context-aware services can effectively support the needs of conference assistance systems; and (b) to highlight the advantages of this approach including its flexibility, scalability and extensibility. We have already implemented a prototype of FlexConf, which operates in the premises of FO.R.T.H. (Foundation for Research and Technology-Hellas) research facilities. In this prototype, location sensing is enabled by CLS [3,4], a novel positioning system exploiting the existing IEEE802.11 wireless infrastructure. However, the flexibility in the system design enables deploying FlexConf anywhere that a location sensing subsystem is available to provide the necessary location information. The rest of the paper is organized as follows. Section 2 discusses related work on context-aware notification systems. Section 3 describes a use case scenario that highlights the desired functionality of a conference assistance system. Section 4 describes an ontology-based context representation model and a rule-based model that enables reasoning with the available knowledge. Section 5 provides a description of the system architecture, while Section 6 summarizes and discusses plans for future work.

2

Related Work

Several recent works have focused on systems that offer context-aware notification services to the members of a specific community. The Mass Notification System described in [5] aims at the assistance of students in a university campus through recommendations based on user preferences and user location, task reminders, and support for collaborative applications. The Library SMS Alert Service developed in the Hong Kong Institute of Education [6] integrates mobile phone SMS and Google Calendar technologies to provide simplified versions of important library notices, such as availability of requested items and overdue reminders. eyeJot [7] is a context-aware campus information system that supports information posting for news, activities and schedules using Short Message Service (SMS). All these approaches share a common deficiency. The lack of a formal model for modeling and reasoning about the relevant context information

110

N. Armenatzoglou et al.

influences their flexibility, as the decision-making processes of those systems are hardcoded, and therefore difficult to adjust. There is also a number of recent works that exploit Semantic Web technologies to support context-aware services. [8] presents an extended survey of such systems. The most relevant to our work is the semantics-based meeting alerting system of [9], which integrates RDF [10], and Semantic Web rules in Defeasible Logic for making context-dependent decisions, GPS technology for location sensing and SMS message delivery. Though the underlying representation and reasoning models are similar to those used in FlexConf, the specific system is aimed at different types of applications and outdoor environments. Finally, to our knowledge, the Conference Assistant prototype described in [11] as an application of Dey and Abowd’s Context Toolkit is the only implemented system that provides context-aware services to conference attendees. Compared to FlexConf, it also takes into account user’s interests and profile information to recommend specific events that take place during a conference, without however supporting notifications / alerts to conference attendees.

3

Use Case

In this section an imaginary use case scenario is presented, in order to explore the functionalities that a context-aware conference assistant should support. Consider a Knowledge Representation Conference, which takes place in the FORTH conference area. This area includes several meeting, seminar and other types of rooms that can be used to host paper presentations, invited talks, demonstrations and discussions. Consider also a visitor, Mark, that has registered to attend the conference, and enters the conference area for the first time. Mark updates the conference assistant with personal information by filling up his profile (i.e. name, role in the conference, research interests, physical disabilities, group memberships). Mark states that he has movement disabilities (he uses a wheelchair). He also states that his research interests include semantic web (SW). According to the conference programme, a presentation on RDF concepts is scheduled to take place in Seminar Room VI at 12.15 pm. The system should inform Mark in time for this presentation (as it matches with his research interests) and guide him towards Seminar Room VI taking into account his disabilities. To accomplish that, the system provides a floorplan of the whole conference area indicating the users current position, the exact location of room VI, as well as how the room is accessible to people using wheelchair. Consider, finally, another conference attendee, James, who is a member of SW-Group. James should also receive an alert for the same presentation due to common interests of SW-Group members.

4

Context Representation and Reasoning

In this section, we describe the ontology-based context representation model and the rule-based reasoning methods that we employed to enable context-based decisions.

FleXConf: A Flexible Conference Assistant

4.1

111

Ontology-Based Modeling

For the representation of people, events, interests and other conference related concepts, we designed an ontology (ConfOntology) in RDFS [12]. ConfOntology can be used as a standard format for representing and exchanging information, for the domain of Conference Assistance Systems. Figure 1 illustrates the proposed ontology schema and a hypothetical instantiation. The upper part of Figure 1 depicts the schema of ConfOntology, while below the schema there is a possible instantiation, which we use as the running example throughout the rest of the paper and which is based on the use case scenario that we described in Section 3. The RDF classes are represented as boxes. The labeled arrows stand for properties having as domain the class connected to the beginning of the arrow, and as range the class connected to its end. The label of an arrow stands for the name of the respective property. Unlabeled bolded arrows denote subclass relations - the class connected to the beginning of the arrow is a subclass of the class connected to its end. Finally, dashed arrows denote class instantiations. ConfOntology TimeTable

receivesAlert

hasInterest

dailyEvent

Event

domain

SocialEvent

Presentation presenter

RDF Concepts

memberOf Group Group

Person

domain

groupInterests

Interest

Research

Personal

host

SW

hasInterest groupInterests

Mark James

memberOf SW Group Group

Fig. 1. The ConfOntology Schema and instantiation

The main ontology classes are Person, Event, Group, Interest and TimeTable. The Person class models conference attendees. For each person, various types of relevant information are retained. One such type is a person’s interests (in terms of both personal and research interests), which are modeled through Interest class, and are associated to a person through the hasInterest property. The Event class is used to represent events related to the conference program, such as presentations, lectures, demonstrations or talks. It is also used for other types of activities such as excursions or museum visits. The Group class is used for groups of people that share common interests, which are linked to groups through the groupInterests property. For instance, according to Figure 1, both Mark

112

N. Armenatzoglou et al.

and James will receive an alert for the RDF Concepts presentation, as Mark has explicitly included Semantic Web, which is the domain of the event, in his research interests, while James is member of SWGroup, which is also linked to Semantic Web through groupInterests. Finally, the TimeTable class is used to group events and deliver their schedule to the users. For the creation of the ontology, we used the ontology editor Prot´eg´e1. Prot´eg´e, besides the editor, provides a suite of tools that support the creation, visualization, and manipulation of ontologies in various representation formats. 4.2

Rule-Based Reasoning

Ontology languages provide some limited forms of reasoning through specially designed query languages. However, these languages can not cover the needs of large-scale context aware systems, as they are primarily focused on information retrieval. More expressive forms of reasoning are required for making contextdependent decisions. To this end, we designed a separate rule-based reasoning subsystem. The rules that we use follow the form described below. [R : {list of predicates}− > conclusion] R denotes the id of the rule. The predicates used in the body of the rule are matched with RDF triples in the knowledge base. Finally, the conclusion in the head of the rule is used by the system to determine the appropriate actions, as described in Section 5. Below, we describe two representative examples. [R1 : (?presentation : P resenter?person) → (?person : receivesAlert?presentation)] [R2 : (?presentation : P resentationDomain?interest), (?person : HasInterests?interest), (?person : wantsAlerts yes ) → (?person : receivesAlert?presentation)] R1 is used to alert presenters of presentations, while a similar rule is used to alert hosts. R2 is used to alert people that their interests match with the domain of a presentation, and who have stated that they wish to receive system alerts. Similar rules are used for alerting people about events with domains that match with the common interests of the groups that those people are members of.

5

Technical Description

In this section, we describe the system architecture and provide important implementation details. A component diagram of the system architecture is depicted in Figure 2. Overall, the system comprises the following components: (i) the UserInterface, through which users users can interact with the system; (ii) SWKM, 1

http://protege.stanford.edu/

FleXConf: A Flexible Conference Assistant

113

cmp ConfManagementSystem

SWKM

UserInterface

Repositor yManager

LocationSensing

Sheduler

Reas oner

Fig. 2. The Architecture of the system

which is a persistence storage RDF mechanism, and RepositoryManager that acts a mediator between SWKM and the rest of the system; (iii) the Reasoner, which is used to execute the rules and determine about the appropriate system actions; (iv) the Location Sensing Subsystem, which provides the exact position of the user in the physical space; and (v) the Scheduler, which is responsible for the management of notifications. In the rest of the section, we describe each component in detail. 5.1

User Interface

The UserInterface constitutes the interaction means between the users and FlexConf (see Figure 3). The UserInterface does not require any specific software; it is a web application, and thus is accessible through any web browser. FlexConf identifies and supports two types of users; common users and system administrators. Through UserInterface, a common user may import or update information about personal preferences and groups memberships. He can also have access to the conference program and view details about specific events. Finally, he has the option to disable alerts, so that the system does not include him in the list of the potential notification recipients, and stops positioning him in the

Fig. 3. User Interface

114

N. Armenatzoglou et al.

conference area. Administrators are users with appropriate privileges that allow them to perform additional actions, such as creating or updating information about events, groups, or interest categories. 5.2

SWKM and Repository Manager

The Semantic Web Knowledge Middleware (SWKM)2 is a persistence storage RDF mechanism. It provides a set of services that aim at the manipulation of a database containing RDF data. The basic set of services consist of import, export, query and update services, through which the user can import/export RDF schemas and RDF files and also query/update the RDF knowledge base. The benefits of adopting such a SW-based repository is that we can exploit its validation mechanisms, and therefore ensure that the ontology is consistent with the RDF standard and the instances are valid according to the schema, and its declarative query and update languages. For example, in the future one might want to extend the core ontology with a class Accommodation to support information about the hotels that accommodate the conference attendees. Moreover, let’s assume that this class is added manually (and not using a tool like Prot´eg´e). During import time the extension will be examined and in case it is valid, it will be immediately imported in the ontology schema. Otherwise, the user will be prompted for the errors in the RDF schema. The Repository Manager acts as mediator between the system and SWKM. Specifically, through the Repository Manager, SWKM interacts with UserInterface in order to update the knowledge base, and with the Scheduler to retrieve information about users’ profile information and scheduled events. 5.3

Reasoner

The reasoner subsystem uses the available context information and rules such as those that we described in Section 4.2, to determine the people that should be informed about certain upcoming events. For the reasoning tasks of our system, we used the Jena2 Java framework3 . The Jena2 inference subsystem is designed to allow a range of inference engines or reasoners to be plugged into Jena. The primary use of this mechanism is to support the use of ontology languages, such as RDFS and OWL [13], which allow additional facts to be inferred from instance data and class descriptions. Jena2 also includes a general purpose rule-based reasoner, which we used to perform rule-based reasoning for the notification of users, using the rules that we described in Section 4.2. 5.4

Location Sensing

In our system prototype, we used a novel positioning system, the Cooperative Location-sensing system (CLS) [3,4], which exploits the IEEE802.11 network, 2 3

http://139.91.183.30:9090/SWKM/ http://jena.sourceforge.net/

FleXConf: A Flexible Conference Assistant

115

mainly due to the wide popularity of the network, the low deployment cost, and the advantages of using it for both communication and positioning. (CLS) employs the peer-to-peer paradigm and a probabilistic framework to estimate the position of wireless-enabled devices in an iterative manner without the need for an extensive infrastructure or time-strenuous training. CLS can incorporate signal-strength maps of the environment to improve the position estimates. Such maps have been built using measurements that were acquired from access points (APs) and peers during a training phase. CLS adopts a grid-based representation of the physical space; each cell of the grid corresponds to a physical position of the physical space. The cell size reflects the spatial granularity/scale. Each cell of the grid is associated with a value that indicates the likelihood that the node is in that cell. For our needs, we divided the FORTH testbed into certain zones (areas containing multiple cells). CLS computes an estimated position iteratively every 3-4 seconds. In each iteration a file with a predefined name containing the zone ID of the user’s estimated position is updated. An empirical evaluation of CLS is presented in [3,4]. 5.5

Scheduler

The Scheduler is responsible for checking upcoming events and for notifying the people that are responsible for an event or may be interested in it by sending them alerts via e-mail. It runs as a daemon process that periodically checks whether there are any events in a subsequent time interval. The period of checks and the time interval can be configured based on the needs of a specific conference. For example, wider conference areas impose the need for longer time intervals, while dense conference programs require shorter checking periods. The responsibilities of the Scheduler include the coordination of the rest of the system components and the management of notifications. Initially, when the process ”wakes up”, it communicates with the Repository Manager to retrieve information about upcoming events. If there are no events scheduled for the subsequent time interval, it suspends for the predefined period. Otherwise, it contacts the Reasoner to retrieve information about the people that should be alerted, as well as additional information that will be included in the body of the notification e-mail (i.e. information for the event, location of the event). It also contacts the Location Sensing Subsystem to retrieve the user’s location. Using this information, it creates a floorplan of the area, marked with the user’s current location and the relevant (according to upcoming events and user’s interests) conference rooms, and attaches the floorplan to the notification e-mail. After sending the appropriate alerts, the Scheduler suspends for the predefined period. Back in our running example, the RDFConcept presentation has been scheduled to start at 12.15 pm. in Seminar Room VI. Assuming that the time interval has been configured to 60 minutes, and that at 11.30 am. the Scheduler checks for upcoming events, the RDFConcept presentation will be included in the list of upcoming events. Based on Mark’s interests that include Semantic Web, James’ group memberships that include SWGroup, and the domain of the presentation, which is Semantic Web, the system (Reasoner) determines that both Mark and

116

N. Armenatzoglou et al.

Fig. 4. The floor plan for Mark

James should be alerted about the RDFConcept presentation. The next step is to localize Mark and James using the Location Sensing component in order to deliver the appropriate floorplans. Figure 4 presents the floorplan that will be created for Mark. In the floorplan, the cell that Mark is located at is filled with red, and Mark’s current position is denoted ny a star. Additionally, the position of the Seminar Room VI is described by a red arrow pointing at the entrance of the room, followed by the name of the seminar room. Finally, the system creates and sends the appropriate e-mail notifications to them.

6

Conclusions and Future Work

In this paper we described FlexConf, a flexible conference assistant that integrates Semantic Web technologies, a location sensing system, and relevant context information to support personalized, context-aware notifications to conference attendees. The main features of the system include: (i) a semantics-based knowledge representation and reasoning model, (ii) a flexible design, which enables using the system anywhere that a location sensing system is available and (iii) personalized notifications that are delivered to conference attendees in a timely manner, and are created according to various context parameters. In the future we plan to extend FlexConf in various ways, taking into account the needs of conference organizers and attendees. First of all, we plan to employ the peer-to-peer paradigm for users to communicate. This will allow them to share files, exchange ideas or even use instant messaging through the platform. Furthermore, we plan to continue our work on sending alerts via Bluetooth or SMS to mobile devices e.g. PDAs and mobile phones. A third plan is to integrate navigation services, which will more effectively assist conference attendees to find their way in the conference area. Finally, integrating more context parameters,

FleXConf: A Flexible Conference Assistant

117

such as personal calendars, privacy preferences and several types of sensory information will enable us to support more advanced notification, as well as other types of context-based services. Our future plans also include a more complete evaluation of the system. Currently, only the Location Sensing subsystem has been extensively evaluated. Additionally, we plan to evaluate the overall system performance, as well as the usability of FlexConf.

References 1. Schilit, B., Adams, N., Want, R.: Context-aware computing applications. In: Workshop on Mobile Computing Systems and Applications, 1994. Proceedings, pp. 85–90 (1994) 2. Schmidt, A.: Interactive Context-Aware Systems Interacting with Ambient Intelligence. In: Riva, G., Vatalaro, F., Davide, F., Alcaniz, M. (eds.) Ambient Intelligence. IOS Press, Amsterdam (2005) 3. Fretzagias, C., Papadopouli, M.: Cooperative location-sensing for wireless networks. In: Proceedings of the Second IEEE Annual Conference on Pervasive Computing and Communications, PerCom 2004, pp. 121–131 (2004) 4. Vandikas, K., Katranidou, A., Kriara, L., Baltzakis, H., Papakonstantinou, T., Papadopouli, M.: Empirical-based analysis of a cooperative location-sensing system. In: Proceedings of the 1st international conference on Autonomic computing and communication systems (2007) 5. Mass Notification Systems for College: University & Higher Education Schools by e2Campus: Info On The Go!, Omnilert LLC (2009), http://www.e2campus.com/ 6. Library SMS Alert Service: The Hong Kong Institute of Education (2007), http://www.lib.ied.edu.hk/collection/sms.html 7. Al Takrouri, B., Canonico, A., Gongora, L., Janiszewski, M., Toader, C., Schrader, A.: eyeJOT-A Ubiquitous Context-aware Campus Information System. In: 2nd International Conference on Pervasive Computing and Applications, ICPCA 2007, pp. 122–127 (2007) 8. Bikakis, A., Patkos, T., Antoniou, G., Plexousakis, D.: A Survey of Semanticsbased Approaches for Context Reasoning in Ambient Intelligence. In: Constructing Ambient Intelligence, AmI 2007 Workshops Proceedings. CCIC, vol. 3774, pp. 14– 23. Springer, Heidelberg (2008) 9. Antoniou, G., Bikakis, A., Karamolegou, A., Papachristodoulou, N.: A contextaware meeting alert using semantic web and rule technology. International Journal of Metadata, Semantics and Ontologies 2(3), 147–156 (2007) 10. Lassila, O., Swick, R.: Resource Description Framework (RDF) Model and Syntax Specification. W3C Recommendation, World Wide Web Consortium (1999) 11. Dey, A.K., Abowd, G.D., Salber, D.: A conceptual framework and a toolkit for supporting the rapid prototyping of context-aware applications. Human-Computer Interaction 16(2), 97–166 (2001) 12. Brickley, D., Guha, R.V.: RDF Vocabulary Description Language 1.0: RDF Schema. W3C Recommendation, World Wide Web Consortium (February 2004) 13. van Harmelen, F., McGuiness, D.: OWL Web Ontology Language Overview. W3C Recommendation, World Wide Web Consortium (February 2004)

A Framework for Context-Aware Adaptation in Public Displays Jorge C.S. Cardoso1,2 and Rui José1 1

DSI, Universidade do Minho, Campus de Azurém, 4800-058 Guimarães, Portugal 2 E.Artes / CITAR, Universidade Católica Portuguesa (UCP), 4169-005 Porto, Portugal [email protected], [email protected]

Abstract. Several approaches for context-aware public display systems exist but none has been able to bridge the gap between the myriad of possible interactive features of a display and adaptation rules for its content. In this paper, we propose a framework of digital footprints generated by the interaction with public displays that can be used as a means to dynamically characterise a place. We describe these footprints, how they can be generated and how they can be used by context-aware display systems to adapt to the social environment of a place. Keywords: situated displays, digital footprints, context-aware.

1 Introduction The overall idea of a context-aware public display that is able to deliver “the right information at the right time” has been pursued for some time, but remains to be realised. Most public displays are not even sensitive to their context. Content is entirely defined and fully controlled by the display owner, who, at best, uses some knowledge about the local place and the intended audience to define what might be interesting content. This, however, is a limited approach because public places are inherently very dynamic and diverse, supporting a broad range of situated practices. If all the decisions must be made a priori, they will not take into account the fluidity and heterogeneity of the social context around the display. The absence of interactive or sensing features also means that there will be no meaningful traces of user activity: their intended use is simply to be seen by people, so it will normally be used without generating any information about how it was used. Enriching public displays with interaction capabilities provide the obvious path for addressing these two issues. Displays that offer people the possibility to interact can lead to stronger user engagement and possibly user-generated content. They will also be able to produce traces of user activity upon which multiple adaptation processes can be implemented. Multiple variants of this approach have been tried to explore the obvious potential of interactive features in generating activity traces that may support context-aware adaptation. However, success has also been very limited, especially in obtaining results that could be generalized to multiple adaptation processes. Part of R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 118–127, 2009. © Springer-Verlag Berlin Heidelberg 2009

A Framework for Context-Aware Adaptation in Public Displays

119

the problem may originate from the clear gap between the information generated from interaction events in public displays and adaptation processes. The key problem is that given the broad diversity of interaction modalities and adaptation rules, there is nothing as obvious as a user click that we can immediately take as a concept for linking these two sides. In this work, we propose a framework for designing context-aware public displays. Our goal is to create a design space that can serve as tool for informing designers of situated displays about the relation between the supported interaction modes, the type of digital footprints they can generate and the type of adaptation processes they may support. We started by analyzing multiple interaction alternatives from the perspective of the information they generate. Rather than considering the specific affordances or semantics of the interactive features offered by the display, we focused on the type of digital trace they generate. We use the concept of digital footprint to refer to the digital traces generated as a side-effect of implicit or explicit interactions with the display, which can be of many different types e.g. keywords, content, presence, indication of external content, feedback on presented content, external personal profiles, or others. Based on their key properties, we aggregated those digital footprints according to 4 main categories: presence, presence self-exposure, content suggestion and actionables, providing a mapping between multiple interaction alternatives and their contribution to the generation of local digital footprints. We then analyse the types of adaptation processes that can be associated with each of those digital footprints, thus providing a mapping from footprints into context-aware adaptation processes. Overall, these mappings provide the framework for reflecting on context-aware behaviours without being caught by the specificities of any particular interaction or sensing mechanisms, thus providing a path for generic context-aware mechanisms.

2 A Framework for Digital Footprints in Public Displays The potential existence of a very broad range of sensing and interaction mechanisms, with very diverse properties in terms of the digital footprints they can generate represents a major challenge towards a generic model of context-aware displays. To address this issue, we will now analyze the various types of footprint from the perspective of their key properties. This classification is clearly display-centred, in that the categories were defined according to the type of footprint that gets generated at the display, without any consideration for the particular interaction model provided to the user. We have divided the digital footprints into four categories: presence, presence self-exposure, content suggestion and actionables. 2.1 Presence Presence corresponds to the ability of the display to collect information about nearby people. There are several levels of presence information that may generate very different digital footprints, more specifically, we consider the following levels: presence detection, presence characterisation and presence identification.

120

J.C.S. Cardoso and R. José

Presence detection Presence detection is the most basic level of presence information in which the system is simply able to detect whether or not there is someone nearby. Knowing that someone is near a display, even without knowing who or how many, may be used as a simple way to characterise a place, but is most likely to serve as a trigger for specific content on the display to get people’s attention and attract them to interact. Commercial motion or distance sensors can be used for this purpose. In Virtual Kitchen [7], for example, a passive infrared sensor to detect presence in the Kitchen. Presence was used to disable the outside “Off” button that stopped the video streaming if someone wanted more privacy (the button was only available if the no one was in the kitchen already). Distance can also be used by the display. There is usually a strong correlation between distance and awareness level towards the display. In [9], for example, an infrared distance sensor was used to determine the distance of people using a whiteboard application and trigger different interaction modes. Computer vision techniques such as frame differencing to determine movement can also be used for this purpose. In the Aware Community Portals [21] frame differencing was used to detect passers-by and triggered the display to cycle through images of recent stories. Pressure mats [5], usually designed for security applications, can also be used as a presence detection mechanism, for very well-defined and small areas. The digital footprint generated by these presence detection mechanisms is a presence/absence pattern that may help to characterise the nature of the place in terms of people flow. Presence characterisation The second level of presence information is the ability to characterise presence. This may involve determining how many people are near the display or inferring some type of characteristic about viewers, such as age or gender. Periods of high activity or low activity in a place, or the presence of people with specific characteristics, can all be used to trigger specific content in the display. Commercial people counters [25] that count the number of people entering/exiting a room can be used by a display system to estimate the number of people nearby. Computer vision techniques such as face detection, gender classification [23] and age classification [10], used by some audience metering products [18], can also be used to characterise and estimate the number of people in front of a display. These audience metering products can deliver reports about the number, attention span, gender and age of the viewers of a particular display. Presence characterisation generates a richer description of people flow. The display system is able not only to determine periods of presence/absence, it also becomes able to characterise the changes in the number and type of viewers. Presence Identification Presence identification corresponds to the ability to detect unique identities in the presences. Determining who is present, in the sense that the display system is able to determine that the same person is present in different occasions, gives the display system, not only the possibility to determine how many people are present, but also to establish a correlation between different people or groups of people. This may be achieved through face recognition techniques, but the most common approach is by

A Framework for Context-Aware Adaptation in Public Displays

121

far the use of some personal device (with Bluetooth or RFID capabilities, for example) as a proxy for the person. Bluetooth has been used extensively as presence detection mechanism since many people already own a Bluetooth enabled mobile phone. The BluScreen system [20] uses Bluetooth detection to avoid showing advertisements to users more than once. The Cityware project [12] explored several ways in which to analyse Bluetooth mobility traces, including a set of in situ visualizations about Bluetooth presences [11]. These visualisations provide people with information about current or recent Bluetooth presences. Radio Frequency Identification (RFID) tags can also be used for presence identification. In the IntelliBadge project [4], users participating in a conference were given RFID augmented badges that were used to track them through the conference rooms. A display at the conference cycled through several visualizations of the resulting data. RFID tags have the advantage that they are small and can be incorporated into many existing artifacts. In situations such as a conference, as in the IntelliBadge system, where people are already obliged to wear a badge, this may be a good choice. Bluetooth, on the other hand, is a very widely deployed technology and many mobile-phones are already Bluetooth enabled. This means that it is possible to use the Bluetooth discovery features to detect presence without requiring the user to carry any additional object (as with the RFID tags), as most people already carry a mobile phone regularly. Also, Bluetooth allows the user to manage his presence by turning it on or off at will. 2.2 Presence Self-exposure Self-exposure corresponds to the ability of the display to obtain information about the interests, preferences or activities of nearby people. This type of knowledge about the people that use a place may enable the display to adapt itself to their expectations and preferences. For this to happen, users must be willing to let the display system know something about them. This personal information can take many forms: it may be a reference to a user’s personal webpage, a set of user associated tags, the username for some social sharing website, a set of interest categories or even personal information, such as age and gender. The most common approach for supporting presence self-exposure combines presence identification with the a priori definition of a user profile that becomes associated with the identity. This approach was used in the Proactive Displays [13], were users attending a conference registered their affiliation, interests and personal webpage before the conference day and were given RFID augmented conference badges at the conference site. In this system, the user does not have easy access to their information in order to update it which means that they have less control over what information the display system uses in a given moment. Another way to achieve this self-exposure is to use an information device (e.g. mobile phone) with a custom application that allows users to register a profile. This application can connect automatically, or on demand, to the display system and communicate users’ preferences. One example of this is Camera-Phone [22], where a custom mobile application is used to interact with public displays. This application may be configured with personal information that is made automatically available to the display system when a user interacts with the display. One advantage of this approach is that the information is always available to be updated by its owner.

122

J.C.S. Cardoso and R. José

Bluetooth naming, as described in [8], is yet another alternative for managing selfexposure. Naming is explored to allow users to enter predefined commands in their mobile phone Bluetooth name. Since these names can be read by any other Bluetooth device, this can be used to provide an opportunistic interaction mechanism to any user since there is no need to install an application. This approach, however, is less suited for private information since anybody can read the Bluetooth name. Personal information can also be sent explicitly by the user, using OBEX over Bluetooth, for example, to push a vCard or other structured text file to the display. 2.3 Suggest Content The display may offer user the possibility to upload content or references to content for presentations. By suggesting content, users are implicitly saying that such content belongs to that place. This is thus a way for the display system to sense the kind of adequate content for a place. Content may be specified directly or indirectly by the user: by sending the content itself, e.g., a picture, video, text or audio; or by providing a reference to the content (e.g. an URL); whatever the means used to suggest content, the display system will receive or access the content itself and possible meta-data associated with it. Many display system provide various alternatives for users to send content in order to facilitate content submission. WebWall [6], for example, allowed users to suggest content using SMS, email or a web interface. Plasma Poster [2] is another example of a display system that allows content (photos, text, web pages) submission through two interfaces: email and web form. Web Glance [17], a group web browsing system, also allows several input interfaces to be used: email and instant messaging. Bluetooth can be used in two ways to send content to a display system: using the standard OBEX protocol or a custom mobile application. Both Hermes [3] and Snap and Grab [15] use the OBEX feature to enable users to send pictures (in the case of Hermes) or any other media type to a display. In both cases, the user just selects the content on his mobile phone, selects the “send via Bluetooth” command and selects a particularly named device. Bluetooth can also be used by mobile applications to communicate with a display system. The advantage over using just OBEX to transfer files is that a custom application can be built to interact specifically with a given display thus allowing a more rich interaction. OBEX has an obvious advantage over a custom application: it does not need the user to install any additional software on his mobile device and so allow a slightly more opportunistic interaction. Content suggestion can be used by display systems in many ways, depending on the type of content. However, in most cases the display system will be able to associate, at least, keywords with the content the user submitted (either by gathering them from the content itself or from meta-data). 2.4 Actionables Actionables detection corresponds to the ability of the display to detect the user reactions to any suggested action. A considerable part of the information shown on public displays is intended to cause people to act [14]. In many cases, the action is completely unrelated with the interaction supported by the display, and there is no

A Framework for Context-Aware Adaptation in Public Displays

123

way to perceive the efficiency of actionables. However, it is also possible to conceive actionables that are intrinsically linked to the interaction modes supported by the public display, and thus obtain feedback on how they are used. This enables the system to infer interest on the content or services that are being offered. The concept of actionable is very broad and can take many and very diverse forms. We will explore in more detail the following approaches: content download, content control, rating, voting and classification. Content Download Content download is a way to get a personal record of something that is currently displayed. A user may wish to download an item for various reasons: to keep a permanent record of an item or as a way to inspect an item in more detail if the display only shows a summary, for example. Content can be downloaded to the user’s mobile device if a custom mobile application is provided by the display system that allows browsing and selecting content to download as in Content Cascade [19] or a user can browse for his Bluetooth device to send the selected content item in a touch-screen as in the Hermes Photo Display [3]. A different approach is taken by the Snap and Grab technique [15] where a user can select an item on the public display by taking a picture of it with a camera phone and then send it via Bluetooth (OBEX) to the display. The display system then searches the picture for embedded visual tags that identify the item; if a tag if found, the associated content is sent back (also via Bluetooth) to the users’ mobile phone. By downloading an item the user is implicitly saying that he finds that particular item of some interest, or at least of potential interest. Content Control Content control gives users some type of control over the information being displayed. In a touch-sensitive screen this may result in something very similar to a browsing experience, where the user can navigate through content and fully control the display. Other interaction techniques may offer lighter forms of control such as selecting which video should be presented next from a set of possible alternatives. Other alternatives may include asking for more details or extending the presentation time of an item being displayed, or asking for an item currently not being displayed. If the user asks to skip the current item, the display system can infer that the user does not find that item particularly interesting and instead wants to see what is next. If the display shows a list of scheduled items to appear next and the user is able to skip to a particular item the display system can infer interest on that particular item. Content control can be achieved by any selection mechanism. A touch screen is an obvious choice for this. Both Hermes Photo Display and Plasma Poster [2] use a touch screen interface to let users navigate their content. Jukola [16] also uses a touch screen, but in this case content is indirectly controlled through voting: users of a bar have the possiblity to vote on the next music to be played by selecting a music, among a list. Other selection mechanisms such as the one used by Snap and Grab or Content Cascade could be used for this purpose. Text commands sent by SMS, email or IM, as in the In WebGlance [17] system where users send an email IM message to the display system with a number corresponding to an option on the could also be used.

124

J.C.S. Cardoso and R. José

Content control is also a way to collect users’ implicit interest on an item, similarly to what happens with content download. Rating By rating an item, the user is explicitly saying the he likes or dislikes that item, depending on the value of the rating. This is a way for the display system to allow a user to explicitly indicate his preferences. Rating is found on many websites such as Youtube, Lastfm, Amazon, etc. On public displays, rating can be implemented using any selection mechanism or through text commands. Voting Displays can also collect users’ preferences by crafting polls which allow it to extract information directly or indirectly from an individual. For example, sports preferences of a user can be estimated by asking him to vote on his preferred athlete from a list of athletes from different sports. As with rating, voting can be accomplished through many different interaction mechanisms. As an example, Bluevote [1] uses images push via Bluetooth. In this case the selection command is a picture sent previously by the display system (by pushing the images to all discoverable Bluetooth devices). Users send back to the system the picture that corresponds to their vote. Bluevote was used in a conference setting to allow participants to vote on the best paper award. Classification Classification is of a different nature than the previous categories because the result is not a preference but the association of a description or keywords, for example, with a given content item. This can be a less natural action for a user, especially for public items, but it can be provided by displays in a more ludic perspective following the approach of Games With a Purpose [24]. Classification requires that the user is able to send free text to the display system and so requires a text submission mechanism such as SMS, email, IM, Bluetooth names, etc. 2.5 Footprints for Socially-Aware Interactive Displays The previous sections have highlighted the types of interaction mechanisms that we may need if we want to gather a particular type of footprint. This section will now analyse how those multiple footprints can be used to support various types of contextaware adaptation processes. Table 1 presents a mapping between the digital footprints and the most widely used interaction or presence mechanisms that generate those footprints. This mapping can be used by situated display designers to help choose the interaction mechanisms provided by the display in order to be able to collect a given set of footprints. Overall, the entire set of digital footprints constitutes a collection of data which can be used to characterise the place profile, enabling the display system to adapt its behaviour to that particular social setting. Regardless of their generic contribution to this broad adaptation, specific types of footprint can support specific types of adaptive behaviour. Figure 1 summarizes the relationships that can be established between the different footprints and possible adaptation processes.

A Framework for Context-Aware Adaptation in Public Displays

125

Table 1. Mapping between interaction mechanisms and digital footprints Footprint Presence Detection

Interaction Mechanism . Movement detection (proximity sensor; computer-vision)

Presence Characterisation . Face detection with age or gender classification, people counters Presence Identification Presence Self-exposure

. Bluetooth . RFID . Bluetooth (profile on device name; a priori profile definition) . RFID (a priori profile definition)

Suggest Content

. Email/IM . SMS/MMS . Bluetooth (OBEX; BT Name)

Actionables

. Touch screen (Standard GUI controls) . Email/IM (Text commands) . SMS/MMS (Text commands) . Bluetooth (Text commands, e.g. BT naming; Standard GUI mobile application) . RFID (Proximity activation, e.g. Touch & Interact)

Fig. 1. Possible adaptive processes associated with different digital footprints

3 Conclusions Situated displays cannot rely solely on a static pre-characterisation of the place they were designed to. They must adapt themselves to their changing environment by collecting digital footprints that will help in characterising the social context in which the display is embedded.

126

J.C.S. Cardoso and R. José

In order to be efficient, digital displays need to target their audience’s needs, expectations and tastes. By collecting digital footprints of people’s interactions, displays can take a step in this direction. We have presented an interaction design space that defines a mapping between interaction mechanisms and their contribution to the generation of digital footprints with relevance for the characterisation of a place. Each footprint may be used in isolation or in conjunction with other footprints by digital displays to target specific aspects of their audience.

Acknowledgements This work has been supported by “Fundação para a Ciência e Tecnologia” and “Programa Operacional Ciência e Inovação 2010” (POCI 2010), co-funded by the Portuguese Government and European Union by FEDER Program and by “Fundação para a Ciência e Tecnologia” training grant SFRH/BD/47354/2008.

References 1. Bortenschlager, M., Rehrl, K.: BlueVote - A Ubiquitous Audience Voting Service. In: Adjunct Proc. of the 9th Intl Conference on Ubiquitous Computing UbiComp 2007 (2007) 2. Churchill, E.F., Nelson, L., Denoue, L., Helfman, J., Murphy, P.: Sharing multimedia content with interactive public displays: a case study. In: DIS 2004: Proc. of the 5th conference on Designing interactive systems, pp. 7–16. ACM, New York (2004) 3. Cheverst, K., Dix, A., Fitton, D., Kray, C., Rouncefield, M., Sas, C., Saslis-Lagoudakis, G., Sheridan, J.G.: Exploring bluetooth based mobile phone interaction with the hermes photo display. In: MobileHCI 2005: Proceedings of the 7th international conference on Human computer interaction with mobile devices & services, pp. 47–54. ACM, New York (2005) 4. Cox, D., Kindratenko, V., Pointer, D.: IntelliBadge: Towards Providing Location-Aware Value-Added Services at Academic Conferences, pp. 264–280 (2003) 5. Electronics, A.: Pressure Mats (2009), http://www.arun-electronics.co.uk/ pressure_mat.htm (visited April 2009) 6. Ferscha, A., Kathan, G., Vogl, S.: WebWall - An Architecture for Public Display WWW Services. In: The Eleventh International World Wide Web Conference (2002) 7. Jancke, G., Venolia, G.D., Grudin, J., Cadiz, J.J., Gupta, A.: Linking public spaces: technical and social issues. In: CHI 2001: Proceedings of the SIGCHI conference on Human factors in computing systems, pp. 530–537. ACM, New York (2001) 8. Jose, R., Otero, N., Izadi, S., Harper, R.: Instant Places: Using Bluetooth for Situated Interaction in Public Displays. IEEE Pervasive Computing 7(4), 52–57 (2008) 9. Ju, W., Lee, B.A., Klemmer, S.R.: Range: exploring implicit interaction through electronic whiteboard design. In: CSCW 2008: Proceedings of the ACM 2008 conference on Computer supported cooperative work, pp. 17–26. ACM, New York (2008) 10. Kwon, Y.H., Vitoria Lobo, N.d.: Age classification from facial images. Comput. Vis. Image Underst. 74(1), 1–21 (1999) 11. Kostakos, V., O’Neill, E.: Capturing and visualising Bluetooth encounters. In: adjunct Proceedings of the conference on Human factors in computing systems, CHI 2008 (2008)

A Framework for Context-Aware Adaptation in Public Displays

127

12. Kostakos, V., O’Neill, E.: Cityware: Urban Computing to Bridge Online and Real-world Social Networks. In: Foth, M. (ed.) Handbook of Research on Urban Informatics: The Practice and Promise of the Real-Time City. Inf. Science Ref., pp. 195–204. IGI Global (2008) 13. McDonald, D.W., McCarthy, J.F., Soroczak, S., Nguyen, D.H., Rashid, A.M.: Proactive displays: Supporting awareness in fluid social environments. ACM Trans. Comput.-Hum. Interact. 14(4), 1–31 (2008) 14. Müller, J., Krüger, A., Kuflik, T.: Maximizing the Utility of Situated Public Displays. In: Conati, C., McCoy, K., Paliouras, G. (eds.) UM 2007. LNCS (LNAI), vol. 4511, pp. 395– 399. Springer, Heidelberg (2007) 15. Maunder, A., Marsden, G., Harper, R.: Creating and sharing multi-media packages using large situated public displays and mobile phones. In: MobileHCI 2007: Proc. of the 9th Intl. Conf. on Human computer interaction with mobile devices and services, pp. 222–225. ACM, New York (2007) 16. O’Hara, K., Lipson, M., Jansen, M., Unger, A., Jeffries, H., Macer, P.: Jukola: democratic music choice in a public space. In: DIS 2004: Proceedings of the 5th conference on Designing interactive systems, pp. 145–154. ACM, New York (2004) 17. Paek, T., Agrawala, M., Basu, S., Drucker, S., Kristjansson, T., Logan, R., Toyama, K., Wilson, A.: Toward universal mobile interaction for shared displays. In: CSCW 2004: Proc. of the 2004 ACM Conf. on Computer supported cooperative work, pp. 266–269. ACM, New York (2004) 18. Quividi: Quividi - Automated Audience Measurement of Billboards and Out of Home Digital Media (2009), http://www.quividi.com/ (visited April 2009) 19. Raj, H., Gossweiler, R., Milojicic, D.: ContentCascade incremental content exchange between public displays and personal devices. In: The First Annual Intl. Conf. on Mobile and Ubiquitous Systems: Networking and Services, pp. 374–381 (2004) 20. Sharifi, M., Payne, T., David, E.: Public Display Advertising Based on Bluetooth Device Presence. In: Mobile Interaction with the Real World (MIRW) in conjunction with the 8th Intl Conf. on Human-Comp. Interaction with Mobile Devices and Services (2006) 21. Sawhney, N., Wheeler, S., Schmandt, C.: Aware Community Portals: Shared Information Appliances for Transitional Spaces. Personal Ubiquitous Comp. 5(1), 66–70 (2001) 22. Toye, E., Madhavapeddy, A., Sharp, R., Scott, D., Blackwell, A., Upton, E.: Using camera-phones to interact with context-aware mobile services. Technical report, University of Cambridge, Computer Laboratory (2004) 23. Verschae, R., Ruiz-del-Solar, J., Correa, M.: A unified learning framework for object detection and classification using nested cascades of boosted classifiers. Mach. Vision Appl. 19(2), 85–103 (2008) 24. von Ahn, L., Dabbish, L.: Designing games with a purpose. Comm. ACM 51, 58–67 (2008) 25. Wikipedia, People counter - Wikipedia, The Free Encyclopedia (accessed 6-April 2009)

Location Based Application Availability Raja Naeem Akram, Konstantinos Markantonakis, and Keith Mayes Information Security Group Smart card Centre, Royal Holloway, University of London Egham, Surrey, United Kingdom {R.N.Akram,K.Markantonakis,Keith.Mayes}@rhul.ac.uk

Abstract. Smart cards are being integrated into a diverse range of industries: ranging from banking, telecom, transport, home/office access control to health and E-passport. Traditionally, cardholders are required to carry a smart card for each application. However, recent developments in the Near Field Communication (NFC) have renewed the interest in multiple applications for different services on a single device. This paper builds onto the NFC initiative and avoids the smart card ownership issues that hinder the adoption of such devices. The proposal integrates the Global Positioning System with the NFC in mobile phones to provide a ubiquitously and flexible service access model.

1

Introduction

The smart card based service model is predominately issuer centric. This model gives the control of cards to its issuing organisation (i.e. banks, Telco, transport operator). The multi-application smart cards gave the technical capability of having multiple applications on a single card; however, the business case for such a scenario has been considered difficult until now. The Near Field Communication (NFC) [1] has enabled a Secure Element (SE) in a mobile phone to communicate with the terminal (e.g. ATM, Access Control, smart card reader etc) as a contactless smart card. A SE is an electronic chip that can securely store and execute programs (e.g. smart cards). Over the course of this paper, the term SE and smart card are used interchangeably. There are many organisations [2-4] that are putting new business models on trial to foster partnerships to accommodate this trend of convergence revitalised by the NFC initiative of different services onto a single chip. However, the traditional ownership issues of the SE are not being addressed. In this paper, a model based on the SE, NFC and Global Positioning System (GPS) [8] is proposed, enabling cell phones to be used ubiquitously to access a range of services. The proposal avoids the ownership issues of the smart card based service model that has decelerated the adoption of multi-application smart card technology. In section two the Location Based Application Availability (LBAA) is described along with the motivation. The architecture that supports the LBAA proposal is discussed in section three. Different processes of the proposed model are described in section four. In section five, future research directions are listed, and finally in section six, we present the concluding remarks. R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 128–138, 2009. c Springer-Verlag Berlin Heidelberg 2009 

Location Based Application Availability

2

129

Location Based Application Availability

In the following section we provide the motivation behind the proposed model, followed by the description of the LBAA proposal. 2.1

Motivation

The multi-application smart card technology has been introduced for more than a decade. However, the adoption of the technology is not being encouraged and it is mainly hindered by the issues of smart card ownership and associated relationship with customers. The issuers of smart cards actively control the relationship with the customer, as in most cases customers have to register with the issuers. Recent developments like NFC [1] and SE [4, 14, 15] in cell phones has reenergised the multi-application smart card initiative. It can enable a user to have multiple applications from different organisations that are installed on their SE, and use their cell phone to access associated services. Reducing the number of cards a user has to carry to perform mundane tasks. To support the initiative, there are different proposals for hardware and application lifecycle management. One proposal is to keep the traditional issuer ownership model that has been existing in the smart card based service model for decades. Another proposal is to delegate the ownership to a third party referred to as a Trusted Service Manager [4, 5, 6] that only manages the SE platform lifecycle. In both of these proposals, the ownership has to be delegated to an organisation. Whereas, other companies (lease holders) has to establish a trust relationship with the owner of the SE before they are able to provide services to their customers. The lease holders also have to trust the underline platform where their application is going to be installed. Thus, not only the lease holder has to trust the owner but also the actual platform. The ownership issue is still not fully resolved in the NFC initiative, puting it off for later resolution. However, it is evident from the multi-application smart card initiative that if these issues are not resolved satisfactorily, the fate of this trend would also be similar. In this paper, we present a theoretical proposal that removes the ownership issues and implicit trust in the underlying platform (SE). 2.2

Location Based Application Availability

The Location Based Application Availability (LBAA) enables a user to utilise a service by connecting to an associated remote application, based on its location information. The LBAA does not require the installation of an application onto a SE, removing the requirement of implicit trust and ownership of the platform. The remote application is hosted on a Remote Application Server (RAS) that is in total control of the application issuer (i.e. banks, transport, etc). The SE will support the LBAA model independently of its owner. The security of the SE is ensured by the manufacturer, making the ownership issues irrelevant in the LBBA model. The SE only has a secure binding with a RAS that enables the cell phone to connect with it and use the associated services. The cell phone connects through

130

R.N. Akram, K. Markantonakis, and K. Mayes

the internet provided by the mobile operators, as soon as the user enters the associated service zone. The service zone is identified by the aid of the GPS, collaborated with the published service terminals. The GPS is a navigational system that utilises a constellation of satellites in the medium earth orbit. The GPS can lock a position accurate to about 5 to 15 meters horizontal depending upon the atmosphere and geographical factors [8]. Most of the modern cell phones are equipped with the GPS, and it is used by the LBAA framework as a primary reference to the user’s position. The list of service terminals and their GPS locations can be advertised by mobile operators, third parties or users. The customers are only required to carry their cell phones, and applications to access services (i.e. banking, transport, etc) will be made available on demand. The location of a user plays an important role in the model. It decides whether to connect with a RAS, depending upon the services available in close vicinity. For the LBAA, the functionalities provided by the proposed model are as below: 1. A user only presents his/her mobile phone to a terminal and the related application should be available automatically without user’s involvement. 2. Applications are not stored on SEs. They are hosted on their issuer’s RAS and execute remotely. 3. The SE has credentials to access the remote application and acts as a secure communication bridge between the remote application and the terminal. 4. It provides a secure and flexible interface/mechanism to register with a RAS. 5. The SE connects with the remote application(s) as soon as the user enters into the proximity of the terminal. For example, if a user enters the proximity of an ATM the SE would connect with a remote banking application. 6. The SE should provide adequate security and privacy to the security parameters for each of the remote application, which is registered with it. The details of the proposed architecture based on the Smart Card Web Server (SCWS)[7], NFC, and GPS are discussed in the next section.

3

Location Based Application Availability Architecture

This section details the architecture of the proposal and its integral components. 3.1

Generic Architecture of Location Based Application Availability

The LBAA framework is based on cell phones and Service Providers (SP) that supports the LBAA to provide services to their customers. The mobile phones have SE(s) that also has the capability of the SCWS. The architecture is illustrated in figure 1 and main components are described in the following sections. The mobile phone provides an interface that enables a user to enter SP’s registration credentials. The SP’s registration credentials are issued by the relevant SPs after the user is registered. From the SP’s registration credentials the SE will initiate an enrolment process with the Remote Application Enrolment Server (RAES). The RAES enables the SE to establish a secure binding for the

Location Based Application Availability

131

Remote Application Server (RAS). The secure binding will be used in future to establish a connection with the RAS to access the remote application(s). As a user enters in vicinity of a service terminal, the Event Triggering Software sends an alert to the Behaviour Analyzer. That calculates the probability of the user accessing the service. If the user is predicted to use the service, it would request the SCWS to establish a connection over the internet with the corresponding RAS and then act as a bridge between the terminal and the remote application(s).

Fig. 1. Location Based Application Availability Architecture

When the user waves the mobile phone on a terminal to access service(s), the terminal challenges the mobile phone to authenticate the user (application). The challenge is sent to the remote applications by the SE. Once the remote application authenticates the user, the terminal will provide the requested service(s). 3.2

Secure Element

A removable smart card based memory card is a suitable option for the SE for its mobility and in most case under user’s ownership. The SE provides the operational and security support for the LBAA model and it will ensure that the user would have the total privilege to bind their SE to any RAS they require. 3.3

Smart Card Web Server

The Smart Card Web Server (SCWS) enables a SE to communicate directly over the internet. The LBAA model requires that the SCWS supports the TCP/IP and SSL/TLS protocols. The functions of the SCWS in the LBAA framework are listed as below: 1. Facilitate the establishment of a secure binding between a SE and a RAS. 2. The Secure and unique bindings are store in a secure storage in complete isolation to any other applications/processes or bindings.

132

R.N. Akram, K. Markantonakis, and K. Mayes

3. On the request of either the Behaviour Analyzer or the user, the SCWS establishes and maintains the connection with the RAS. 4. The SCWS act as a communication bridge between the terminal and the remote application, once the connection is being established. 3.4

Behaviour Analyzer

As the user enters in the vicinity of a service terminal, the SE establishes a connection with the corresponding remote application. The establishment of the connection adds up to the time that a user would have to wait before (s)he can access the service(s). Therefore, a possible solution is to anticipate the user’s behaviour. For this purpose, an Artificial Intelligent Agent is included in the model, referred to as a Behaviour Analyzer. The Behaviour Analyzer can base its decision on the availability of terminals in the proximity environment, the direction of movement and the behaviour of the user. If the probability is high for a particular service, the Behaviour Analyzer will request the SCWS to establish a connection with the relevant RAS. 3.5

Event Triggering Software

The Event Triggering Software (ETS) checks the GPS measurements and matches with its own or off-site (i.e. mobile operator’s) database for service terminals along with supported applications. The ETS maintains a set of services that lists the unique services available in a user’s proximity. When the ETS detects any changes in the location of the user, it scans for unique services provided by new terminals in the vicinity. If it finds a unique service, it will trigger an alert to the Behaviour Analyzer. Thus ETS limits the alerts to the Behaviour Analyzer by only alerting for terminals with new services. 3.6

Service Provider

A service provider (e.g. banks, transport, health services) is a company that offers smart card based services. In the LBAA framework, an SP is a company that supports the framework and offers their remote application(s) to their customers. To support the LBAA functionality, SPs are required to implement the following servers. Remote Application Enrolment Server. A Remote Application Enrolment Server (RAES) enables a SP to enrol their user’s SE to access their remote application(s). The RAES should base its enrolment process on a mechanism that does not rely on the active involvement of the telecom operators. In addition, the SPs rely on the trust relationship with their customers but not with the mobile operators or the owner of the SE. To support the LBAA model the RAES should provide the following services; – User’s Account Management This provides the crucial service of managing the details of the user’s registered SEs for accessing the remote application(s).

Location Based Application Availability

133

– User’s Device Enrolment: : This service allows a user to enrol a new SE to access remote application or remove a SE. – Remote Application Server Update: Once a binding is generated, the RAES will send the binding to the RAS along with the user’s SE details. These bindings, referred to as security parameters are used to access the remote application(s). Remote Application Server. The Remote Application Server (RAS) stores the personalised applications for each of the enrolled customers. A personalised application holds the customer specific data that may include customer’s personal details along with unique cryptographic keys. The RAS also allow the remote execution of application(s) and communicate the execution results to the requesting terminal via user’s SE. To provide this service, the RAS first authenticates the user’s SE to hold a valid binding and permission to access the remote application(s) without involving the users. Application Service Access Server. The Application Service Access Server (ASAS) is an authentication server that authorises the user’s requests to access the services provided by the SP. The current architecture of the ASAS as implemented in the banking, transport, etc, does not require to be modified. This enables an SP to implement the LBAA framework without any extensive modification to their existing infrastructure.

4

Location Based Application Availability Framework Processes

This section describes the processes involved in the proposed architecture of the LBAA framework 4.1

Remote Application Enrolment

The Remote Application Enrolment (or Scheme Enrolment) process registers a user’s SE with the Remote Application Enrolment Server (RAES) and establishes a secure binding that the SE can use to access the remote application(s). Before the Scheme Enrolment process can be initiated, the SP registers their customer with the RAES and provides them the registration credentials. The credentials include the RAES web address, user’s account ID and password. The description of the credentials is in the SP’s discretion. The operations performed in the Remote Application Enrolment process are listed as below: 1. A SCWS initiates the connection with a RAES. The connection is based on two-way SSL/TLS protocol [9]. After the connection is established, the user provides his/her credentials through the cell phone. The credentials are communicated to RAES and they should not be stored by the SCWS.

134

R.N. Akram, K. Markantonakis, and K. Mayes

2. If credentials are verified, the RAES send the platform specification that contains cryptographic requirement for establishing and using the binding to access remote application(s). It also include the validity (lifetime) of the binding. The lifetime can be a number of executions, or time depending upon the discretion of the SP. 3. If SCWS satisfies the platform specification, it initiates the binding process by sending a binding request. The binding request contains a unique device number from the SE that is used to create a unique binding and manufacturer certificate. The certificates are cryptographically generated by the manufacturers and they assure that SE meets the platform specification. 4. The RAES will generate a unique remote application access identifier and a cryptographic binding key (K-Binding). The remote application access identifier is generated by taking the MAC [10] of the SE’s unique number along with user credentials, remote application details, and a random number [10]. The identifier acts as a login name to access the RAS and the K-Binding acts as a password. 5. The RAES updates the RAS with the new binding. The RAS uses the binding to authenticate the SCWS when it requests the access of the remote application(s). 4.2

Application Availability Process

The LBAA depends upon the active recognition of terminals and associated services. The owner of the terminal registers their terminal location with either the mobile operator or a third party. When a user enters the vicinity of a terminal, the ETS recognizes it, and decides whether to invoke the Behaviour Analyzer or not. However, if the user decides that only the GPS is not sufficient, the LBAA framework can use other mechanisms like Bluetooth, Wireless network, etc. The terminals can advertise their geographical location and services maintained through these mediums. This would be a preferable option for small/close company environment (e.g. University, Leisure Centre, etc). The LBAA framework also allows a user to manual enter a terminal’s GPS location information along with supported applications to the ETS. This allows small businesses or an individual to customize the LBAA to their requirements. Regardless of the mechanism through which a terminal advertises its location, the application availability process will be the same. 4.3

Remote Application Connection Establishment

The SCWS in LBAA framework establishes a connection to access a remote application on a RAS. The main requirement is the SCWS establishes a secure and low footprint communication channel. The protocol to establish a secure channel is illustrated in the figure 2. The SCWS generates a cryptogram that is encrypted by the application’s binding key (K-Binding). It contains the SCWS identifier, a random number, user’s location information, and application identifier.

Location Based Application Availability

135

The RAS has the same K-Binding and it decrypts and verifies the message. If the message is valid, the RAS would issue a remote application access ticket. The ticket contains a new session key encrypted with the SCWS key along with the RAS Identifier, location information and lifetime of the ticket. The structure of the RAS Identifier is left on the discretion of the SP. The SCWS retrieves the session key and sends an acknowledgement message.

Fig. 2. The Protocol to establish the connection between the SCWS and RAS

The protocol is kept simple and less computational intense to reduce the overhead of establishing the connection. The location information in the protocol is added for the audit purposes. If a user claims that his/her device was not used to access services at a particular location, the SP could verify the remote access logs to confirm it. There is a possibility that in certain situation the services like the GPS and mobile Internet are not available (i.e. blank spots in-terms of coverage or in an underground system). In these cases, the LBAA model should have some alternate methods like requesting the service terminal to provide internet gateway. 4.4

Application Services Access

The application access is initiated when user presents his/her cell phone to request a terminal. The process presented in this section is generic and it does not dive into the details of different application (i.e. banking, transport, and access control). The process can be divided into two distinctive phases. In first phase, the remote application connects with the terminal and verifies the locality of the mobile phone and terminal to avoid replay attacks. Second phase will be application specific, conforming to their specific standards/specifications (i.e. EMV [11], ITSO [12]). In this section we will only discusses the first phase as illustrated by the figure 3. A terminal sends a signed message by its signature key (SKT) to a SE. The message consists of a Challenge (i.e. Random Number) along with the terminal’s GPS location and cryptographic certificate. The cryptographic certificate verifies the authenticity of the signature key. The signature generated on the message is verified by the RAS, and it can match the certificate with blacklisted terminals and revoked certificates from the terminal manufacturers. A terminal sends signed messages by its signature key (SKT) to a SE (actually to SCWS in the SE). The message consists of a Challenge (i.e. Random Number

136

R.N. Akram, K. Markantonakis, and K. Mayes

Fig. 3. Application Services Access Process Phase 1

[10]) along with the terminal’s GPS location and cryptographic certificate. The cryptographic certificate verifies the authenticity of the signature key and the message verifies the location of the terminal. The certificate is generated by the manufacturer of the terminal and it also verifies the authenticity of the terminal itself. An adversary can emulate a terminal with desirable location information but it would be difficult to get a verifiable certificate to authenticate the genuine terminal. The signature generated on the message is verified by the RAS, and it can match the certificate with blacklisted terminals and revoked certificates from the terminal manufacturers. The SCWS then generates a message and sends it to the RAS. The message consists of the SE’s location and the message sent by the terminal. The RAS verifies the certificate for the terminal and also the signed message. It checks the location information sent by SE and terminal. If the variation is beyond the locality threshold of the SP, the process would be terminated. The locality threshold is the maximum variation in the GPS information of the SE and terminal, acceptable to a SP. The locality threshold is used to avoid the replay attacks over long distances. If the RAS is satisfied with the locality of the SE and Terminal, it encrypts the messages sent by SE and terminal with remote application LBAA key to Application Services Access Services (ASAS) along with remote application details. These details help ASAS to quickly locate the relevant decryption key for the remote application. The ASAS then initiates the application specific dialog with the remote application through the terminal and SE.

5

Future Research Directions

In this section, we will discuss the research topics that require further deliberations – Remote Application Execution: It is challenging to remote application execution in a resource constraint environment like smart cards. The implementation to support it should be secure, robust, and efficient. – Behaviour Analyzer: It is essential to the LBAA model for performance reasons; therefore, it should be a light weight implementation. The design should take into account that its purpose is to avoid unnecessary connections requested by the SCWS for remote applications.

Location Based Application Availability

137

– Vicinity Exploration Mechanisms: The main emphasis of this paper is on using the GPS to determine the available services in the vicinity of a user. However, other mechanisms that can provide the service availability in the vicinity in adequate timeframe should be explored. – Distributed Execution Model: This topic builds on the work remote application execution. As remote application execution will take longer then local execution. One possible solution to this execution lag is to distribute the execution between the SE and RAS. The common component of the application will be executed on the SE. The common components are sections of the application that a SP implements as part of their compliance with corresponding standard/specification. The sensitive part (i.e. cryptographic processing, proprietary algorithms) will execute on the RAS. This solution may reduce the communication and execution load on the RAS. – Practical Feasibility: We consider that it is necessary to measure the performance of the framework in the real world application. This analysis will assess whether such a model can be commercially feasible or not. A secure, robust, reliable and flexible solution of these questions will enable the model to be regarded as a practically feasible model.

6

Conclusion

The convergence of different applications on to a single chip is encouraging; however, the centralised control of the chip will still decelerate the adoption of a true open platform based service access model. The proposal does not violates the security and privacy requirement of each of the SPs as the applications are in total control of their SPs and they only provide the credentials to access them for remote execution. The proposal has its limitations and we expect it to be slower on performance than applications executing locally on the SE. However, it provides an alternative way to the present application execution model and research into the topics list above will determine whether it is possible to shorten the performance gap with the locally executing application.

References 1. Near Field Communication and the NFC Forum: The Keys to Truly Interoperable Communications, NFC Forum, White Paper (November 2006) 2. Co-Branded Multi-Application Contactless Cards for Transit and Financial Payment, Smart Card Alliance, Princeton Junction, NJ 08550. USA, White Paper TC-08001 (March 2008) 3. Pay-Buy-Mobile: Business Opportunity Analysis, GSM Association, White Paper 1.0 (November 2007) 4. Mobile NFC Services, GSM Association, White Paper 1.0 (2007) 5. Mobile NFC Technical Guidelines, GSM Association, White Paper 2.0 (November 2007)

138

R.N. Akram, K. Markantonakis, and K. Mayes

6. Best Practice for Mobile Financial Services: Enrolment Business Model Analysis, Mobey Forum Mobile Financial Services, White Paper 1.0 (2008) 7. Smartcard-Web-Server, Smartcard Web Server Enabler Architecture, Smartcard Web Server Requirements, Open Mobile Alliance (OMA), Version 1.1 (2008) 8. Parkinson, B., Spiker, J.J.: Global Positioning System: Theory and Applications. AIAA 1 (January 1996) 9. Dierks, T., Rescorla, E. (eds.): The Transport Layer Security (TLS) Protocol Version 1.1. RFC 4346 (2006), http://tools.ietf.org/html/rfc4346 10. Menezes, A.J., van Oorschot, P.C., Vanstone, S.A.: Handbook of Applied Cryptography. CRC, Boca Raton (1996) 11. EMV 4.2: Book 1 - Application Independent ICC to Terminal Interface Requirements, Book 2 - Security and Key Management, Book 3 - Application Specification, Book 4 - Cardholder, Attendant, and Acquirer Interface Requirements, EMVCo 4.2 (May 2008) 12. ITSO Std., http://www.itso.org.uk/ 13. K¨ upper, A.: Location-Based Services: Fundamentals and Operation. Wiley, Chichester (2005) 14. Madlmayr, G., Langer, J., Scharinger, J.: Managing an NFC Ecosystem. In: ICMB 2008: Proceedings of the 2008 7th International Conference on Mobile Business, Washington, DC, USA, pp. 95–101. IEEE Computer Society, Los Alamitos (2008) 15. Dynamic Management of Multi-Application Secure Elements, StoLPaN, White Paper 1.0 (2008)

EI2N 2009 PC Co-chairs’ Message After the successful third edition in 2008, the fourth edition of the Enterprise Integration, Interoperability and Networking workshop (EI2N 2009) was organized as part of the OTM 2009 Federated Conferences and was supported by the IFAC Technical Committee 5.3 “Enterprise Integration and Networking” and the IFIP Working Group 5.12 “Architectures for Enterprise Integration.” It is a fact that enterprises need to collaborate in order to prosper in the current extremely dynamic and heterogeneous business environment. Enterprise integration, interoperability and networking are the major disciplines that have studied how to allow companies to collaborate and communicate in the most effective way. These disciplines are well-established and are supported by international conferences, initiatives, groups, task forces and European projects where different domains of knowledge and points of view (e.g., technological or managerial) are used to achieve a variety of objectives in this domain. The past decade of enterprise integration research has seen the emergence of important new areas, such as research into interoperability and networking, which involve breaking down organizational barriers to improve synergy within the enterprise and among enterprises. The ambition to achieve dynamic, efficient and effective co-operation of enterprises within networks of companies, or in an entire industry sector, requires the improvement of existing, or the development of new, theories and technologies. An entire research community is, for example, devoted to the technical and theoretical questions of co-operative information systems. Enterprise modelling, architecture, and ontology are the pillars supporting the achievement of enterprise integration and interoperability, and each of these areas needs to produce results to contribute to the ambition. For these reasons, the workshop’s objective is to foster discussions among representatives of these neighboring disciplines and to discover new research paths within the enterprise integration community. To answer the needs of industry, the European commission has also started a new cluster (FinES) dedicated to studying new approaches to cope with the complexity of the future networked enterprises which will be able to exploit a set of business services supporting collaboration and interoperability, based on the Future Internet connectivity. Ideally the business process needs to become interactive, and the business flow needs to vary and evolve according to the behavior of the actors who cope with the external (market) requirements. After peer reviews, eight papers were accepted out of 15 submissions to this workshop. In addition to the presentations of the accepted papers, to involve workshop participants, groups were organized into what E2IN traditionally calls “workshop cafés” to discuss and debate the presented topics. The two “workshop cafés” enabled discussions related to the "Science foundation of Enterprise Integration and Interoperability" discussion (led by Herve Panetto, Ted Goranson and Ricardo Gonçalves) and to the “Management Aspects of the Next Generation of Enterprise Architecture” (discussion led by Peter Bernus, Pat Turner and John Gøtze). These groups reported the results of the respective discussions. To complete the workshop discussions, Claude Feliot, Core Competence Network Leader at Alstom Transport, was invited as a keynote speaker, and talked about R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 139–140, 2009. © Springer-Verlag Berlin Heidelberg 2009

140

Preface

“systems as foundations for MBSE (model-based systems engineering).” Systems engineering has been an important contributor to the field of enterprise architecture and enterprise engineering, as these fields can be considered to be “applied systems engineering,” whereupon the objective is to achieve integration and various systemic properties, such as interoperability, in systems that are complex and hybrid (human + technical) entities. Model-driven systems engineering and enterprise engineering are thus close relatives, with the opportunity to open mutually beneficial exchange of ideas. The papers published in this volume of proceedings present samples of current research in the enterprise modelling, systems interoperability, services orchestration, and, more globally, systems engineering and enterprise architecture domains. One architecting principle that has gained currency in the recent past is service-oriented architecture with its principles, reference models and technology, and if applied correctly can be an important contributor to the future of interoperable, networked and collaborative enterprises. A quality of these reference models has to be evaluated through maturity models and metrics before engineering the interoperability characteristics of the enterprise applications involved in the product value chain. The success of this complex field also depends on the maturity and coherency of the management of the involved enterprises, a topic covered by the second workshop café. It has been a great pleasure to work with the members of the international Programme Committee who dedicated their valuable effort for reviewing the submitted papers; we are indebted to all of them. We also would like to thank all authors for their contribution to the workshop objectives and discussions. Hervé Panetto Peter Bernus Ricardo Gonçalves Ted Goranson

Systems as Foundations for MBSE Claude Feliot ALSTOM Transport

Abstract. System enginieering has been able to cope, in the last decade, with its definition in terms of processes for the analysis of products, services and organisations in view of their design. Thus, system engineering has been more defined by its intend and program then by its purpose that Systems are. However, through the underlying assumption of MBSE (Model-Based Systems Engineering) which is that : insofar as we think through models, engineering is also a matter of modelling thinkings. This leads to the requirement that the other side of the definition of System engineering been addressed answering to "What are Systems?". In this communication, we will draw out some mainlines and orientations toward the formal definition of the concept of systems which are the fundations that MBSE is looking for.

R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, p. 141, 2009. c Springer-Verlag Berlin Heidelberg 2009 

High-Speed Access to RFID Data: Meeting Real-Time Requirements in Distributed Value Chains Holger Ziekow1,2, Benjamin Fabian2 , and Cristian M¨ uller2 1

International Computer Science Institute, Berkeley, U.S.A. [email protected] 2 Institut f¨ ur Wirtschaftsinformatik, Humboldt-Universit¨ at zu Berlin, Berlin, Germany {ziekow,bfabian,cristian.mueller}@wiwi.hu-berlin.de

Abstract. Using RFID data within operational processes requires fast data access. In distributed value chains, RFID data is not only captured locally, but also accessed from remote locations. However, retrieving data from remote RFID repositories may pose significant delays and slow down the operations. This paper analyses how companies can exchange RFID data in the presence of real-time requirements. We analyze results of performance experiments with globally distributed RFID repositories and propose novel architectures for speeding up data access.

1

Introduction

As companies continue to vertically integrate their processes, they need to exchange information across several steps in their value chains. RFID technology together with the EPCglobal Network promise to improve the exchange for object related data between organizations [1,2]. This network of information sources is based on the Electronic Product Code (EPC), which defines a numbering framework for uniquely identifying objects. RFID tags can store the EPC of the object they are attached to, which provides a unique reference number for managing data about this object. As objects move through the value chain, entities at different locations will collect data about them. Simple examples are records about the arrival of an object at a certain location, or the execution of a certain processing step. One important challenge is to integrate such object data across several value-chain steps and across different locations. The EPCglobal Network facilitates discovery and retrieval of RFID data from locations across the globe. Core services in this infrastructure are EPC Information Services (EPCIS) [1]. These services provide access to object-related data captured at a certain location or value-chain step, respectively. While these services work well for track and trace applications, their applicability under realtime constraints is questionable. Downstream business operations may require fast access to data records from previous steps. For example, a manufacturer may route items trough its production lines based on object-related information. R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 142–151, 2009. c Springer-Verlag Berlin Heidelberg 2009 

High-Speed Access to RFID Data

143

Also, companies may quickly check some object-related data at the material intake to reject invalid deliveries right away. In such applications, it is inevitable that the process of accessing EPCIS does not slow down the operations. Even manual operations usually require system responses faster than 0.5 seconds in order to not delay the process [3]. This number can be much lower for automatic processes. Meeting real-time requirements is particularly challenging if the application needs RFID data from very remote locations. In this paper we address the challenges of using EPCIS for time-critical operations. We specifically take the potentially global distribution of data sources into account. In Fig. 2 we present experimental results about accessing EPCIS around the globe. We propose a range of solutions for accelerating RFID data access in Fig. 3 and discuss their strength and weaknesses. The paper closes with an outlook on our future work.

2

Experiments on Retrieving Distributed RFID Data

We conducted large-scale experiments to test the retrieval of RFID data from remote sources. In our experimental setup, we did deliberately choose not to include the delay caused by an optional EPCIS-discovery phase – either using the standard Object Naming Service (ONS) [1], P2P-ONS [4], or EPCIS Discovery Services [5] – since our particular goals were to test (1) what minimal delays occur in accessing RFID data via EPCIS and (2) how the physical distribution influences the response time of the actual data exchange, even if all data sources are known in advance. Adding a discovery phase will only increase the access time for the whole process, and involves challenges out of the scope of this paper. Particular the aspect of physical distribution of the EPCIS is relevant in global supply chains. In this scenario, network delays due to long distance communication are inevitable. In our experiments we analyze the impact of this effect on real-time requirements for the actual data access. For the experiments we deployed EPCIS on globally distributed locations and issued simple queries for RFID data (see Fig. 1). As EPCIS software we used the open source implementation provided by Fosstrak [6]. Using the infrastructure of PlanetLab [7] we deployed EPCIS on servers in USA, Germany, China, and Japan. In all regions participated with three to five servers. The variance in set up servers derives from the fact that the nodes on PlanetLab are not reliable. We lost several nodes, even during the short period of time our experiment lasted. During our experiments we issued queries between the servers and recorded the response times. For a period of three days, we let every server issue one query per minute to the EPCIS on all other servers. We used a very simple EPCIS query that retrieves all data records about a single object (or EPC). All RFID data repositories stored records about two observations of the queried object and consequently the EPCIS returned two records for each request. Following the EPCglobal event model, each record includes the EPC, the event type (or action value, here “OBSERVE”), an identifier of the conducted business step, and a time stamp [8].

144

H. Ziekow, B. Fabian, and C. M¨ uller

Germany USA(EastCoast)

Japan China

Fig. 1. Locations of servers involved in our experiments

x100000

Fig. 2 depicts the distribution of response times for all queries in our experiments. The results show that only few queries responded with short delays. Overall, 65% of the queries took longer than 0.5 seconds to respond. Such delays would even slow down manual processes. Note that we tested EPCIS with very simple requests, so we measure delays for EPCIS queries under rather ideal conditions. Consequently, our experiments show results along the lower bound for delays. More complex examples are likely to yield even longer response times. 2

Responses

1,5

1

0,5

0 0 0,5 1 1,5 2 2,5 3 3,5 4 4,5 5 5,5 6 6,5 7 7,5 8 8,5 9 9,5 10 Responsetimeins

Fig. 2. Response times for EPCIS queries

Our results show that response times in a global setting are often too long for time critical processes. Consequently, time critical processes require measures to speed up data access. A more detailed look at our measurements reveals the cause of long response times and discloses where countermeasures can apply. Table 1 shows an extract of our measurements. It lists the minimum response times for queries between servers in different cities. Connections having response times always above 0.5 sec are highlighted. A proportion of the delay certainly results from low performance of some involved servers. This is because servers in PlanetLab usually run several experiments by different research groups in parallel, which can result in a slowdown

High-Speed Access to RFID Data

145

Table 1. Response times for queries between different locations from / to Berlin Boston Tokyo Toyohashi Osaka Hong Kong Beijing Berlin

70

267

652

658

649

753

805

New York

162

63

247

252

248

370

350

Boston

257

54

431

449

436

595

579

Tokyo

692

471

104

152

140

299

314

Toyohashi

642

439

86

41

73

224

1024

Osaka

641

254

81

77

48

213

394

597

736

719

655

735

Hong Kong 1271 1092

of some query clients and EPCIS servers in our particular experimental setting. The PlanetLab node in Hong Kong is an example where particularly the query client suffered from poor performance (see Table 1). For real world applications, we assume that high performing servers are available and the problem would diminish. However, Table 1 also shows that the physical distribution of data sources has a significant impact on the response time. This is due to the increased network QueriestoBoston Responsetimeinms

Responsetimeinms

500 400 300 200 100 0 0

5000

10000

QueriestoBerlin

800 700 600 500 400 300 200 100 0

15000

0

QueriestoTokyo

700 600 500 400 300 200 100 0 0

5000

10000

Distanceinkm

10000

15000

Distanceinkm

Responsetimeinms

Responsetimeinms

Distanceinkm

5000

15000

QueriestoOsaka

700 600 500 400 300 200 100 0 0

5000

10000

Distanceinkm

Fig. 3. Minimal response times in dependence on physical distance

15000

146

H. Ziekow, B. Fabian, and C. M¨ uller

delay for long distance communication. Note, that network delay is independent of the used server hardware and inherent in distributed data access. This effect is therefore of major relevance for accessing distributed RFID data. Fig. 3 provides more details. It shows the minimal query response times in dependence of the physical distance. Visualized are results for queries to Boston (top left), Berlin (top right), Tokyo (bottom left), and Osaka (bottom right). The charts show considerable variations between the depicted cases. Yet, in all cases we clearly see the impact of the physical distance. Our experiments show that the physical distribution of EPCIS servers accounts for a significant proportion in query response times. This effect is of particular importance to applications in distributed value chains. Short response times are often crucial to avoid slow down of operations. Given our performance measurements, it seems currently unlikely that EPCIS-based solutions can support time critical processes in distributed value chains. High performing servers may solve parts of the problem. However, network delay is inherent in accessing remote data sources. This effect appears to be significant in accessing remote EPCIS. To overcome this problem, we are developing several candidate architectures that take locality into account and thereby ensure short query response time. We describe these solutions in the following section.

3

Solutions for High Speed Data Access

Our goal is realizing fast access to RFID data in distributed value chains. When an object arrives at a certain process step, the object-related data must be available in short time. To achieve this goal we must overcome the problem of network delay. In the following, we propose four new architectures that allow answering EPCIS-queries without long-distance communication. The underlying principle of all solutions is to place required RFID data physically close to the query sinks. The solutions vary in the assumptions they make on the underlying processes and in the distribution of load throughout the system. We discuss each solution and illustrate it along simple supply chains. For our illustrations we assume that each supply chain station requires captured RFID data from all previous locations. An example for such applications is the creation of Epedigrees, for example in the pharmaceutical supply chain [9]. 3.1

Pulling RFID Data from EPCIS

Solution 0 shows RFID data retrieval using currently specified services, only. In this solution all supply chain parties pull required information on demand from their predecessors in the chain (see Fig. 4). As our experiments showed, this solution does not ensure short query response times. We include this solution in our discussion to clearly point out the differences to our alternative propositions.

High-Speed Access to RFID Data

StepN

147

LocationforsupplyͲchainstepN PhysicalProductFlow

Step1

Step2

DataFlow(Pull)

Step3

Fig. 4. Data flow in solution 0 (Pull)

3.2

Proactively Pushing RFID Data

In this solution, each supply chain station proactively pushes captured RFID data to locations that will need them (see Fig. 5). This ensures that the RFID data is already locally available when the corresponding object arrives at a certain process step. It is then possible to look for object-related information locally, resulting in very fast response times.

StepN

LocationforsupplyͲchainstepN PhysicalProductFlow

Step1

Step2

Step3

DataFlow(Push)

Fig. 5. Data flow in solution 1 (Push)

Because EPCIS do support push-based communication, one can implement this solution solely using EPCglobal standards. However, this solution makes very strong assumptions on the underlying processes. To setup the data distribution, one must know in advance (1) the exact path of each object and (2) the whole downstream information demand. That is, one must know which location will issue which query about which object. This can be viable in rigidly planned processes. However, the solution is infeasible for dynamic and flexible value chains. 3.3

Passing on RFID Data Hop-by-Hop along the Product Flow

In this solution, RFID data follow the product flow hop-by-hop (see Fig. 6). When a product is shipped, captured RFID data are sent along to the designed destination. Note, that this includes RFID data from the current and all previous steps. Thereby, all RFID data for an object reside on a close by server. We leave open if these servers run directly at the involved supply chain station or at a designated third party information broker. This solution ensures short response times by providing all required RFID data at a close-by server. However, it makes some assumption on the underlying

148

H. Ziekow, B. Fabian, and C. M¨ uller

StepN

LocationforsupplyͲchainstepN PhysicalProductFlow

Step1

Step2

Step3

DataFlow(Push)

Fig. 6. Data flow in solution 2 (Hop-by-Hop)

business process: (1) each supply chain station must know the immediate next hop in chain. This is generally a practically viable assumption. However, third party logistic providers may introduce some intermediate stations that are unknown to the sender. (2) In order to send the right information, it is necessary to know the whole downstream information demand in advance. Alternatively, one can simply pass on all available information. However, this would cause considerable overhead. (3) Passing all information along the chain may conflict with confidentiality policies. It is required that all downstream players cooperate and are trusted with the information. Another disadvantage of this solution is the distribution of load throughout the system. Servers downstream in the supply chain handle increasingly high data volumes. This raises questions about how supply chain partners share the burden of running the required servers or the payment for third-party information brokers. 3.4

Using Anycast and Distributed Mirrors

In this solution, each supply chain station pushes captured RFID data to distributed mirrors, e.g. run by one or several information brokers (see Fig. 7). Each query addresses the nearest server using anycast protocols [10]. A simple way of determining the nearest server is to use the physical distance as metric. Mapping servers into a multidimensional cost space may yield better results, but comes at the cost of keeping the servers network coordinates up to date [11]. The advantage of this solution is that it poses no restrictions on the underlying business processes. That is, it requires no knowledge about the product flow or the downstream information demand. Another advantage is that one can implement anycast transparently without changing EPCIS standards.. Query applications can simply use the EPCIS standard without noticing if they access the original data source or a close-by mirror. On the downside, this approach is somewhat limited with respect to reducing the response times. This is because it makes no assumptions on the origin of future queries. Consequently, one needs a large number of mirrors to ensure low network delay for any possible query sink. With only few mirrors available around the world, it is still possible that certain supply chain locations must access data from a remote mirror. The challenge is finding a good balance between expected delay and the number of mirrors. Favoring certain regions in the placement of mirrors can offer opportunity for optimization. For example, a

High-Speed Access to RFID Data

149

Broker1

Step1

Step2

Step3

Broker2

StepN

LocationforsupplyͲchainstepN PhysicalProductFlow

Broker

InformationBroker

DataFlow(Push)

DataFlow(Pull)

Fig. 7. Data flow in solution 3 (Anycast and Distributed Mirrors)

company may mirror its RFID data at the geometrical centroid (barycenter) of its most important clients. 3.5

Querying One Supply Chain Step in Advance

This solution compromises between push and pull in retrieving RFID data. Each supply chain station N informs its predecessor N-1 about its data demand (transmits the query). When station N-1 ships an object to station N, it pulls all required object data from distributed information sources and pushes them to station N (see Fig. 8 left). Note that to avoid confidential data for station N passing trough station N-1, a trusted third-party information broker (like in [12]) can come into play (see Fig. 8 right).

1.Query

Broker2 1.Query

Step1

StepNͲ1

2.RFIDData

StepN

StepN

3.RFIDData (includingthose fromStep1)

LocationforsupplyͲchainstepN PhysicalProductFlow

2a.RFIDData 2b.RFIDData

Step1

Broker

DataFlow(Push)

3.RFIDData

StepNͲ1

StepN

InformationBroker DataFlow(Pull)

Fig. 8. Data flow in solution 4 (Delegated Query Execution)

The advantage of this solution is that is makes very little assumptions on the underlying business processes. Most of the information flow is pull-based. Thus,

150

H. Ziekow, B. Fabian, and C. M¨ uller

upstream supply chain stations need not know the downstream information demand in advance. The only limitations are that (1) each supply chain station must know its predecessor and (2) that the predecessor cooperates. However, these are relatively viable assumptions. The above-discussed solutions show a spectrum of possible solutions for accessing RFID data. The spectrum ranges from very flexible solutions with potentially long response times to solutions that ensure fast response times but make strong assumptions on the underlying business processes. Table 2 provides an overview of strengths and weaknesses of the different solutions.

Table 2. Strengths and weaknesses of the solutions Solution

Strength

Weakness

0

-

Uses existing EPCglobal standards only. Is very flexible and poses no limitations to processes.

-

Has potentially very slow response times.

1

-

Uses existing EPCglobal standards only. Has fast response times.

-

Is very inflexible and poses strong limitations to processes.

2

-

Can ensure fast response times (Potentially zero network delay). Reduces network load trough reuse of event data as it is passed on. Distributes load.

-

Requires that the whole chain supports the service. Poses some limitations to processes by demanding that the next hop of the product flow is known. Requires that the downstream information demand is known.

-

-

3

-

Reduces response times. Conforms to EPCglobal standards.

-

The possible reduction of response times is limited (i.e. zero network delay requires mirrors on all computers in the world).

4

-

Can ensure fast response times (potentially zero network delay). Does not require that the whole chain supports the service.

-

Poses some limitations to processes by demanding that of the product flow is known one hop in advance.

-

4

Conclusions

In time-critical applications, the potentially global distribution of RFID data sources may constitute an important bottleneck for fast data lookup and storage. In this paper, we presented experiments on PlanetLab confirming this intuition. In our opinion it is therefore inevitable to design mechanisms and architectures to answer time-critical queries locally. We presented and discussed four important solutions to mitigate this problem. Our future work will concentrate on evaluating and comparing these solutions by analytical means, simulation, and extended experiments on real-world testbeds like the PlanetLab, focusing on trade-offs between flexibility and system performance.

High-Speed Access to RFID Data

151

References 1. EPCglobal: The EPCglobal Architecture Framework – Version 1.2 (September 2007), http://www.epcglobalinc.org/standards/architecture/ 2. Wamba, S., Boeck, H.: Enhancing Information Flow in a Retail Supply Chain Using RFID and the EPC Network: A Proof-of-Concept Approach. Journal of Theoretical and Applied Electronic Commerce Research 3, 92–105 (2008) 3. Ziekow, H., Ivantysynova, L.: Design Guidelines for RFID-Based Applications in Manufacturing. In: 16th European Conference on Information Systems, Galway, Ireland, pp. 2580–2591 (2008) 4. Fabian, B., G¨ unther, O.: Distributed ONS and Its Impact on Privacy. In: IEEE International Conference on Communications (ICC 2007), Glasgow, Scotland, pp. 1223–1228. IEEE Press, Los Alamitos (2007) 5. BRIDGE: BRIDGE Project WP2 – Serial-Level Lookup Service (2009), http://www.bridge-project.eu/index.php/workpackage2/en/ 6. Fosstrak: Fosstrak – Free and Open Source Software for Track and Trace (2009), http://www.fosstrak.org/ 7. PlanetLab: PlanetLab – An Open Platform for Developing, Deploying, and Accessing Planetary-Scale Services (2009), http://www.planet-lab.org 8. EPCglobal: EPC Information Services (EPCIS) Version 1.01 Specification (September 2007), http://www.epcglobalinc.org/standards/epcis/ 9. EPCglobal: Pedigree Ratified Standard – Version 1.0 (January 2007), http://www.epcglobalinc.org/standards/pedigree/ 10. Abley, J., Lindqvist, K.: Operation of Anycast Services, Request for Comments, RFC 4786 (December 2006), http://www.ietf.org/rfc/rfc4786.txt 11. Zhang, B., Ng, T.S.E., Nandi, A., Riedi, R., Druschel, P., Wang, G.: Measurementbased Analysis, Modeling, and Synthesis of the Internet Delay Space. In: 6th ACM SIGCOMM Conference on Internet Measurement (IMC 2006), pp. 85–98. ACM Press, New York (2006) 12. Ziekow, H.: In-Network Event Processing in a Peer to Peer Broker Network for the Internet of Things. In: Meersman, R., Tari, Z., Herrero, P. (eds.) OTM-WS 2007, Part II. LNCS, vol. 4806, pp. 970–979. Springer, Heidelberg (2007)

Cross-Dimensional Modelling Patterns to Empower Pan-European Business to Government Services Interoperability Fenareti Lampathaki, Sotiris Koussouris, George Gionis, Yannis Charalabidis, and Dimitris Askounis National Technical National Technical University of Athens, 9 Iroon Polytechniou, Athens, Greece {flamp,skoussouris,gionis,yannisx,askous}@epu.ntua.gr

Abstract. Pan-European policies envisioning a single European market and reduction of administrative burden call for effective, interoperable implementation and transformation of cross-border business-to-government services. Despite the existence of dedicated tools and methodologies that enable modelling and execution of cross-organizational business processes, a service-driven approach, that implies associating legal and business rules on the workflow, binding reusable documents with specific information exchanges among the stakeholders and extracting all-inclusive executable flows, remains to be adopted. In this context, the present paper outlines cross-dimensional patterns for modelling and transforming pan-European Business to Government Services interconnecting processes, data and rules under a common, cross-country prism. Such modeldriven patterns foster interoperability on a conceptual and platform-independent basis. Discussion on the results is targeting best practices that can be drawn at research level and is pointing out the key difficulties that have to be tackled due to lack of enterprises’ and public organizations’ readiness in various countries. Keywords: Enterprise Modelling, Data Modelling, Legal Rules, Pan-European Business to Government Services, Interoperability.

1 Introduction As governments across the world try to estimate and exploit the impact of Web 2.0 tools [1], their traditional role in service provision confronts a key challenge: the deployment of personalized, high quality electronic services through multiple channels needs to be accelerated, even if this requires changing their modus operandi. Moving towards a single European market, current advancements in the eGovernment domain, such as the EU Services Directive 2006/123/EC and the i2010 Strategic Framework, call for effective implementation of cross-border public sector services, also known as Pan-European Governmental Services (PEGS), which make the need for interoperability resolution more urgent and complex - due to the organizational, cultural and legal barriers. R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 152–161, 2009. © Springer-Verlag Berlin Heidelberg 2009

Cross-Dimensional Modelling Patterns to Empower Pan-European Business

153

In Computer Science and the new academic and research discipline, namely Service Science, Management and Engineering (SSME), services are autonomous, platform-independent entities that can be described, published, discovered, and loosely coupled in novel ways. Any piece of code and any application component deployed on a system can be reused and transformed into a network-available service [2]. In order to establish a systematic approach to public service design, services often tend to be considered as complex service systems. The challenges in such consideration include both the multidisciplinary nature of public services which combine ‘business’, technology, and organizational dimensions, and the lack of formal representations of public services. In the public sector, though, services shall obtain an even more holistic view incorporating both the conventional and the electronic services, as well as web services. In this direction, Business Process Management has been established as a recent trend in public administrations worldwide, following a relevant adoption by large enterprises. Although BPM in enterprises is often satisfactory, its application in public sector processes reveals important specificities and issues that need to be tackled [3] as: • Public sector organizations offer a large number of service types, usually being at the range of a few thousand and the documents needed as inputs, or are produced as outputs of the above are also counted at the range of several thousand. • Processes are highly structured: information requirements, methods for processing information and desired formats are known precisely. • Public services are run in silos, which constrain effectiveness in providing integrated and cost-effective services to customers. By breaking the siloed business processes into reusable services, and executing them with innovative serviceoriented technical architecture and infrastructure services, new pathways to future service business revenue and profitability success may open up [4]. • Legal issues have to be considered when a significant process change is to be performed in a set of public services, requiring the interconnected management of the legal elements and structures that affect the targeted services. Gaining knowledge and best practices from the implementation of several research projects (such as FP6 GENESIS, ATHENA-IP and FP7 COIN-IP, ONE) and EU member states initiatives, the present paper outlines a methodological framework for modelling pan-European e-Government services towards enterprises. The proposed methodology has already been applied to a set of targeted countries including Bulgaria, Romania, Czech Republic, Greece, Italy, Turkey and Cyprus, for which core Government to Business (G2B) services, including VAT reporting and payment, Income Tax, e-Procurement / e-Invoicing and Intrastat reporting processes, were effectively modelled and transformed [5]. The paper is structured as follows: In the second chapter, the proposed Crosscountry Government to Business pattern driven modelling methodology is outlined and analyzed. Chapter 3 discusses the main findings of this research and finally chapter 4 concludes by presenting the conclusions and the future steps towards a unified, interoperable and coherent Government to Business transaction environment.

154

F. Lampathaki et al.

2 Cross-Country Government to Business Transformation Methodology 2.1 Background Government to Business Modelling has received considerable attention recently by both business administration and computer science communities [6] as tools and methodologies are emerging to enable modelling and execution of crossorganizational business processes, and standards are being defined using guidelines and best practice approaches [7]. Much of the literature produced by the business process management community would suggest that implementing process orientated structures will help organizations to be more responsive to an increasingly changing environment: • The concept of Process Modelling has a long tradition from enterprise frameworks identifying and relating different architectural viewpoints and the modelling techniques associated with them [8], to state-of-the-art visual notations that represent business processes and their transformation into executable workflows [2]. Such standards typically provide a common notation that is readily understandable by all business users, from the business analysts to the technical developers and business people. • When it comes to data and documents modelling, XML (eXtensible Markup Language) and XML Schemas cannot help being in the foreground. According to [9], the UN/CEFACT Core Components Technical Specification (CCTS), as well as the Universal Business Language (UBL) also provide remarkable results through the utilization of reusable data components in order to allow for reusability of data elements, and to avoid transaction errors due to ambiguous notation. • As business rules are important for organizations, legal rules can be defined as business rules with the difference that they do not originate from sources relating directly to the enterprise, but come mainly from the underlying legal and statutory framework [10]. Modelling these rules is accompanied by emerging standards, like PRR (Production Rule Representation), RIF (Rule Interchanges Format) and SBVR (Semantics of Business Vocabulary and Business Rules) and has gained momentum in terms of describing and automating business behavior [11]. 2.2 Cross-Dimensional Patterns for Modelling and Transformation In this paper, the proposed approach for modelling and transformation of governmental services concisely includes the following steps, during which specific ICT tools are being applied: 1. Identification and prioritization of the services to be transformed. 2. Preparation of common libraries, definition of naming rules and formulation of semantically rich codelists, to be followed. 3. Unified modelling of the business processes to be transformed in each country, with the aid of Business Process Management and XML authoring software suites – properly extended to support additional features. The modelling aspects cover the legal, the organizational, the procedural, the semantic and the technological

Cross-Dimensional Modelling Patterns to Empower Pan-European Business

155

aspects, in compliance with internationally accepted standards, such as Business Process Modelling Language (BPMN), Business Process Execution Language (BPEL), United Nations’ Core component Technical Specification (UN/CEFACT CCTS) and Unified Business Language (UBL). Throughout this phase, existing patterns in terms of process flow, data and rules are investigated and compared against other knows standards (like ebXML, UBL, etc) in order to build reusable blocks that will be present in the generic models. 4. Harmonization & generalization efforts that produce generic, country-independent models for the services at pan-European level. Such models, which contain the patterns recognized during the previous step, are the foundation for enabling interoperability between administrations and businesses, providing for crosscountry electronic services, such as a generic VAT statement and payment process. 5. Analysis of the differences, discrepancies and different granularity levels observed among the models of the countries, leading to recommendations on amending the existing legislative framework accordingly in order to transform the processes and satisfy the generic models that enable interoperability. Such a methodology can run over increasing cycles (spiral approach), starting from a limited set of ‘core services’ for businesses and iteratively expanding, following the steps described above, until it covers all public B2G services. The contribution of this approach can be summarized as: • Adopting a Unified Modelling perspective complying with Model-Driven Architecture and taking into account not only process and workflow aspects, but also the data and the legal rules viewpoints at various granularity levels, as well. • Unveiling a rationale for harmonizing cross-country service models in compliance with the underlying legal framework and the specific country requirements by using the in-process recognized and reusable patterns of workflow, data and rules. • Bridging and coordinating public services modelling and transformation efforts at a cross-country level. 2.2.1 Preparatory Analysis of the Methodological Framework Since modelling and transforming all the public services at once is not feasible, due to the huge investments needed which will not present a high ROI rate in the short-term, selecting the well-timed policy domains and the corresponding public services of interest in order to pilot the proposed approach is thus not a step that should be underestimated since such a testbed may judge its prospective adoption. In this context, an initial set of service scenarios can be built on the basis of a multi-criteria evaluation framework consisting of criteria actual administrative cost of a service, its alignment with key e-Business and e-Government policies and standards, such as the UBL services and the i2010 List of 20 Basic Public Services towards businesses, etc. This kind of analysis will lead to the decision of which services should be prioritized and modelled in advance of others, in order to formulate a “core” public service set, containing the most important and valuable services, which will not only act as a probe for the verification of the methodology, but also as the foundation for future services to be constructed on top of it. During the modelling preparation phase, a set of infrastructures are being set up in order to ensure that the modelling and transformation phases that follow will run

156

F. Lampathaki et al.

smoothly and at the same level of granularity for all the stakeholders’ countries. Such infrastructures include: • Recommendation and adoption of common naming and design rules as a quality framework for the homogeneous design of models. Such rules at a cross-country level mandate the use of the English language. • Preparation of common libraries or pools for reusable assets, such as documents, organizations. Use “entry points” that help starting with the description of processrelated information without to work on the process model itself, Documents, IT Resources, Information Exchanges, and Roles. • Definition of glossaries and code lists • Decision on the level of detail (or abstraction) by which all processes will be described. This is not an easy part since there the process/subprocess/task terms often are overlapped and may lead to confusion. Furthermore, if the authorities have deployed infrastructures for managing e-Government knowledge around the services, such Service Registries and Core Directories [12] need to be exploited as they publish a great amount of explicit knowledge. 2.2.2 Unified Business Processes Modelling Phase In this phase, the Modelling Framework Granularity Levels are recognized taking into account the national and cross-country nature of the transactions between enterprises and governmental organizations (B2G transactions). Such modelling aspects from which modelling activities shall begin can be further detailed into: • Business Processes, with the complete workflow, the internal actions and activities performed during the process execution described in compliance with BPMN, as to be in a position to extract executable code in BPEL for the automation of the transactions in future systems. • Documents and Data acting as the interfaces of the business processes that require interaction with other external parties. It should be noted that documents are perceived as any documentation that contains information which is relevant either for supporting an activity or communicating and include both electronic and printed documents. Documents are constructed using CCTS which at a later stage contribute to the definition of the XLM Schema of the generic documents to be used during the actual transaction. • Rules embracing both business rules which are used from the different stakeholders either enterprises or governmental organizations and legal rules that govern the service execution and differ from country to country. Rules are described using the SBVR specification and are infiltrated both in the decision points of the processes and in the different documents in order to manage and drive the flow of the transaction in alignment with the existing legislative frameworks. As far as business processes dimension is concerned, the description views fall into three levels [13]: • Private Process view: shows all activities which are performed within the process. The focus is set on as-is organizational process modelling, it means activities like internal decisions or internal administrative work are also included. Such activities

Cross-Dimensional Modelling Patterns to Empower Pan-European Business

157

usually provide rich information on organizational units, IT resources, business and legal rules that impact the process design. • Public Process view: only shows activities that are useful to understand the relevant process outputs and communication with an external entity. The significant process logic has to be indicated as well. Activities of the external entity are not described: the description scope ends with an indication about the exchanged documents and messages. • Collaboration Process view: shows a consolidation of public processes for all the involved entities/roles. Public activities of each role are being linked through messages. Interactions are then visualized very easily and are the basis for more technical process description. In business data modelling, three main artifacts can be exploited [14]: • Core Data Types (CDT): Pre-defined by the UN/CEFACT, build the foundation of the GENESIS core component data modelling approach. The UN/CEFACT CDT defines the smallest and generic (without any semantic meaning) pieces of information in a business document with relevant characteristics. In this way, UN/CEFACT has created an unambiguous basis of atomic business information parts up to a complete business document according to the rules of CCTS, based on 21 standardized and well established data types (Amount, Binary Object, Code, Date, Date Time, Duration, Graphic, Identifier, Indicator, etc). • Reusable Business Information Entities (BIEs) which are the building blocks used to assemble business documents. As defined in the CCTS meta-model, Basic Business Information Entities (BBIEs), Aggregated Business Information Entities (ABIEs), and Association Business Information Entities (ASBIEs) are the reusable building blocks that are used during data modelling. • Specific Business Document (SBD) summarizing information about a complete and user-specific document and is referenced in user-specific process models. SBDs include context information that specifies the business environment in which they can be used. According to the different levels of IT knowledge of each role owner, the SBD distinguishes between “Unstructured Documentation” and “Structured Documentation”. The unstructured documentation requires only basic input on a business document like “Business information entity” (the name of the data field), “Mandatory”, and “Formatting Rules”. It allows a user with a limited technical know-how to easily describe a business document. Derived from the unstructured documentation, the structured information is then created. In order to create sound models of legal rules, a legal rules meta-model has been designed and defined in detail in [15]. The basic entities that need to be captured and interconnected with business processes and documents are: • Legal Framework which is a collection of basic conditions or parameters that an organization has to consider when conducting business. This may happen on a mandatory basis (the case with legal rules) or there may be voluntarily incorporated frameworks (like business rules or optional statutory guidelines). • Legal Element that defines a single element of a complete framework collection and is used to refine the view on entire frameworks. These elements affect the data Core Components used to generate the Business Documents of a transaction party.

158

F. Lampathaki et al.

• Rule defining the notion of rule (legal or business). These rules are inserted in the decision points of a collaborative process model in order to steer the execution of the transaction based on the underlying legislation, and are also present in the Business Documents in order to dictate the mandatory information which needs to be exchanged during the transaction. The models created in this phase focus on as-is situation and are characterized as Specific Representations – Variants that depend on the business context and combine the dimensions of Country, End-user and IT-system. Each variant is described and documented according to the pre-defined Description Views (Private, Public and Collaboration Process View) and Description Elements (Process, Rules, Documents).

Fig. 1. Unified Business Processes Modelling Granularity Levels

2.2.3 Harmonization and Generalization Phase When it comes to implement cross-country, different end-users and supporting IT systems transactions, the variants do not cover the necessary requirements for a generic representation, but provide insight on specific, narrow representations. Generalization and harmonization activities of the Specific Representation thus need to follow in order to lead to a Generic Representation of each process at the same abstraction level of the description elements (processes, rules, and data). In this context, "Generic" means that this process is not specific to countries, end users or systems, but considers all special requirements and recognized patterns and is the common denominator of the relevant variants. At data level, the Generic Business Document (GBD) can be considered a consolidated version of several user-specific documents and features all data items

Cross-Dimensional Modelling Patterns to Empower Pan-European Business

159

that occur in any of the affiliated SBDs. The idea behind the establishment of GBDs was to create data templates that can be used by all organizations at cross-country level and only need to be restricted according to their context to exactly match their respective business requirements. GBDs are then referenced from the harmonized collaboration process model. They also include contextual information to allow a (potentially) automated derivation of specific business documents.

3 Discussion Cross-dimensional patterns for modelling and transforming pan-European Business to Government Services by interconnecting processes, data and rules under a common, cross-country prism appear as a worthwhile track towards the implementation of B2G electronic services. From the application of the proposed methodological patterns in numerous European members states towards their governmental services modelling and transformation, important artifacts are presented with the application of generally available software tools, such as unified processes in BPMN and BPEL, universal CCTS-compliant syntax-independent schemas and XML Schemas, business and legal rules regulating the transactions expressed in a syntax-independent manner and as a SBVR vocabulary, for instance for automated income tax reporting and payment for Small and Medium Enterprises results from 7 countries have been collected and aggregated to create generic models. Problems faced during the adoption and application of the proposed methodology were not trivial and have to be to be taken in mind during relevant attempts by enterprises and government officials. Recognizing process and data reusable patterns within the specific-country variants in order to create generic models in compliance with the legal framework presupposes an agreed level of detail (or abstraction) by which all the models are described. In this context, strict modelling conventions and rules need to be applied and process and data models have to be re-worked to conform to such guidelines, otherwise automatic generation of executable code (in BPEL for processes and XML Schema for documents) fails. Conflicts in the legal framework of each country that lead to differences in the process workflow cannot be ignored under any circumstances and create exceptions in the generic models. Such exceptions in the generic process models that describe the current as-is situation of the involved stakeholders in order to conduct cross-country transactions can indeed inform the reference country or organization about possible malfunctioning services and potential points that should be re-engineered. Differences in data models, on the other hand, are resolved either during the mapping procedure from specific-country to generic data models (for example by recognizing synonyms, abbreviations, etc.) or through proper customization of context within generic data models. Models management and evolution are also crucial matters when it comes to the long term exploitation and viability of the proposed methodological framework. The adoption of a common “governance policy” including the change management procedures, the roles involved and the permissions allowed to the modelers needs to be defined in detail. As far as the data modelling aspects are concerned, customization issues of information modelling building blocks that reside in a repository should be handled through (not rigid enough) rules that allow users not only to use predefined

160

F. Lampathaki et al.

templates but also to customize / extend these templates according to their needs in compliance with a customization procedure. Finally, it needs to be mentioned that attaching legal rules expressed in a clear and straightforward phrasing (after having taken into consideration all the pertinent passages of the regulatory framework and all their relevant interpretations) in the modelling viewpoints appears as the most important element in a Business to Government Service, since they are the ones that dictate not only the execution of the workflow, but also the required data sets. What emerges from incorporating legal rules in the B2G services and their nature (as national governments set mandatory rules within legislation which should be respected by the other entities) is that legal interoperability aspects cannot be underestimated and homogenization and harmonization of legislation between the different countries at a pan-European level is a key driver that should be resolved in order to enable true interoperability.

4 Conclusions Motivated by the increasing need to achieve interoperability among small-medium enterprises and governmental organizations, this paper has presented design patterns for modelling and transforming pan-European B2G Services that cross the dimensions and provide equal attention to processes, data and rules. The proposed methodological framework builds on the principles of Model-Driven Architecture (MDA) and provides conceptual and platform-independent models on two axes: specific-country models that define the current situation in every country and generic models which are extracted out of the specific-country ones in order to add an abstraction layer and facilitate cross-country transactions. As the proposed methodological patterns have already been applied in the EUfunded research project GENESIS [5], future steps along our work mainly include exploration of how such cross-dimensional modelling patterns as the proposed ones can: (a) be exploited in the implementation of light-house projects at European level, such as the EC Large Scale Pilot SPOCS (Simple Procedures Online for Cross-border Services), which aims to meet the requirements set by the Services Directive and implement a first set of on-line Pan-European G2B Services, and (b) be further elicited in order to provide for automatic, on the fly generation of generic models based on the specific-country ones. Acknowledgments. This paper has been created closely to research activities during the EU-funded projects GENESIS (Contract Number FP6-027867) and GIC (Contract Number FP7- 204999).

References [1] Pascu, C., Osimo, D., Turlea, G., Ulbrich, M., Punie, Y., Burgelman, J.-C.: Social computing: implications for the EU innovation landscape. Foresight 10(1), 37–52 (2008) [2] Papazoglou, M.P., Traverso, P., Dustdar, S., Leymann, F.: Service-Oriented Computing: State of the Art and Research Challenges. IEEE Computer 40 (11), 38–45 (2007)

Cross-Dimensional Modelling Patterns to Empower Pan-European Business

161

[3] Becker, J., Pfeiffer, D., Räckers, M.: Domain Specific Process Modelling in Public Administrations – The PICTURE-Approach. In: Wimmer, M.A., Scholl, J., Grönlund, Å. (eds.) EGOV 2007. LNCS, vol. 4656, pp. 68–79. Springer, Heidelberg (2007) [4] Demirkan, H., Kauffman, R., Vayghan, J., Fill, H.-J., Karagiannis, D., Maglio, P.: Service-oriented technology and management: Perspectives on research and practice for the coming decade. Electronic Commerce Research and Applications 7, 356–376 (2008) [5] GENESIS Project (2009), http://www.genesis-ist.eu [6] Weske, M.: Business Process Management: Concepts, Languages, Architectures (2007) [7] Lippe, S., Ulrike, G., Barros, A.: A Survey on State of the Art to Facilitate Modelling of Cross-Organizational Business Processes. In: 2nd GI Workshop XML4BPM, pp. 7–22 (2005) [8] Lankhorst, M.: Enterprise Architecture at Work (2005) [9] Lampathaki, F., Mouzakitis, S., Gionis, G., Charalabidis, Y., Askounis, D.: Business to Business Interoperability: A Current Review of XML Data Integration Standards. Computer Standards & Interfaces 31, 1045–1055 (2009) [10] Gionis, G., Charalabidis, Y., Sourouni, K., Askounis, D.: Enabling Cross-Border Interoperability: Modelling Legal Rules for Electronic Transactions in the European Union. In: Enterprise Interoperability II. New Challenges and Approaches (2007b) [11] Graml, T., Bracht, R., Spies, M.: Patterns of Business Rules to Enable Agile Business Processes. In: EDOC 2007, Annapolis Maryland, U.S.A. (2007) [12] Sourouni, A.-M., Lampathaki, F., Mouzakitis, S., Charalabidis, Y., Askounis, D.: Paving the way to eGovernment transformation: Interoperability registry infrastructure development. In: Wimmer, M.A., Scholl, H.J., Ferro, E. (eds.) EGOV 2008. LNCS, vol. 5184, pp. 340–351. Springer, Heidelberg (2008) [13] Koussouris, S., Gionis, G., Sourouni, A.-M., Askounis, D., Kalaboukas, K.: Heterogeneous Domains’ e-Business Transactions Interoperability with the use of Generic Process Models. In: Enterprise Interoperability III: New Challenges and Industrial Approaches, pp. 159–170 (2008) [14] Lampathaki, F., Mouzakitis, S., Janner, T., Schroth, C., Askounis, D., Hoyer, V.: Achieving Cross-Country Electronic Documents Interoperability with the help of a CCTS-based Modelling Framework. EJETA 2(3) (2008) [15] Gionis, G., Charalabidis, Y., Janner, T., Schroth, C., Koussouris, S., Askounis, D.: Enabling Cross-Organizational Interoperability: A Hybrid e-Business Architecture. In: Enterprise Interoperability II. New Challenges and Approaches (2007)

Architecting the Firm – Coherency and Consistency in Managing the Enterprise Patrick Turner1, John Gøtze2, and Peter Bernus3 1 ASPL, Brisbane, AU [email protected] 2 Copenhagen Business School and IT-Univ Copenhagen, DK [email protected] 3 Griffth University, Brisbane, AU [email protected]

Abstract. Traditional Enterprise Architecture (EA) practice lacks a clear and effective governance and management layer that is easily understandable and intuitive to senior decision makers with the modern organisation. This paper uses three case studies to demonstrate the relative maturity of different EA practice groups within these organisations to demonstrate the strengths and weaknesses of a traditional ICT management approach versus those that include EA practice in all levels and domains of management. Concepts of Coherency Management and Pervasiveness will be used to explain the idea of a next Generation of EA practice that permeates all layers of the organisation and no longer remains the domain of technologists but instead influences and informs decision-making at all levels (operational, tactical, managerial / strategic) of the organisation. Conditions of such future EA practices are also discussed. Keywords: Next Generation Enterprise Architecture, Coherency Management, Enterprise Architecture Maturity, Interoperability.

1 Introduction Enterprise Architecture (EA) as a discipline was originally developed to support the full gamut of management in organisations [1, p23] [6]. However, historically, the architecture function has only been implemented to various extents within organisations, predominantly in technology support roles or as an ICT management framework. This paper presents three case studies (with the identities of the involved organisations removed) to demonstrate different levels of maturity at which enterprise architecture and enterprise architects function in the modern organisation. Whilst the case studies are not exhaustive, all three authors have repeatedly experienced similar patterns in other Organisations and, as such, argue that the cases can be considered archetypes of the way in which EA practice evolves The paper argues that this evolution eventually leads to a new approach where the Architecture function is directly responsible to the senior management team and accountable for the quality, consistency and timeliness of the information flow to that group. The direction of the evolution of EA practice (and of its components) points to a future R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 162–171, 2009. © Springer-Verlag Berlin Heidelberg 2009

Architecting the Firm – Coherency and Consistency in Managing the Enterprise

163

where this practice becomes pervasive across the organisation, is supported by adequate decision support tools, and is the platform underlying the coherency of management decisions [5].

2 Case Study Organisation #1 (Local Government Department) Architecture as a Liability (Cost) Organisation #1 is a classic Government Department. All Information and Communication Technology (ICT) related matters reside with the Manager of the Information Services Branch (ISB). The ISB Manager represented his employees and IT for that matter at the weekly and monthly management team meetings and dealt with all related issues personally. As serious issues emerged (system upgrades, failure of services, production outages, requests for new functionality, security policy reviews etc) he assigned tasks to his senior engineers as necessary. These senior engineers may or may not have been called architects and were often called system support officers, analysts or engineers. They maintained informal networks across the Organisation, based on their reputation and the quality of their work on previous tasks. They had no formal linkages or relationships with operational staff and certainly had no visibility or relationship with other Branch Managers or Department Heads apart from that of an employee delivering a service. The lesson from this case is that the stage of EA practice in such an organisation is characterised by a ‘struggle for existence’. Engineers or Managers trying to establish Architecture practice within an Organisation at this level of EA maturity can find themselves under attack or viewed with deep suspicion or accused of ‘empire building’ by their colleagues. The level of engagement by non-technical personnel will often be effectively nil and individuals not used to communicating in a non technical way may find the going too tough and give up. This will often reflect their relatively low standing within the Organisation and lack of real political and cultural power which impacts upon their ability to drive home real and lasting change. Successful individuals working at this level of maturity within the Organisation will often have to adopt a ‘crash or crash through’ approach to the use of EA and success Media Liaison

Minister’s Office

Finance mgr

HR mgr

Finance

HR

Project Sponsor Project A: Upgrade General Ledger

CS mgr

ISB mgr

Custom. Serv. Inf Sys Branch

Senior Executive Mgmt Team

PR CC mgr

Policy mgr

Marketing mgr

Call Centre

Policy

Marketing

Senior Engineer Business Analyst(s)

Project Sponsor

Technical Analyst(s) Developer(s)

Project C: On-line Marketing Strategy

Tester(s) Tester(s) DBA(s) Project Mgmt Pool

Project Sponsor Project B: Refresh Technology

Fig. 1. Architecture as a Cost Centre

164

P. Turner, J. Gøtze, and P. Bernus

will largely be localised in the first instance and more a factor of the strength of their personal convictions rather than any commitment to EA at an Organisational level. Given the above, it can be said that EA within this environment often emerges in the form of a champion or a senior engineer frustrated with the ad-hoc nature of things or someone who has external reading, study or work experience which demonstrates to them that there is a better way of organising and managing an ICT environment. Often this individual goes to extraordinary lengths, with some personal and professional risk involved, to get the ISB Manager to make the first faltering steps towards the development of an EA framework. The EA framework itself will always be seen here as an IT controlled asset, run by ‘techies’ for ‘techies’ with limited use and value by other personnel in the organisation apart from operational and program level reporting, specifically for technology driven initiatives or programs of work. Within this model there is no thought to exposing others outside of the IT Branch to the potential value or utility of an EA framework. Line Managers ‘procure’ technical resources via discussions with the ISB Manager and expect that they come equipped with their own approach and frameworks that will deliver the required outcomes.

3 Case Study Organisation #2 (Large Mining Company) – Architecture as an Asset Within this model, the Organisation from the beginning has recognised the existence of Architecture and the potential role it can play in managing and coordinating the delivery of technology aligned programs of work. In this case the CIO has created specific Architect roles (Chief Architect, Solution, Information, Infrastructure architect, etc) with the express purpose of achieving productivity improvements in the management and coordination of large enterprise ICT assets (ERP, billing, invoices, customer and vendor management, payroll, management and operational reporting, manufacturing, logistics, supply chain). In this type of Organisation, there is recognition at least of the potential for EA to help manage ICT assets across the Organisation and the understanding that other Departmental Heads and personnel need to understand and be involved in EA activities within the Organisation. This stage of EA practice evolution can often be ‘evangelical’, whereby a defined sub-group or community within the Organisation seeks to spread or extend its influence using whatever means possible. There is a religiosity about ‘spreading the word’ in that practitioners seek new converts wherever they may find them. The founding of this new faith can only occur because at least one of the senior Managers, often the CIO, is already a convert and the community has at last found some protection within one individual at a senior management level to defend and protect their flock. Architecture is now a recognised practice within the Organisation with published position descriptions and with proscribed review and over-watch responsibilities within the design and delivery of any large program of work. Figure 1 illustrates how large programs of work, with dedicated long term program resources and responsibility for delivering Organisational artefacts spanning several operational areas (Departments) have emerged.

Architecting the Firm – Coherency and Consistency in Managing the Enterprise

Executive director

Executive director

Board

Executive director

HR director

Finance

HR

VP Mine Ops

CIO

Mine operations IT Department

Project sponsor

Chief architect

Program A Consolidate Operational Systems

Architects

Project manager Business analyst Admin

Technical Analysts(s) Developer(s) DBA Team

Executive director

Senior Executive Management Team

CEO CFO

165

VP-Ports

COO

Marketing dir

Ports

Infrastructure

Marketing

Project sponsor Program A Consolidate Operational Systems

Program B Global Web Strategy Rollout

Project manager

Project manager

Business analyst

Business analyst

Admin

Admin

Fig. 2. Architecture as an Asset

The locus of control for the EA framework still firmly resides with the CIO and the traditional IT Department aided by an evolved structure hierarchy of chief- or principal architect and then senior and junior architects perhaps also managed by functional layers – i.e. data, integration, system, application etc. Certifications, training and experience with various EA frameworks have now become highly valued and the Architectural community that has emerged is often characterised by religious ‘wars’ between competing ideologies or camps supporting one EA framework or toolset over another. These often occur within the IT Department itself and can result in significant personal and professional loss of face to the protagonists who often begin to use external materials, vendor publications, industry surveys, reports, consultants, academic or commercial journals to state their case or overcome their opponents. In this stage EA practice is seen as an enabler for the organisation to define and to deliver ICT services to best support business needs, and architecture descriptions are to be also seen by non-IT people – although traditional models which satisfy IT stakeholder concerns may not be of interest to the non-IT stakeholder [7]. New communication and modelling skills (and tools) become necessary for this more extended architecture practice to be successful. Ross et al [9] describe roadmaps and criteria for success for this stage of development with skill extensions and dual role definitions required for Technologists and Managers alike.

4 Case Study Organisation #3 (Global Bank) – Architecture as a Service On this level of maturity, the EA function is now offered as a core Service provided by a de-centralised Enterprise Architecture team. Not all members of the team are physically co-located, with the delivery and maintenance of core EA assets across multiple geographic locations. Many architect- and analyst roles now reside permanently within business units themselves outside of this core EA team. The core EA team ‘own’ the dissemination and communication of corporate standards, governance and procurement of new system domains and de-commissioning of old

166

P. Turner, J. Gøtze, and P. Bernus

core platforms, whole of Enterprise initiatives and upgrades to the core operating systems within the Organisation as a whole but in an increasingly “custodial” fashion only. The first elements of self absorbed “coherency” practice with a level of pervasiveness (unconscious adoption) can now be seen. In organisations with this level of EA practice maturity the core EA team (‘Global EA Framework and Service Delivery Team’ in Fig.3) will focus on strategic initiatives. Also, individual line Departments will now have the delegated authority to design, procure, implement and support their own specialised applications as long as each step in the journey stays within the approved governance procedures and standards and policies. No longer does the core team ‘own’ architecture outside of the core EA assets and framework, as applied architecture in the form of application and system level design has now permeated the whole Organisation with dozens if not hundreds of simultaneous programs of work occurring across multiple specialised domains of work. The Core EA team is responsible for the establishment of Meta models and a Meta framework, and for a repository and tool-set used for the creation and dissemination of architecture artefacts (architecture descriptions and models), as well as ensuring broad conformity within a published set of standards and procedures. Pervasiveness or “unconscious adoption” is now vitally important if the EA framework is to have any hope of success given the limited ability of the now vastly reduced core EA team in directly influencing all of the architectural and general business decision making events happening every second and minute of the day at all levels of what is now a significantly complex Organisation with many moving parts and increasingly complex decision making points at all levels of the structure. Board Secretariat

Non Exec Director

Executive Director

Executive Director

Head Office Admin

COO

CIO

Secretary

Chairman

Executive Director CEO

Executive Mgmt Team

Non Exec Director CTO

Board CFO

Global VP Finance Principal Architect

Global VP HR Principal Architect

Global VP Sales & Mkt Principal Architect

Global VP ICT Principal Architect

Global VP Retail Principal Architect

Global VP Commercial Principal Architect

Global VP Insurance Principal Architect

Country Manager(s)

Country Manager(s)

Country Manager(s)

Country Manager(s)

Country Manager(s)

Country Manager(s)

Country Manager(s)

Regional Operation(s)

Regional Operation(s)

Regional Operation(s)

Regional Operation(s)

Regional Operation(s)

Regional Operation(s)

Regional Operation(s)

Enterprise Architect(s)

Domain Experts

Meta Models

EA Reference Review/QA Policies & Models Global EA Governance Fwk Repository Processes Standards

Technical Application Information Infrastruct. Architects Architects Architects Architects Global EA Delivery Team

Integration Architects

Program and Portfolio Management Approach

Network Architects

Process Architects

B: Global ERP Implementation

C: Global Portal & A: Data Warehouse & Data Consolidation Intranet Rollout Project Program of Business Solution Work Team PMO SMEs Testers Developers Manager Work A ofAnalyst(s) Architects Project Program Business Solution Work Team PMO SMEs Testers Developers Manager Work A ofAnalyst(s) Architects Project Program Business Solution Work Team PMO SMEs Testers Developers Manager Work A Analyst(s) Architects

Fig. 3. Architecture as a Service

Architecting the Firm – Coherency and Consistency in Managing the Enterprise

167

5 Next Generation EA – Architecture as a Pervasive Management Decision Support Tool The proposed approach envisages the fully evolved next generation EA practice operating above and beyond the scope covered by the discussed case studies. In this idealised state, the next-gen EA is all pervasive and fully coherent at all levels of the Organisation, a natural and unconscious extension of normal management practice. Political and cultural divides between technology and business disappear as the management value of EA is realised by all stakeholders and championed by senior managers in making strategic business decisions. A fully pervasive and conformed EA practice and supporting framework across all levels of the Organisation allow for superior and consistent decision-making ability in a fully informed information environment. The underlying framework allows for a fast and truly evolved combination of business and technology metrics and inputs across the organisation. Under this model, the Architecture team is aligned directly with the executive management team and truly accountably for the accuracy, consistency, timeliness and quality of all management and corporate reporting and analysis being conducted. As Fig.4 illustrates, the EA team is now involved in producing key issues- and strategic briefing papers for Board meetings and quarterly AGMs. All executive, Board Secretariat

Non Exec Director

Executive Director

Executive Director

Secretary

Chairman

Executive Director

Non Exec Board Director

Corporate Dashboard and Board Reporting Global EA Team

Head Office Admin

COO

Global VP Finance Principal Architect

Global VP HR Principal Architect

Global VP Sales & Mkt Principal Architect

Global VP ICT Principal Architect

Global VP Retail Principal Architect

Global VP Commercial Principal Architect

Global VP Insurance Principal Architect

Country Principal Manager(s) Architect

Country Principal Manager(s) Architect

Country Principal Manager(s) Architect

Country Principal Manager(s) Architect

Country Principal Manager(s) Architect

Country Principal Manager(s) Architect

Country Principal Manager(s) Architect

Regional Operation(s)

Regional Operation(s)

Regional Operation(s)

Regional Operation(s)

Regional Operation(s)

Regional Operation(s)

Regional Operation(s)

CIO

CEO

Executive Mgmt Team

CTO

CFO

EA Repository Reporting Layer (metamodels, domain models & model views addressing stakeholder concerns) Enterprise Architect(s)

Domain Experts

Meta Models

EA Reference Review/QA Policies & Models Global EA Governance Fwk Repository Processes Standards

Technical Application Information Infrastruct. Global EA Delivery Team Architects Architects Architects Architects

Integration Architects

Network Architects

Process Architects

Program and Portfolio Management Approach Operational Reporting Layer (daily/weekly/monthly analyses, cubes, marts…) Project Program of Business Solution Work Team PMO SMEs Testers Developers Manager Work A ofAnalyst(s) Architects Project Program Business Solution Work Team PMO SMEs Testers Developers Manager Work A ofAnalyst(s) Architects Project Program Business Solution Work Team PMO SMEs Testers Developers Manager Work A Analyst(s) Architects

Fig. 4. A pervasive EA practice supporting coherency in management

168

P. Turner, J. Gøtze, and P. Bernus

corporate and management reporting uses an organisation-wide management reporting tool with corporate Dashboards and views available for executive managers and Board members. These reports are now also for the first time fully consistent and aligned with all subordinate reporting layers so that a coherent and pervasive view of the Organisation emerges for all levels of operations and at all times. The EA team is now fully tasked with the responsibility and accountability of ensuring that all of the technical impacts and technological risks associated with any new corporate initiatives (mergers, takeovers, acquisitions, major system upgrades or business transformation projects) are fully understood and have been factored in as part of the full decision making process for the Board. This responsibility then flows down to ensuring that sophisticated analytics and impact assessments (including scenario analysis and portfolio and program management options) are also available in a consistent manner for executive, senior and operational management teams. In this role, the EA team (as opposed to operational architects such as solution- or process architects embedded in line Departments and project teams) are still responsible for the EA framework and meta models within the Organisation, but now have the additional responsibility (similar now to that of the Finance function) of ensuring that senior business decision-makers are fully informed prior to any strategic business decision is made. This vision for EA however relies on all of the technological advances that are part of the next generation vision. Fully enabled and seamless interoperability across internal business units and external partners, fully maximised and intelligent pro-active optimisation of existing assets (internally and externally), use of virtual resources such as cloud- and grid computing and the creation of virtual enterprises able to react and respond rapidly and quickly to new business opportunities and threats. The legitimacy of this new vision for EA is dependent upon some significant progress that must occur for EA practice and tools to realize this ambition. Elements needed to implement a fully coherent and understandable framework include: 1. A unifying theory of EA that is acceptable (and accepted) as a common ground by both the business / management and engineering communities. Part of the is technical (need improved tool-sets, metamodels, reference models, demonstrations, prototypes, etc); and part of it is community building to bring together influential thinkers of management and engineering representing both points of view, and to develop trust and acceptance of any technical results; 2. Reliable and effective enterprise layers that seamlessly allow transactional and other information flows through the various domains and sub-domains as well as layers of management. Given today’s decision support tools and investment in their deployment, work on the interoperability of such tools is imperative or the above ideas may not be realistic or feasible; 3. Extension of enterprise modelling tools enabling decision optimisation using relevant views for senior management and allowing business prototyping, what-ifand predictive analyses (future state modelling for risk, profitability, cost, resource, productivity and other non financial metrics (e.g. legal)); While the above list addresses several key technical issues and some aspects of discipline development, coherency in management has a number of other conditions as well. The summary of these conditions is provided in Fig.5. [5].

Architecting the Firm – Coherency and Consistency in Managing the Enterprise

COHERENT

NT

IS NAL TIO TITU INS ED

6 Are artefacts, standards semantic models and frameworks followed in all parts of the organisation? 7 Do all parts of the organisation operate in a coordinated manner?

OR GA NI SE D

ISTE

S DE

D NE IG

1 Are all artefacts, standards, semantic models and frameworks formally categorised? 2 Are the users aware of their existence and have access to them?

CON S

8 Are all the organisational artefacts formally planned developed and managed?

CONNECTED

169

3 Do all parts of the organisation follow the same standards, semantic models and frameworks to develop enterprise artefacts?

4 Are all the parts of the organisation linked to one another? 5 Are we able to understand the impact of making change in one part on the remaining part?

Fig. 5. The meaning of coherency in management [5] (used with permission)

There are a number of important consequences to this condition [5]. Firstly, agreed, consistent and institutionalised EA methods create alignment between various lines of business which facilitates communication and agreement. Secondly, coherent and pervasive decision making practices allow the enterprise to identify, and to react to, market opportunities, i.e. act in an agile way, because EA practice ensures the swift translation of strategic decisions to tactical and operational levels. Thirdly, the ability of decision makers to access the right information in the right time is an assurance that decision making will be based on the best available information. The presented case studies reinforce the findings of others [5] that there exist various maturity levels in EA practice, i.e., even if all the technical conditions were satisfied, for any enterprise the adoption of a pervasive fully mature EA practice needs to go through stages. Doucet et al [5] introduce the concept of modes of EA to describe the maturing EA practice. The first mode is called Foundational Architecture corresponds to our Case Study #1 and #2, in which EA is very IT-centric and its tools and methods are used for the optimisation and governance of the enterprise’s IT systems, with different degrees of visibility and participation from business. The next mode is Extended Architecture which corresponds to our Case Study #3, where EA is used for the planning of business objectives, processes, etc – not only the IT systems themselves, and with the full participation in an explicit EA process by various business stakeholders. However, on this level the EA process is not pervasive, it is not embedded in the normal processes and as such parts of the enterprise may remain isolated from this practice (such as, for example, senior management). Embedded Architecture) is the third mode, where EA practices are pervasive and cover all levels of management, as illustrated in Fig.4. [5] also defines a fourth mode (fifth maturity level) called Balanced Architecture, where the business is actively using EA tools and methods for the creation or validation of business strategies, e.g. to respond to market opportunities in an agile way, to optimise business plans, to analyse and mitigate risks – in other words this is the level where applied EA theory and management theory become indistinguishable. As the Synopsis of the Handbook on Enterprise Architecture [1] predicts “what earlier seemed to be separate disciplines, such as

170

P. Turner, J. Gøtze, and P. Bernus

enterprise engineering, systems and software engineering, project management, and industrial and manufacturing engineering, suddenly become unified into one under one powerful theory of enterprise entities. However, this unification is not overtaking or destroying the individual efforts, it rather allows the significant details of these discipline to fit together”. After more than thirty years of work on the topic, the vision of the right information for the right people at the right time and in the right format has still not been realised, and it appears that the reason is partly the lack of an underlying commonly accepted theory, and partly the lack of mature enough tools. The coherency of information flow has always been the original aim of the discipline of Enterprise Integration (EI), “The goal of enterprise integration is to provide timely and accurate exchange of consistent information between business functions to support strategic and tactical business goals in a manner that appears to be seamless” [10], and since the 1980s [12] integration of the information flow has been a major strategic objective – whether integration by design or dynamic integration (interoperation).

6 Future Issues Future issues that remain un-resolved and open for further investigation in this exciting emerging field include the following: 1. For pervasive and coherent EA practices to achieve more penetration, much more research and development is needed to define feasible pathways for the uptake of EA frameworks and practices and tools, which still have not reached optimum influence and usage within organisations. Current developments in the disciplinary EA-bodies, such as the Open Group, must be supported by academic practice. 2. Traditional management roles, responsibilities and authorities (as well as assumed skills and competencies) may have to change in order for pervasive and coherent EA practice to take a foothold in the armoury of higher management. Demonstration is needed on significant case studies of the benefits of such practice, as successful examples are the best motivators for the adoption of new practices (examples of EA being used in business design include [11, 8, 3] demonstrating virtual enterprise creation, trust, virtual breeding environments, brokering, and other fundamental management problems, although decision support tools are still evolving [14,15]). 3. EA frameworks and practices have to evolve in order to deliver benefits needed for these two audiences. The frameworks need to contain metamodels to define a common terminology to be used by stakeholders, and must also be expressed as ontological theories, so as EA tools can be used to make inferences from architecture descriptions and models for the benefit of such stakeholders. While the requirements have been known for over a decade [2], and are part of the international standard that defines requirements to be satisfied by EA frameworks [6], the metamodels behind today’s enterprise modeling tools are often limited to the concepts necessary to deliver the IT function, and not adequate for the full architecture of the firm.

Architecting the Firm – Coherency and Consistency in Managing the Enterprise

171

7 Conclusions This paper attempted to outline various deficiencies in the traditional role of Enterprise Architecture and Architects themselves. It has been argued that a subordinated role of Architecture has led to a failure to provide effective decision support to senior business decision makers. A future model has been proposed in which next generation EA would be positioned to include senior business management providing effective and full information to the right people at the right time. It is suggested that this re-positioning of Architecture within the modern Organization can have a significant contribution to the timeliness, effectiveness and accuracy of the decisions made by these senior business decision makers.

References 1. Bernus, P., Nemes, L., Schmidt, G.: Handbook on Enterprise Architecture. Springer, Heidelberg (2003) 2. Bernus, P., Nemes, L.: A Framework to Define a Generic Enterprise Reference Architecture and Methodology. Computer Integrated Manufacturing Systems 9(3), 179– 191 (1996) 3. Camarinha-Matos, L.M., Afsarmanesh, H., Ollus, M. (eds.): Methods and Tools for Collaborative Networked Organisations. Springer, Berlin (2008) 4. Information Technology Management Reform Act (40 U.S.C. 1401(3)) (1996) 5. Doucet, G., Gøtze, J., Saha, P., Bernard, S. (eds.): Coherency Management: Architecting the Enterprise for Alignment, Agility, and Assurance. International Enterprise Architecture Institute, Falls Church (2009) 6. ISO 15704:2000 Industrial automation systems – Requirements for enterprise-reference architectures and methodologies. ISO, Geneva (2000) 7. ISO/IEC 42010:2007. Systems and Software Engineering – Recommended practice for architectural description of software-intensive systems. ISO, Geneva (2007) 8. Karvoinen, I., et al. (eds.): Global Engineering and Manufacturing in Enterprise Networks (Globemen). VTT Symposium Series, vol. 224. VTT, Helsinki (2002) 9. Ross, J.W., Weill, P., Robertson, D.: Enterprise Architecture as Strategy: Creating a Foundation for Business Execution. Harvard Business School Press, Cambridge (2006) 10. Smith, D., O’Brien, L., Kontogiannis, K., Barbacci, M.: Enterprise Integration. The Architect 5(4), 1–14 (2002) 11. Uwakato, U.: The Intelligent Manufacturing Systems Program. In: Wessner, C.W. (ed.) International friction and cooperation in high-technology development and trade, pp. 205– 215. NAP, Washington (1997) 12. Vernadat, F.: Enterprise Modeling and Integration: Principles and Applications. Springer, Berlin (1996) 13. IFIP-IFAC Task Force GERAM: Generalised Enterprise Reference Architecture and Methodology Version 1.6.3. (1999), http://www.cit.gu.edu.au/~bernus/taskforce/geram/versions/ geram1-6-3/v1.6.3.html (accessed July 1, 2009) 14. Peñaranda, N., Galeano, N., Romero, D., Mejía, R., Molina, A.: Collaborative Engineering Environments for Virtual Organizations. Int. J. Technology Mgmt. 8(3), 298–320 (2009) 15. Noran, O.: A Decision Support Framework for Collaborative Networks. Int. J. of Production Research 47(17), 4813–4832 (2009)

Aspects of the BPRIM Language for Risk Driven Process Engineering Amadou Sienou1, Elyes Lamine1, Hervé Pingaud1, and Achim Karduck2 1

Université de Toulouse, Mines Albi, Centre de Génie Industriel Campus Jarlard Route de Teillet, 81 013 Albi Cedex 09, France {sienou,lamine,pingaud}@mines-albi.fr 2 Hochschule Furtwangen, Faculty of Computer Science Robert-Gerwig-Platz 1, 78120 Furtwangen, Germany [email protected]

Abstract. Nowadays organizations are exposed to frequent changes in business environment requiring continuous alignment of business processes on business strategies. This agility requires methods promoted in enterprise engineering approaches. Risk consideration in enterprise engineering is getting important since the business environment is becoming more and more competitive and unpredictable. Business processes are subject to the same quality requirements as material and human resources. Thus, process management is supposed to tackle value creation challenges but also the ones related to value preservation. Our research considers risk driven business process design as an integral part of enterprise engineering. A graphical modelling language for risk driven business process engineering was introduced in former research. This paper extends the language and handles questions related to modelling risk in organisational context. Keywords: risk modelling, business process modelling, meta model, methodological framework, enterprise integration.

1 Introduction Enterprise engineering is concerned with the design of projects, which aim to improve the structure and behaviour of organisations. It develops approaches based on modelling techniques, particularly on business process modelling in order to assure the quality and the global consistency of the project portfolio. Risk consideration in enterprise engineering is getting important since the business environment is becoming more and more competitive and unpredictable. In fact, business processes, the main objects of enterprise engineering, are fields for various business interactions. Thus, processes are source or target of incidents, which may even imply business interruptions. As a consequence, processes are subject to the same quality requirements as material and human resources. Process management is supposed to tackle value creation challenges but also the ones related to value preservation. Improving the interactions between the process management cycle and the risk management cycle is a possible approach to handle these requirements. R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 172–183, 2009. © Springer-Verlag Berlin Heidelberg 2009

Aspects of the BPRIM Language for Risk Driven Process Engineering

173

In [1] a methodological framework known as the BPRIM (“Business Process-Risk Management – Integrated Method”.) methodology has been introduced. It consists of the BPRIM framework, the BPRIM process, the BPRIM conceptual models and the BPRIM modelling language. The BPRIM process focuses on risk driven business process design as an integral part of enterprise engineering. The BPRIM language for risk driven process engineering supports the graphical modelling of business processes and risk. This paper introduces the risk context diagram and the risk diagram, which are part of the BPRIM language initially introduced in [1, 2]. First, our vision of risk driven process engineering is explained before introducing the BPRIM process, which shall legitimate the kind of diagrams one must deal with. Then, the selected two kinds of diagrams shall be introduced.

2 Risk and Its Relation to Business Process 2.1 Understanding Risk There are many definitions of risk [3, 4]: “combination of the probability of an event and its consequence” [5]; “variance of return”[6]; “the possibility that an event will occur and adversely affect the achievement of objectives”[7]. Beyond the multitude of definitions, risk need to be conceptualized (fig. 1) in order to be understood: risk shall is defined with regard to two perspectives, the causal aspect and the consequence. The causal aspect consists of risk factors that are favourable for the occurrence of a given risk event. This risk event is considered being the root cause of a risk situation, which describes a possible state of the system of analysis. The state is evaluated in terms of impact (positive or negative). The causality and the impact are interpreted by a set of actors while considering their interests: this information is setup in the context of risk.

Fig. 1. A generic model of risk [1]

Any risk may have variable time and logical inter-relationships and relationships to other objects. Understanding these characteristics in order to manage risk to be acceptable is the intention of risk management. This is achieved by making decisions with regard to establishing control mechanisms affecting the cause or the consequence.

174

A. Sienou et al.

2.2 Risk and Business Process: The Relation A business process is “a str5uctured, measured set of activities designed to produce a specific output for a particular customer or market" [8]. Hammer stated that “a business process is a collection of activities that takes one or more kinds of inputs and creates outputs that is of value for the customer” [9]. For F. Vernadat, “a business process is a sequence … of enterprise activities, execution of which is triggered by some event and will result in some observable or quantifiable end result” [10]. Considering most definitions, value creation seems to be a main characteristic of business processes. However, the concept of value seems to be ignored while conceptualizing business processes. In general, value designates the assessment of a value object by a given stakeholder [11-13]. This assessment is quantitatively or qualitatively evaluated in terms of level of value. The conceptualization of fig. 2 is defined based on this definition.

Fig. 2. The concept of value [1]: value describes the interest of a stakeholder for a given object. It may be evaluated in terms of level of value. Value refers to an object and is interpreted by stakeholders.

Since a business process is a place for value creation, many objects would have different values for different stakeholders. The performance is for instance important for the process owner, while compliance is relevant to quality manager and work security to the performing actor. Further, it is possible to categorise value objet while considering the input, control, resource and output dimensions of business processes. As shown in (fig. 1), the consequence part of risk is evaluated in terms of impact. Since, risks are able to cause value modification; it is easy to link business process to risk by defining the impact of risk as a perception of the variation of the level of value: considering business processes, a risk is able to modify the level associated to a value interpreted by a set of stakeholders. A risk may cause for example performance, quality or compliance variations. Risk driven process engineering is expected to provide means for mastering these variations.

3 Risk Driven Process Engineering The BPRIM process is a lifecycle model integrating the process of risk management and business process management [1]. The model consists in synchronizing steps of

Aspects of the BPRIM Language for Risk Driven Process Engineering

175

process management with those of risk management while considering the conceptual and operational levels. The former is the risk driven process engineering, which consists of risk driven process design and risk driven process configuration. In this paper the emphasis is on the design step (fig. 3): −

−

−

Contextualise: The process models are defined. The information, organization, resource and functional aspects of the process models will provide information for managing risk by establishing the context of risk. This is performed by enriching process models with statements about object of value, stakeholder and the relations in terms of interest including the stakeholders’ risk appetite. Analyse: First, risks are identified. Then processes are analysed with regard to their properties such as capability and stability. Qualitative and quantitative evaluation of risks is subsequently launched. The process models shall be enriched with risks models. Treat: Based upon information from the previous phase, selected risks are treated by defining control mechanisms. The mitigation may imply process changes.

CONTEXTUALISE Discover

Establish context

Design

Context Diagr. Value added Diagr.

ECP, Organigram

ANALYSE

Analyse process

Identify

Risk taxonomy Diagr.

Analyse

EPC with risk

Risk Diagr.

Evaluate

Risk analysis Diagr.

Risk relations Diagr.

Risk map

TREAT Identify controls

Evaluate controls

Risk Diagr.

Understand the effect of control mechanisms

Implement controls

Risk map

Adjust the contex (implements controls)

Fig. 3. Extract of the BPRIM process: the lifecycle for risk driven process design consists of three phases each of which is a three stepped process. The risk management activities are dark. The outputs of activities are listed. The activity “discover” creates for instance a “value added diagram”.

176

A. Sienou et al.

4 The BPRIM Language The BPRIM language is designed to support the BPRIM process and shall enable process models enrichment with risk models. Some of the diagrams such as the EPC and the organigram are defined in the ARIS method [14]. Other diagrams, like the context diagram, risk diagram and risk analysis diagram need to be introduced. The BPRIM modelling language considers this issue while extending process modelling capabilities with risk modelling. At the conceptual level, the language extends ISO/DIS 19440 with concepts related to risk management. It is a generic language. We provide a visual notation, which illustrates how to support this language with regard to the extended Event-driven Process Chain (eEPC) [14]. 4.1 A Vocabulary for Risk Modelling The following tables illustrate the graphical notation for risk modelling. There are graphical symbols for concepts, relations and operators. Given the intention to couple processes and risks, an effort is made to re-used representation formalism of process modelling languages; mainly the eEPC notation. Here the syntax of operations is extended while new concepts and relations are introduced. This set of elements is sufficient for the representation risk in relation to business processes. However, information about the actual relations between enterprise concepts and risk will be missing. Table 1. Graphical notation for risk modelling Symbol

Description Risk factor: characteristics of the system affecting the cause or the consequence of risk. Risk situation: the state in which a risk event may lead the system. Value: a graphical representation of a value. Risk: the possibility of a situation affecting an asset. Control mechanism: activities planed or executed in order to face a risk:

Type

Category to classify risk, event or factors.

Category name

Concept that represents a risk indicator A concept that represents an event A concept that represents a stakeholder

Aspects of the BPRIM Language for Risk Driven Process Engineering

177

Table 2. Graphical notation of relations in the visual risk modelling language Notation

Description Influence relation of a factor on an event. Inter-event influence relation. Classification relation. Aggregation relation between risks. Aggregation is a parameterized relation, which can be customized by defining an aggregation criterion. Generalisation relation Causality relation between an event and a risk situation. Impact relation between risk situation and asset. General association relation between concepts. Relation between risk and process concepts (process, activity, and object): the direction indicates the target component. Interest relation between a stakeholder and an asset. Treatment relation between risk and risk treatment measure.

Table 3. Graphical notation of operators in the visual risk modeling language notation V

Description AND operator

V

OR Operator

XOR

XOR Operator

4.2 Diagrams for Risk and Process Modelling During the execution of the BPRIM process (fig. 3), elements of process vocabulary and risk vocabulary are combined in various stages in order to produce diagrams. The following simple business case shall illustrate the diagrams. At the enterprise level the domain “Make Desktop PC to Stock” produces “Desktop PC” and achieves a perfect order fulfilment. This objective is defined in terms of time and quality related goals. The achievement of the objective is qualified thanks to performance indicators such as the manufacturing reliability. The domain is under the authority of the manufacturing department. At the business process levels, the “Manufacture Desktop PC” process consists of activities such as “Assemble Computer Components”. The later is triggered once components are issued to assembly. The Risk Context Diagram A risk context model states to what extend a given value is relevant to a given stakeholder. The risk appetite of the stakeholder and the risk tolerance of the value object are defined in this model. A shown in fig. 5, at the conceptual level, a risk

178

A. Sienou et al. Enterprise level Manufacturing

Sales Forecast

Make Desktop PC to stock

Released Desktop PC

Business Process level

Buy Parts

Schedule Production

Issue Components

Make Desktop PC

Manufacture Desktop PC

Release desktop PC to deliver

Enterprise Activity level Components issued Ássembly schedule

Minimized defect size reliability: % of schedule missed

Construction Supervisor

Productivity: assembled/hour

Component Assembler

Hardware components

Assemble Computer Components

Computer Skeleton

Production Plan

Hardware requirements

Computer Assembly Manual

Manufacturing Tools XOR

Computer Components not assembled

Computer Components assembled

Computer Components partially assembled

...

Fig. 4. Sample enterprise models for building computer to stock

context is a mapping of concepts related to value toward the organisational model of the enterprise. We have selected the meta models developed in ISO/DIS 19440 for enterprise modelling. In fig. 5, concepts such as enterprise activity, business processes, and functional entity or enterprise objects are mapped to value objects; i.e. objects, which may be evaluated by a stakeholder as being of value. In addition, other concepts such as organisational unit or functional entity are mapped to stakeholder. We consider the example of building computer to stock and illustrate a risk context diagram in the fig. 6. Here, the objective “assemble schedule” is considered being of value for the assembly operator (operational role) and the assembly supervisor (organizational role). The assembly operator and supervisor are willing to accept a schedule variation of 2 hours/day. Fig. 7 is the meta model of the risk context diagram.

Aspects of the BPRIM Language for Risk Driven Process Engineering

«compConcept» Performanc eIndicator

EnterpriseActiv ity

Business Process 0. .1

«compConce... Obj ec tiv e

Capability

0. .1

0. .1

179

0. .1

0. .1

«isConsideredAs» «isConsideredAs»

0. .1 *

«isConsideredAs» 0. .1 0. .1

0. .1

«isConsideredAs»

ValueObj et

0. .1

«isConsideredAs»

0. .1

0. .1

1 relat ed to

* 0. .1

Enterpri seObj ect 1. .

Value

Value Lev el

1

«isConsideredAs» 1. .*

1

1

RiskTol erance

0. .1 RiskAppetite

Inte rest 0. .1 1. .* 0. .1

«isConsideredAs»

Stakeholder

0. .1

0. .1

0. .1

«isConsideredAs»

0. .1 «isConsideredAs»

FunctionalEntity

0. .1

0. .1

1

1. .*

assi gned to

OrganizationalUnit

PersonP rofile

*

1. .* 1

1 *

assi gned to

«isConsideredAs»

*

assi gned to

* operates responsible for

*

1. .* *

DecisionCentre 0. .1 *

assi gned to

Resource *

1

OrganizationalRole

OperationalRole

1

Fig. 5. Conceptual model of risk context (mapping of ISO/DIS 19440 to our conceptual model of value)

Fig. 6. Sample risk context diagram

180

A. Sienou et al.

Nota tion

Geometry

has 1

1. .*

source 1..* Flow Connector

Obj ect cible 1..*

eEPCObj ect

1. .*

1. .*

is con nected with 1. .*

ResourceFlow

Organigram

OrganisationalEntity 2 1 ContextDiagram

Contai nment OrganisationalUnit

1. .* 0. .1

Hierarchy

Person

OrganisationalRole

1. .* Value

Stakeholder 1 is con nected with 1. .*

1 is con nected with 1. .* Inte rest

Fig. 7. The meta model of the risk context diagram

The Risk Diagram Identified and analysed, a risk is described by considering its environment. As shown in fig. 8, concepts such as risk indicator, risk owner, control mechanisms and the relations to business processes, enterprise activities and enterprise objects are defined. EnterpriseActiv ity

Dom ain

*

RiskDomainAssociation «compConcept» Performanc eIndicator

* RiskClass ification

source/target

RiskActiv ityAssociation

source/target RiskCategory

generalises

is classified in *

0. .1

RiskGeneralisation *

*

*

Risk 1

consists of

RiskAggregation

*

indic ated by

RiskIndicator

*

Indic ation

0. .1 *

source/target

*

source

Enterpri seObj ect

Business Process

* *

* RiskProcess Association

RiskObj ectAssociation

*

0. .1

1. .* *

RiskPersoneProfilAssociation

hand led by

Contr ol *

*

2..*

Handling RiskO w ner

engages

PersonP rofile

* uses

*

responssible for

Handli ngRule *

Fig. 8. Conceptual model of risk in its environment

Aspects of the BPRIM Language for Risk Driven Process Engineering

181

Fig. 9. Sample risk diagram with risk category, indicator, owner, business process and controls

Fig. 9 illustrates a risk diagram. The later is classified as an operational risk, which affects the activity “assemble components”. The risk may be handled by considering 2 controls mechanisms associated with the AND operator. Since control inherits from business process (fig. 9), it may be defined using a language such as the EPC.

5 Related Work The COSO proposed a framework for Enterprise Risk Management (ERM) [7]. Approaches to Business Continuity Management [16] also address process level risks. In [17], the authors integrated risk models in process models while modelling risk as an error occurrence. Widely used in decision analysis influence diagrams and fishbone diagrams are related to our approach. In contrast to influence diagrams, which emphasizes scenario analysis, fishbone diagrams and other approaches to industrial events analysis (FMEA, FTA, ETA) supports systematic analysis of root causes of problems. We adopted a model based approach and consider risk as a complex and structured concept, immerged in an environment, which may allow a positive or negative interpretation depending on the objects of interest. In addition to causalities, we consider perspectives of different stakeholders and provide a possibility to associate to each risk the corresponding control mechanism.

5 Conclusion and Future Work Research communities investigated on quantitative approaches to risk management while qualitative ones seams to be neglected. However, quantitative approaches rely deeply on qualitative techniques. The former are based on analytical techniques

182

A. Sienou et al.

whereas the later are stakeholder driven. Both approaches are complementary. Our research is targeted to enhance this complementary by providing means to improve the quality and accessibility of quantitative risk management. The BPRIM framework for the integrated management of business process addresses these issues. This paper developed some aspects of the language while considering the risk context diagram and the risk diagram, which are extensions of pervious work. The risk context sets up the relations that are necessary for risk assessment. Actually, risk is perceived as being an eventual disequilibrium of the risk context. Identified and analysed, risks are extended with environmental information such as controls, indicators or categories. The risk diagram is designed to capture this knowledge. We are working on industrial experiences. It is plan to investigate on tools for guiding the usage of the framework and its models in order to improve the quality of information required for quantitative risk management.

References 1. Sienou, A.: Proposition d’un cadre méthodologique pour le management intégré des risques et des processus d’entreprise. Thèse de doctorat (PhD thesis). Université de Toulouse, Toulouse (2009) 2. Sienou, A., Lamine, E., Karduck, P.A., Pingaud, H.: Conceptual model of risk: towards a risk modeling language. In: Weske, M., Hacid, M.-S., Godart, C. (eds.) WISE Workshops 2007. LNCS, vol. 4832, pp. 118–129. Springer, Heidelberg (2007) 3. Bernard, J.-G., Aubert, A.B., Bourdeau, S., Clément, E., Debuissy, C., Dumoulin, M.-J., Laberge, M., de Marcellis, N., Peigner, I.: Le risque: un model conceptuel d’integration. CIRANO: Centre interuniversitaire de recherche en analyse des organisations, Montréal (2002) 4. ISO/IEC CD 2 Guide 73: Risk management — Vocabulary. ISO, Geneva, CH (2008) 5. ISO/IEC GUIDE 73:2002: ISO/IEC Guide 73:2002 - Risk management — Vocabulary — Guidelines for use in standards. ISO, Geneva, Switzerland (2002) 6. Markowitz, H.M.: Portfolio Selection. Journal of Finance 7, 77–91 (1952) 7. COSO: Enterprise Risk Management - Integrated Framework. Committee of Sponsoring Organizations of the Treadway Commission (2004) 8. Davenport, T.H.: Process Innovation. Reengineering Work through Information Technology. Harvard Business School Press, Boston (1993) 9. Hammer, M., Champy, J.: Reengineering the Corporation: A Manifesto for Business Revolution. Harper Business, New York (1993) 10. Vernadat, F.: Enterprise modeling and integration: principles and applications. Chapman & Hall, London (1996) 11. Lorino, P.: Comptes et récits de la performance. Essai sur le pilotage de l’entreprise Les Editions d’Organisation (1995) 12. Porter, M.: Competitive Advantage: Creating and Sustaining Superior Performance. The Free Press, New York (1985) 13. NF EN 12973: Management par la valeur. AFNOR (2000) 14. Scheer, A.-W.: ARIS – Business Process Modeling. Springer, Berlin (2000)

Aspects of the BPRIM Language for Risk Driven Process Engineering

183

15. Sienou, A., Lamine, E., Pingaud, H., Karduck, A.P.: Vers un langage de modelisation des risques et des processus. In: MOSIM 2008, vol. 2, pp. 1270–1279. TEC & DOC LAVOISIER, Paris, France (2008) 16. The Business Continuity Institute: Business Continuity Management - Good practice guidelines 2008. In: Smith, D.J. (ed.) The Business Continuity Institute (2008) 17. Zur Muehlen, M., Rosemann, M.: Integrating Risks in Business Process Models. In: Proceedings of the 2005 Australian Conference on Information Systems (ACIS 2005), Manly, Sydney, Australia (2005)

ProcessGene-Connect: SOA Integration between Business Process Models and Enactment Transactions of Enterprise Software Systems Avi Wasser1 and Maya Lincoln2 1

2

University of Haifa, Mount Carmel, Haifa 31905, Israel [email protected] ProcessGene Ltd. 10940 Wilshire Bvd., Los Angeles, CA 90024 [email protected]

Abstract. In recent years, both practitioners and applied researchers have become increasingly interested in methods for integrating business process models and enterprise software systems through the deployment of enabling middleware. Integrative BPM research has been mainly focusing on the conversion of workflow notations into enacted application procedures, and less effort has been invested in enhancing the connectivity between design level, non-workflow business process models and related enactment systems such as: ERP, SCM and CRM. This type of integration is useful at several stages of an IT system lifecycle, from design and implementation through change management, upgrades and rollout. The paper presents an integration method that utilizes SOA for connecting business process models with corresponding enterprise software systems. The method is then demonstrated through an Oracle E-Business Suite procurement process and its ERP transactions. Keywords: Business process integration and management, EA, BPM, SOA, ERP, Business Process Realization.

1

Introduction

In recent years, both applied researchers and practitioners have become increasingly interested in methods for business process integration with enactment systems. The main research domains addressing this topic have been Enterprise Architecture (EA) and Business Process Management (BPM), with the possible utilization of Service Oriented Architecture (SOA) [2]. Previous work was conducted on describing the correlation between these approaches [6] and on identifying how SOA can be combined within EA frameworks [10]. Within this set of disciplines, integrative BPM research has been mainly focused on the interpretation of workflow notations into enacted application procedures[5,14], optionally through SOA[4]. Less effort has been invested in enhancing the connectivity between design level, non-workflow business process models and related enactment systems such as: ERP, SCM and CRM, that are assumed to operate based on such design. This type of structured connectivity is important for R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 184–193, 2009. c Springer-Verlag Berlin Heidelberg 2009 

ProcessGene-Connect: SOA Integration

185

ensuring a valid fit between enterprise design requirements, and corresponding IT system elements [7]. A disconnect can result non valid IT solutions, that do not conform with organizational strategy and goals [15]. Hence, to ensure effective business process realization it is required to establish structured integration between the process design level and the actual fulfillment [11,16]. This paper aims to provide a framework for SOA integration between business process models and ERP enactment transactions. For example, when a procurement process owner wishes to re-design parts of the process “issue a purchase order”, he would design and document the process at a modeling environment, using a structural framework, and then transfer this design for deployment at the relevant ERP module and its pertaining ERP transactions. As there is no direct integration of the process model with the ERP production environment, the connectivity is manual and relatively loose. Moreover, changes in the business process model, or in the ERP system that happen after the initial implementation of the system, can cause inconsistencies between the business process model and the enactment layer due to this non-dynamic and unstructured connectivity pattern. The suggested integration method “ProcessGene Connector” offers a complementing approach, aiming to create direct, online, SOA-based connectivity between the business process modeling and the ERP enactment environments. The novelty of this work lies in the definition of a dynamic SOA connector that is responsible for the construction and ongoing maintenance of the connection between the design and the IT enactment layers of business processes. The connector constructs direct links between business activities and ERP transactions and invokes handling instructions regarding inconsistencies that may occur between the connected layers. This method can broaden the enactment scope of BPM and EA beyond the domain of realizing direct workflow notations, and enable clear integration to a variety of third party systems; in fact to every system that supports SOA. More particularly, the approach can assist both system designers and IT implementers in the process of business process realization. The paper features the following sections: a review of approaches for connecting business processes with enactment systems (section 2); the ProcessGene Connector model for integrating business process models and enterprise software systems (section 3); a method for synchronizing enterprise process design and realization layers, including an example for connecting a procurement business process model with the Oracle E-Business Suite (section 4); and finally conclusions and suggestions for further work (section 5).

2

Systems Integration: From General to Specific Approaches for Connecting Business Processes and Enactment Systems

Literature has discussed integration challenges and general methods both in the EA and BPM domains. In EA related contexts, researchers have argued that an enterprise can be recursively composed of its systems [9]. To support the

186

A. Wasser and M. Lincoln

realization of this approach, standards such as IEC [1] aim to define information exchange frameworks for facilitating the integration of business data and manufacturing control applications. Another targeted research in this field [13] has focused on the establishment of a formalized product based ontology, leaning on product technical data. Hence a “product” becomes a mobile, interoperable entity that can communicate with various type of applications. Researchers in the field of BPM have also invested efforts in the formalization of generalized business process ontologies and their related semantics [8], but the realization of process models integration with actual ERP systems has been led by vendors, that deploy proprietary ontologies and semantics per application. More specifically, ERP vendors have been providing organizations with business process integration and connectivity solutions that mainly use loose links between process descriptions and their applicative artifacts. These solutions, such as the Oracle Tutor1 or the SAP solution composer2 , assume a hierarchal process-artifact relationship, when one of the process descriptive artifacts is an indicative pointer to a synthetic ERP environment (e.g. to the Oracle EBS demo3 environment or to SAP IDES4 ), aiming to demonstrate, in a rather loose format, how the ERP system can be configured in accordance to relevant segments of business process models. In the Oracle business process flows, for example, the “Process Categories” for an industrial sector present names and descriptions of the top level functionalities for that industry and their corresponding “Major Processes. “Major Processes” are then broken into “Main Processes” that hold “Processes” altogether structuring a four-level model scale. For example, Oracle’s “Category”: “Procure to Pay” consists of several “Major Processes”, one of which is: “Requisition to Purchase Order”. This “Major Processes”, similarly to its other siblings, is further broken into “processes” (e.g. “Issue a Non-Production Purchase Order”). For each level-4 process, the Oracle suite offers a set of application configurations, that function as a foundation for the ERP implementation. The integration fulfillment involves manual management of the connectivity between several implementation components and environments that cover (separately) modeling tasks, requirements management, quality testing and actual application setup. This lack of automated, online connectivity constrains the capability to collaborate and reuse the data across ERP/SCM/CRM implementation environments, hence leading to a potential disconnect between the business requirements and supporting IT systems. Further concerns are retention of implementation data, required rework in implementation rollouts (that may require different ERP server deployment), and difficulty in managing changes to requirements and configurations [12]. Harnessing the power of SOA, the ProcessGene Connector method aims to provide a solution to these challenges.

1 2 3 4

http://www.oracle.com/applications/tutor/index.html http://www.sap.com/solutions/businessmaps/composer/index.epx http://www.oracle.com/applications/e-business-suite.html http://help.sap.com/SAPHelp_46c/helpdata/EN/af/ fc4f35dfe82578e10000009b38f839/frameset.htm

ProcessGene-Connect: SOA Integration

3

187

The Integration Model

According to BPMN [17], a business process model (BPM) is a “collection of interconnected business processes”. Each business process can be represented as a flow of activities that “produce a specific service or product (serve a particular goal) for a particular customer or customers”. Each such activity has an input data received from predecessor activities or from external sources; functionality - the procedure conducted for implementing the activity’s goal; and an output - the functionality’s processing outcome(s). For example, Oracle’s procurement process represents the activity flow that fulfills the purchasing goals of an enterprise. Fig. 1 presents a partial segment of this process using YAWL[14] modeling layout, with three slight modifications: (a) the outputs of each activity are presented at the bottom of its shape; (b) predicate evaluation values are presented on the activity connector shape; and (c) activity identifying numbers are presented on top of each activity shape. Note that the inputs for each activity are the outputs of all its predecessor activities. Based on the above definition, business process models serve as the process design layer of the enterprise know-how. This design layer is implemented either through manual activities or by using IT enactment systems. We refer to the implementation and enactment of a business process model as the process realization layer. From the user’s viewpoint, this layer is composed of IT system transactions, which, in the case of ERP systems, are also referred to as “ERP transactions”. To connect between the design layer and the realization layer of a business process model, each activity in the business process model is related to an ERP transaction, as illustrated in Fig. 2. For example, the activity “New supplier entry” from Fig. 1 is related to the oracle transaction: “Sourcing rules”, which is responsible for implementing this activity’s functionality within the Oracle ERP Suite. Note that some activities may be manual and therefore will not be related to any 1

Nonproduction or production purchase order (PO)? PO type

Non-production 2 PO Issue non-PO Non-production PO 3

Issue PO production PO

Production PO

4

Select potential suppliers Suppliers list

5

Approach suppliers Suppliers’ confirmation

6 New supplier entry New supplier documents

Fig. 1. A segment of Oracle’s procurement process

Business Process Model 1

1

Input

n

n

Activity 1 1 1 1

Functionality

ERP Transaction

1 n

Output

Fig. 2. Business Process and ERP transaction integration model

188

A. Wasser and M. Lincoln

ERP transaction. Since this paper focuses on connectivity to enterprise software systems, such cases are not within our scope and therefore disregarded.

4

The ProcessGene Connector Method: Synchronizing Enterprise Process Design and Realization Layers

The business process design layer and the business process realization layer of an enterprise are expected to be synchronized, since the latter represents the implementation of the former, hence both represent the same business logic expressed by different means. Therefore, after the first definition of a business process model and its implementation within the enterprise IT systems, the connectivity between the two layers is to be maintained, aiming to assure that any changes made in the design layer (e.g. as a result of process improvement efforts) are fully reflected in the IT enactment system (e.g. in the ERP system). Based on this working assumption, the “ProcessGene Connector” method presented hereby, is aimed at managing and reassuring this connectivity through three main phases: (1) initial business process modeling and IT implementation; (2) change request definition; and (3) implementation of the change in the IT systems, as illustrated in Fig. 3.At the first stage, the initial business process model is defined by the enterprise process architects. This group of architects can include process owners, key users and business analysts. After processes are delineated and approved by this process modeling team, each non-manual activity is related to an ERP transaction that supports its realization, as further detailed in Section 4.1. Since this stage requires knowledge of the underlying ERP system, it is supported also by the IT implementers, which are responsible for tailoring the ERP system according to the business definitions. This tailoring effort can involve either the customization and adjustment of an off-the-shelf ERP system, or writing code procedures to fulfill the required process design, or a combination of both alternatives, as commonly practiced. After the business process model is adequately defined and each non-manual activity is related to its realizing ERP transaction, the IT implementers configure the ERP system so that it reflects the enterprise business process design. At this point of the process realization lifecycle, the enterprise starts using its tailored ERP system. Further along the ERP system lifecycle, at any future point of time, the enterprise may encounter a need for changing its business processes. Such changes can be required, for example, as a result of business process re-design, an expansion of new business activities within the enterprise conduct or as part of an effort to comply with certain industry regulations. To define the required changes, the process architects make adjustments to the business process model. Such modifications can involve: (a) adding new activities; (b) deleting existing activities; (c) changing the order of existing activities; or (d) modifying existing activities. Since the business process model can include many interconnected processes, and since any activity can take part and be reused in several business scenarios, any such change of the business process model can involve a set of change considerations and change implications. A manual analysis of such change

ProcessGene-Connect: SOA Integration

Initial Process Modeling and Implementation s t ss c Business ec eti process roP hrc modeling Relating A ERP transactions et ne TI m IT el sr p implementation Im ss yti m ceo ivtc isn rP e ah eh nno ce TCM

Process Change Request

189

IT Change Implementation

Changing the BPM Change implementation & tests Generating change requirements

Generating test scenarios

Fig. 3. The business process model realization lifecycle

implications may require going over the entire model, searching for change implications. Instead, the proposed connectivity method, generates automatically textual change requirements that are presented to the IT implementers, as detailed in Section 4.2. Furthermore, in order to test the implemented changes in all possible use-cases, prior to the delivery and usage of the changed IT system in production environments, the ProcessGene Connector method enables the generation of textual test scenarios, as detailed in section 4.3. At the IT change implementation phase, the IT implementers implement the required process changes according to the generated change requirements and test their effect using generated test scenarios, prior to importing changes into the ERP production environments. The test scenarios can also be used to present the process architects with changes to all related business scenarios - so they can visualize and approve them before and during the the development phase (performing Conference Room Pilots (CRPs), in Oracle terms). At any future time, the enterprise may require additional process changes and the same change request and implementation procedure are re-conducted. 4.1

Connecting between BPM Activities and ERP Transactions

In order to formulate and demonstrate the proposed connectivity framework between BPM activities and ERP transactions, we present a sequence diagram that organizes a SOA flow between business process models and ERP systems. Then we elaborate on the SOA connectivity method. We use the Oracle EBusiness Suite as an example for this demonstration, but the principle is generic and may be applied to other systems such as Lawson Intentia, SAP, Microsoft Dynamics, etc. The Oracle connectivity Web-service, presented as a sequence diagram in Fig. 4, shows how a business activity is connected to a transaction within the Oracle applications suite. This connection can be easily defined by the BPM users (e.g. process architects). At the first stage of this connectivity flow,

190

A. Wasser and M. Lincoln

User Selects an activity

ProcessGene Request for Connector related Builds an Oracle Oracle parameters screen selection User Interface (UI)

Selects one of the Oracle application menus/ setup screens from the presented list of options

Oracle screen options

Presents Oracle screen multipleselection UI

Selected screens

•

Enters a process, and presses on one of its activity’s Oracle screen link

Pressed link

Request for Menu data (based on a spesific user name) Menu data

Oracle Apps Finds All user Profiles • Gets all profiles’ related menus •

Saves user selection • Presents a link to the Oracle apps. for the selected screen • •

Collects link’s data Builds the URL for Oracle apps. ( single sign-on)

The built URL

Executes the link request (based on Oracle user-name and screen’s full path)

Fig. 4. SOA-based sequence diagram between BPM Activities and Oracle ERP Screens

the user selects an activity within the BPM. As a result, and based on the user’s profile as defined in the Oracle applications suit, the ProcessGene Connector retrieves a list of related Oracle menus that are presented to the user as an option tree. After the user selects the appropriate menu, the Connector produces a link that connects between the specified activity and the ERP transaction. At any later time, a user can click on any activity within the business process model and “jump” to the Oracle supporting transaction’s screen, using his own Oracle user profile and the previously selected screen data. Note that any user can only “jump” to ERP screens using his own profile, and therefore different users may see the same screen in a slightly modified configuration. This behavior cannot be avoid, since users navigate in the ERP system based on their permission level and therefore their available screen must match their user credentials, from security reasons. The connectivity between the process modeling environment and the Oracle ERP system is performed based on SOA. The connectivity solution extends one of the classes from PHP’s Document Object Model (DOM) library[?], creating a subclass that interacts with the Oracle E-Business Suite environment. The solution allows operating an XML document with the DOM API. It also uses other domxml functions to turn a complete XML document into a tree of PHP objects- featuring relevant Oracle forms/framework components. Example: Connecting a Business Process with the Oracle E-Business Suite System. To illustrate the proposed connectivity framework, we continue

ProcessGene-Connect: SOA Integration

191

the example presented in Section 3, in which the user wants to connect the activity “New supplier entry” with the related Oracle transaction in a production environment. Using the ProcessGene Connector Web-service, the user retrieves in real time data that includes specific user roles (e.g. “Application Developer”) within the Oracle applications and related menus (e.g. “Access Suppliers” and “Bills in Distribution”), from a live production environment. He then selects the compatible Oracle screen, which in our example is named: “Sourcing Rules” and saves his selection. At the next step, the user can use the generated link for accessing directly to the relevant area in the Oracle application. Access focus is a function of the process hierarchal level, e.g. if the indication is at a low modeling level (5 and below), user will be directed to an actual transaction or customization parameters. After “jumping” to the real Oracle application, the user can always retrieve all process model elements that are related to this transaction using a reverse Web-service, and “jump” back to the compatible process or activity in the business process modeling environment. 4.2

Generating Change Requirements

Whenever any change is applied to the business process model, it is required also to adjust the ERP system accordingly. To bridge the gap between the two edges (process model and IT enactment system) which are handled by different parties using different languages and tools, the ProcessGene Connector is invoked as a result of changes made in the BPM and generates textual change requirements for the IT developers. Each requirement is generated for each changed activity, based on the following four change types within the process model: (1) Adding new activities, (2) Deleting existing activities, (3) Changing the order of existing activities and (4) Modifying existing activities. For example, by re-examining the procurement process (Fig. 1), the process designer may want to add the activity “Approve PO” before proceeding the process and selecting suppliers (before activity #4). As a result of this process change, a new development requirement is generated, and since both activities #2 and #3 are connected to the new activity as predecessors, two use-cases are specified. In addition, activity 4’s input is changed. The generated requirement is illustrated in Fig. 5.

Requirement for changes in Oracle Applications Requirement type - new activity Required development - implement a new functionality for: “Approve PO” Functionality use-cases i

Use case # Input Output 1 Non-production PO Approved PO 2 Production PO Approved PO Affected activities - the input of the following activities was changed to match the output of “Approve PO” Activity ID Activity Name 4 Non-production PO

Fig. 5. An example for an automatically generated requirement for new activity

192

4.3

A. Wasser and M. Lincoln

Generating Test Scenarios

For each BPM change, the ProcessGene Connector produces test scenarios, which are BPM path segments that represent all paths that involve the changed activity. In addition, each path segment also includes two predecessor activities and two successor activities (adjacent activities from level 1 and 2, correspondingly) for the changed activity, hence containing five activities altogether. Adjacent activities from level 1 are included in the test scenario path, since they can be modified as well as a result of implementing the activity change (see Section 4.2). Adjacent activities from level 2 are also represented in the test scenario path, in order to involve non-changed activities, so the scenario can start and end with activities to which and from which the activity flow was already tested in the past. Continuing the above example (Section 4.2), in case the activity “Approve PO” is added to the BPM before activity #4 (see Fig. 1), the following test scenarios are produced (each activity is represented by its serial number; the id of the new activity is marked as “4” ’): (a) 1->2>4’->4>5; (b) 1->3>4’->4>5.

5

Summary and Conclusions

The ProcessGene Connector enables direct connectivity of business process models with enterprise software enactment systems. The method and supporting architecture allow users to pursue this connectivity without extensive knowledge of the underlying software structure. This live connectivity also assists in synchronizing changes that may occur both in the process model and the enactment system. Although the ProcessGene Connector provides a starting point for SOA-based process integration, further elaboration is needed to overcome open issues such as adding low level capabilities to ERP system customization and configuration mechanisms, enabling single-login interfaces to the ERP applications and improving the accuracy of the detailed levels (4 and below) connectivity indications. It is hoped that by expanding connectivity capabilities, researchers and IT practitioners will be able to provide additional flexibility and visibility to the relatively complex procedure of ERP implementation, configuration and customization as well as to the ongoing management of such systems.

References 1. Iec 62264 enterprise-control system integration, iso/iec, geneva (2002) 2. Assmann, M., Engels, G.: Transition to Service-Oriented Enterprise Architecture. In: Proceedings of the 2nd European conference on Software Architecture, pp. 346–349. Springer, Heidelberg (2008) 3. Barney, L., McLaughlin, M.: Oracle Database AJAX & PHP Web Application Development: Build Scalable. In: Reliable Web 2.0 Applications for the Oracle Environment. McGraw-Hill Osborne Media, New York (2008) 4. Decker, G., Mendling, J.: Process instantiation. Data & Knowledge Engineering (2009)

ProcessGene-Connect: SOA Integration

193

5. Fettke, P., Loos, P., Zwicker, J.: Business process reference models: Survey and classification. In: Bussler, C.J., Haller, A. (eds.) BPM 2005. LNCS, vol. 3812, pp. 469–483. Springer, Heidelberg (2006) 6. Hartges, M., Krafzig, D., Kunz, M., Mosch, F., Slama, D., Stahl, T.: Enterprise Architecture: BPM, SOA, and MDSD. Cutter it Journal 20(11), 6 (2007) 7. Holland, C.R., Light, B.: A critical success factors model for ERP implementation. IEEE Software 16(3), 30–36 (1999) 8. Lincoln, M., Karni, R., Wasser, A.: A Framework for Ontological Standardization of Business Process Content. In: International Conference on Enterprise Information Systems, pp. 257–263 (2007) 9. Morel, G., Auzelle, J.P., Mayer, F., Panetto, H.: System of enterprise-Systems integration issues: an engineering perspective (Invited plenary paper). In: IFAC Cost Effective Automation in Networked Product Development and Manufacturing, pp. 2–5 (2007) 10. Noran, O., Bernus, P.: Service Oriented Architecture vs. Enterprise Architecture: Competition or Synergy? In: Proceedings of the OTM Confederated International Workshops and Posters on On the Move to Meaningful Internet Systems: 2008 Workshops: ADI, AWeSoMe, COMBEK, EI2N, IWSSA, MONET, OnToContent+ QSI, ORM, PerSys, RDDS, SEMELS, and SWWS, pp. 304–312 (2008) 11. Recker, J., Mendling, J., Van Der Aalst, W., Rosemann, M.: Model-driven enterprise systems configuration. In: Dubois, E., Pohl, K. (eds.) CAiSE 2006. LNCS, vol. 4001, pp. 369–383. Springer, Heidelberg (2006) 12. Rolland, C., Prakash, N.: Bridging the gap between organisational needs and ERP functionality. Requirements Engineering 5(3), 180–193 (2000) 13. Tursi, A., Panetto, H., Morel, G., Dassisti, M.: Ontological approach for ProductsCentric Information System Interoperability in Networked Manufacturing Enterprises (2009) 14. Van der Aalst, W.M.P., Ter Hofstede, A.H.M.: YAWL: yet another workflow language. Information Systems 30(4), 245–275 (2005) 15. Wasser, A., Lincoln, M., Karni, R.: Accelerated enterprise process modeling through a formalized functional typology. In: van der Aalst, W.M.P., Benatallah, B., Casati, F., Curbera, F. (eds.) BPM 2005. LNCS, vol. 3649, pp. 446–451. Springer, Heidelberg (2005) 16. Wasser, A., Lincoln, M., Karni, R.: ERP Reference Process Models: From Generic to Specific. In: Eder, J., Dustdar, S. (eds.) BPM Workshops 2006. LNCS, vol. 4103, pp. 45–54. Springer, Heidelberg (2006) 17. White, S.A., et al.: Business Process Modeling Notation (BPMN) Version 1.0. Business Process Management Initiative, BPMI. org. (2004)

Dynamic Business Networks: A Headache for Sustainable Systems Interoperability Carlos Agostinho and Ricardo Jardim-Goncalves UNINOVA-GRIS, Group for the Research in Interoperability of Systems - Instituto de Desenvolvimento de Novas Tecnologias, Caparica, Portugal {ca, rg}@uninova.pt

Abstract. Collaborative networked environments emerged with the spread of the internet, contributing to overcome past communication barriers, and identifying interoperability as an essential property. When achieved seamlessly, efficiency is increased in the entire product life cycle. Nowadays, most organizations try to attain interoperability by establishing peer-to-peer mappings with the different partners, or in optimized networks, by using international standard models as the core for information exchange. In current industrial practice, mappings are only defined once, and the morphisms that represent them, are hardcoded in the enterprise systems. This solution has been effective for static environments, where enterprise and product models are valid for decades. However, with an increasingly complex and dynamic global market, models change frequently to answer new customer requirements. This paper draws concepts from the complex systems science and proposes a framework for sustainable systems interoperability in dynamic networks, enabling different organizations to evolve at their own rate. Keywords: Interoperability, Model Morphisms, Complexity, Dynamic Networks, Sustainability.

1 Introduction In today’s networked economy, strategic business partnerships and outsourcing have become dominant business paradigms evidencing a tremendous increase in trade and investments between nations. This fact is evidenced by the globalization phenomena, which is entering a third era where the world becomes a tiny flat place and information can be exchanged and applied innovatively across continents, independently of races, cultures, languages or systems [1]. Also, mass-customization has become a major business hub replacing mass-productions, with trends changing their focus from technology and product-driven to market and customer-driven [2], [3], thus increasing trade and information exchange. This evolution has provided consumers a fundamental role on supply chains. Reliability and rapid delivery of defect-free products to customers is no longer seen as a competitive advantage, but as a requirement [4], [5]. Competitive markets are becoming increasingly complex and dynamic and the traditional way of doing business does not provide the expected efficiency [6]. Indeed, in most cases, a single R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 194–204, 2009. © Springer-Verlag Berlin Heidelberg 2009

Dynamic Business Networks: A Headache for Sustainable Systems Interoperability

195

company cannot satisfy all customers’ requirements. It needs to streamline its supply chain (SC), and collaborate actively with partners to create valued networks between buyers, vendors, and suppliers [7]. Once, individual organizations battled against each other, but today the war is waged between networks of interconnected organisations [8], e.g. SCs. Therefore, to succeed in this collaborative but at the same time competitive environment, enterprise systems and applications need to be interoperable, i.e. be able to share technical, and business information seamlessly within and across organisations, and must be adaptable to different network environments at all product life cycle (PLC) phases [6], [9]. A proven approach to deal with interoperability relies on the usage of dedicated knowledge models and international standards acting as information regulators among organizations, and covering many industrial areas and activities, from design to production and commercialization1 [10]. However, achieving that inside heterogeneous networks, such as SCs, is still an ongoing challenge hindered by the fact that they are, intrinsically, composed by many distributed hardware platforms, software tools and ICT. Even some standardisation groups are developing specific solutions to provide national capabilities, when the full potential benefits could only be achieved if interoperability was underpinned by a coherent set of open, and internationally accepted ICT standards [9], [11]. Nevertheless, considering that the above issues are overcome and research successfully applied in industry, an emergent problem for seamless interoperability is rising, i.e. its sustainability within collaborative industrial networks: Retail and manufacturing systems are constantly adapting to new market and customer requirements, thus answering the need to respond with faster and better quality production; New organizations are constantly entering and leaving collaboration networks, leading to a constant fluctuation and evolution of business networks and system models; In addition, even standards need to be adjusted from time to time. All these factors are making interoperability difficult to maintain. After providing an overview on the state of the art research and applied solutions for interoperability achievement within industrial networks, this paper addresses the non-linear problem of the network stability maintenance. Concepts from the complex systems science are analysed and applied on top of the most advanced state of the art interoperability practice to elaborate a heuristic framework where dynamism is tolerated, thus allowing automatic readjustments in the information flows without the need to reprogram the full systems.

2 Interoperability on Global Business Networks Global business networks are suffering from the delocalisation phenomena, with suppliers and manufacturers moving their production networks to countries with cheaper human efforts or skill competences. Nowadays, worldwide non-hierarchical networks are characterized by non-centralised decision making. This, increases the autonomy of hub organizations, enabling different rules and procedures for decision 1

FP6-507482 Knoweledge Web, FP6- 507590 CrossWork, FP6-507626 NO-REST, FP6507601 SPIDER-WIN, FP6-507849 ATHENA, FP6-508011 InterOP, and others.

196

C. Agostinho and R. Jardim-Goncalves

making within the same supply chain, but decreases the effectiveness in terms of integration and interoperability, which is defined as ‘the ability two or more systems or components have to exchange information and to use the information that has been exchanged’ [12] [13]. Paraphrasing Steve Ray, Division Chief at the National Institute of Standards and Technology “Supply chains are plagued with uncertainty (…) Most goods are still handed-off through faxes, phone calls, paper documents, and a wide range of proprietary or standard-based electronic exchanges” [14]. Indeed, interoperability has become the R&D target of many public and private programmes to address the above situation. To better describe the evolution of this domain, the authors classify current practices under the four following categories. 2.1 Slack Interoperability Most of the information being exchanged through the internet is not much more than untagged text, which might be acceptable for human reading or to large-scale electronic libraries, but is useless for e-business [15]. In B2B relationships it is expected that computer systems are able to communicate with the minimum human intervention possible, thus maximizing efficiency and time-to-market. The authors classify as slack interoperability, all communication sets (Cs) where there is no previous understanding between the sender and receiver. All electronic messages (m) exchanged between the two different organizations requires a corresponding “request for clarification” (rc) from the receiver side (see eq. 1), a response from the sender (r), and in some cases a set of actions normally involving human intervention (ha). , ∆

∆

, ∆

:

rc ∆

r

(1) ∆

(2)

This is highly inefficient since the total time spent on the communications among two organizations is given by the sum of four operands, and as expressed in eq. 2 (n = total messages exchanged), is increased with the time spent on the clarifications, responses and human interventions. Slack interoperability does not improve over time, and subsequent communications between the same organizations result in the same costs, i.e. no knowledge is stored and there is always the need to redo the entire clarification process. 2.2 Unregulated Interoperability As stated before, enterprise systems and applications need to be interoperable to achieve seamless operational and business interaction, and create networked organizations [16]. However, as illustrated by Fig. 1, organizations are traditionally focused on peer-to-peer relationships, thus disregarding the overall collaboration need of the network. Each organization tends to use its own data format and business rules, and handles as many mappings as the number of business partners. The fig. illustrates an extreme case where all organizations need to communicate with all the others.

Dynamic Business Networks: A Headache for Sustainable Systems Interoperability

197

Unregulated interoperability is quite efficient for networks of two or three organizations. However, it becomes unbearable for large networks, demanding a considerable financial effort, and producing an excessive workload for the software engineers responsible for the definition of the model morphisms (MMs) that enable communications (Cs) [17]. Each e-message (m) exchanged between two different organizations requires an initial effort to establish a mapping (map) among the models used by both (see eq. 3). Each time a new organization enters the collaborative network Fig. 1. Unregulated Interoperability causes an increase of the total number of mappings (map(x)) of the network according to eq. 4, but unlike slack interoperability, the knowledge regarding the transformation is stored within the systems and the major time consumption is concentrated at the first business interaction, i.e. at the time of the mapping establishment. , !

(3) 1

∆

∆

∆

∆

0, 1 , ∆

1 1

(4)

∆

(5)

When comparing the total time spent on communications (given by eq. 5) with the previous eq. 2, one might think that it has increased. However, that is not true since the request for clarifications (rc), corresponding responses(r) and human interventions (ha) are significantly reduced, being ‘k’ a limit lower than the total number of messages in the communications among two organizations within the network (n). Despite being the most common interoperability practice in industry, especially among SME’s, the costs of establishing a new mapping in unregulated interoperability is preventing the enlargement of networks, thus slowing the organizations expansion. Only through the adoption of harmonized and rigorous strategies is possible to break this barrier [18], [19]. 2.3 Standard-Based Interoperability Standardization rapidly became an evident priority adding efficiency to unregulated interoperability. Several dedicated reference models covering many industrial areas and related application activities, from design phase to production and commercialization, have been developed enabling industrial sectors to exchange information based on common models [20] [21].

198

C. Agostinho and R. Jardim-Goncalves

In that sense, one of the most important sets of standards for representation of product information in industrial environments is ISO 10303, commonly known as the Standard for the Exchange of Product Model Data (STEP) [22]. It encompasses standards for several industrial sectors as the automotive, aircraft, shipbuilding, furniture, construction, and others. When using standards as the reference format for information exchange (Fig. 2), organizations only need to be concerned with a single morphism, i.e. the one describing the mapping among its Fig. 2. Standard-based Interoperability internal system model and the standardized one being used in the communication. Therefore, for each message (m) exchanged between two different organizations, a single mapping (map) is required (see eq. 3). The major advantage comparing with unregulated interoperability concerns the total amount of mappings required within the network. As expressed by eq. 6, the total mappings (map(x)) correspond to the number of organizations (x). In this case, the collaboration effect is maximized and when a new organization enters the network, only needs to do a one-time effort of integration with the standard model. The remaining ones have no extra work. (6) ∆

∆

∆

∆

∆

∆

(7)

Concerning the total time spent on the communications between organizations (given by eq. 7) with eq. 5 from unregulated interoperability, one might think that it is the same. However, that is not true since the request for clarifications (rc), corresponding responses(r) and human interventions (ha) are significantly reduced, being ‘j’ a limit lower than ‘k’, which is also lower than the total number of messages in the communication (n). Here, all the clarifications are related with domain semantic issues, not with the morphisms syntax, since they follow a standardized structure. 2.4 Semantic Interoperability Interoperability is not a characteristic exclusive to ICT systems. On the contrary, it should be homogeneous throughout the network, crossing all enterprise levels, from the human knowledge, to business processes, down to plain data [16]. Unfortunately, that is not yet completely accomplished, and not addressed by standard-based interoperability [23]. To this envisaged level, the authors refer as semantic interoperability. It is defined by two kinds of knowledge: tacit knowledge, that people carry in their minds, providing context for people, places, ideas, and

Dynamic Business Networks: A Headache for Sustainable Systems Interoperability

199

experiences; and explicit knowledge that has been or can be articulated, codified, and stored in certain media, e.g. a standard [24]. It is because of the first, i.e. the human knowledge involved in businesses, that the previously described interoperability practices still require requests for clarification, and human actions need to be accounted in the total communications time. As an example, each stakeholder can have its own nomenclature and associated meaning for their business products. Therefore the information exchanged, even if sharing the same structure as in the standard-based interoperability, still may not be understood by all business partners [25]. Semantic annotation, semantic enrichment and knowledge mediation using domain ontologies are the current state-of-the-art research to address the above issues [25], [26], [27], [28]. Only when these challenges are accomplished, complemented with the usage of a standard, and applied in industry, seamless interoperability will become a reality. , !

,

(8) 2

∆

∆

∆

(9) ∆

(10)

As evidenced by eq. 8 and eq. 9, the number of mapping within the network will be more than in standard-based interoperability. This is because in addition to the morphism expressing the mapping (map) between the organization’s model and the standard model, there is also the need to map (ontomap) the organization’s semantics to a domain ontology, which is common to the collaboration network [29], [30]. The total time spent on the communications between two organizations (given by eq. 10) is heavily reduced when comparing with the previous practices, since having the domain semantics integrated, clarifications will no longer be required, and the communications set (Cs) automated. If semantic integration is done with other type of interoperability, other than the standard based, then the equations might not apply.

3 Sustainable Systems Interoperability In the global market, companies and the networks which they are part of, tend to follow a dynamic and evolutionary behaviour as in complex adaptive systems (CAS), exhibiting similar properties: heterogeneous agents, interaction, autonomy, ability to learn, self-organization, melting zone, and coevolution [31], [32]. Organizations wish to adapt themselves accordingly to the market demands and the availability of new systems and applications, or just by reusing existing ones introducing new requirements and corrections (e.g. to adapt themselves to a new client or making part of a new marketplace). However, adaptation also builds complexity [33]. As a consequence of these adaptations, models and semantics change, resulting in harmonization breaking, and introducing a new dimension to interoperability research: sustainable interoperability.

200

C. Agostinho and R. Jardim-Goncalves

3.1 Harmonization Breaking It is a well-established fact that in classical sciences, like physics, certain phenomena can be described in exactly the same way even if experiments are carried out under different observational circumstances. This means that the laws describing the phenomena display similar results for similar inputs, i.e. symmetries, or symmetric behaviour. Yet, experiments have proven that in extreme circumstances small fluctuations acting on a system may cause it to cross a critical point and evidence an unexpected behaviour. This disorder is designated as symmetry breaking, and is a characteristic of complex behaviour [34]. Drawing a parallelism with the collaboration networks addressed in this paper, the behaviour evidenced by organizations can be characterized similarly. After interoperability is first established, the set of organizations within a network demonstrate stability exchanging e-messages following established laws (i.e. morphisms). Therefore, networks display symmetry. However, as explained before, that may change according to new market requirements. If just one of the network members adapts to a new requirement, the harmony is broken, and the network begins experiencing interoperability problems. Therefore, the authors designate harmonization breaking, as the interoperability behaviour equivalent to symmetry breaking from classical sciences. 3.2 Collaboration Networks and Complex Adaptive Systems Cybernetics and systems thinking are well established in management literature. However, they are limited in scope to the boundaries of a system and by the perspective of management. Cybernetic systems operate at the level of basic processes that are relatively undisturbed, and systems thinking is an approach to problem solving when substantial changes have occurred in processes, viewing disruptions as parts of an overall system. However, neither can deal with major environmental changes of collaborative networks. Real dynamic systems are too complex to manage in a traditional manner [35]. The information age has highlighted the complex nature of systems, which move between ordered and disordered states, and networked organizations are an emerging logical form for organizing [36]. Over the past decades complexity theory has become a broad ranging subject appreciated in a variety of ways. The study of CAS has become the ultimate interdisciplinary science, focusing its modelling activities on how microstate events, whether particles, molecules, human agents, or firms, self-organize into emergent aggregate structure [37]. With roots in many disciplines such as evolutionary biology, non-linear dynamical systems, and artificial intelligence, modern theories and models of CAS focus on the interplay between a system and its environment and the coevolution of both [31]. Models of CAS can be used to explore how large-scale (macro) order is shaped by the characteristics of local (micro) interactions, i.e. how different patterns of local interaction and organization adaptive behaviour impact the overall network behaviour and performance [38]. In the context of collaboration networks, the macro or networked system would refer to a set of organizations that collectively supply, sell, or produce a given part or product. The micro, or individual system is the organization itself, and the

Dynamic Business Network ks: A Headache for Sustainable Systems Interoperability

201

environment would consist of end consumer markets that exert demand for the products and services. CAS can bee used to analyse how intervention strategiess on the network evolution, namely attemptts to shape local interaction patterns and map ppings, affect the network interoperability susstainability. 3.3 Heuristic Framework k for Network Stability Maintenancce Complexity science has beeen largely used as an analytic framework fo or organizational management, and recently y has also been Fig. 3. Sustainable Interoperabbility acknowledged as a fram mework for the Framework design of information systeems [39], [40]. It offers a powerful set of o methods for explaining non-linear, emeergent behaviour in complex systems, such as CAS whhich are presumed to be capab ble of autonomously adapting to environmental changges. However, some available literature l makes very clear that CAS result in non-linnear behaviour with some prob bability of butterfly events spiralling into positive and negative extremes [32]. To o avoid that, context awareness is demanded in supporrt of intelligence (Integration Inttelligence Layer). Monitoring and decision support systeems must be considered in the construction of a framework that implements sustainaable interoperability in cooperatiion networks (see Fig. 3). Such a framework mustt exhibit: (1) discovery capabilities, detecting when nnew system is added, or updated d in the network, thus creating harmonisation breaking; (2) Learning and adaptability, i.e., after detecting the harmonization breaking a learnning process should be triggered d to learn more about the changes occurred and the noodes adaptation required; It shou uld enable the adaptation of systems and the optimizattion of the maintenance processs, using knowledge representation technologies, appliedd to the model management do omain, namely dynamic model morphisms. (3) Transiient analysis, to understand how w a network, as an integrated complex system will suuffer from the transient period, and a how it affects the overall behaviour; (4) Notificatiion, informing in what way should the network nodes react, so that they obttain information for the needed adaptations, in order to enable that the system, as welll as the entire network, evolv ve for the new interoperable state. The evolution and adaptation of each node off the network should be executed, supported by the stuudy and analysis of the transient periods the proposed modifications could cause in the systems, both at individual and global level. Sustainable interoperabiility cannot just appear from scratch. It needs to buildd on previous practices such as a semantic interoperability, complementing them w with sustainability techniques. It I adds some extra time on the total time spent on the communications (Cs) betweeen two organizations (eq. 11), since in addition to eq. 10, it is now required to accou unt for the time spent on the sustainability recovery cyycle. However, on the long-run n it pays off. The network becomes immune to exterrnal phenomena that otherwise would produce serious costs in production lines and S SCs becoming paralysed if a maajor player was affected by the harmonization breaking.

202

C. Agostinho and R. Jardim-Goncalves

∆

∆

∆

∆

∆

(11)

4 Conclusions and Future Work The net effect of cheap communications is a perception that individuals and organizations have to deal with a world that is increasingly dynamical, complex and uncertain, and that their actions may have unintended consequences that impact on other parts of the world [41]. Indeed, supply chains are plagued with uncertainty, and systems interoperability has become an important topic of research in the latest years. Evolving from slack to unregulated interoperability, and then from standard-based to semantic, nowadays organizations have plenty of solutions that help establishing an efficient business partnership. Electronic communications are the basis for automation and efficiency. However, that is lost when just a single organization changes its information structures or semantics, causing the collaboration network to begin evidencing interoperability problems, i.e. harmonization breaking. The theoretical framework that is emerging based in complexity science appears to have relevance as an orienting device for entrepreneurship and sustainable interoperability research. Interpreting knowledge of the organizations domain through a metaphorical language of complexity may provide building blocks for explaining behaviour in terms of complex adaptive systems [42]. Evolvable systems imply ontology-based process-specific modularity at fine granularity with local intelligence and a distributed control solution [43]. Hence, the internal environment of the organization and its information system can create the adequate response to the external environment. For that to happen, both human workforce and information systems need form an adaptive resource [40]. Therefore, there is a need for a heuristic framework capable of capturing environment knowledge and relate human choices and preferences, using monitoring and decision support. An early version of this framework is presented in this paper. Similarly to what occurs in the model-driven development (MDD) architectures, meta-information and technologies related to transformation automation are considered. The application of these adaptive techniques will also enable the characterization of the current system status concerning morphisms and evolutionary transitions. However, the major complexity associated to the study of the properties of complex systems is that the associated models, drive to non-linearity, which in turn, drives to difficulties in the system’s study and in predicting their behaviour. In this context and part of future work, at the system microscopic level, prediction could be seen as a proposal for the automatic adaptation of the network morphisms, i.e., the point-to-point readjustments among the different systems, answering to the harmonization breaking. Thus, the framework envisages to include learning capabilities, monitoring, diagnostic and prognostic based on the operations history and interventions of the involved systems. It allows a control and optimization process of future adaptations, monitoring the individual evolution of each networked system, as well as the dynamics of the entire network. The research to be developed will establish the scientific and technological basis to enable different system nodes, belonging to a collaborative network, evolve at their own time, and keep being interoperable on the network they want to be part of.

Dynamic Business Networks: A Headache for Sustainable Systems Interoperability

203

References 1. Friedman, T.: The World is Flat. Farrar. Straus & Giroux (2005) 2. Pine, B.J., Gilmore, J.H.: The experience economy. Harvard Business Press (1999) 3. Gunasekaran, A., Ngai, E.W.T.: Build-to-order supply chain management: a literature review and framework for development. Journal of Operations Management 23, 423–451 (2005) 4. Mentzer, J.T., DeWitt, W., Keebler, J.S., Min, S., Nix, N.W., Smith, C.D.: Defining Supply Chain Management. Journal of Business Logistics 22(2), 1–25 (2001) 5. Panetto, H., Jardim-Gonçalves, R., Pereira, C.: E-Manufacturing and Web-Based Technology for Intelligent Manufacturing and Networked Enterprise. Journal of Intelligent Manufacturing 17(6), 715–724 (2006) 6. Jardim-Goncalves, R., Agostinho, C., Malo, P., Steiger-Garcao, A.: Harmonising technologies in conceptual models representation. International Journal of Product Lifecycle Management 2(2), 187–205 (2007) 7. SMART-fm project, Consolidated report on the state of the art in the research areas of SMART-fm. SMART-fm Deliverable 1.1 (2003) 8. Peppard, J., Rylander, A.: From Value Chain to Value Network: Insights for Mobile Operators. European Management Journal 24(2-3), 128–141 (2006) 9. Ray, S.R., Jones, A.T.: Manufacturing interoperability. Journal of Intelligent Manufacturing 17(6), 681–688 (2006) 10. Information Society Technologies (IST), http://cordis.europa.eu/ist/ projects/projects.htm (accessed on July 2009) 11. Mason, H.: Enabling e-business. ISO focus (July-August 2007) 12. Institute of Electrical and Electronics Engineers. IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries. New York, NY (1990) 13. Carnegie Mellon University.: Software Technology Roadmap (STR) (2004) 14. Watson, S.: Material offshore sourcing undergoes standardization. SCBIZ magazine (April-May 2008), http://www.scbizmag.com 15. Berners-Lee, T., Fischetti, M.: Weaving the Web: The Original Design and Ultimate Destiny of the World Wide Web by Its Inventor. HarperOne, San Francisco (1999) 16. Athena Integrated Project, EC FP6-507849 (2004), http://www.athena-ip.org 17. Agostinho, C., Sarraipa, J., D’Antonio, F., Jardim-Goncalves, R.: Enhancing STEP-based Interoperabity Applying Model Morphisms. In: Proceedings of the 3rd International Conference on Interoperability for Enterprise Software and Applications (I-ESA 2007), Madeira, Portugal (March 2007) 18. Jardim-Goncalves, R., Agostinho, C., Malo, P., Steiger-Garcao, A.: AP236-XML: a framework for integration and harmonization of STEP Application Protocols. In: Proceedings of IDETC/CIE 2005, ASME 2005 International Design Engineering Technical Conferences and Computers and Information in Engineering Conference, Long Beach, California, USA (September 2005) 19. Ray, S.: Interoperability Standards in the Semantic Web. Journal of Computer and Information Science in Engineering 2(1), 65–70 (2002) 20. Building Smart - International Alliance for Interoperability (IAI). Industry Foundation Classes (IFC), http://www.buildingsmart.com/bim (accessed on July 2009) 21. Jardim-Goncalves, R., Figay, N., Steiger, A.: Enabling interoperability of STEP Application Protocols at meta-data and knowledge level. International Journal of Technology Management 36(4), 402–421 (2006) 22. ISO/TC184-SC4. Standard for the Exchange of Product Data - ISO 10303 (STEP) overview, http://www.tc184-sc4.org/SC4_Open/ SC4%20Legacy%20Products%20%282001-08%29/STEP_%2810303%29/ (accessed on July 2009)

204

C. Agostinho and R. Jardim-Goncalves

23. EC Future Internet Enterprise Systems Cluster. Enterprise Interoperability Research Roadmap (version 5.0) (March 2008) 24. Nonaka, I., Konno, N., Toyama, R.: Emergence of “Ba”. In: Nonaka, I., Nishiguchi, T. (eds.) Knowledge Emergence: Social, Technical, and Evolutionary Dimensions of Knowledge Creation, pp. 13–29. Oxford University Press, US (2001) 25. Sarraipa, J., Agostinho, C., Panetto, H., Jardim-Goncalves, R.: Semantic Enrichment of Standard-based Electronic Catalogues. In: Proceedings of 13th IFAC Symposium on Information Control Problems in Manufacturing (INCOM 2009), Moscow Russia (June 2009) 26. Missikoff, M., Schiappelli, F., Taglino, F.: A Controlled Language for Semantic Annotation and Interoperability in e-Business Applications. In: Proceedings of the Second International Semantic Web Conference (ISWC 2003), Sanibel Island, Florida, pp. 1–6 (2003) 27. Boudjlida, N., Panetto, H.: Enterprise Semantic Modelling for Interoperability. In: Proceedings of 12th IEEE Conference on Emerging Technologies and Factory Automation (ETFA 2007), Patras, Greece, September 25-28, pp. 847–854 (2007) 28. Franconi, E.: Using Ontologies. IEEE Intelligent Systems 19(1), 76–79 (2004) 29. Jardim-Goncalves, R., Silva, J.P.M.A., Steiger-Garcao, A., Monteiro, A.: Framework for Enhanced Interoperability Through Ontological Harmonization of Enterprise Product Models in book Ontologies: A Handbook of Principles, Concepts and Applications. Integrated Series in Information Systems, vol. 14, XXIV, 915 p., 245 (2007) 30. Sarraipa, J., Silva, J., Jardim-Goncalves, R., Monteiro, A.: MENTOR – A Methodology for Enterprise Reference Ontology Development. In: 2008 4th International IEEE Conference on Intelligent Systems (2008) 31. Choi, T.Y., Dooley, K.J., Rungtusanatham, M.: Supply networks and complex adaptive systems: control versus emergence. Journal of Operations Management 19(3), 351–366 (2001) 32. Wycisk, C., McKelvey, B., Hulsmann, M.: Smart parts: supply networks as complex adaptive systems: analysis and implications. International Journal of Physical Distribution & Logistics Management 38(2), 108–125 (2008) 33. Holland, J.H.: Hidden order: how adaptation builds complexity. Perseus Books (1996) 34. Nicolis, G., Prigogine, I.: Exploring Complexity: An Introduction. W. H. Freeman and Company, New York (1989) 35. Schary, P.: Supply chain management: the challenge of systems. In: Waters, D. (ed.) Global Logistics: New Directions in Supply Chain Management, 5th edn. Kogan Page Pub. (2007) 36. Black, J.A., Edwards, S.: Emergence of virtual or network organizations: fad or feature. Journal of Organizational Change Management 13(6), 567–576 (2000) 37. McKelvey, B.: Complexity Theory in Organization Science: Seizing the Promise or Becoming a Fad? Emergence 1(1), 5–32 (1999) 38. Wilkinson, I., Young, L.: On cooperating: firms, relations and networks. Journal of Business Research 55(2), 123–132 (2002) 39. Merali, Y.: Complexity and Information Systems: the emergent domain. Journal of Information Technology 21, 216–228 (2006) 40. Courtney, J., Merali, Y., Paradice, D., Wynn, E.: On the Study of Complexity in Information Systems. International Journal of Information Technologies and Systems Approach 1(1), 37–48 (2008) 41. Merali, Y., McKelvey, B.: Using Complexity Science to effect a paradigm shift in Information Systems for the 21st century. Journal of Information Technology 21(4), 211– 215 (2006) 42. Fuller, T., Moran, P.: Small enterprises as complex adaptive systems: a methodological question? Entrepreneurship and Regional Development 13(1), 47–63 (2001) 43. Frei, R., Barata, J., Serugendo, G.: A Complexity Theory Approach to Evolvable Production Systems. In: Proceedings of 3rd International Workshop on Multi-Agent Robotic Systems in conjunction with ICINCO 2007, Angers, France, pp. 44–53 (2007)

On the Use of Description Logic for Semantic Interoperability of Enterprise Systems Esma Yahia, Jing Yang, Alexis Aubry, and Hervé Panetto Research Centre for Automatic Control (CRAN), Nancy-University, CNRS, Campus Scientifique, Faculté des Sciences et Techniques, BP 70239, 54506 Vandoeuvre-lès-Nancy Cedex, France {Esma.Yahia, Jing.Yang, Alexis.Aubry, Herve.Panetto}@cran.uhp-nancy.fr

Abstract. With the growing advances in computing and communications technologies, the concept of system-of-systems (SoS) becomes widely recognized as it offers potential benefits and new challenges. Relevant perspectives related to SoS constitutes nowadays an active domain of research, among them those issues concerning the need of full interoperation. When it is related to enterprise information systems, the SoS paradigm may then be derived to a form of System-of-Information Systems (SoIS). This paper presents an overview of the features of the interoperation in SoIS and proposes guidelines to evaluate and formalize it in order to identify semantic gaps between information systems concepts and models. It provides, through an example, an approach to use Description Logic for evaluating semantic interoperability concerns. Keywords: System-of-Systems, Information Systems, Semantic Interoperability, Description Logic, Ontology.

1 Introduction Today’s needs for more capable enterprise systems in a short timeframe are leading more organizations toward the integration of existing component-systems into broader intra-organizational or inter-organizational enterprise-systems. The remaining challenge of enterprise integration (EI) is to provide the right information at the right place at the right time for decision-making by integrating these heterogeneous information-intensive product-systems to achieve vertical business-to-manufacturing as well as horizontal business-to-business integration [1]. Advances in information technologies (IT) facilitate the implementation of applications interoperability but are not efficient to support the single enterprise as well as the networked enterprise to move from tightly coupled systems based on enterprise application integration (EAI) to loosely coupled systems based on service-oriented architectures (SOA) [2]. The integration in manufacturing paradigm (CIM concept) which underlies the global optimality of a monolithic enterprise-system fails to face this evolution, mainly because the related modelling frameworks are not appropriate to solve problems that continually change as they are being addressed. The intelligence in manufacturing R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 205–215, 2009. © Springer-Verlag Berlin Heidelberg 2009

206

E. Yahia et al.

paradigm (IMS concept) which is addressing the complexity to architect heterarchical enterprise-systems has difficulty to demonstrate its efficiency in real industrial environment [3], mainly because of the lack of a modelling framework to define, to develop, to deploy and to test self-organizing systems [4]. These integration issues are not handled well in traditional systems engineering templates (SE) because of the increasing complexity to architect enterprise-systems as a whole for each opportunistic collaboration; this from the bottom set of heterogeneous component systems to the system-of-systems (SoS) that emerges from their relationships, while they continue to exist on their own missions [5]. We agree that the essence of enterprise integration is the recursively interoperation of constituent systems to compose a system to achieve a specific purpose in a given context [6]. The related interoperability relationship can be implemented in several ways to compose a fully, tightly or loosely integrated system or a SoS depending on the adaptability of the constituent systems and the assigned mission [2]. Bridging the gap from an integrated system to a system of interoperable systems underlies knowledgeintensive organizational and cultural issues beyond technological ones, requiring multi scale modelling frameworks to cope with the limitations of human abilities to face complexity [7]. Many definitions are being amended with a number a required properties [8][9] to make SoS a candidate rationale artefact to distinguish a very large and complex socio-technical system of interoperable enterprise-systems from a monolithic non-SoS [10]. However, when it is related to enterprise information systems, the SoS paradigm may then be derived to a form of System-of-Information Systems (SoIS) where each heterogeneous information system has to semantically interoperate to ensure the whole enterprise performance. Semantic interoperability aims at ensuring that the meaning of the information that is exchanged is correctly interpreted by the receiver of a message. In centralized systems, this property improves the relevance of query answers. In distributed heterogeneous systems, such as systems-of-systems, it is compulsory to enable autonomous heterogeneous sources understanding each other to obtain relevant results. To provide semantic interoperability within a system, much research has been conducted on semantic representations. The main idea is to use meta-information which eases the meaning understanding. This approach needs the definition of ontologies which describe the concepts and relations between them, for a given domain. During the last fifteen years, much effort has focused on formal methods to describe ontologies, resource description languages, reasoning engines... All these methods represent the foundations of the semantic web. However, many works rely on the assumption that a single ontology is shared by all the participants of the system. Indeed, in systems-of-systems comprising autonomous sub-systems, this assumption is not realistic anymore. On the contrary, one has to consider that the subsystems create their ontologies independently of each other. Thus, most often ontologies differ, more or less, even if they are related to some common concepts. The main issue is then, at least to detect and, even more, to formally identify the semantic gap arising when two heterogeneous systems, sharing common concepts, interoperate. Formalizing the semantic match between two information system models is still a first open issue. Then, in this context, scientifically founding the interoperation process towards a science of interoperability implies, at a first step,

On the Use of Description Logic for Semantic Interoperability of Enterprise Systems

207

defining some metrics and a scale, in order to evaluate, quantitatively and better qualitatively, the maturity of this interoperation process. This paper aims to sketch some issues in studying semantic gaps between information systems concepts and models coming from heterogeneous interoperable systems, in a SoIS context, with a tentative formalization of those concepts using Description Logic. After highlighting the need of interoperability formalization in SoIS and showing the relevance of Description Logic (DL) as a candidate for a formalization tool in section 2, a methodology to formalize interoperability in SoIS is proposed in section 3. Finally, in section 4, this methodology is illustrated through a particular SoIS: the enterprise systems in the domain of manufacturing applications.

2 Ontology and Semantic Interoperability 2.1 Semantic Interoperability With the increasing complexity of Information Systems (IS) and mainly the evolvement of these IS from integrated systems to a system of interoperable ones, the need to achieve the interoperation becomes a critical issue in the research domain of information systems integration [11]. Interoperability is typically defined as the ability of two or more systems or components to exchange and use information [12]. Integration is generally considered to go beyond mere interoperability to involve some degree of functional dependence [13]. Many researches are trying to demonstrate that semantic interoperability can be enabled through setting up concepts via Ontology. The use of ontology is required as it acts as a conceptual model representing enterprise consensus semantics [14]. It aims at reducing the semantics loss among heterogeneous information systems that are sharing mostly common concepts from the same area of knowledge. Furthermore, ontology provides a common understanding and a formal model of the basic entities, properties and relationships for a given domain that are essential to overcome semantic heterogeneity. Generally, ontology is expressed with logic based languages; we can quote the first-order logics, the rules Languages, the non-classical logics and the Description Logics. All these languages are characterized by a formal specification of the semantics that allows expressing structured knowledge in one hand and promotes the implementation of reasoning support in the other hand. In this paper we will attempt to use Description Logics that is one of the knowledge representation (KR) formalisms which allows modelling the application domain by defining the relevant concepts of the domain and then using these concepts to specify properties of objects and individuals occurring in the domain [15]. Description logics can be considered as a variant of first-order logic (FOL) as it borrows the basic syntax, semantics and the proof theory necessary to describe the real word. The choice of Description Logics can be justified by the fact that we do not need all the full power of FOL in term of knowledge Representation to achieve a correct level of expressiveness [16]. Description Logics are mainly characterized by a set of constructors that allow building complex concepts and roles from atomic ones. Besides, concepts correspond to classes and they are interpreted as sets of objects otherwise, roles correspond to relations and are interpreted as binary relationships on objects. We present in Table 1 the basic constructors and their interpretation ΔI.

208

E. Yahia et al. Table 1. The basic DL constructors Constructor

Syntax

atomic concept atomic role

A R

C

disjunction

¬A

negation

∃ R.C ∀ R.C

existence restriction. value restriction. universal concept

T

bottom concept

⊥

⊆△ R ⊆△ × △ AI

⊓D C⊔D

conjunction

Semantics I

I

I

I

I

I

C ∩D

∪D △ -A {x| ∃ y.<x, y>∈ R ∧ y ∈ C } {x| ∀ y.<x, y>∈ R ⇒ y ∈ C } T = △ (the set of all individuals) CI

I

I

I

I

I

I

I

I

⊥I= ∅ (the empty set)

Description Logics allow mainly to represent knowledge and logic reasoning through different inference engines such as Racer1, Pellet2, FaCT++3... 2.2 Ontology for Semantic Interoperability To overcome the problem of semantic interoperability, there already exist some techniques; one solution is to use ontology mapping that consists in finding semantics correspondences between concepts from two given ontologies. Mapping is defined by [17] in this way: Given two ontologies O1 and O2, mapping one ontology with another means that for each concept (node) in ontology O1, we try to find a corresponding concept (node), which has the same or similar semantics, in ontology O2 and vice versa. Other but similar definitions are given by [18]. Formally an ontology mapping function can be defined in the following way [19]: - map: - map

-

1

=

, if

,

http://www.racer-systems.com/ http://clarkparsia.com/pellet/features/ 3 http://owl.man.ac.uk/factplusplus/ 2

> t with t being the threshold

entity is mapped onto ; they are semantically identical, each entity mapped to at most one entity Where: : ontology, with ontology index , : similarity function : entities of , with , , , entity index , : similarity function between two entities and

is

On the Use of Description Logic for Semantic Interoperability of Enterprise Systems

209

Automatic or semi-automatic mapping may use some mapping tools such as FCAMerge [20], IF-map [21], GLUE [22], COMA++ [23]. These automatic or semiautomatic mapping tools achieve accurate mapping results under the conditions of two ontologies defined in natural-language descriptions which are at the conceptual level. Most researchers [24] agree that automatic mapping between ontologies is important and critical for ontology integration for exploiting semantic relationships between ontologies, such as, the semantics of the subclass-of or part-of relationships, attachment of a property to a class, domain and range definitions for properties and so on. Thus, for higher abstraction level concepts, it is quite hard to automatically detect the semantic relationships. When it is the case, another approach consists in using a top ontology and providing mapping between these high abstraction level concepts and the concepts of the top ontology [25]. Several suggestions for such Top Ontologies have been studied, for example: DOLCE4, BFO5, Cyc6 and so on. This kind of upper ontology formalizes general or high level concepts such as processes, time, region, physical objects, and the semantic relationships of these notions. Our goal is then to provide a domainspecific ontology extending a selected Top Ontology. In the next section, we adapt this approach when ontologies are formalized with Description Logics.

3 Proposed Methodology for Semantic Interoperability In the case of SoIS, when two (or more) heterogeneous information systems IS1, IS2… have to communicate by exchanging data based on ad-hoc models, we propose an approach for formalizing the semantic gap that occurs between those heterogeneous models. We are basing this formalization on ontology representation. The first step is analyzing the two ontologies O1 and O2 that are already created by conceptualising the different information systems IS1, IS2... Despite the fact that they share some concepts, those ontologies differ by their terminologies. Establishing mappings between these two ontologies represents a first issue and we propose to put it in practice in order to evaluate the semantic relationships between two ontologies in the frame of SoIS as shown in Fig. 1. We assume that, in the same domain, two communities desire to share knowledge but each one has encoded knowledge according to its own local ontology O1 and O2 defined by concepts, axioms, and instances. The approach as shown in Fig.1 is defined as following: Let O1 and O2 be the local ontologies formalising the local domain of expertise. In order to compute some concepts mapping between O1 and O2, we must include an upper ontology U3. We are then mapping the relations over (O1, U3), (O2, U3). Then, a DL reasoner would be able to infer logical relationships over (O1, O2) from a set of asserted facts or axioms of (O1, U3) and (O2, U3): (O1, U3), (O2, U3) → (O1, O2). However in order to get sound reasoning results between O1, O2, there must be some restrictions about the “upper ontology”. It must previously agree upon a 4

http://www.loa-cnr.it/DOLCE.html http://www.ifomis.org/bfo 6 http://www.cyc.com/ 5

210

E. Yahia et al.

IS 1 IS 2

Ontology layer

Upper ontology

Ontology1

SoIS layer

Ontology2

DL Reasoning

Fig. 1. Proposed approach

common understanding, in order to favour the sharing of knowledge. The “upper ontology” must be well-defined, expressive enough. A standard upper/top ontology can serve as the upper ontology here. We will talk about it in 4.2 in detail. We must notice that it is necessary that the reasoning result should be validated by domain experts.

4 Use Case 4.1 An Overview of the Context Let us now illustrate the methodology proposed in section 3 on a particular system-ofinformation systems: the product manufacturing systems. Actually the increasing complexity on information flows on the one hand, and the distribution of the information in the whole supply chain on the other hand, had lead enterprises to use a lot of heterogeneous software applications like APS (Advanced Planning and Scheduling system), ERP (Enterprise Resource Planning), MES (Manufacturing Execution System), SCM (Supply Chain Management), PDM (Product Data Management)… to name only a few. Thus, all the enterprise systems have to interoperate to achieve global performances for the full manufacturing processes. In [26], it is suggested and we agree that it is the customized product which must drive the interoperability relationship in the manufacturing process. In this paradigm, the product is seen as an information system that embeds the information about itself and that is able to communicate with the software applications in order to be manufactured. [11] shows that when an “active product” interoperates with other enterprise systems, then the emerging system, with its own new mission, can be assimilated to a System-of-Information Systems. In the context of information exchange related to product data models, some efforts have already been made to

On the Use of Description Logic for Semantic Interoperability of Enterprise Systems

211

facilitate enterprise applications interoperability. We can notice two standardisation initiatives: the IEC 62264 set of standards [27] and the ISO 10303 STEP PDM technical specifications [28]. These standards try to solve the problem of managing heterogeneous information coming from different systems by formalising the knowledge related to products technical data [29]. The first one provides standard models and terminology for defining the interfaces between an enterprise’s business systems and its manufacturing control systems [27]. This standard defines concepts and models related to the product at the business and the manufacturing levels of enterprises (B2M). Applications interested by this standard are for example ERP systems at the business level and MES systems at the manufacturing level. The second one aims to provide a neutral mechanism capable of describing products throughout their lifecycle [29]. Applications interested by this standard are for example Product Data Management (PDM) systems or Computer Aided Design (CAD) systems. Together, the two standards are covering most information characterizing products and their related enterprise processes. They have been developed on the basis of a consensual expertise and, thus, may be considered as domain ontologies embedding domain knowledge with a high level of abstraction. Thus, in this context, the proposed methodology (see section 3) is relevant to study the interoperability relationship between enterprise information systems in the domain of manufacturing applications, through the existing standards. 4.2 Application of Proposed Methodology In the SoIS layer, we consider information systems IS1 and IS2. The IS1 is based on IEC 62264 set of standards while IS2 is based on the standard ISO 10303 STEP-PDM. Our approach is developed within two phases. • Phase 1: Ontology Formalization of the Standards Using DL to formalize the concepts and axioms of IEC 62264 and ISO 10303 STEP-PDM can be done manually or semi-automatically. In order to build a knowledge representation manually, some steps must be followed during its design. It is significant that we must firstly make a list of elements of the domain and then distinguish which will become concepts, roles or individuals. Then we need firstly to define the classification of all the concepts and roles for identifying classes, sub-classes and roles, sub-roles and, then to develop concept axioms. We use Protégé7 to develop the ontologies of both IEC 62264 and ISO 10303 STEPPDM. Concerning semi-automatic transformation from the standard language to ontology, there exist several tools helping at generating, at least, the taxonomy of the concepts. One must then develop, manually, the related axioms defining the ontology constraints. Starting from the UML representation of the conceptualised Material model, derived from the IEC 62264 [29], the semantics of the modelling concepts, informally defined in the standard, have been formalized by DL axioms as shown on Table 2.

7

http://protege.stanford.edu/

212

E. Yahia et al.

Table 2. Some of the important axioms of concepts in IEC 62264 material model ontology

⊑∀ ⊑∀ ⊑ ⊑∀ ⊑ ⊑∀ ⊑∀

MaterialClass define_a_grouping. MaterialDefinition MaterialClass hasTestedMaterialClassProperty. TestedMaterialClassProperty MaterialClass ≤ 1 part_of. MaterialInformation MaterialClassProperty hasValue.Value MaterialClassProperty =1 TestedMaterialClassProperty.TestedMaterialClassPropety MaterialDefiniton define_a_grouping-1.MaterialClass MaterialDefintion defined_by. MaterialLot .....

The semantics of the some modelling concepts, informally defined in the ISO STEPPDM standard models, have been formalized by DL axioms as shown on Table 3. Table 3. Some important axioms of concepts in ISO 10303 ontology Product_relationship Product_relationship Product_relationship Product Product Product Product

⊑ ∃ relating_product .Product ⊑ ≤ 1 (relating_product . Product) ⊔ (related_product ⊑ ∃ related_product .product ⊑ ∀ Product_relationship.Product ⊑ ∀ hasDescription.Description ⊑ ∀ HasProduct_Category. Product_Category ⊑ ≤ 1 HasProduct_Version. Product_Version -1

-1

-1

. Product)

-1

For both the standards ISO and IEC, concepts, roles, axioms, properties were then formalized using DL. We have got two disjoined ontologies in term of concepts. But, they are sharing the common knowledge related to any manufactured product. Among those Top Ontologies that contain highly abstract concepts, we propose to use DOLCE. • Phase 2: Using the Top Ontology: DOLCE DOLCE is a Descriptive Ontology for Linguistic and Cognitive Engineering. It has clear cognitive/linguistic bias, in the sense that “it aims at capturing the ontological categories underlying natural language and human commonsense”. This is promoted with a rich axiomatisation, with at least 37 basic categories and 7 basic relations and 80 axioms and 100 definitions and 20 theorems. The idea of our work is to perform the mapping of the two standard ontologies in a consistent way with respect to the definitions of concepts formalized in DOLCE. This should allow finding correspondences between the concepts of ISO and IEC. Practically, it is impossible to achieve reasoning based directly on the DOLCE axiomatisation. We experiment semiautomatic reasoning (using an inference engine) by deriving DOLCE axioms to formalize our standard ontologies. We were not able to achieve any practical results as the concepts of the Top Ontology are too abstract for a practical use in engineering applications. The relevant solution would consist on designing a Top-Domain

On the Use of Description Logic for Semantic Interoperability of Enterprise Systems

213

Ontology that holds the generic core classes of a given domain to interface both domain and top ontology [30]. So mapping the Top-Domain ontology to DOLCE would facilitate a better understanding and clarification of the given domain. Some efforts in our case domain (manufacturing) are already carried out to create a Top-Domain Ontology formalizing the technical data related to any manufactured products. In the literature, this is also called Product Ontology. We can quote two significant ones: (i) PRONTO (Product ONTOlogy) [30], ad-hoc ontology that focuses mainly on product structural information and (ii) a Product Ontology proposed by [29] based on existing standards and supporting the definition of product technical data. Independently of the terminologies involved in those two Product Ontology, it is primordial to point out that both share almost the main concepts related to the product. For instance, PRONTO suggests some concepts like Product family, Product, Property, Variant family…, that have correspondences on the other Product Ontology as the following: MaterialDefinition, MaterialClass, MaterialDefinitionProperty and so on. We claim that the coherent way for applying our approach consists on (i) mapping a Product Ontology to the DOLCE Top ontology, and (ii) mapping each of the two domain ontologies to the Product Ontology. We present in the following Table 4. Some Product Ontology concepts mapped on DOLCE Top classes Concepts

Axioms

DOLCE

Material

⊑ ∀is _member_of. VariantSet

Physical Endurant

SimpleProduct

⊑ Material ⊓ (RawMaterial ⊔ ¬ composed_of.Τ)

Physical Object ⊓¬atomic_part.T

ComplexProduct

⊑ ≥1 composed_of. SimpleProduct

MaterialClass

⊑ ∃is _member_of-1.VariantSet

Physical Object ⊓ Atomic_part_of.T Non Physical Endurant

5 Conclusion The focus of this paper is mainly to formalize interoperability relationships between heterogeneous Information Systems, from which emerges a so-called Systems-ofInformation System. The evolution of the interoperation complexity between existing enterprise and component systems asks the question about the science foundation of the interoperability domain. Current approaches to semantics interoperability for Enterprise Integration issues are examined as a first step to define such foundations. Nevertheless, these solutions are not sufficient when the number of relationships expands because of ad-hoc interfaces and specialised models that do not take into account existing standards. In this paper, we propose a new approach for studying the semantics gaps between existing information models, based on the formalization of domain ontologies with the expertise coming from standards of the domain. We proposed an approach to formalise, using Description Logic, such ontologies with regards to the DOLCE Top Ontology, through a Top Domain ontology (our Product Ontology) that holds the generic core classes of our given domain to interface both domain and top ontology [30]. Current work aims to scientifically found the interoperation process by defining some metrics and a scale, in order to evaluate,

214

E. Yahia et al.

quantitatively and better qualitatively, the maturity of this interoperation process. To some extent, the work presented in this paper is a first step in contributing to the definition of a Science for Interoperability.

References 1. Giachetti, R.E.: A framework to review the information integration of the enterprise. International Journal of Production Research 42(6), 1147–1166 (2004) 2. Morel, G., Panetto, H., Mayer, F., Auzelle, J.P.: System of Enterprise-Systems Integration Issues An Engineering Perspective. In: Keynote plenary paper, IFAC Cost Effective Automation in Networked Product Development and Manufacturing (CEA 2007), Monterrey NL, Mexico, October 2-5 (2007) 3. Marik, V., Lazansky, J.: Industrial applications of agent technologies. Control Engineering Practice (2007) 4. Valckenaers, P., Van Brussel, H., Hadeli, Bochmann, O., Saint Germain, B., Zamfirescu, C.: On the design of emergent systems an investigation of integration and interoperability issues. Engineering Applications of Artificial Intelligence 16, 377–393 (2003) 5. Maier, M.W.: Architecting principles for systems-of-system. Systems Engineering 1(4), 267–284 (1998) 6. Carney, D., Fischer, D., Place, P.: Topics in Interoperability System-of-Systems Evolution, Report CMU/SEI-2005-TN-002 (2005) 7. Bjelkemyr, M., Semere, D., Lindberg, B.: An engineering systems perspective on system of systems methodology. In: IEEE 1st Annual Systems Conference, Hawaii, April 9-13, pp. 1–7 (2007) 8. Sage, A.P., Cuppan, C.D.: On the Systems Engineering and Management of Systems-ofSystems and Federations of Systems. Information, Knowledge, Systems Management 2(4), 325–345 (2001) 9. Fisher, D.A.: An Emergent Perspective on Interoperation in Systems-of-Systems. Carnegie Mellon University (2006) 10. Carlock, P.G., Fenton, R.E.: Systems-of-Systems (SoS) Enterprise Systems Engineering for Information- Intensive Organizations. Systems Engineering 4(4), 242–261 (2001) 11. Auzelle, J.P.: Proposition d’un cadre de modélisation multi-échelles d’un Système d’Information en entreprise centré sur le produit. PhD Thesis, Henri Poincaré, Nancy University (2009) (in French) 12. IEEE (Institute of Electrical and Electronics Engineers): Standard Computer Dictionary A Compilation of IEEE Standard Computer Glossaries, 610-1990, NY (1990) ISBN: 1559370793 13. Panetto, H.: Towards a Classification Framework for Interoperability of Enterprise Applications. International Journal of CIM 20(8), 727–740 (2007) 14. Obrest, L., Liu, H., Way, R.: Ontologies for Corporate Web Applications. AI Magazine (Fall 2003) 15. Baader, F., Calvanese, D., McGuinness, D., Nardi, D., Patel-Schneider, P.F.: The Description Logic Handbook: Theory, Implementation, and Applications. Cambridge University Press, Cambridge (2003) 16. Breitman, K.K., Casanova, M.A., Truszkowski, W.: Semantic Web: Concepts, Technologies and Applications. Springer, Heidelberg (2007)

On the Use of Description Logic for Semantic Interoperability of Enterprise Systems

215

17. Su, X.M.: A text categorization perspective for ontology mapping. Technical report, Department of Computer and Information Science. Norwegian University of Science and Technology, Norway (2002) 18. Ding, Y., Fensel, D., Klein, M.: Boris Omelayenko: Ontology management: Survey, requirements and directions. Deliverable 4. IST Project IST-1999-10132 (2001) 19. Ehrig, M., Sure, Y.: Ontology Mapping - An Integrated Approach. In: Bussler, C.J., Davies, J., Fensel, D., Studer, R. (eds.) ESWS 2004. LNCS, vol. 3053, pp. 76–91. Springer, Heidelberg (2004) 20. Stumme, G., Mädche, A.: FCA-Merge: Bottom-up merging of ontologies. In: 7th International Joint Conference on Artificial Intelligence (IJCAI 2001), pp. 225–230 (2001) 21. Kong, X., Murphy, K., Raj, T., He, C., White, P.S., Matise, T.C.: A combined linkagephysical map of the human genome. American Journal of Human Genetics 75(6), 1143– 1150 (2004) 22. Doan, A., Madhavan, J., Domingos, P., Halevy, A.: Learning to map between ontologies on the semantic web. In: Proceedings of the 11th international conference on World Wide Web, Honolulu, Hawaii, USA, pp. 662–673 (2002) ISBN: 1-58113-449-5 23. Do, H.-H., Rahm, E.: Matching Large Schemas: Approaches and Evaluation. Information Systems 32(6), 857–885 (2007) 24. Noy, N.F.: Semantic integration: a survey of ontology-based approache. Special section on semantic integration, 65–70 (2004) ISSN: 0163-5808 25. Kalfoglou, Y., Schorlemmer, M., Sheth, A., Staab, S., Uschold, M.: Semantic interoperability and integration. In: Dagstuhl Seminar on Semantic Interoperability and Integration, Dagstuhl, Germany (2004) 26. Morel, G., Panetto, H., Zaremba, M.B., Mayer, F.: Manufacturing Enterprise Control and Management System Engineering paradigms and open issues. IFAC Annual Reviews in Control 27(2), 199–209 (2003) 27. Enterprise-control system integration. Part 1. Models and terminology. Part 2: Model object attributes: ISO/IEC FDIS Standard, IEC and ISO, Geneva, Switzerland (2002) 28. ISO/TS 10303 STEP modules related to Product Data Management: Industrial automation systems and integration - Product data representation and exchange, Geneva (2004) 29. Tursi, A., Panetto, H., Morel, G., Dassisti, M.: Ontological approach for Products-Centric Information System Interoperability in Networked Manufacturing Enterprises. IFAC Annual Reviews in Control 33(3) (September 2009) ISSN: 1367-5788 30. Stenzhorn, H., Schulz, S., Beisswanger, E., Hahn, U., Hoek, L.V.D., Mulligen, E.V.: BioTop and ChemTop–Top-Domain Ontologies for Biology and Chemistry. In: 7th International Semantic Web Conference (ISWC), vol. 401 (2008)

A Maturity Model for Enterprise Interoperability Wided Guédria1,2, David Chen1, and Yannick Naudet2 1

IMS-LAPS/GRAI, University Bordeaux 1. 351, cours de la libération, 33405, Talence cedex, France 2 CITI, Henri Tudor Public Research Center. 29, Av. John F.Kennedy, 1855 Luxemboug-Kirchberg, Luxembourg {wided.guedria,david.chen}@ims-bordeaux.fr, {wided.guedria,yannick.naudet}@tudor.lu

Abstract. Existing interoperability maturity models are fragmented and only cover some interoperability aspects. This paper tentatively proposes a maturity model for enterprise interoperability which is elaborated on the basis of existing ones. It is also consistent to the Enterprise Interoperability Framework currently under the standardization process. After a brief introduction, the paper reviews existing maturity models for interoperability and recalls the basic concepts of the Enterprise Interoperability Framework. Then the proposed maturity model for enterprise interoperability is discussed in details. Metrics for determining maturity levels are presented as well. Finally the last part of the paper gives the conclusions and perspectives for future work. Keywords: Interoperability measure, maturity models, assessment, enterprise interoperability.

1 Introduction Developing interoperability implies establishing measures of merit to evaluate the degree of interoperability. Maturity is one of the possible measures, describing the stages through which systems can evolve to reach higher degree of interoperability. The interoperability maturity assessment allows companies knowing their strengths and weaknesses in terms of ability to interoperate with others, and defining priorities to improve interoperability. Today there exist many maturity models. Few were developed for interoperability assessment. The objective of our research is to propose a Maturity Model for Enterprise Interoperability (MMEI) which deals with all major aspects of interoperability and covers the main concepts of existing interoperability maturity models. The Framework for Enterprise Interoperability (FEI) initially elaborated in INTEROP NoE [12] and now under CEN/ISO standardization process (CEN/ISO 11354) is used as a basis to build this MMEI. Previously, survey and comparison studies [1] [2] have been performed to evaluate existing interoperability maturity models: LISI (Levels of Information System Interoperability) [4], OIM (Organizational Interoperability Model) [5], LCIM (Levels of Conceptual Interoperability Model) [6], and EIMM (Enterprise Interoperability Maturity Model) [7], as well as ISO/15504 (SPICE) [3] although it is not dedicated to R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 216–225, 2009. © Springer-Verlag Berlin Heidelberg 2009

A Maturity Model for Enterprise Interoperability

217

interoperability assessment. Existing interoperability maturity models focus, in most of cases, on one simple facet of interoperability (data, technology, conceptual, Enterprise modeling, etc.). They are complementary rather than contradictory. Consequently it is necessary to structure them into a single complete interoperability maturity model to avoid redundancy and ensure consistency. This paper aims at presenting a preliminary research result on the development of such a Maturity Model for Enterprise Interoperability. This development is a long and iterative process which needs significant industrial applications and case-studies for its improvement and validation. The model presented in this paper should be considered as a basis and a starting point for further research and development. The paper is structured as follows. In section 2, the Framework for Enterprise Interoperability is briefly presented. Main relevant interoperability maturity models are mapped to the framework to evaluate their coverage. In sections 3 and 4, the proposed maturity model for enterprise interoperability and associated metrics are outlined. Finally section 5 concludes the paper and proposes future work.

2 Framework for Enterprise Interoperability The Framework for Enterprise Interoperability [12] defines three basic dimensions as follows: -

Interoperability concerns, defining the content of interoperation that may take place at various levels of the enterprise (data, service, process, business). Interoperability barriers, identifying various obstacles to interoperability in three categories (conceptual, technological, and organizational) Interoperability approaches, representing the different ways in which barriers can be removed (integrated, unified, and federated)

The first two dimensions, interoperability concerns and barriers, constitute the problem space of enterprise interoperability. The intersection of a barrier and a concern is the set of interoperability problems having the same barrier and concern. The three dimensions together constitute the solution space of enterprise interoperability. Prior to the development of MMEI, existing interoperability maturity models were mapped to the FEI. Fig. 1 shows the framework with the first two dimensions and the coverage of existing interoperability maturity in the enterprise interoperability problem space of FEI. While ISO/IEC 15504 model targets enterprise processes and is not specific to interoperability, it is however shown in the figure. In fact, using this model to improve processes will increase the interoperability potential, and as shown, it covers the three categories of interoperability barriers (conceptual, technological and organisational). LISI maturity model focuses on technology (IT) issues, and mainly concerns communication, data exchange and service (application) interoperability. LCIM deals with data interoperability and focuses on data representation issues (syntax and semantics) as well as data interchange, interface and accessibility. EIMM

218

W. Guédria, D. Chen, and Y. Naudet

Fig. 1. Mapping of main maturity models to FEI (here the two dimensions only)

aims at evaluating enterprise modelling/model maturity and covers data, service and process interoperability issues. OIM assesses organisation maturity issues at business/ company level. Most of existing models were developed based on the main concepts of CMMI [13] which is considered as an instance of ISO/IEC 15504 and thus not presented here.

3 Maturity Model for Enterprise Interoperability (MMEI) In this section, the proposed MMEI is presented. It covers the whole problem space of the Framework for Enterprise Interoperability (four interoperability concerns and three types of interoperability barriers). Main issues and concepts of existing interoperability maturity models are used as a basis to define criteria and requirements for accessing maturity levels. Generally speaking, the maturity can be measured a priori (in this case the measure is concerned with the interoperability potentiality, i.e. with a possible future partner. The partner is not known at the moment of evaluation) or a posteriori (interoperation already exists between partners and in this case the assessment is concerned with the existing interoperability situation, i.e. considering the incompatibilities between two known systems). While MMEI is designed in an interoperability potentiality view, it might be exploited as well a posteriori. 3.1 Overview When enterprise wants or needs to be able to properly interoperate with others, different tools such as guidelines or metrics might be useful. Evaluating its interoperability potentiality using the MMEI allows an enterprise having an idea of the probability it has to support efficient interoperations. But also to detect precisely the weaknesses which can be sources of interoperability problems. MMEI defines four levels of interoperability maturity as shown in the table 1. Each level identifies a certain degree of capability to establish/improve interoperability.

A Maturity Model for Enterprise Interoperability

219

Table 1. Interoperability maturity levels

Maturity Level Level 4 - Adapted Level 3 - Organized Level 2 - Aligned Level 1 - Defined Level 0 - Unprepared

Maturity assessment Capable of negotiating and dynamically accommodating with any heterogeneous partner Capable of meta modeling for necessary mapping in order to interoperate with multiple heterogeneous partners Capable of making necessary changes to align to common formats or standards Capability of properly modeling and describing systems to prepare interoperability Not relevant: there is no capability for interoperation

Levels 0 and 1 correspond to the situation where there are no or some ad-hoc interoperations. From levels 2 to 4, three levels of maturity are defined corresponding to Interoperability Approach dimension of FEI (Integrated, Unified and Federated). Table 2 shows the mapping between maturity levels and interoperation environments. Table 2. Maturity levels vs. interoperation environments

Maturity Level Level 4 - Adapted Level 3 - Organized Level 2 - Aligned Level 1 - Defined Level 0 - Unprepared

Interoperation environments Federated: No pre-defined format or meta-models. Dynamically adjust and accommodate Unified: Use of meta-models allowing heterogeneous systems to map one to others Integrated: Common format (or standard) for all partners to build there systems (components) Connected: Simple electronic exchange of information, messaging, etc. Isolated: Occasional and manual exchange of information (document, fax...)

Each level of maturity also corresponds to a degree of interoperability ranging from no interoperability to full interoperability as shown in table 3. Table 3. Maturity levels and interoperability degree

Maturity Level Level 4 - Adapted Level 3 - Organized Level 2 - Aligned Level 1 - Defined Level 0 - Unprepared

Interoperability degree Generalized (full interoperability to any potential partners worldwide) Extended (many-to-many relation, multiple heterogeneous partners) Restricted (Peer-to-peer relation, to use a common format or standard) Limited (with only some ad hoc interoperations) Inexistent

Table 4 gives a high level view of MMEI and shows the focuses and concerns at each maturity level and for each interoperability barrier category.

220

W. Guédria, D. Chen, and Y. Naudet Table 4. Focus and concern of MMEI

Maturity Levels/ Barriers Level 4 - Adapted Level 3 - Organized Level 2 - Aligned Level 1 - Defined Level 0 - Unprepared

Conceptual

Technological

Organizational

Accommodated Mapped Adhered Modeled Incomplete

Reconfigurable Open-architecture Arranged Connectable Inaccessible

Agile Trained Flexible Specified Inexplicit

In the following sections, each maturity level is described with a table based on the FEI (dimensions of interoperability concerns and interoperability barriers). Each cell defines requirements (or criteria to meet) which are necessary to reach that interoperability maturity level. The transition from one level to a higher one corresponds generally to the removal of interoperability barriers and satisfaction of requirements. 3.2 Level 0 (Unprepared) The initial level of interoperability maturity is characterized by proprietary or closed systems. In such systems, resources are not meant to be shared with others. System modeling and description are not complete or even inexistent. Organization is not explicitly specified. There is in general no interoperation possible or desired. Communication remains mainly manual exchange. Systems run stand-alone and are not prepared for interoperability. The level 0 of interoperability maturity is described in table 5. Table 5. Description of the MMEI level 0 Level 0 Business

Process

Service Data

Conceptual Heterogeneous visions, strategies, politics (not properly described) Heterogeneous processes (not formally described) Heterogeneous services (not formally defined) Heterogeneous data representation, not completely modeled

Technological No IT infrastructure /platform in place, or incompatible ones Manual processes

Organizational Undefined /heterogeneous methods of work Undefined /heterogeneous procedures of work Stand-alone services Responsibilities /authorities not known Closed data storage Responsibilities devices, manual /authorities for data exchange not defined

3.3 Level 1 (Defined) Although the systems are still entirely distinct, some ad hoc interoperations can take place, but the interoperability remains very limited. Some basic IT devices are connectable. Simple electronic data exchange becomes possible. Systems and organisations are in general defined and modelled. Modelling tools are in place and used for design time (specifying systems), but these tools are technology dependent and can only run in some specific platforms. Responsibility and authorities to model, update and maintain data, services, processes are explicitly defined.

A Maturity Model for Enterprise Interoperability

221

The description of this level is shown in the table 6. Table 6. Description of the MMEI level 1 Level 1

Business

Process

Service

Data

Conceptual Technological Organizational Business models, IT infrastructure/ Organization structure strategies, politics platform in place, defined and in place described /modeled and connectable Process modeling is Platform dependant performed Process modeling tools (design time) Services defined and Platform dependant documented Service modeling tools (design time) Data models explicitly Devises connected/ defined simple electronic exchange possible

Responsibilities/ authorities for managing process defined Responsibilities/ authorities for managing services defined Responsibilities/ authorities for managing data defined

3.4 Level 2 (Aligned) This level of maturity requires that the company is able (i.e. has the capabilities) to make changes in its system in order to adhere to common formats (imposed by a partner). Relevant standards are also used as much as possible. Some flexibility has been achieved in organization structure. IT infrastructure and platform are connected. Tools remains platform dependent but they are used not only for modeling (design time) but also executable at run time. Generally speaking the efforts (time and cost) to make changes in systems are big and in general not easily reversible. The achieved interoperability by aligning to a common format or standard is said limited in the sense that it is confined to certain fixed and homogenous partners or situations such as for example companies’ merge or fusion. It corresponds to the integrated environment/ approach defined in the Framework of Enterprise Interoperability. The description of level 2 is shown in table 7. Table 7. Description of the MMEI level 2

Level 2

Business

Process

Service

Data

Conceptual Business/IT alignment

Aligned process models using common formats / standards Aligned service models using common formats / standards Align data models using common formats / standards

Technological IT Infrastructure / platform connected (peer-to-peer) Platform dependent Process execution tools (run time) Platform dependent Service execution tools (run time) Data bases connected, remote access to data base possible

Organizational Flexible organization structure Procedures defined

of

work

Guidelines for service exchanges in place Rules and methods for data interoperability management in place

222

W. Guédria, D. Chen, and Y. Naudet

3.5 Level 3 (Organized) At this level, enterprise is well organized to deal with interoperability challenges. Interoperability capability is extended to heterogeneous systems/partners, and often in a networked context. Although companies systems remain heterogeneous but the meta-modeling is performed, and mapping using meta-models is generalized. Organization and decision-making are in general decentralized to improve flexibility and reactivity. Companies are able to interoperate with multiple heterogeneous partners. This level corresponds to the unified environment/ approach defined in the Framework for Enterprise Interoperability. The development of an ontology, reference or standardized meta-models is required. Level 3 requires that people has been trained with collaborative approaches and interoperability notions and guidelines. The description of the level 3 is shown in table 8. Table 8. Description of the MMEI level 3

Level 3 Business

Process

Service

Data

Conceptual Business models for multi partnership and networked enterprise Process specification for mapping

Technological Open and cross-enterprise infrastructure/ platform (many-to-many) Collaborative process engineering and execution tools Services annotation Collaborative service and mapping orchestration /choreography Composable services Meta models for data Remote access to data mapping bases possible for applications

Organizational Organization team trained for interoperability Guideline for crossenterprise collaborative process Multiple roles and responsibilities

Non functional quality for interoperable data management

3.6 Level 4 (Adapted) This level corresponds to the highest level of interoperability maturity (universal). Companies are able to dynamically adjust and accommodate ‘on the fly’. There exist in general shared domain ontologies. At the level 4 companies are able to interoperate with multi-lingual and multiculture heterogeneous partners. This level corresponds to the federated environment / approach defined in the Framework for Enterprise Interoperability. At this level all information and interoperability itself becomes a subject of continuous improvement (evolution and adaptation). This level is rarely reached by systems. The description of this level is shown in table 9.

A Maturity Model for Enterprise Interoperability

223

Table 9. Description of the MMEI level 4

Level 4

Business

Process

Service

Data

Conceptual Continuous Business/ IT alignment Dynamic process re-engineering

Technological Organizational Reconfigurable IT Agile organization for infrastructure / platform on-demand business

Platform independent dynamic and adaptive tools and engines for processes. On-demand/ Platform independent adaptive service reconfigurable services modeling architecture for services composition Adaptive data Direct database model (both syntax exchanges capability and and semantics) full data conversion tool

Real-time monitoring of processes Adaptive work procedures Dynamic and ondemand allocation of resources to services Adaptive data management rules and methods

3.7 Remarks and Discussions It is important to note that a lower interoperability maturity for a company does not systematically mean a dysfunction at all levels and for all functions of the company. The maturity is only evaluated from the interoperability point of view and cannot be applied for other purpose. High level degree of interoperability cannot be achieved for free. It is generally costly and time consuming. Each enterprise must define its needed interoperability requirements and maturity level to reach. It is not recommended to all enterprise to look for the highest interoperability level regardless of their needs.

4 Maturity Model Metrics We associate a metric Mk to each maturity level k. Mk is obtained from the different scores Sij assigned by the evaluators, for each interoperability concern i and interoperability barrier j. These factors represent the proportion to which an evaluator thinks that the evaluated system is in the state described by the element (k, i, j) of the matrix (IML, EC, IL), IML representing the interoperability maturity levels; EC being the interoperability concerns; and IL the interoperability barriers. We were inspired by the rating scale of SPICE [3], which uses a linear percentage scale against which each attribute is assessed in [0, 100] %. This allows us to define, in a coherent manner, a person's judgment which is subjective. Let the scores Sij be a percentage of achievement, i.e. in [0, 100] %. For a maturity level k, the following scale can be used: • • • •

0 < Sij ≤ 15 => not achieved 16 < Sij ≤ 50 => partially achieved 51< Sij ≤ 80 => achieved 81< Sij ≤ 100 => fully achieved

224

W. Guédria, D. Chen, and Y. Naudet

From these assigned scores, we can determine whereas the maturity level k is reached or not by calculating the metric Mk following the formula (1). A necessary condition for that is that the previous level (l-1) is already fully achieved (81<Mk-1≤100). Mk

i

∑ ,,

i

sij.

(1)

With: -

ni the number of the interoperability barriers to evaluate, n the number of interoperability concerns, sij the scale associated to the interoperability concern j at the interoperability level i.

The considered level is reached (achieved) at least if Mk > 0.51. Because it is difficult for people making a fine judgment and assigning coherent numerical values, it can be convenient to use directly the linguistic variables for representing the assigned scores. In this case, the formula (1) would be changed to a fuzzy version, which can be treated using fuzzy logic to obtain directly a linguistic qualification of the maturity. This is one of our perspective works. Example. To make the use of the maturity model and its metrics more concrete, we present here an example, for which we show how to determine interoperability level on the basis of examples considering two interoperating enterprises E1 and E2. When a particular interoperability project starts (i.e. the partner is known), barriers to interoperability can exist at each level of the company and of its partner. After a series of interviews, the evaluators give a report for the maturity level L2, shown in table 10. Table 10. Example of degrees assigned after a series of interviews

Level 2

Concerns Business Process Service Data

Conceptual 0.5 0.65 0.8 0.9

Technological 0.7 0.85 0.7 0.9

Organizational 0.8 0.5 0.7 0.4

To evaluate the general enterprise interoperability at all its levels, the maturity level is calculated by: M2

0.5

0.65

0.8

0.9 0.7 0.85 0.7 0.4 = 0.7.

0.7

0.9

0.8

0.5

(2)

M2> 0.51, so the global interoperability maturity is at the level L2.

5 Conclusion and Future Work In this paper, the development of a maturity model for enterprise interoperability has been proposed. Five levels of maturity and metrics were defined and described. Based on the FEI, the proposed MMEI covers the four main enterprise interoperability

A Maturity Model for Enterprise Interoperability

225

concerns (data, service, process, and business) and the three main problem areas (conceptual, technical, and organizational) which were usually dealt by separated distinct maturity models. Future work is planned to refine the proposed model and metrics, and to perform some case studies in enterprises. A detailed questionnaire associated with a structured methodology will also be elaborated to support the use of MMEI in industry. MMEI is also based on the concepts and notions coming from general system theory which is considered as relevant to develop a science base for enterprise interoperability [8]. The MMEI is intended to be used in association with OoEI (Ontology of Enterprise Interoperability) [9] to develop a knowledge based system to support enterprise interoperability analysis and diagnostics.

References 1. Panetto, H.: Towards a classification framework for interoperability of enterprise applications. International journal of Computer Integrated Manufacturing 20(8), 727–740 (2007) 2. Guedria, W., Naudet, Y., Chen, D.: Interoperability maturity models – Survey and Comparison. In: Proc. of the 3rd IFAC/IFIP, OTM workshop, EI2N 2008 (Enterprise Integration, Interoperability and Networking), Monterrey, Mexico (2008) 3. International Organization for Standardization and International Electrotechnical Commission, ISO/IEC 15504 Software Process Improvement and Capability DEtermination Model (SPICE) (2001) 4. C4ISR Interoperability Working Group, Levels of information systems interoperability (lisi), Tech. report, US Department of Defense, Washington, DC (1998) 5. Clark, T., Jones, R.: Organisational interoperability maturity model for c2. In: Proc. of the 1999 Command and Control Research and Technology Symposium, Washington (1999) 6. Tolk, A., Muguira, J.A.: The levels of conceptual interoperability model. In: 2003 Fall Simulation Interoperability Workshop, USA (September 2003) 7. ATHENA. Advanced Technologies for Interoperability of Heterogeneous Enterprise Networks and their Applications, FP6-2002-IST1, Integrated Project Proposal (April 2003) 8. Von Bertalanfy, L.: General System Theory: Foundations, Development, Applications. Georges Braziller, Inc., New York (1968) 9. Naudet, Y., Guédria, W., Chen, D.: Systems Science for Enterprise Interoperability. In: IESA 2009 workshops, 5th International Conference Interoperability for Enterprise Software and Applications, Beijing, China (2009) 10. CompTIA: European Industry Association. European Interoperability Framework, white paper - ICT Industry Recommendations (2004), http://www.comptia.org 11. INTEROP, Enterprise Interoperability -Framework and knowledge corpus- Final report, INTEROP NOE, FP6 -Contact n 508011, Deliverable DI.3 (2007) 12. Method Integrated Team.: Standard CMMI Appraisal Method for Process Improvement (SCAMPI), Version 1.1: Method Definition Document Members of the Assessment (2001)

ISDE 2009 PC Co-chairs’ Message Information Systems in a Distributed Environment (ISDE) are rapidly becoming a popular paradigm in this globalization era due to advancements in information and communication technologies. The increased popularity of ISDE due to various factors has resulted in a substantial number of research and industrial studies. Information system development and implementation in distributed environments is still evolving and presents novel challenges. Therefore, it is crucial to understand current research and practices in this regard and share knowledge with researchers and practitioners in these areas. The selected papers of the ISDE 2009 workshop in conjunction with OTM conferences present recent advances and novel proposals in this direction. Jürgen Münch and Ansgar Lamersdorf, in their paper “Systematic Task Allocation Evaluation in Distributed Software Development,” present a customizable process for task allocation evaluation that is based on results from a systematic interview study with practitioners. In this process, the relevant criteria for evaluating task allocation alternatives are derived by applying principles from goal-oriented measurement, and customization of this process is also demonstrated along with limitations and directions for future work. “Extending Global Tool Integration Environment Towards Lifecycle Management” by Jukka Kääriäinen, Juho Eskeli, Susanna Teppola, Antti Välimäki, Pekka Tuuttila, and Markus Piippola presents the analysis of an open source global tool integration environment, called ToolChain, and proposes improvements for it towards application lifecycle management (ALM). The demonstration of ToolChain and the collection of improvement proposals were carried out in the telecommunication industry. The analysis was made using the ALM framework and global software development (GSD) patterns developed in previous studies in the automation industry. Pawel Rubach and Michael Sobolewski in their paper “Dynamic SLA Negotiation in Autonomic Federated Environments” propose a new SLA-based SERViceable Metacomputing Environment (SERVME) capable of matching providers based on QoS requirements and performing autonomic provisioning and deprovisioning of services according to dynamic requestor needs. This paper presents the SLA negotiation process that includes the on-demand provisioning and uses the object-oriented SLA model for large-scale service-oriented systems introduced by SERVME. Non-functional requirements (NFR) such as network security recently gained widespread attention in distributed information systems. Despite their significance, there is no systematic approach to validate these requirements given the complexity and uncertainty characterizing modern networks. Vicky Papadopoulou and Andreas Gregoriades in their paper “Network Security Validation Using Game Theory” present a game-theoretic approach to security requirements validation. An introduction to game theory is given along with an example that demonstrates the application of the approach. In “Obstacles in Implementing Agile Methods––Reflections from Experiences in Distributed Environment” by Nilay Oza and co-authors report various reflections from real-world distributed projects where agile methods were implemented. They also present their stance on obstacles in implementing agile methods in industrial software projects in distributed environments. R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 226–227, 2009. © Springer-Verlag Berlin Heidelberg 2009

Preface

227

Despite the fact that global software development (GSD) is steadily becoming the standard engineering mode in the software industry, commercial projects still struggle with how to effectively manage it. In the paper “On the Use of Handover Checkpoints to Manage the Global Software Development Process,” Frank Salger discusses typical management problems in GSD, and describes how handover checkpoints are used at Capgemini to control and safely manage large GSD projects. “Exploiting Process Knowledge for Event Processing in Distributed Business Applications” by Holger Ziekow addresses event processing for applications in distributed business processes. For this application context an approach for improving in-network processing of events is presented. The role of a priori process knowledge for query optimization is highlighted and distributed event processing based on decision points in the process is illustrated. In their paper “Distributed Information System Development: Review of Some Management Issues” Alok Mishra and Deepti Mishra review significant management, issues such as process and project management, requirements management and knowledge management, which have received much attention from a distributed information system development perspective. The authors have observed that areas like quality and risk management issues can get only scant attention in distributed information system development and implementation.

Alok Mishra Deepti Mishra Ozlem Albayrak

Systematic Task Allocation Evaluation in Distributed Software Development Jürgen Münch1 and Ansgar Lamersdorf2 1

Fraunhofer IESE, Fraunhofer Platz 1, 67663 Kaiserslautern, Germany [email protected] 2 University of Kaiserslautern, Gottlieb-Daimler-Str., 67653 Kaiserslautern, Germany [email protected]

Systematic task allocation to different development sites in global software development projects can open business and engineering perspectives and help to reduce risks and problems inherent in distributed development. Relying only on a single evaluation criterion such as development cost when distributing tasks to development sites has shown to be very risky and often does not lead to successful solutions in the long run. Task allocation in global software projects is challenging due to a multitude of impact factors and constraints. Systematic allocation decisions require the ability to evaluate and compare task allocation alternatives and to effectively establish customized task allocation practices in an organization. In this article, we present a customizable process for task allocation evaluation that is based on results from a systematic interview study with practitioners. In this process, the relevant criteria for evaluating task allocation alternatives are derived by applying principles from goal-oriented measurement. In addition, the customization of the process is demonstrated, related work and limitations are sketched, and an outlook on future work is given.

1 Introduction Global Software Development (GSD) has become reality in many software development organizations, due to its promising benefits such as decreased labor costs and access to a worldwide pool of resources [1]. However, its inherent risks and complexity increase the difficulty and failure rate of GSD compared to single-site development [2]. The allocation of tasks, in particular (i.e., the decision on how to structure a GSD project and assign the work to different locations throughout the world), has a large impact on the success of distributed development projects and is influenced by several different criteria ([3], [4]). The authors hypothesize that, on the one hand, “smart globalization” (i.e., distributing work based upon systematic consideration of relevant criteria) can be the basis for many business and engineering prospects in GSD. On the other hand, omitting systematic evaluation of alternatives or having only one decision criterion (e.g., labor cost rates [5]) largely increases the risks of GSD. We thus see a need for the systematic selection and evaluation of task allocation alternatives. This article presents an approach for systematically evaluating task allocations in GSD. As the criteria and factors influencing evaluation are very much dependent on R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 228–237, 2009. © Springer-Verlag Berlin Heidelberg 2009

Systematic Task Allocation Evaluation in Distributed Software Development

229

the organization, we do not give a specific model but instead discuss a series of logical steps. They are based on principles from the Goal/Question/Metric (GQM) approach [6], a framework for the derivation of measures from goals (such as evaluation goals). GQM has been widely accepted and comes with a set of guidelines and sheets [7]. The article is structured as follows: First, the task allocation decision problem is explained in a specific scenario based on the results of an empirical study. Section 3 presents related work. The approach is presented together with its application on the given scenario. Finally, limitations and future work are sketched.

2 Scenario of a Task Allocation Decision Problem In this section, we present a scenario for a typical task allocation problem in global software development in order to highlight important challenges and constraints. The scenario is based on the results of a qualitative study the authors conducted in order to analyze the state of the practice in task allocation [3]. In the following, we will briefly summarize the relevant findings of this study and then introduce the scenario, which will be used as an example throughout the remainder of this article. Empirical Basis for the Scenario. We conducted a systematic interview study with 12 practitioners from different companies with several years of experience in distributed and global development [3]. The main goal of the study was to identify the industrial practice in task allocation, especially with respect to the criteria applied. Thus, the interviewees were asked to name the general background of distributed development at their company and to describe in detail the task allocation process and the applied criteria for one specific past project. The main result was that the strategy for task allocation very much depends on the type of distributed development (see Figure 1): While in software development outsourcing, large pieces of work (e.g., complete projects or products to be developed) are usually assigned to outside contractors, task assignment in captive offshoring (i.e., within one organization that has globally distributed sites) is done on a much finer level of granularity. Captive offshoring can be further classified into development of standard software (e.g., shrink-wrapped software) and project-based development of custom software for individual clients. We found that in standard software development, assignment is largely done based on specialized teams that evolve over a long time. In custom software development, however, there is larger freedom in the assignment, and tasks are mostly allocated by availability of resources only.

Fig. 1. Types of distributed development

230

J. Münch and A. Lamersdorf

The study also revealed the importance of cost rates as a driving force for GSD. Low labor cost rates were the most prominent criterion both for initiating global development and establishing new sites: New sites were built in low-cost regions in order to leverage labor costs. In custom development projects, there is also often pressure towards assigning more work to the low-cost sites, if possible. Out of the three identified types, we will focus on the development of custom software due to several reasons: On the one hand, the task allocation decision is highly complex, since there is a large degree of freedom in assigning work to sites and multiple influencing factors (e.g., cost rate, expertise, proximity to customer) have to be considered. On the other hand, in practice task assignment is typically unsystematic, based just on availability and cost rates. We thus see a high potential here for avoiding or reducing development risks as well as many opportunities for gaining benefits from distributed development. Another finding of the study was that in many cases of custom software development, the requirements and the coarse architecture are derived at a central site, followed by the assignment of development work to the available sites. This means that task allocation in these cases is an assignment of the development of coarse architectural components to sites. In the following scenario, we will use this as a basis for the description of the tasks to be assigned. Task Allocation Scenario. In order to illustrate the scenario, we introduce the “GlobalSoft” project as an exemplary case of custom software development in GSD. Even though it does not specifically reflect one of the projects described in the interview study, it is based on the experiences reported there. GlobalSoft is a large, Europe-based software company that develops individual software products for customers in Germany and the UK. Its main development centers are located in Frankfurt and Cologne, Germany, and a smaller subsidiary also exists in London, UK, in order to have a site close to the British customers. Recently the company also established a site in Bangalore, India, in order to reduce labor costs and gain access to a large pool of software engineers. Figure 2 gives an overview of the available sites together with the labor cost rates per site. In our scenario, GlobalSoft is developing new software for one of its customers, BigIndustries. BigIndustries is located in London and is well known to GlobalSoft due to a set of previously conducted projects. The old projects were always done at the sites in London, Frankfurt, and Cologne. In this new project, there is also the possibility of assigning work to the new development center in Bangalore. At the time of the task allocation decision, requirements engineering and high-level architecture design have already been done at the sites in London and Frankfurt. Project management (located in Frankfurt) now has to decide how to assign the development of the identified architectural components to the sites. In addition, system testing and integration have to be assigned, too. Figure 3 shows the resulting tasks that are to be assigned together with the expected effort distribution. As the high-level architecture already exists, it is also possible to estimate the expected coupling between the components. In the scenario, we assume that the coupling of the components is an indicator for the communication needed between sites [8].

Systematic Task Allocation Evaluation in Distributed Software Development

231

- PM - Architecture 150 km

GS Frankfurt

GS Cologne

Average Cost per PM (in € €) 600 km 1 hour time shift

7500 km 3,5 hour time shift

BI HQ 20 km

GS London

GS Bangalore 8000 km 4,5 hour time shift

London

7500

Frankfurt

6000

Cologne

6000

Bangalore

3000

- RE

Fig. 2. Available Sites Comp 1

Effort distribution

1 2

Comp 2

3

Comp 3

Comp 4

System Test

5 2

Comp 5

Integration

n

Coupling Index, e.g. Fan-in + Fan-out

Comp 1

15%

Comp 2

10%

Comp 3

10%

Comp 4

30%

Comp 5

10%

System testing

15%

Integration

10%

Fig. 3. Tasks together with the coupling between components

The problem faced by the project management is now to find an assignment of these tasks to sites that fits best with the concrete project environment and goals. This means that it must be possible to evaluate and compare the assignment of certain tasks to India versus the traditional assignment of all work to the sites in Europe. This decision has to be made with respect to a large set of influencing factors (such as the expertise available at the sites and their physical and cultural distance).

3 Related Work In the following section, existing models and approaches for selecting and evaluating alternatives are briefly introduced, following by a short discussion of the applicability of each approach. Approaches for decision support in task allocation can be classified into two groups: Optimization approaches that aim at identifying the best task assignment with respect to some goal function and predictive approaches that try to assess one specific assignment and thus can help to evaluate different assignment alternatives. Mockus and Weiss [9] present an optimization algorithm for assigning work (chunks of modules) to sites that minimizes the communication need between the sites and thus minimizes the inherent overhead of distributed development. This model is clearly defined and easily applicable, but it focuses on only one criterion. In the given scenario, this is only of limited use, as it would neglect many important influencing factors such as the capability or cost rate at the different sites. Another optimization approach was presented by Lamersdorf et al. [4]. In contrast to the previous approach, the focus here was placed on supporting various and

232

J. Münch and A. Lamersdorf

conflicting criteria and on finding task assignment suggestions under conditions of uncertainty. However, this approach focuses much on the algorithmic identification of task assignments. A standard causal model of influencing factors and their impact on the decision was derived empirically but a process for customizing the model for a specific organization has not yet been defined. Evaluation models focus on the influencing factors and their impact on one specific assignment rather than on the algorithmic identification of best assignments. Often, this is done by extending the COCOMO approach for effort estimation. Madachy [10], for instance, developed an extension of COCOMO that is able to describe sitedependent effort multipliers and thus model the impact of assigning work to specific sites. The effort multipliers, however, do not reflect the impact of distributed collaboration (e.g., physical, time-zone, or cultural distance). Keil et al. [11] address this issue by suggesting a set of new effort multipliers that explicitly consider the impact of distributed collaboration. But this approach only names a set of multipliers without justification and also does not quantify the impact. Another evaluation model is presented by Sooraj and Mohapatra [12], who developed an index for comparing different assignments with respect to multiple criteria. The model is based on empirical studies, but there is no explanation of how to customize the model to a specific environment and use it in this specific environment. In summary, the existing approaches do not or only insufficiently take into account that an evaluation model has to be tailored to a specific organization and thus do not address the problem of developing a company-specific evaluation approach.

4 An Approach for Systematic Task Allocation Evaluation In this section, we present an approach for systematically evaluating task allocation alternatives. It is based on the GQM approach for systematic and goal-driven measurement and evaluation and contains a set of logical steps that need to be performed for evaluating task assignments. In the following, an overview on the approach will be given first, followed by a description of each logical step. Approach Overview. When deciding on the allocation of tasks to sites within a GSD project, decision makers are confronted with the problem of evaluating task allocations: Based on the evaluation and comparison of possible alternatives, their task is to identify the assignment which is most suitable for the specific project situation. The problem of task allocation can thus be reduced to finding a systematic evaluation of task alternatives with respect to the project goals and the project constraints. The approach presented here aims at highlighting the steps that have to be performed in order to arrive at a systematic evaluation. Particularly, the factors influencing a decision and their relative weight have to be determined individually for every project. The goals of the approach can thus be described as follows: Goal 1: Identify the project-specific influencing factors for a task allocation decision and their impact. Goal 2: Evaluate the possible task allocation alternatives according to the projectspecific influencing factors.

Systematic Task Allocation Evaluation in Distributed Software Development

1. Define Viewpoint: • Decision maker

2. Define Context: • Project characteristics • Task, Sites • Constraints

Object: Purpose: Quality F: Task Evaluation Project Allocation goals

Viewpoint: Context:

Quality focus

Variation factors

Baseline hypothesis

Impact on baseline

8. Evaluate Assignments: • Manually or (semi-) automated

7. Assess Variation Factors: • Estimate values for every factor at the current project

233

3. Define Focus: • Project goals • Evaluation criteria

4. Define Variation Factors: • GSD factors that impact goals • E.g., time zones, cultural difference, turnover rate 5. Define Baseline: • What would be the expected project results under collocated development? 6. Define Impact of Variation Factors: • Formulas or expert estimations

Fig. 4. GQM abstraction sheet together with process overview

The approach is formulated as a set of logical steps that are based on GQM. Particularly, the GQM abstraction sheet [7] is used as a means for finding the relevant influencing factors for a specific evaluation goal. An overview of the abstraction sheet and the related process steps is given in Figure 4. The evaluation, specified according to the GQM goal template [7], is: “Analyze the task allocation for the purpose of evaluation with respect to the project goals from the viewpoint of […] in the context of […]”. Based on this goal and the project-specific context and viewpoint, our approach aims at identifying the measures for project success, a baseline for the evaluation, relevant influencing factors of distributed development, and the impact of the variation factors on project success. Depending on the maturity of the organization and the availability of data, the process steps can be supported by repositories and/or decision models. For example, a company might possess an experience base of organization-wide influence factors together with data on their impact. In this case, the project-specific selection of influencing factors would consist of selecting the relevant factors from the organizational repository. Process Steps. In the following, we will list all steps of the evaluation process together with its application in the previously defined scenario. 1. Define Viewpoint: At first, the viewpoint of the decision (i.e., the decision maker) must be identified. This is the person responsible for the decision and the one who has the relevant information about the context of the allocation decision. Scenario: At GlobalSoft, the task allocation decision is made by the responsible project manager. As he was also in charge of previous projects with BigIndustries, he knows the project and the involved participants very well. 2. Define Context: The context of the project comprises the characterization of the available sites (and their relations such as time-zone distances), the distribution of

234

J. Münch and A. Lamersdorf

work to different tasks, and constraints on the task allocation decision (i.e., already assigned tasks). It thus defines the input for the task allocation decision. Scenario: The context of the project, the tasks, and the sites were already described in Section 2. 3. Define Focus: The focus of the evaluation is on the project goals. Now, these goals have to be specified further: Which criteria define project success (e.g., cost, quality)? The different possible assignments will later be evaluated with respect to these criteria. If possible, the measures should be quantifiable. If different measures are named, a strategy for weighting them against each other should also be defined (e.g., if assignment A results in higher cost and higher quality compared to assignment B, which is rated as being suited better with respect to the goals and the given context?). Scenario: In order to simplify the scenario, the total development costs are selected as the only criterion in the quality focus: The assignment with the lowest expected development costs is to be selected. However, in contrast to many approaches in practice, hourly cost rates are not the only issue that is regarded. Instead, the evaluation focus is on a realistic estimation of development costs, which also includes an estimation of the individual productivity at each site (which is determined by both site-specific factors and the overhead due to communication across sites). 4. Define Variation Factors: Variation factors are all those factors that have an allocation-dependent influence on the evaluation criteria. For example, if developer experience differed between sites, then assigning more work to the experienced sites would probably decrease effort. Given that effort is an evaluation criterion, developer experience would therefore be a variation factor (because its impact on effort would be dependent on the question of which tasks are assigned to the experienced or inexperienced sites). We categorize variation factors into (a) characteristics of sites (e.g., cost rate, experience), (b) dependencies between sites (e.g., time-zone differences), (c) characteristics of tasks (e.g., size), (d) dependencies between tasks (e.g., coupling), and (e) task-site dependencies (e.g., the knowledge for performing task X existing at site Y). Scenario: Based on the COCOMO II [13] effort multipliers and our own expert opinions, the following variation factors were identified: (a) (b) (c) (d) (e)

Site characteristics: Analyst capability, programmer capability, language and tool experience, personnel continuity, customer proximity Site dependencies: Cultural difference, time-zone difference Task characteristics: Size Task dependencies: Coupling Task-site dependencies: Application experience, platform experience

5. Define Baseline: The goal of this process step is to derive a baseline for the success measures. Depending on the overall goal (i.e., establishing distributed development vs. modifying a distributed task assignment) and available knowledge, the baseline can reflect collocated development (all work would be assigned to one site) or an already established assignment (work would be assigned as in previous projects). The baseline may, for instance, be determined by expert estimations, historical project data, or using standard prediction models.

Systematic Task Allocation Evaluation in Distributed Software Development

235

Scenario: At GlobalSoft, effort is estimated using COCOMO II. For baseline estimation, all site-dependent factors are set to the optimal case. Based on known project characteristics and the COCOMO formula, the baseline effort is estimated at 172 person-months, which are then distributed across the tasks according to the effort distribution given in Figure 3. 6. Define Impact of Variation Factors: In this process step, the impact of every variation factor (defined in step 4) on every criterion in the focus (defined in step 3) is evaluated. This can be done with the help of expert estimations or by analyzing past projects. For example, if effort is in the evaluation focus and time-zone difference was defined as a variation factor, the step should answer the question “How does a certain time-zone difference between two sites affect the effort overhead for tasks assigned to these sites?” If possible, this should be done quantitatively. Scenario: GlobalSoft chose to use the CoBRA® approach [14] for cost estimation. This method provides a way for describing a causal model with influencing factors on development effort. Figure 5 shows the derived causal model. The quantification of the impact was done by experienced project managers at GlobalSoft. As the complete model is quantified, it is implemented in MS Excel. 7. Assess Variation Factors: For all tasks and sites identified in step 2, the values of the variation factors are now assessed for the project at hand. Scenario: The project manager assesses all values and inserts them into the Excel model. 8. Evaluate Assignment Alternative: Finally, every possible assignment can now be evaluated using the results of the previous steps. Depending on whether quality focus and impact of variation factors were described quantitatively or not, the evaluation can now provide predictions or guidelines and hints for every assignment that is of interest. Scenario: The project manager investigates three alternatives: Assigning all work within Europe, assigning system testing and component 4 to India, and assigning everything to India. He is now able to evaluate all of them. The results show (Table 4) that assigning all work within Europe would lead to the lowest effort. Assigning parts of the work to India leads to the lowest development costs (but the difference is not very large due to the decrease in productivity). However, assigning all work to India would again increase the total costs because of the large additional effort. Based on the results, it is decided to assign component 4 and system testing to India. Programmer capability

Analyst capability

Language & tool experience

Cultural difference

-

-

-

Personnel continuity Application experience

+ +

Effort -

-

Task coupling +

Customer proximity

Platform experience

Time-zone difference

Fig. 5. Causal model for impact of variation factors

236

J. Münch and A. Lamersdorf

Table 1. Result of the assessment: Impact on effort (person-months) and cost (in 1000 euros) Comp 1

Comp 2

Comp 3

Comp 4

Comp 5

System Test

Integration

Total

PM

Cost

PM

Cost

PM

Cost

PM

Cost

PM

Cost

PM

Cost

PM

Cost

PM

Cost

All in Europe

75

451

40

237

55

328

176

1058

43

258

84

626

38

283

510

3241

Comp 4, Testing: India

77

464

41

243

56

337

272

816

49

292

179

536

40

299

713

2987

All in India

147

440

109

328

131

393

226

679

113

338

146

437

136

408

1007 3022

5 Conclusion and Future Work In this article, we presented a series of logical steps that have to be performed in order to systematically evaluate possible task allocation alternatives. The steps are described on a very high level and thus have to be instantiated individually for every organization. However, as they focus on the development of an organization-specific approach for task allocation evaluation and selection, they go beyond the approaches in the literature, which typically present a rigid model for task allocation without dealing with adaptation to company-specific needs. The instantiation of the process was done in a very optimistic scenario: All necessary information about the relevant influencing factors and their impact was available in a quantitative form, which made it possible to develop a specific quantitative model and thus exactly quantify the results of every task allocation alternative. The selection of total development costs as the only evaluation criterion also increased the ability to quantify the model (but might not be realistic in industry). In reality, however, the available knowledge is not always as detailed and quantifiable as shown here. In this case, the process steps have to be instantiated in a different way, for example by formulating qualitative rules or guidelines on the impact of certain factors. Another limitation of the approach is that it assumes a relatively high degree of freedom in the task allocation decision regarding a specific project. In reality, however, the decision is often predefined due to specializations (especially in standard software development) and long-term strategic goals of higher management. Still, in many cases a systematic evaluation of alternatives (as presented here) promises to result in higher project success than unsubstantiated task allocation decisions focusing on cost rates only (while neglecting the impact of distribution on productivity). In future work, we plan to apply the process steps to a real industrial global software development project in order to evaluate the approach. Based on the results, future work will also have to develop a more detailed process for evaluation and support it with tools and experience bases. As discussed in Section 3, task allocation decision support can be seen as support for evaluating alternatives (as presented here) or as algorithmic identification of assignments. If the set of possible assignments grows over a certain size, it might not be practical to evaluate all assignments manually. We developed TAMRI, a model and tool for providing decision support in this case [4]. In future work, we plan to combine the two approaches by developing a method for project-specific task allocation evaluation and, based upon it, an algorithm for suggesting possible task assignments.

Systematic Task Allocation Evaluation in Distributed Software Development

237

References [1] Damian, D., Moitra, D.: Global Software Development: How Far Have We Come? IEEE Software 23(5), 17–19 (2006) [2] Seshagiri, G.: GSD: Not a Business Necessity, but a March of Folly. IEEE Software 23(5), 63 (2006) [3] Lamersdorf, A., Münch, J., Rombach, D.: A Survey on the State of the Practice in Distributed Software Development: Criteria for Task Allocation. In: International Conference on Global Software Engineering, ICGSE 2009, Limerick, Ireland (2009) [4] Lamersdorf, A., Münch, J., Rombach, D.: A Decision Model for Supporting Task Allocation Processes in Global Software Development. In: International Conference on Product Focused Software Development and Process Improvement, PROFES 2009 (2009) [5] Bass, M., Paulish, D.: Global Software Development Process Research at Siemens. In: Third International Workshop on Global Software Development, ICSE 2004 (2004) [6] Basili, V., Weiss, D.: A Methodology for Collecting Valid Software Engineering Data. IEEE Transactions on Software Engineering 10(3), 728–738 (1984) [7] Briand, L.C., Differding, C.M., Rombach, H.D.: Practical Guidelines for MeasurementBased Process Improvement. Software Process – Improvement and Practice 2(4), 253– 280 (1996) [8] Avritzer, A., Paulish, D., Cai, Y.: Coordination Implications of Software Architecture in a Global Software Development Project. In: Seventh Working IEEE/IFIP Conference on Software Architecture, WICSA 2008 (2008) [9] Mockus, A., Weiss, D.M.: Globalization by Chunking: A Quantitative Approach. IEEE Software 18(2) (March 2001) [10] Madachy, R.: Distributed Global Development Parametric Cost Modeling. In: Wang, Q., Pfahl, D., Raffo, D.M. (eds.) ICSP 2007. LNCS, vol. 4470, pp. 159–168. Springer, Heidelberg (2007) [11] Keil, P., Paulish, D.J., Sangwan, R.: Cost Estimation for Global Software Development. In: International workshop on Economics Driven Software Engineering, Shanghai, China, pp. 7–10 (2006) [12] Sooraj, P., Mohapatra, P.K.J.: Developing an Inter-site Coordination Index for Global Software Development. In: International Conference on global Software Engineering, ICGSE 2008 (2008) [13] Boehm, B., Abts, C., Brown, A., Chulani, S., Clark, B., Horowitz, E., Madachy, R., Reifer, D., Steece, B.: Software Cost Estimation with COCOMO II. Prentice-Hall, Englewood Cliffs (2000) [14] Briand, L.C., El Emam, K., Bomarius, F.: COBRA: A Hybrid Method for Software Cost Estimation, Benchmarking, and Risk Assessment. In: International Conference on Software Engineering (1998)

Extending Global Tool Integration Environment towards Lifecycle Management Jukka Kääriäinen1, Juho Eskeli1, Susanna Teppola1, Antti Välimäki2, Pekka Tuuttila3, and Markus Piippola4 1 VTT, Oulu, Finland [email protected], [email protected], [email protected] 2 Metso Automation Inc, Tampere, Finland [email protected] 3 Nokia Siemens Networks, Oulu, Finland [email protected] 4 Espotel, Oulu, Finland [email protected]

Abstract. Development and verification of complex systems requires close collaboration between different disciplines and specialists operating in a global development environment with various tools and product data storage. Fluent integration of the tools and databases facilitate a productive development environment by enabling the user to easily launch tools and transfer information between the disconnected databases and tools. The concept of Application Lifecycle Management (ALM) was established to indicate the coordination of activities and the management of artefacts during the software product’s lifecycle. This paper presents the analysis of an open source global tool integration environment called ToolChain, and proposes improvement ideas for it towards application lifecycle management. The demonstration of ToolChain and the collection of improvement proposals were carried out in the telecommunication industry. The analysis was made using the ALM framework and Global Software Development (GSD) patterns developed in previous studies in the automation industry. Keywords: Tool integration, Application Lifecycle Management, Lifecycle Management, Eclipse.

1 Introduction Development and verification of complex systems requires close collaboration between different disciplines and specialists. For example, product managers, architects, developers, project managers and testers produce different kinds of information during product development, such as abstractions from a product, project management data and testing/analysis data. Typically, products are simply too complex to represent only one single type of representation and are thus often described at multiple levels of abstraction [1]. For instance, SW can be presented R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 238–247, 2009. © Springer-Verlag Berlin Heidelberg 2009

Extending Global Tool Integration Environment towards Lifecycle Management

239

using abstractions, such as requirements, design, source code and object code. Therefore, the development of multidisciplinary products is supported with various development and product information management systems, for example, Requirements Management tools, Configuration Management tools, Development tools, Testing tools, Test Data databases, etc. These systems are targeted for certain development lifecycle phases. The lifecycle artefacts from the systems should be interlinked in product information management databases in order to support, for example, reporting of lifecycle artefacts like testing coverage of requirements. Usually preserving the consistency of data would require integrations between existing systems. The need for integration of various product information management systems has been discussed, e.g. in [2] and [3]. Instead of copying the product data from one database to another, it is more reasonable to use item identifiers (IDs) to compose traceability information and then to use this traceability information for retrieving up-to-date information from the source database, for example, for reporting purposes. One of the responses to the challenges in the development lifecycle is the rise of the so called Application Lifecycle Management (ALM) solutions. The roots of ALM are in Configuration Management (CM) and therefore CM systems are usually the foundations of ALM solutions [4]. In this paper our study of ALM is especially focused on the development phase of the SW lifecycle. One of the roles of ALM is to store artefacts produced in the different stages of the development process. These artefacts can be associated with each other, communicated to the relevant stakeholders and relevant real-time reports can be generated from this data to support product development and administration. Because SW development tends to be a global activity nowadays, ALM aims to support global software development with information visibility and consistency in projects. Therefore, in practice, an ALM solution may become a complicated development environment that integrates different kinds of global product information management databases. In our previous industrial studies in the automation industry [5] we discovered that ALM can be supported with a dedicated ALM suite or by integrating a set of proprietary product information management databases. This paper presents the results of the ToolChain analysis and its demonstration in a telecommunication company. ToolChain is a Proof-of-Concept tool integration solution [6]. The aim of the solution, besides product information transparency, is to improve the traceability of information during global software development. The implementation of ToolChain is composed of a set of Eclipse plug-ins. Eclipse is a well-known platform for tool integration. For instance, Yang & Jiang [7] present a summary of experiences of the use of open Eclipse tool integration framework. In the article, they discuss the benefits and also challenges encountered while integrating tools specific to different lifecycle development phases. The basic intention of ToolChain is to provide an overall frame for traceability and project data visibility where different kinds of tools, especially Open Source tools and databases, can be connected as needed. In its current version, ToolChain has been extended to provide support for test data management, test analysis and simple workflow guidance [6]. The aim of the research is to apply an ALM framework and GSD patterns for analysing a tool integration environment. The analysis clarifies how the current ToolChain version supports ALM features in a global development environment.

240

J. Kääriäinen et al.

Furthermore, it proposes improvement ideas for future development and research related to tool integration environments towards ALM for GSD. This paper is organised as follows: The next section introduces demonstration settings comprising an ALM framework, GSD pattern language and the research process of demonstration. Then we introduce the results of the ToolChain analysis and demonstration. In section four we discuss the results of this research. Finally, section five concludes the paper.

2 Demonstration This section introduces the analysis frameworks used in ToolChain analysis, the setting of ToolChain demonstration and methods used for experience collection from the demonstration project. 2.1 ALM Framework and ALM Related GSD Patterns In our studies, the need to better understand the elements of ALM in order to support the development of ALM in an organization has emerged [8, 9, 5]. In these studies we developed a framework consisting of six principal elements that characterize ALM. This framework can be used for documenting and analyzing organizations ALM solution and thus to support the practical development of ALM in an organization. This framework was constructed and successfully applied in an automation company to support its ALM documentation and improvement efforts. The current framework version contains six elements [5] as presented in Figure 1. Application Application Lifecycle LifecycleManagement Management Release Release

Maintenance Maintenance

verification InIntegration tegration && verificat io n

Design Design

Coding anduunit testing Co ding and nit test in g

Project manager

Req uirements def inition Requirement s definit ion

Product manager

Developer

Communication

Project management Requirement s management Configuration management

Traceability Traceability Reporting Report ing Process Process support, support,tool toolintegration int egrat ion

Tester

Reporting of lifecycle artefacts Traceability of lifecycle artefacts Creation and management of lifecycle artefacts

Process support

Tool integration

Ar chitec t

Fig. 1. Principal elements of Application Lifecycle Management [5]

“Creation and management of lifecycle artefacts” is the foundation for ALM. The product information collected and managed by this element is needed, for instance, for traceability and reporting activities. “Traceability of lifecycle artefacts” provides a means to identify and maintain relationships between managed lifecycle artefacts and, therefore, facilitates reporting, change impact analysis and information visibility throughout the development lifecycle. “Reporting of lifecycle artefacts” utilises managed lifecycle artefacts and traceability information to generate needed reports from the lifecycle product information to support SW development and management. “Communication” provides communication tools (e.g. chat) as well as channels for

Extending Global Tool Integration Environment towards Lifecycle Management

241

Table 1. Mapping between ALM elements and related GSD patterns ALM elements

Related GSD patterns

Creation and management of lifecycle artefacts

Common Repositories and Tools (ID 07)

Traceability of lifecycle artefacts Reporting of lifecycle artefacts

Common Repositories and Tools (ID 07) Common Repositories and Tools (ID 07) Common Repositories and Tools (ID 07)

Communication

Communication Tools (ID 06) Common Repositories and Tools (ID 07)

Process support

Tool integration

Use Common Processes (ID 12) Common Repositories and Tools (ID 07)

How GSD patterns cover ALM elements Global databases to support the management and visibility of lifecycle artefacts. Traceability of lifecycle artefacts in GSD environment. Reporting of lifecycle artefacts and traces in GSD environment. Asynchronous communication (visibility of lifecycle artefacts) Synchronous/asynchronous communication tools (e.g. net meeting, chat, conference phone, discussion forum) Process support features such as state models, workflows or process templates. Common upper level GSD process and ability to tailor the process support for a project or a team on site level. In practice, common repository can be a single central database or several integrated databases.

distributing information about product lifecycle artefacts, links and reports and thus facilitates product information visibility for the whole SW project. “Process support” and “Tool integration” are the elements that are used to configure the ALM solution to support SW development procedures, guide the user through development activities and to facilitate a productive development environment by enabling the user to easily launch tools and transfer information between different tools and databases. ALM support for Global Software Development can be analysed by using GSD for Project Management Pattern Language [10]. This GSD Pattern Language includes 18 process patterns which have been found to be important in the area of project management in GSD. If these GSD patterns are compared to ALM elements, it can be noted that some patterns relate to ALM elements [10] (Table 1). Patterns named “Communication Tools” and “Common Repositories and Tools” relate to ALM elements. Furthermore, “Use Common Processes” relates to an ALM element called “Process support”. Some other patterns relate indirectly to ALM elements. For instance, an “Iteration planning” pattern uses “Communication Tools” and “Common Repositories and Tools” patterns to support synchronous communication and information visibility during the planning meeting. 2.2 ToolChain Demonstration in the Telecommunication Industry The ALM features of ToolChain (Figure 2) were analysed by using an ALM framework (for ALM framework see the previous section). The results of the analysis are presented in section 3. ToolChain was demonstrated in a telecommunication company. The solution was introduced to the members of the demonstration group. One person from the company was responsible for the set-up of the ToolChain for their IT-environment. Two of the persons demonstrated the solution in the company.

242

J. Kääriäinen et al.

The following figure 3 shows the activities that are covered by the current version of ToolChain. It further enumerates the plug-ins that exist in the current toolbox and presents the traceability model of the ToolChain traceability database. The demonstration was set-up as follows:

Fig. 2. ToolChain screenshot with MVA (MultiVariate Analysis) tool launched with test dataset Configuration management (CM): Subversion Requirement management (RM): Open Source Requiremens Management tool (OSRMT), RequisitePro, Telelogic DOORS Feature

Task

Item Eclipse / ToolChain

Unique identifier 1:N

Unique identifier

Project management (PM): TRAC, Microsoft project, Open workbench

Unique identifier

1:N

1:N

Test management (TM): TestLink Test Case

Unique identifier Test data

1:N

Unique identifier 1:N

Analysis & Simulation results

Test Data management (TDM): TestAnalysis (TA): MultiVariate Analysis tool, Probe database Performance visualization and simulation tool

Fig. 3. ToolChain tools, items and traceability model

Demonstration project: The aim of the demonstration project was to measure the performance of the Espotel JiVe platform’s Ethernet connection. Espotel JiVe is a portable platform with a touch screen and several interfaces [11]. It is also a product that can be tailored to customer specifications and brand. Furthermore, the target of the demonstration project was to study the applicability of ToolChain with test data management and analysis features. The demonstration project defined performance requirements with OSRMT-tool (Open Source Requirements Management Tool) and related testing tasks with Trac-tool. The tasks were associated with the requirements in ToolChain. Test cases were defined with TestLink and associated in ToolChain

Extending Global Tool Integration Environment towards Lifecycle Management

243

with the requirements. The tests were run on the JiVe platform and test data was collected, processed and further imported into ProbeDB [12]. The test data was associated with the corresponding test case in ToolChain. Test analysis parameters were defined in ToolChain. MultiVariate Analysis tool [13] was launched with the selected ProbeDB dataset and appropriate parameters from ToolChain (e.g. check how varying of packet/s & frame size affects packet loss on the target platform). The results of the MVA analysis have been given to Espotel and they can be used in future JiVe platform optimisation projects. ToolChain set-up: ToolChain was used with the following set-up: • • • • • •

Requirements Management: OSRMT (Open Source Management Tool) Project Management: Trac Test Management: TestLink Test Data Management: Probe database (ProbeDB) Test Analysis: MultiVariate Analysis (MVA) Configuration Management (CM): Subversion

Requirements

Data collection: The experience data from the usage of ToolChain was collected via a questionnaire. The questions were chosen based on the ToolChain tools and ALM framework elements. A comment field was included in the questionnaire where respondents could also give general comments about the solution and other improvement proposals. Furthermore, the results of the questionnaire were presented, discussed and complemented in a workshop session. In this session we discussed the results and clarified issues that were unclear after the questionnaire. Industrial participants in the workshop session represented specialists in SW development and testing and software process improvement (SPI). The summary of results of the questionnaire and the workshop session are presented in this paper. Results were reviewed by the demonstration group members and workshop participants.

3 Results We analysed the ToolChain prototype with an ALM framework (Table 2) and collected experiences from ToolChain demonstration (Table 3) using the framework. The current version of ToolChain is a proof-of-concept showing that product development can be supported with test data management and analysis in an integrated development environment. However, different organisations and projects tend to have different needs for development and management tools. Therefore, the ToolChain concept should be refined so that it could be easily adapted into the context of an organisation or project where the needs for ALM features can vary (e.g. tool integrations, traceability needs, reports, development methods). During the workshop session workflow support was identified as an important improvement issue that needs more research. Originally, ToolChain was developed to support especially global software development. Therefore, current extensions have been technically designed so that they support data visibility and traceability also for distributed development teams. If

244

J. Kääriäinen et al. Table 2. Summary of ToolChain features according to an ALM framework

ALM elements Creation and management of lifecycle artefacts Traceability of lifecycle artefacts

Reporting of lifecycle artefacts Communication

Process support

Tool integration

ToolChain features Tools available for creation and management of lifecycle artefacts. For each development phase, tools and lifecycle items are listed in Figure 3. Development lifecycle activities covered are: Requirements Management, Project Management, Test Management, Test Data Management, Test Analysis, CM. Traceability is implemented by using a traceability database (MySQL/JDBC database) where the configuration item IDs and links between the IDs are used to store the traceability information. ToolChain uses Drag-and-Drop functionality for traceability collection. Item IDs are stored in traceability database and any other information related to items in the traceability view is retrieved from up-to-date tool databases. Therefore, possible information inconsistencies are avoided. Figure 3 presents the traceability model of the ToolChain. ToolChain does not contain reporting features yet. However, good potential for this feature since previous two features are covered and thus provides possibility to use lifecycle and traceability data for reporting purposes. Communication is supported through information visibility in ToolChain user interface for project members (Figure 2) (asynchronous). There are no communication tools integrated into ToolChain (synchronous (e.g. chat, Internet phone) or asynchronous (e.g. discussion forums). Each tool in ToolChain has its own features for process support. Usually items have some kind of state transition model that support the operation according to defined procedures. ToolChain also contains modifiable textual workflow guidance implemented with CheatSheets (see Figure 2) that guides the user through the development process. However, there are no process templates that could be used to configure the tool environment to support different development processes. A number of tools are integrated as plug-ins or interfaces in ToolChain (Figure 3). Therefore, it is possible to launch several tools from ToolChain environment and transfer data between the tools. However, it is not possible to launch all tools (standalone) from ToolChain.

Table 3. Summary of results from industrial demonstration ALM elements Creation and management of lifecycle artefacts Traceability of lifecycle artefacts Reporting lifecycle artefacts

of

Communication

+ (positive comment) Basically tools integrated ToolChain are easy to use.

in

Strength of the ToolChain. Traceability that usually happens on a “mental” level is supported by the ToolChain. No specific comments, since this feature is missing.

Common project traceability and status information can be seen from ToolChain environment.

- (what to improve) Support for test automation is missing. Tools have different user interfaces. This complicates the usage of the tool environment. Ability to compare test data from different development iterations is needed. Study the possibility to assign traces between test parameters and test data. Reporting would bring additional value to ToolChain. For example, report about requirements/features, related test cases, related test results and related analysis figures. The reports could be made visible through a Project Portal that would facilitate the real-time information visibility for the project. Communication means would bring additional value to ToolChain. E.g. chat for discussion or Project Portal as a forum for exchanging project information, searching information and storing experiences.

Extending Global Tool Integration Environment towards Lifecycle Management

245

Table 3. (continued) Process support

Workflow replaces traditional Help-files and tool instruction documents. Makes it easier for new users to start using the system

Tool integration

Important feature. Possibility to use/integrate different databases. Possibility to collect information from several databases into one view.

Now allows just textual descriptions. Support for e.g. pictures is needed to support new users. Workflow variants should exist for users with different skills (new user, advanced user). Harmonisation of user interfaces. Quick launch for all applications would increase the usability (launching stand-alone tools from ToolChain).

compared with key GSD patterns that relate to ALM elements [10], it can be noted that the current version of ToolChain provides only partial support for them. The GSD pattern, named “Communication Tools”, refers primarily to tools such as chat, discussion forum, teleconference, etc. ToolChain does not support this pattern since there are no communication tools integrated into the ToolChain environment. However, ToolChain provides moderate support for the GSD pattern “Common Repositories and Tools” as it supports all other pattern-related ALM elements except “Reporting of lifecycle artefacts”. However, the GSD pattern “Use Common Processes” is not supported since in the current version of ToolChain, the workflow feature is static and local, demonstrating a workflow description that is closer to helpfile that is embedded into Eclipse as a view. Therefore, the functionality of ToolChain needs to be extended to support a common GSD process and its local adaptations as described in “Use Common Processes” –pattern [10].

4 Discussion Yang & Jiang [7] argue that Eclipse is a cost-effective and productive development environment to support lifecycle software development. Our demonstration results showed that Eclipse-based ToolChain has many advantages during the development and testing process. A general positive comment related to the ToolChain’s ability to collect different tools and databases together that are needed during product development. The traceability that usually happens on a “mental” level is now facilitated with the ToolChain traceability feature. Crnkovic et al. [2] states that it is important that the use of many different tools does not introduce new complexity into the entire (development) process and that information is accessible in a smooth and uniform way. To support this, ToolChain targets provide easy access to interlinked information originated from different product information management databases through a central global traceability view. According to demonstration results, this was identified as a strength of the ToolChain. Negative ToolChain comments related to the number of different user interfaces that is quite confusing and therefore ToolChain should be able to somehow harmonise user interfaces from different tools. The lack of test automation support was defined as a critical deficiency. Furthermore, features that would provide additional value for stakeholders operating in a global development environment are missing. The results of demonstration, ALM analysis and GSD pattern analysis indicate that further extensions are needed, especially related to lifecycle reporting, synchronous communication and workflow support. ToolChain has a good basis for extensions towards lifecycle reporting since it

246

J. Kääriäinen et al.

contains good support for the ALM elements, “creation and management of lifecycle artefacts” and “traceability of lifecycle artefacts”, that have been identified as foundations for effective lifecycle reporting [5]. The concept of workflow was discussed during the workshop. Workflows and workflow management systems offer user-specific guidance and coordination enabling the person to perform his/her work tasks independently by using the help of a workflow system. According to the literature, there are several studies related to workflows, workflow applications and workflow management systems. A number of papers were written in the middle of the 90’s about workflow technology [14, 15, 16]. Based on the literature, it can be noted that the research area of workflows is wide. Despite that, there seems to be challenges. Many challenges relate to the functionality of workflow systems; workflow tools’ capabilities in supporting the performance of complex technical tasks are inadequate [14, 17, 18].

5 Conclusions This paper presents the analysis of an open source global tool integration environment, called ToolChain, and proposes improvement ideas for it towards application lifecycle management. The demonstration of ToolChain and the collection of improvement proposals were carried out in the telecommunication industry. The analysis was made by using an ALM framework and GSD patterns developed in previous studies in the automation industry. The results of this analysis can be used for further improvement of ToolChain towards features of lifecycle management in a global development environment. The study also showed that process support needs more research especially from a workflow point of view. The functionality and tool set of the ToolChain prototype has evolved gradually. The demonstration project and ToolChain analysis according to an ALM framework and GSD patterns show that the ToolChain prototype provides basic features such as storing and managing lifecycle artefacts as well as traceability issues. However, more advanced features that would provide additional value for stakeholders operating in a global development environment are missing. The results of demonstration and analysis indicate that further extensions are needed especially related to test automation, lifecycle reporting, synchronous communication and workflow support. Acknowledgements. This research has been done in ITEA projects named TWINS [19] and MERLIN [20]. This research is funded by Tekes, Espotel, Metso Automation, Nokia Siemens Networks and VTT. The authors would like to thank all contributors for their assistance and cooperation. This work is being supported by the Academy of Finland under grant 130685.

References 1. Van Den Hamer, P., Lepoeter, K.: Managing Design data: The Five Dimensions of CAD Frameworks, Configuration Management, and Product Data Management. Proceedings of the IEEE 84(1), 42–56 (1996) 2. Crnkovic, I., Asklund, U., Dahlqvist, A.: Implementing and Integrating Product Data Management and Software Configuration Management. Artech House, London (2003)

Extending Global Tool Integration Environment towards Lifecycle Management

247

3. Svensson, D.: Towards Product Structure Management in Heterogeneous Environments. In: Product and Production Development. Engineering and Industrial Design. Chalmers University of Technology, Göteborg (2003) 4. Schwaber, C.: The Expanding Purview Of Software Configuration Management. Forrester Research Inc., White paper (July 22, 2005) 5. Kääriäinen, J., Välimäki, A.: Applying Application Lifecycle Management for the Development of Complex Systems: Experiences from the Automation Industry. Accepted to EuroSPI 2009 conference (2009) 6. Eskeli, J.: Integrated Tool Support For Hardware Related Software Development. Master’s thesis, University of Oulu, Department of Electrical and Information Engineering, Oulu, Finland (2009) 7. Yang, Z., Jiang, M.: Using Eclipse as a Tool-Integration Platform for Software Development. IEEE Software 24(2), 87–89 (2007) 8. Kääriäinen, J., Välimäki, A.: Impact of Application Lifecycle Management – a Case Study. In: International Conference on Interoperability of Enterprise, Software and Applications (I-ESA), Berlin, German, March 25-28, pp. 55–67 (2008) 9. Kääriäinen, J., Välimäki, A.: Get a Grip on your Distributed Software Development with Application Lifecycle Management. Accepted to be published in International Journal of Computer Applications in Technology (IJCAT) (to be Publish, 2009) 10. Välimäki, A., Kääriäinen, J., Koskimies, K.: Global Software Development Patterns for Project Management. Accepted to EuroSPI 2009 conference (2009) 11. Espotel JiVe platform, http://www.espotel.fi/english/solutions_jive.htm (available 4.6.2009) 12. Vitikka, J.: Supporting Database Interface Development with Application Lifecycle Management Solution. Master’s thesis, University of Oulu, Department of Electrical and Information Engineering, Oulu, Finland (2008) 13. Tuuttila, P., Kanstrén, T.: Experiences in Using Principal Component Analysis for Testing and Analysing Complex System Behaviour. In: ICSSEA 2008 (Internation Conference on Software & Systems Engineering and their Applications), Paris, France (2008) 14. Georgakopoulos, D., Hornick, M.: An Overview of Workflow Management: From Process Modeling to Workflow Automation Infrastructure. Distributed and Parallel Databases 3, 119–153 (1995) 15. McReady, S.: There is more than one kind of Work-flow Software. Computer World (November 2, 1992) 16. Jablonski, S., Bussler, C.: Workflow management: Modelling Concepts, Architecture, and Implementation. International Thomson Computer Press (1996) 17. Tan, D., Wandke, H.: Process-Oriented User Support for Workflow Applications. In: Jacko, J. (ed.) HCI 2007. LNCS, vol. 4553, pp. 752–761. Springer, Heidelberg (2007) 18. Workflow Problem Space, http://wiki.fluidproject.org/display/fluid/ Workflow+Problem+Space (available 4.6.2009) 19. ITEA-TWINS project, Optimizing HW-SW Co-design flow for software intensive system development, http://www.twins-itea.org/ (available 4.6.2009) 20. ITEA-MERLIN project, Embedded Systems Engineering in Collaboration, http://www.merlinproject.org/ (available 4.6.2009)

Dynamic SLA Negotiation in Autonomic Federated Environments Pawel Rubach1,2 and Michael Sobolewski1 1

Computer Science, Texas Tech University, SORCER Research Group, Box 43104 Boston & 8th, Lubbock, TX 79409, USA {pawel.rubach, sobol}@sorcersoft.org 2 Business Informatics, Warsaw School of Economics, Al. Niepodleglosci 162, 02-554 Warszawa, Poland

Abstract. Federated computing environments offer requestors the ability to dynamically invoke services offered by collaborating providers in the virtual service network. Without an efficient resource management that includes Dynamic SLA Negotiation, however, the assignment of providers to customer’s requests cannot be optimized and cannot offer high reliability without relevant SLA guarantees. We propose a new SLA-based SERViceable Metacomputing Environment (SERVME) capable of matching providers based on QoS requirements and performing autonomic provisioning and deprovisioning of services according to dynamic requestor needs. This paper presents the SLA negotiation process that includes ondemand provisioning and uses an object-oriented SLA model for large-scale serviceoriented systems supported by SERVME. An initial reference implementation in the SORCER environment is also described. Keywords: SLA Negotiation, QoS, SLA, Metacomputing, Service-Oriented Architecture, SORCER.

1 Introduction Many research activities worldwide are focused on developing smart, selfmanageable systems that will allow applications to run smoothly and reliably in a distributed environment. IBM calls this Autonomic Computing [1]. The realization of this concept would enable the move towards Utility Computing – the long awaited vision where computing power would be available as a utility just like water or electricity is delivered to our homes today. One of the challenges in addressing this concept lies in the problem of guaranteeing a certain level of Quality of Service (QoS) to the customer for which he/she would be willing to pay. In this paper we address related issues by proposing the Dynamic SLA Negotiation process for the SERViceable Metacomputing Environment (SERVME)[2] which is based on the SORCER (Service-Oriented Computing EnviRonment) [3] environment extended by adding a QoS Management Framework. This paper presents the SLA negotiation process including the on-demand provisioning of services and briefly describes the architecture of the federated P2P environment. SORCER provides a way of creating service-oriented programs and executing them in a metacomputing environment. The service-oriented paradigm is a distributed R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 248–258, 2009. © Springer-Verlag Berlin Heidelberg 2009

Dynamic SLA Negotiation in Autonomic Federated Environments

249

computing concept wherein objects across the network play their predefined roles as service providers. Service requestors can access these providers by passing messages called service exertions. An exertion defines how the service providers federate among themselves to supply the requestor with a required service collaboration. All these services form an instruction-set of a virtual metacomputer that looks to the enduser as a single computer. The proposed SLA negotiation process has been implemented and validated as part of the SERVME framework in the SORCER environment. However, due to its generic nature we believe that both the Service Level Agreements (SLA) object model as well as the underlying communication model defined in terms of communication interfaces could be adopted for other service-oriented architectures. This paper is a follow-up to [2] – the first one to describe the SERVME framework. Here the focus is the SLA life-cycle and negotiation whereas [2] concentrated on the SERVME architecture and the SLA object model. The rest of the paper is divided into the following sections: Section 2 describes the related work, Section 3 gives introduction to SORCER, Section 4 presents the overview of SERVME, Section 5 elaborates on the SLA negotiation, Section 6 presents the deployment of the framework, and Section 7 concludes the paper.

2 Related Work SLA negotiation has been researched extensively at first in the area of networking. Its application to services was propagated with the emergence of Grid Computing. At first the Globus Resource Allocation Manager (GRAM) [4] lacked a general negotiation protocol that was added later (as described in [5]) in form of the Service Negotiation and Acquisition Protocol (SNAP) [6] that addresses complex, multi-level SLA management. SNAP defines three types of SLAs: Task SLAs, Resource SLAs and Binding SLAs and provides a generic framework, however as Quan et al. [7] underline the protocol needs further extensions for its implementation to address specific problems. As grid technology started to move from traditional network batch queuing towards the application of Web Services (WS) the work of the grid community as well as others focused on incorporating SLA negotiation into the stack of WS technologies. The Web Service Level Agreement framework (WSLA) [8] and the WS-Agreement specification [9] have been proposed to standardize the SLA specification. WS-Agreement specifies also basic negotiation semantics, however, allows only a simple one-phase - offer-accept/reject negotiation. More complex twoand three-phase commit protocols applied in conjunction with WS-Agreement are described in [10]. A different approach to enable automatic SLA negotiation was taken by [11] and [12] who propose to use agents for the negotiation of SLAs in grids. In [13] authors propose to introduce a meta-negotiation protocol that will allow the parties to select via negotiation the protocol used for the actual SLA negotiation. The above solutions concentrate on traditional grids or WS architectures, however, new challenges that reach beyond the multi-phase commit protocols arise when introducing P2P resource management. Significant work has also been pursued in this area, for example by [15], however, this research does not include SLA negotiation.

250

P. Rubach and M. Sobolewski

A novel approach to SLA management and negotiation for P2P distributed environments where federations of services are formed on-the-fly is presented. To fully address the problems with network/resource unreliability and contract SLAs for multi-level, multiple party scenarios this paper introduces a leasing mechanism that is used in conjunction with the 2-phase commit transactional semantics.

3 SORCER SORCER [3] is a federated service-to-service (S2S) metacomputing environment that treats service providers as network objects with well-defined semantics of a federated service object-oriented architecture. It is based on Jini [16] semantics of services in the network and Jini programming model with explicit leases, distributed events, transactions, and discovery/join protocols. While Jini focuses on service management in a networked environment, SORCER focuses on exertion-oriented programming and the execution environment for exertions [3]. SORCER uses Jini discovery/join protocols to implement its exertion-oriented architecture (EOA) [18], but hides all the low-level programming details of the Jini programming model. In EOA, a service provider is an object that accepts remote messages from service requestors to execute collaboration. These messages are called service exertions and describe collaboration data, operations and collaboration's control strategy. An exertion task (or simply a task) is an elementary service request, a kind of elementary instruction executed by a single service provider or a small-scale federation for the same service data. A composite exertion called an exertion job (or simply a job) is defined hierarchically in terms of tasks and other jobs, a kind of federated procedure executed by a large-scale federation. The executing exertion is dynamically bound to all required and currently available service providers on the network. This collection of providers identified in runtime is called an exertion federation. The federation provides the virtual processor (metaprocessor) for the collaboration as specified by its exertion. When the federation is formed, each exertion’s operation has its corresponding method (code) available on the network. Thus, the network exerts the collaboration with the help of the dynamically formed service federation. In other words, we send the request onto the network implicitly, not to a particular service provider explicitly. The overlay network of service providers is called the service grid and an exertion federation is in fact a virtual metaprocessor. The metainstruction set of the metaprocessor consists of all operations offered by all providers in the service grid. Thus, an exertion-oriented (EO) program is composed of metainstructions with its own control strategy and a service context representing the metaprogram data. These operations can be specified in the requestor’s exertion only, and the exertion is passed by itself on to the initializing service provider (found dynamically) via the top-level Servicer interface implemented by all service providers called servicers—service peers. Thus all service providers in EOA implement the service(Exertion, Transaction) : Exertion operation of the Servicer interface. Domain specific servicers within the federation, or task peers (taskers), execute task exertions. Rendezvous peers (jobbers and spacers) coordinate execution of job exertions. Providers of the Tasker, Jobber, and Spacer type are three of SORCER main infrastructure servicers.

Dynamic SLA Negotiation in Autonomic Federated Environments

251

To further clarify what an exertion is, an exertion consists mainly of three parts: a set of service signatures, which is a description of operations in collaboration, the associated service context upon which to execute the exertion, and control strategy (default provided) that defines how signatures are applied in the collaboration. A service signature specifies at least the provider’s service type (interface) that the service requestor would like to use and a selected operation to run within that interface. A service context consists of several data nodes used for either: input, output, or both. A task works with only a single service context, while a job may work with multiple service contexts since it can contain multiple tasks [18]. In SERVME a signature includes a QoS Context (described in Section 4.2) that encapsulates all QoS/SLA data.

4 SERVME Overview To perform SLA negotiation one has to define: 1) a SLA negotiation protocol and interactions between components, 2) a QoS/SLA specification and 3) a negotiation strategy or a decision-making model. SERVME defines the negotiation protocol in the form of a generic communication model, its components tailored to the requirements of federated environments as well as the SLA specification in form of an object model and its data structures. A default negotiation strategy and a decisionmaking model is presented below, however, SERVME is designed to allow an easy customization of the negotiation business logic for each provider and requestor since in a real-world scenario of a free-market service economy these rules may decide which provider receives more requests and thus may become part of its competitive advantage and be considered confidential. 4.1 SERVME Components SERVME builds on the SORCER environment by extending its interfaces and adding new service providers. The details of the architecture have been described in [2]. The components used in the SLA negotiation process are shortly presented below. • ServiceProvider provides the requested service and has a built-in component called SlaDispatcher that retrieves the QoS parameters from the operating system and is responsible for the SLA management on the provider side. • QosCatalog is an independent service that acts as an extended Lookup Service (QoS LUS) as well as the SLA negotiation broker between the provider and the requestor. • SlaPrioritizer is a component that allows controlling the prioritization of the execution of exertions according to organizational requirements (see section 4.2) • SlaMonitor is an independent service that acts as a registry for negotiated SLA contracts and exposes the user interface (UI) for administrators to allow them to monitor and cancel active SLAs. • OnDemandProvisioner is a SERVME provider that enables on-demand provisioning of services in cooperation with the Rio Provisioner [14] [16]. The QosCatalog uses it when no matching service provider can be found that meets requestor QoS requirements.

252

P. Rubach and M. Sobolewski

4.2 SLA Object Model The key feature of the framework is the proposed SLA object model designed to meet the requirements of federated metacomputing environments. For a detailed description including a UML class diagram please refer to [2]. The two main artifacts are: QosContext and SlaContext. The first one groups the requirements submitted by the requestor. It contains: 1) Functional Requirements—a service type (interface) identifying a requested provider, operation to be executed, and related provider's attributes, 2) System Requirements—fixed properties that describe the requested provider’s hardware and software environment (i.e. CPU architecture, OS name and version etc.), 3) Organizational Requirements— properties of the submitting entity (department, team, project, requested timeframe for the execution, priority etc.), 4) Metrics—dynamic, user defined, compound parameters which are calculated on the basis of System- or Organizational Requirements, 5) Service Cost—requirements (i.e. Maximum cost of the execution) and 6) SLA Parameter Requests—the demanded ranges of values or fixed values of QoS parameters. The second critical interface—SlaContext defines the actual SLA. It contains the related requirements in form of the QosContext as well as: 1) SLA Parameters offered or guaranteed by the provider 2) the offered price 3) data used to identify the provider (its ID, proxy etc.) and 4) the state of the negotiation that can have one of the enumerated values: SLA_REQUESTED, SLA_UPDATED, SLA_OFFERED, SLA_ACCEPTED, SLA_GRANTED, SLA_ARCHIVED.

5 SLA Negotiation This section describes the SLA negotiation process. Fig. 1 shows how the negotiation process is integrated into the life-cycle of executing exertions. The diagram refers also to other two activity diagrams presented below: SLA Negotiation and SLA Monitoring. 5.1 Recursive Acquisition of SLAs The negotiation sequence for a single exertion of Task type is presented below in detail, however for completeness in this subsection more complex exertions that require recursive SLA acquisition are shortly described.

Fig. 1. Activity Diagram showing how SERVME SLA Negotiation is integrated into EOP

Dynamic SLA Negotiation in Autonomic Federated Environments

The

execution

of

an

exertion

begins

when

the

requestor

253

calls

Exertion.exert(). In case the exertion is of Task type the request is passed on to the QosCalatog that acts as a broker in the negotiation process described below. However, if the exertion is of Job type, then QosCalatog finds in runtime a matching rendezvous provider (Jobber or Spacer) with a guaranteed SLA.

Before the guaranteed SLA is returned, the rendezvous provider recursively acquires SLAs for all component exertions as described below depending on the type (Task or Job) of component exertion. To ensure transactional semantics of the SLA acquisition the rendezvous peer uses a leasing mechanism (described below) that is similar to the two-phase commit protocol defined by the Jini Transaction model. Exertions of Task type may also contain multiple signatures (as explained in Section 3), so the same recursive mechanism is used to acquire the final SLA. However, in this case the requestor only receives the final SLA for the dynamically binding – signature of the PROCESS type. For intelligibility in the following subsections the assumption is that the outcome of the negotiation should be a single SLA contract for a Task with only one signature. 5.2 Preliminary Selection of Providers As depicted in Fig. 2 at first QosCatalog analyzes the QoS requirements passed in the QosContext and extracts the functional requirements (provider's interface, method, and other attributes) as well as system requirements. Based on the functional

Fig. 2. Activity Diagram showing the actual SLA Negotiation

254

P. Rubach and M. Sobolewski

Fig. 3. Activity Diagram showing the SLA Monitoring

requirements QosCatalog performs a dynamic lookup and retrieves a list of all providers offering the requested interface and method. If none are found QosCatalog tries to provision them using the OnDemandProvisioner (ODP) (see subsection 5.5). Next, QosCatalog queries the ServiceProvider to retrieve the basic QoS parameters that it can offer. The supplied data allows it to select providers that match the system requirements. Those are then called via their SlaManagement interface to start the SLA negotiation process. 5.3 Negotiation The negotiation is initiated by the QosCatalog that invokes the negotiateSla operation of the SlaManagement interface of the provider. In the first step the provider extracts the organizational requirements from the QosContext and passes them to the SlaPrioritizer where the exertion's organizational properties are evaluated against strategic rules defined by the management in the SlaPrioritizer service. The provider then receives a permission or denial to execute the exertion and optionally a cost parameter that it may use to calculate the final service cost of the offer. In case no permission is given the provider returns a no-go exception and the QosCatalog has to select an alternate provider or autonomically provision one if no others are available. After locating another provider the negotiation sequence is repeated for that provider. In case the permission is given the provider checks the QoS requirements against its current resource utilization and allocations for other concurrently guaranteed SLAs. If a parameter can be guaranteed the provider copies the corresponding SlaParameter object including the requested threshold values from the QosContext's SLA parameter requests to SlaContext's SLA parameters and sets its state to PARAM_OFFERED. However, if the requirement cannot be fulfilled the corresponding SLA parameter request is also copied to SlaContext but its state is set to PARAM_UPDATE and its threshold range is updated to the maximum/minimum offered value. After processing individual parameters the provider sets the state of the whole SlaContext to SLA_OFFERED if all SLA parameters can be guaranteed or SLA_UPDATED otherwise. In case the QoS requirements can be met the provider calculates the estimated service cost, allocates the offered resources and creates a Lease that is attached to the SLA offer. This Lease has a short expiration time and thus guarantees that the resources are not blocked unnecessarily. Before the exertion is finally executed the

Dynamic SLA Negotiation in Autonomic Federated Environments

255

Lease must be renewed by the requestor to extend the life of the SLA. The estimated

cost in the validation case, for example, is calculated on the basis of historical executions with similar input data on the same host. Cost is inversely proportional to time of execution extended with some parameters that altogether causes that running computations on faster hardware is much more expensive than on lower-end hosts. To guarantee the non-repudiation of contracts or offers the provider uses the SORCER security framework based on PKI infrastructure to sign the SLA offer before passing it on to the QosCatalog. The described negotiation sequence is repeated by the QosCatalog for all providers that initially matched the system requirements. Out of all offers the QosCatalog chooses the best one depending on the specified parameters and passes it to the requestor for acceptance and signing (see Fig. 1). Currently time only or cost only optimizations are supported but the inclusion of non-linear optimization methods that will allow to select a set of offers matching both parameters (i.e., fastest execution but costing no more than X) are a work in progress. 5.4 SLA Acceptance and Signing The requestor may now decide to accept or deny the received offer. However, in case it is denied the SLA negotiation process has to be reinitiated from the very beginning. In case of acceptance the requestor updates the SLA's state to SLA_ACCEPTED and performs digital signing using the PKI infrastructure. From now on the requester is responsible for renewing the Lease of the SLA. The requester calls the signSla method of the provider and passes the SlaContext. If the Lease has not expired the provider grants the SLA by setting its state to SLA_GRANTED. The SlaContext is then returned to the requestor and the execution of the exertion may finally begin. At the same time the provider sends a copy of the SlaContext asynchronously to the SlaMonitor where it is registered and persisted. 5.5 On-Demand Provisioning SERVME reduces the overall resource utilization by allowing service providers to be provisioned on-demand and deprovisioned when they are not used anymore. In the above negotiation process there are three scenarios that may lead to ondemand provisioning: 1) when no providers are available that meet functional requirements 2) when none of the available providers receive a permission to execute the exertion from the SlaPrioritizer and 3) when none of the SLA offers returned by providers to the QosCatalog fully fulfills the requirements (all have a state of negotiation set to SLA_UPDATED). In any of these cases the QosCatalog tries to deploy a new provider with the required QoS parameters by calling the OnDemandProvisioner object. OnDemandProvisioner constructs on-the-fly an OperationalString required by Rio and calls the ProvisionMonitor component of Rio [14] to deploy the required providers. If the provisioning succeeds QosCatalog invokes the same negotiation sequence on the newly provisioned provider. Otherwise QosCatalog returns to the

256

P. Rubach and M. Sobolewski

requestor the full list of SLAs that it negotiated, none of which however, fully fulfills the requestors requirements. The requestor may now choose to accept one of these offers or try to start another round of negotiation with lowered QoS requirements. 5.6 SLA Monitoring and Management As depicted in Fig. 3 the SlaMonitor can be used to monitor the execution and delete an active SLA. It communicates with providers and asynchronously receives messages with updated states of the SLA's lifecycle. 5.7 Deprovisioning Services The leasing mechanism described in subsection 5.3 ensures that the provider is aware when any of the granted SLAs expires or the exertion simply finishes execution. This information is passed on to the SlaMonitor that also receives events regarding the provisioning actions taken by the OnDemandProvisioner. SlaMonitor is thus able to detect situations when the provisioned provider is not used anymore. In that case it notifies the OnDemandProvisioner and this service undeploys the unused provider by calling the Rio's ProvisionMonitor. The provider cannot just simply destroy itself upon finishing the execution of the exertion since in that case Rio's failover mechanism would immediately deploy another instance of that provider.

6 Deployment SERVME has been deployed in the SORCER environment. The framework was validated in a real-world example taken from neuroscience. SERVME was used to invoke and control multiple parallel and sequential computations that dealt with the processing of MRIs of human brains. Six heterogeneous hosts where used to perform several simultaneous computations. The simulations were run several times and have shown that with SERVME it is possible to optimize the execution of complex computations for lowest price or best performance. The overhead time resulting from the communication needed to select the appropriate provider, performing SLA negotiation, and signing the SLA contract has been measured in this environment at around 1-1.5 seconds and as such is negligible in comparison to the computations run, that took minimally 3-4 minutes each. Detailed validation results along with a complete statistical analysis will be published in a forthcoming paper.

7 Conclusions The new SLA Negotiation process for Autonomic Federated Metacomputing Environments is presented in this paper. The described process includes the ondemand provisioning of services and refers to components defined in the SERVME framework: QosCatalog, SlaDispatcher, SlaMonitor, SlaPrioritizer, and OnDemandProvisioner. The negotiation uses the SLA object model introduced in SERVME and defined by the two generic interfaces: QosContext and related SlaContext. To the best of our knowledge this is the first attempt to describe the SLA negotiation process for exertion-oriented programming.

Dynamic SLA Negotiation in Autonomic Federated Environments

257

The presented framework addresses the challenges of spontaneous federations in SORCER and allows for better resource allocation. Also, SERVME provides for better hardware utilization due to Rio monitored provisioning and SORCER ondemand provisioning. The presented architecture scales very well with on-demand provisioning that reduces the number of compute resources to those presently required for collaborations defined by corresponding exertions. When diverse and specialized hardware is used, SERVME provides means to manage the prioritization of tasks according to the organization’s strategy that defines "who is computing what and where". Two zero-install and friendly graphical user interfaces attached to SLA Monitor and SORCER Servicer are available for administration purposes. The SERVME providers are SORCER Servicers so additional SERVME providers can be dynamically provisioned if needed autonomically. Finally, the framework allows for accounting of resource utilization based on dynamic cost metrics, thus it contributes towards the realization of the utility computing concept. Acknowledgments. This work was partially supported by Air Force Research Lab, Air Vehicles Directorate, Multidisciplinary Technology Center, the contract number F33615-03-D-3307, Service-Oriented Optimization Toolkit for Distributed High Fidelity Engineering Design Optimization. We would like also to thank Dennis Reedy the architect of project Rio for his invaluable assistance that helped us to integrate the Rio provisioning framework with the SERVME framework.

References [1] Kephart, J.O., Chess, D.M.: The vision of autonomic computing. Computer 36, 41–50 (2003) [2] Rubach, P., Sobolewski, M.: Autonomic SLA Management in Federated Computing Environments. In: Proceedings of the 2009 International Conference on Parallel Processing Workshops (ICPPW 2009). IEEE Computer Society, Los Alamitos (in press, 2009) [3] Sobolewski, M.: SORCER: Computing and Metacomputing Intergrid. In: 10th International Conference on Enterprise Information Systems, Barcelona, Spain (2008) [4] Czajkowski, K., Foster, I., Karonis, N., Kesselman, C., Martin, S., Smith, W., Tuecke, S.: A resource management architecture for metacomputing systems. In: Feitelson, D.G., Rudolph, L. (eds.) IPPS-WS 1998, SPDP-WS 1998, and JSSPP 1998. LNCS, vol. 1459, pp. 62–82. Springer, Heidelberg (1998) [5] Czajkowski, K., Foster, I., Kesselman, C., Tuecke, S.: Grid service level agreements: Grid resource management with intermediaries. In: Grid resource management: state of the art and future trends, pp. 119–134. Kluwer Academic Publishers, Dordrecht (2004) [6] Czajkowski, K., Foster, I., Kesselman, C., Sander, V., Tuecke, S.: SNAP: A Protocol for Negotiating Service Level Agreements and Coordinating Resource Management in Distributed Systems. In: Feitelson, D.G., Rudolph, L., Schwiegelshohn, U. (eds.) JSSPP 2002. LNCS, vol. 2537, pp. 153–183. Springer, Heidelberg (2002) [7] Quan, D.M., Kao, O.: SLA Negotiation Protocol for Grid-Based Workflows. In: High Performance Computing and Communcations, pp. 505–510 (2005)

258

P. Rubach and M. Sobolewski

[8] Ludwig, H., Keller, A., Dan, A., King, R.P., Franck, R.: Web service level agreement (WSLA) language specification. IBM Corporation (2003) [9] Andrieux, A., Czajkowski, K., Ibm, A.D., Keahey, K., Ibm, H.L., Nec, T.N., Hp, J.P., Ibm, J.R., Tuecke, S., Xu, M.: Web Services Agreement Specification, WS-Agreement (2007) [10] Pichot, A., Wieder, P., Waeldrich, O., Ziegler, W.: Dynamic SLA-negotiation based on WS-Agreement, CoreGRID Technical Report TR-0082, Institute on Resource Management and Scheduling (2007) [11] Shen, W., Li, Y.: Adaptive negotiation for agent-based grid computing. In: Proceedings of the Agentcities/Aamas 2002, vol. 5, pp. 32–36 (2002) [12] Ouelhadj, D., Garibaldi, J., MacLaren, J., Sakellariou, R., Krishnakumar, K.: A Multiagent Infrastructure and a Service Level Agreement Negotiation Protocol for Robust Scheduling in Grid Computing. In: Sloot, P.M.A., Hoekstra, A.G., Priol, T., Reinefeld, A., Bubak, M. (eds.) EGC 2005. LNCS, vol. 3470, pp. 651–660. Springer, Heidelberg (2005) [13] Brandic, I., Venugopal, S., Mattess, M., Buyya, R.: Towards a Meta-Negotiation Architecture for SLA-Aware Grid Services, Technical Report, GRIDS-TR-2008-9, Grid Computing and Distributed Systems Laboratory, The University of Melbourne, Australia (2008) [14] Project Rio, http://rio.dev.java.net/ (accessed on March 13, 2009) [15] Cao, J., Kwong, O.M.K., Wang, X., Cai, W.: A peer-to-peer approach to task scheduling in computation grid. Int. J. Grid Util. Comput. 1, 13–21 (2005) [16] Jini architecture specification, Version 2.1 (accessed on March 2009) [17] Sobolewski, M.: Federated Method Invocation with Exertions. In: Proceedings of the 2007 IMCSIT Conference, pp. 765–778. PTI Press (2007) [18] Sobolewski, M.: Exertion Oriented Programming. In: IADIS, vol. 3, pp. 86–109 (2008)

Network Security Validation Using Game Theory Vicky Papadopoulou and Andreas Gregoriades Computer Science and Engineering Dep., European University Cyprus, Cyprus 6, Diogenes Str., Engomi, P.O. Box: 22006, 1516 Nicosia-Cyprus {v.papadopoulou, a.gregoriades}@euc.ac.cy

Abstract. Non-functional requirements (NFR) such as network security recently gained widespread attention in distributed information systems. Despite their importance however, there is no systematic approach to validate these requirements given the complexity and uncertainty characterizing modern networks. Traditionally, network security requirements specification has been the results of a reactive process. This however, limited the immunity property of the distributed systems that depended on these networks. Security requirements specification need a proactive approach. Networks’ infrastructure is constantly under attack by hackers and malicious software that aim to break into computers. To combat these threats, network designers need sophisticated security validation techniques that will guarantee the minimum level of security for their future networks. This paper presents a game-theoretic approach to security requirements validation. An introduction to game theory is presented along with an example that demonstrates the application of the approach. Keywords: Non-functional requirements, Game Theory, Network Security.

1 Introduction In recent years organizations have experienced the explosion of attacks on their information resources. Among all these attacks, computer virus poses a major threat to the information security for business effectiveness. According to the Computer Security Institute (CSI) [8], viruses constitute the principal cause of financial losses among computer security incidents in organizations. Given this, there is a major need to understand and control virus behavior in network-centric information systems. A computer network is defined as the purposeful interconnection of computer nodes for the efficient and effective interchange of information. Network security consists of the provisions enforced in a computer network that aim to protect the network and its resources from unauthorized access. The recent growth of public networks such as the Internet made this requirement even more critical. However, the dynamic characteristics of contemporary networks combined with their increased size creates an extra challenge for the network designers. This area of research has gained considerable popularity due to the implications it has on users’ satisfaction and business reputation. Therefore, being able to quantify the security performance of a future network early in the design phase is of vital importance. The need to validate security requirements early has been addressed also by Lamsweerde [3] and Crook [1]. R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 259–266, 2009. © Springer-Verlag Berlin Heidelberg 2009

260

V. Papadopoulou and A. Gregoriades

Security as an NFR is influenced by functional aspects of the system. Unlike functional requirements, which can be deterministically validated, NFRs are soft variables that cannot be implemented directly; instead, they are satisfied [??] by a combination of functional requirements. NFRs define the overall qualities or attributes of the resulting system and as such place restrictions on the software product being developed. Typical approaches to validating NFRs include, formal methods, prototypes and system simulations [2] and use of scenarios. Scenarios describe all the states that the network could have, given all the combinations of attack behaviours of the viruses. Specifically, the application of scenarios-based approaches highlighted the problem of having too many scenarios to analyse. This paper addresses this problem through Game Theory. Specifically, we reduce the complexity of the solution space to a manageable set and hence escape from the problem of evaluating too many scenarios.

2 Game Theory Game Theory attempts to mathematically model the rational behavior of actors in strategic situations. In such situations actors success depends on the choices of others. Most of the existing and foreseen complex networks, such as the Internet, are operated and built by thousands of large and small entities (autonomous agents), which collaborate to process and deliver end-to-end flows originating from and terminating at any of them. The distributed nature of the Internet implies a lack of coordination among its users that attempt to maximise their performance according to their own parameters and objectives. Recently, Game Theory has been proven to be a powerful modeling tool to describe such selfish, rational and at the same time, decentralized interactions. Game Theory models such interactions as players with potentially different goals (utility functions), that participate under a common setting with well prescribed interactions (strategies), e.g. TCP/IP protocols. The core concept of Game Theory is the notion of equilibrium that is defined as the condition of a system in which competing influences are balanced. A game, expressed in normal form is given by a tuble G=( M, A, {ui}), where G is a particular game, M is a finite set of players (decision makers) {1,2,…,m}, Ai is the set of actions available to player i, A = A1 × A2 × ⋅⋅⋅× Am is the action space, and {ui} ={ u1 , u2 , ui , um} is the set of objective functions that the players wish to maximize. For every player i, the objective function, ui, is a function of the particular action chosen by player i, ai, and the particular actions chosen by all of the other players in the game, a-i. From this model, steady-state conditions, known as Nash Equilibria [6] are identified wherein no player would rationally choose to deviate from their chosen action as this would diminish their payoff, i.e. ui(a) ≤ ui(bi, a-i) for all i, j ∈ M. Nash equilibria model well stables states of a network, since if the network reaches such a configuration, most probably it would remain in the same configuration, since none of the involving entities has a motivation to change his status in order to be more satisfied.

Network Security Validation Using Game Theory

261

3 The Method To assess network security, we represent the problem in the form of a game between attacking and defending entities [4,5]. When the network designer thinks like an attacker, he/she engages in a game. Finding and evaluating equilibria between attackers’ and defenders’ strategies provide the means to evaluate the network’s security. This information can be provided during the design phase of a prospective network and hence, enables the designer to opt the network features accordingly. Hence, identifying and subsequently evaluating Nash equilibria in prospective networks can help to validate prospective networks’ security. However, evaluating security requirements in the design phase, prerequisite that we capture the network’s behaviour for all possible types of assaults. These combinations constitute a high number of possible test scenarios. Therefore, to evaluate the security performance of a prospective network we need to assess it against each scenario. Scenarios became a popular method for validating NFR [2] where each corresponds to a set of situations that might occur during the operation of a system. Application of scenarios in requirements validation has been performed by a number of researchers [2]. The main problem remaining in requirements validation using scenarios is the specification and subsequently the analysis of a large set of test cases. The large set of scenario variations needed to validate NFRs, overloads the requirements analysis task. On the other hand, automated support for the scenario generation proved to be a vexed problem due to the exponentially large set of possible variations that needs to be examined [2] for the NFR to be guaranteed. An approach that makes this problem tractable is the one described. In particular, we manage to significantly reduce the number of scenarios needed to validate the NFRs by investigating only stable network states (configurations). Actually, our method is of polynomial time complexity compared to the size of the proposed network. Stable configurations describe the most likely states that a network could be in. Thus, by examining network security for only such states, we manage to ensure a satisfactory NFR almost always. Such states are captured through Nash equilibria [6] profiles of the modelled game. Thus, instead of evaluating all possible combinations of network configurations and attacker and defender strategies we only concentrate on Nash equilibria to assess network security. Our approach is composed of the following three steps: 1. Initially the network designer specifies quantitatively the required level of security he wishes to achieve in the future network. 2. Next, security requirement of the prospective network are modeled in the form of a game using a graph. In particular, we represent the network’s topology using a graph and adopt the security game introduced in [4]. Security threats and the potential defense mechanisms are realized using a set of confronting players on a graphical game. It is assumed that the prospective network satisfies some common topological properties. Furthermore, we make some typical assumptions on the attacks that may appear in the network. Moreover it is assumed that we have no prior information on how the attackers behave. Thus, we assume that attacks on the network nodes follow a uniform distribution with equal probability of attacking each node. Game theory also requires the specification of the defenders behaviour or mechanisms. This constitutes the functional immunity requirements of the proposed network.

262

V. Papadopoulou and A. Gregoriades

3. Finally, analyse the identified Nash equilibria. For this we use prior knowledge from [4,5] to measure the security guarantee of the prospective network.

4 Application of the Method Assuming that we want to validate the security of the network depicted in Figure 1. The required level of the networks security is initially defined quantitatively. Finding equilibria through Game Theory enables the designer to identify “stable” network configurations that archive the required level of security. This task is performed analytically. The approach is based on the notion of scenarios [2] that correspond to possible configurations of attackers and defenders on the network. The use of Game Theory enables us to reduce the complexity of this process by analysing only scenarios that both attackers and the defender would choose given that they act rationally and hence, engage in actions that maximizes their benefit. Through gametheoretic analysis strategies of both attackers and the defenders that maximize their individual benefits are identified. Finding and assessing equlibria among these strategies enables the assessment of prospective network’s security. Next section illustrates the application of the method. 4.1 Network’s Topological Specification The prospective network N consists of a number of nodes, n, representing a set of routers, and a set of communication links E between the nodes of the network. Moreover, it is assumed that the network satisfies the hit-all property. Hence, there exists a subset of links E′⊆E such that each node υ of the network is ”hit” (incident) to exactly one link of the set E′. Network topologies that satisfy this property can be build and identified in polynomial time [16]. Such a set is called a Perfect Matching of the network. We call such a network a hit-all network. For example, the network of Figure 1(a) is a hit-all network.

(a)

(b)

Fig. 1. (a) A hit-all network. The thick links, edges e1, e2, e3, constitute a hit-all set for the network since they hit all nodes of the graph. (b) A configuration of a hit-all network that

satisfies the network security specifications and requirements: The network has 3 attackers, x1, x2, x3, each targeting each node of the network with equal probability 1/6. The defender is located on each one of the edges e1, e2, e3 with equal probability 1/3. Therefore, the assessed security here equals to 25%.

Network Security Validation Using Game Theory

263

We remark that this network’s topological specification is realistic and we the reasoning is briefly explained here. Graph Theory [7] suggests that the networks excluded from the specified network family, the hit-all-networks, are those networks that contain nodes which are end points of a star subgraph of the whole network. Those nodes are connected to the rest of the network only through the center node of the star that they belong to. So, one could consider them as being not important and hence ignore them. Thus, the hit-all-networks we assume here represent the most important topological part of a common network. 4.2 Network’s Security Specifications Network security requirements specification is defined using the common process employed in critical systems specifications. The process consists of the following stages: A.

B.

C.

D.

Asset identification: This step addresses the identification of the assets of the network that needs to be protected. In our case, the assets of the network are the nodes of the network. In the most general case, all nodes are of the same importance. A node is considered protected or secure if a security software is installed on that node. Otherwise it is considered vulnerable to attacks. Threat analysis and assignment: This step addresses the identification of the possible security threats. These constitute the viruses, worms, Trojan horses and eavesdroppers which are described as attacks that target the nodes of the network. At any time there is a maximum number of attackers, ν, that may be present in the network. Each of them damages nodes that are not protected. In the most general case, we have no information on the distribution of the attacks on the nodes of the network. So, we assume that attacks will follow a uniform distribution, which is quite common in such cases. We call such attacks uniform attacks. Technology analysis: This step concentrates on the analysis of available security technologies. One major security mechanism for protecting network attacks is the firewalls that we refer to as defenders. In distributed firewalls [8] the part of the network protected is defined by the links that the defenders protect. The simplest case is when the sub-network is a single link with its two nodes. In ideal situation the easiest would have been to install software protection in all links of the network. However, due to the financial costs of security software defence mechanisms are only used on a limited part of the network. Security requirements: the final step of the security specification process includes the definition of the security requirements that will protect the network against the identified threads. Given the above, in this example we assume that the prospective network will be supported by a single security mechanism, denoted as d, which is capable of cleaning a network link at a time. The position of the defender on the network’s nodes is such that satisfies the hit-all property. Security Requirement Validation.

The assessment and subsequently the validation of security requirements in our method necessitate a game theoretic analysis of the problem. Next, we present the tools necessary to evaluate the security level of the prospective network and finally utilize them in order to validate the security requirement specified by the designer.

264

V. Papadopoulou and A. Gregoriades

4.2.1 Game Theoretic Modeling Network’s topological and security specifications are modelled according to sections 4.1 and 4.2 using the graph-theoretic game introduced and investigated in [4,5]. The game is played on a graph G representing the network N. The players of the game are of two kinds: the attackers and the defender players. The attackers play on the vertices of the graph, representing the nodes of the network and the defender plays on the edges of the graph, representing the links of the network. The prospective network’s configuration s of the game is defined by (i) the locations of the attackers and (ii) the location of the defense mechanism. The positioning attackers and defenders on the network follow a probability distribution that defines the likelihoods of each attacking or defending a node or a link respectively. When attackers target more than one node based on a probability distribution and defenders protect more than one link given another probability distribution, the configuration is defined as mixed configuration. Figure 1(b) illustrates a possible configuration for the network. The network satisfies the specifications as defined in Section 4.1. Furthermore, notice that the configuration satisfies the network security specifications of Section 4.2 (A-D): According to this specifications attackers, hit any node on the network uniformly at random, i.e. with probability 1/6, given that the number of nodes is 6. Moreover, the defense mechanism chooses to defend the links of E′= { e1, e2, e3} uniformly at random, where the set E′ constitutes a Perfect Matching, where the edges of the defenders have no common vertices. 4.2.2 Security Assessment To evaluate network security we assess the security level of stable configuration of the game similarly with [4]. Consider a mixed network configuration s. Let sd be the edge selected to being defended by the defender of the resulting respective game defined above. For each attacker i∈[ν], let si be the node in which the attacker strikes. We say that the attacker i is killed by the security mechanism if the node si is one of the two endpoints of the link sd being defended by the security software. Then, the defense ratio [4] of the configuration s, denoted by rs is defined to be as follows, when given as a percentage: rs =

expected number of attackers killed in s

ν

× 100 .

Hence, the optimal defense ratio of a network is 100% if the security software manages to kill all attackers. The larger the value of rs the greater the security level obtained. This approach, enables the quantification of security of a perspective network using only examining stable configurations. A network whenever reaches a stable a configuration tents to remain in the same configuration. This is due to the fact that in such configurations no single player has an incentive to unilaterally deviate from its current strategy. So, such configurations constitute the most probable states of the network. Therefore, we escape from the NP-hard problem of having to assess each possible configuration or scenario. We model stable configuration as Nash equilibria. We evaluate the network security level based on a representative stable configuration.

Network Security Validation Using Game Theory

265

Therefore, through this process we manage to quantify the security level of the prospective network given a representative set of stable configurations. 4.2.3 A Game-Theoretic Validation Given specific network configurations the method provides a mechanism to easily estimate the security level of a prospective network using the following theorem. Theorem 1. [4] Consider a hit-all network N with n nodes and the network security specifications indicated by items A-D in section 4.2. Then the network contains a stable configuration s (i.e. a Nash equilibrium) s with level of security given by the following formulae:

rs =

2 × 100. n

Therefore, based on the above, the network of Figure 1(b) has security level equal to 2/6×100=33%, since n=6. This designates that the level of security is 33% given the functional requirements specified in configuration s. This assessment indicates that the NFR specified by the designer is not satisfied using the prescribed functional requirements of the network. Hence, the network specification needs to be revised and the security NFR reassessed, prior to proceed to the implementation of the network.

5 Discussion and Conclusion Security requirements validation is typically performed through security-specific testing. This process is performed in addition to the traditional types of system testing. In this approach, test cases are usually based on abnormal scenarios that describe situations that the network will be called to face. This is analogous to test cases developed for use case based functional testing. These techniques however are mostly based on a reactive paradigm rather than proactive. Moreover, for these to be effective, it is required that a model of the prospective network is developed in a simulator based on which security can be validated. Most importantly, concentrating only on abnormal scenarios limits the effectiveness of the security validation process. Ideally, validation should be performed on all possible scenarios. However, examining all possible scenarios [2] in order to validating security requirements constitutes a highly complex (thus, inefficient) and sometimes infeasible task. In this work we manage to accomplish this process in only polynomial time. This is achieved by considering only stable configurations of the system, that we model using Nash equilibria. In this context, the method presented in this paper constitutes a novelty in validating security NFR through game theory. The approach presented in this paper is original in security requirements validation since it formally mimics the rationale of the network security problem in a game of attackers and defenders. The application of Game Theory enables the identification of equilibria among the network’s defenses and the attackers strategies and as a result enables the validation of a prospective networks security NFR using only a limited set of test scenarios. The method usage has been elaborated in a case study that explicitly demonstrates the core steps of the process for validating security requirements. The

266

V. Papadopoulou and A. Gregoriades

initial results of this work are encouraging and we are currently looking at techniques to automate the equilibria identification process through the application of systems thinking and system dynamics simulation. Despite its advantages our methods has a number of limitations. Specifically, the assumption that the probability distribution of the attackers’ placements on the network is expressed uniformly corresponds to simplified problem scenario. However, there are cases, where prior knowledge of the attackers’ behaviour is available. This would lead to different distribution of attacks on the network which subsequently can be utilized to come up with a different defence mechanisms so that to obtain a better security level. Moreover, in our method we assume that only a single defence mechanism is present in the network. However, in large networks usually more than one defence mechanisms are available; although almost always they still can not guarantee absolute network security. As a future work, we plan to utilize other theoretical games that model such scenarios and exploit their analysis in order to provide security requirements validation for more complex networks.

References [1] Crook, R., Ince, D., Lin, L., Nuseibeh, B.: Security requirements Engineering: When AntiRequirements Hit the Fan. In: Proceedings of the 10th Anniversary IEEE Joint International Conference on Requirements Engineering, pp. 203–205. IEEE Press, Los Alamitos (2002) [2] Gregoriades, A., Sutcliffe, A.: Scenario-Based Assessment of Non-Functional Requirements. IEEE Transactions on Software Engineering 31(5), 392–409 (2005) [3] van Lamsweerde, A.: Elaborating Security Requirements by Construction of Intentional Anti-Models. In: Proceedings of the 26th International Conference on Software Engineering, pp. 148–157. IEEE Press, Los Alamitos (2004) [4] Mavronicolas, M., Papadopoulou, V.G., Philippou, A., Spirakis, P.G.: A Network Game with Attacker and Protector Entities. Algorithmica. In: Deng, X., Du, D. (eds.) Special Issue with selected papers from the 16th Annual International Symposium on Algorithms and Computation (ISAAC 2005), July 2008, vol. 51(3), pp. 315–341 (2008) [5] Mavronicolas, M., Michael, L., Papadopoulou, V.G., Philippou, A., Spirakis, P.G.: The price of defense. In: Královič, R., Urzyczyn, P. (eds.) MFCS 2006. LNCS, vol. 4162, pp. 717–728. Springer, Heidelberg (2006) [6] Nash, J.F.: Non-cooperative Games. Annals of Mathematics 54(2), 286–295 (1951) [7] West, D.B.: Introduction to Graph Theory, 2nd edn. Prentice Hall, Englewood Cliffs (2001) [8] Markham, T., Payne, C.: Security at the Network Edge: A Distributed Firewall Architecture. In: Proceedings of the 2nd DARPA Information Survivability Conference and Exposition, June 2001, vol. 1, pp. 279–286 (2001)

On the Use of Handover Checkpoints to Manage the Global Software Development Process Frank Salger Capgemini sd&m, Carl-Wery-Straße 42, 81739 Munich, Germany [email protected]

Abstract. Despite the fact that global software development (GSD) is steadily becoming the standard engineering mode in the software industry, commercial projects still struggle with how to effectively manage it. Recent research and our own experiences from numerous GSD projects at Capgemini sd&m indicate that staging the development process with handover checkpoints is a promising practice in order to tackle many of the encountered problems in practice. In this paper we discuss typical management problems in GSD. We describe how handover checkpoints are used at Capgemini sd&m to control and safely manage large GSD projects. We show how these handover checkpoints and the use of cohesive and self-contained work packages effectively mitigate the discussed management problems. We are continuously refining and improving our handover checkpoint approach by applying it within large scale commercial GSD projects. We thus believe that the presented results can serve the practitioner as a fundament for implementing and customizing handover checkpoints within his own organisation.

1 Introduction It is well known that the global distribution of software development processes poses new ones and intensifies existing challenges to project management as compared to collocated software development [1-5]. A number of practices have been proposed in order to tackle these problems. One of the most promising one seems to be the use of clearly defied synchronization and handover points [1, 4-6]. But although much research emphasis the relevance of such handover checkpoints for GSD, the description of these checkpoints is often not elaborated enough to serve as basis for integrating them into commercial GSD projects. The main contribution of this paper is a description of the structure and content of the handover checkpoints used at Capgemini sd&m for managing globally distributed, large scale custom software development projects of business information systems. We provide detailed descriptions on our notion of ‘work package’ as well as on the structure and content of our handover checkpoints. Further, we show how the handover checkpoints complement the ‘quality gates’, already used at Capgemini sd&m. Finally, we explain how these results can serve as a basis for practitioners to integrate handover checkpoints in their own organizations. R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 267–276, 2009. © Springer-Verlag Berlin Heidelberg 2009

268

F. Salger

The notion for ‘work package’ and the definition of handover checkpoints given in this paper where developed at Capgemini sd&m, and are specifically tailored to GSD of large business information systems. Capgemini sd&m is the Technology Services unit of the Capgemini Group in Germany and Switzerland and offers its customers end-to-end process and software solutions that have a crucial impact on their competitiveness. The Capgemini Group exploits captive centers for offshoring software development in several countries. The rest of the paper is organized as follows. In section 2, we discuss the most prevalent problems we encountered when managing GSD project for large business information systems at Capgemini sd&m. In section 3, we introduce and discuss our notion of ‘work package’ and the structure and content of the handover checkpoints. The benefits we obtained by using handover checkpoints in our GSD projects are described in section 4. We draw our conclusions in section 5 and sketch our agenda for future research.

2 Prevalent Problems in GSD In this section, we discuss some of the most prevalent problems we encountered in numerous globally distributed projects for the development of large scale and custom build business information systems. Doing so, we point out related work, thereby affirming our experiences as well as the cited research results. 1. Too Little Process Structure The distributed process is often not structured enough in order to be effectively manageable. Work units (in particular software requirements specifications) are not defined precisely enough [2, 6, 7]. Dependencies between different work units as well as dependencies between different tasks are often little understood [8]. There are no defined points, where work units and the responsibility therefore are handed too and fro between distributed teams. Resulting Problems: Without intermediate milestones or checkpoints, the overall process becomes fragile. Especially in GSD, the distributed teams must be able to relay on stable and complete baselines from which they can safely start their work. 2. Missing Concept to Bundle Work Units The distribution of the software engineering process negatively affects the ability to coordinate and control work [1-6, 8]. It is thus important to bundle work units which can be handled together without further need to communicate too much about them. But defining work packages only form a ‘module point of view’ seems to be insufficient: It is important to define a work package not only from a logical viewpoint but also from a management and risk oriented viewpoint. Resulting problems: Cohesiveness from a logical point of view is not the only important dimension for devising modules. If for example, modules are chosen too small, project management will eventually be screwed up in micro-management and frequent re-planning due to inevitable changes which happen frequently on the fine grained task levels. If the on the other hand work packages are devised too big from a risk management point of view, then problems with such work packages will surface

On the Use of Handover Checkpoints to Manage the GSD Process

269

too late and only until they already have a critical impact on the overall schedule and effort. Finally, if work packages are chosen to be too big from a business logic point of view, they will bundle lots of non-cohesive business logic. This will force the development team of such work packages to know too much about the overall business logic. This leads to a communication overkill, which in turn results in lots of effort and time needed to develop such work packages. 3. Undefined Acceptance Criteria and Quality Objectives Often, acceptance criteria and quality objectives for work units are not defined precisely enough, or are missing altogether. This holds for requirements specifications, system specifications or source code alike. Resulting problems: The fundamental problem with weak acceptance criteria is that it is not clear, when a deliverable is really finished. This makes meaningful earned value analysis impossible, which in turn prohibits controlling of real progress. But rigorously monitoring progress is especially important in GSD [2, 6]. 4. Missing Alignment of Engineering Disciplines GSD poses additional challenges to all software engineering disciplines. In such stormy environments, it is natural that the managers, business analysts and software architects concentrate on getting their own job done. This however proves to be especially dangerous in GSD, where tight cooperation and awareness between different roles is paramount [9]. Resulting problems: Divergence of disciplines can happen in various ways. Probably the most common one is, when actual effort needed for the implementation of work units is not reported to the management in a disciplined manner. It then becomes impossible to readjust the plan and adapt the projections for overall effort and schedule. Moreover, systematic estimation errors are not detected. 5. Insufficient Knowledge Transfer It is well known that global distribution usually necessitates a more intensive knowledge transfer as compared in collocated development settings [2, 6]. It is simply not possible to walk into the colleagues cube and to ask him for the missing information. Cultural differences might further add to this problem, when colleagues find it impolite to ask clarifying questions. Resulting problems: Onsite and offshore software engineers often have little or none project experience in common. Thus, they have less common ground with regards to processes and practices. Intensive knowledge transfer and training is paramount to tackle this issue.

3 The Use of Work Packages and Handover Checkpoints in GSD In this section, we first describe our notion of ‘work package’. We then present the structure of our handover checkpoints and show, how they are applied in GSD.

270

F. Salger

3.1 Work Packages Two organizations that work together but are geographically separated require a clear concept for bundling and executing work. Often, ‘modules’ (in the sense of Parnas [10]) are used as ‘work packages’. As the organizational structure and the product structure influence each other, modules have to be very carefully devised in GSD [8, 11, 12, 13]. At Capgemini sd&m, we defined ‘work packages’ to consist of three kinds of artifacts: 1.

2.

3.

Software requirement specification (SRS) artifacts. A cohesive set of system use cases, user interface descriptions, domain objects and other requirement artifacts. We call such sets ‘conceptual components’ [14]. Additional specification-related information is bundled into a work package: a) ‘Reuse lists’, which contain information about SRS artifacts that can be reused and have already been realized during development of other work packages (like certain business rules). b) ‘Tracing matrices’ which are used to trace the SRS artifacts back to the high level requirements. c) Specifications of functional test cases. Design artifacts. Usually, a subsystem comprising a couple of modules will realize the conceptual component of a work package. Included into a work package will be the external interfaces of the modules (i.e., the external technical view on the subsystem which realizes the conceptual component) and the internal high level design of the modules, like e.g. which layers will be used. Project management artifacts. The engineering artifacts as mentioned under 1) and 2) are complemented by bundling management-oriented artifacts into a work package: These are the list of work units which are bundled into the work package, the schedule for the work package, and the definition of quality objectives and acceptance criteria for the work units.

This notion of work package allow us to define • • •

clear artefacts to be delivered by both parties clear handover points and handover processes clear acceptance criteria for work units of both parties

Some further comments on the notion of work package might be needed: It might seem that a work package is bundled by the onsite team and then ‘thrown over the wall’ to the offshore development team for implementation. This is definitively not the case. In contrary, key offshore roles are involved in the bundling work packages throughout the project live-cycle: First, the offshore business analysts already join the onsite team early on from requirements engineering, and are thus involved in structuring the business domain and ‘cutting’ it down into sub-domains. These sub-domains usually become the first candidates for conceptual components. During the inception and elaboration phase, the onsite and offshore architects together devise the high level architecture, where the conceptual components are further refined into modules. This usually happens incrementally and in some cases might involve the redefinition of some conceptual components. Step by step, reasonably stable components (modulo requirements change) are defined in that way, i.e., the content of the work packages gets fixed. For these fixed

On the Use of Handover Checkpoints to Manage the GSD Process

271

work packages, the onsite and the offshore project manager then jointly create the precise list of work units, devise a work package schedule and allocate the necessary developers to the work package. They also break the overall quality objectives down to the concrete work units. 3.2 Handover Checkpoints Before a work package is cleared for realization, the ‘Work Package Handover Checkpoint’ (WPHC) is applied jointly by onsite and the offshore team members. After the construction of a work package, the result is checked in the ‘Result Handover Checkpoint’ (RHC). Please note that in between these two checkpoints, comprehensive code quality assurance is conducted, like continuous integrations, systematic code reviews, and automatic checks for architecture compliance. One important point to observe is that not the work products themselves are handed over (in the sense of ‘sending a parcel’). They reside in shared repositories anyway. What actually is handed over, is the responsibility for certain activities and tasks conducted on work packages. A positive outcome of the WPHC means that the onsite and offshore team members agree on the ‘transfer’ of the work package: The offshore developers basically declare that the work package contains all information they need in order to construct the work package. Analogously, a positive outcome of the RHC means that the team members jointly agree on transferring the responsibility for the result of the work package construction to the integration team. Figure 1 sketches, how the two checkpoints are used in GSD. The thick arrows indicate a transfer of responsibility. In this example, the sequential realization of two work packages is shown. Usually, multiple work packages will be constructed in a rather overlapping or concurrent fashion. In the example, the integration of the work package results is done onsite as indicated by the assembled pieces of the puzzle top right in the figure.

Fig. 1. Application of handover checkpoints (simplified example)

Checkpoint 1: Work Package Handover Checkpoint (WPHC) The WPHC encompasses two kinds of evaluations: 1A) Initial pre-construction check and 1B) work package check. We now describe these two checks in more detail.

272

F. Salger

1A) Initial pre-construction check: • •

Overall goal: Ensure that the ‘production means’ are in place and mature. This check is not applied to single work packages, but to the ‘production means’ which will be used to construct work packages. Sub-goals: a) Determine that the high-level requirements and the basic specification artefacts are precisely defined and a baseline is established. b) Ensure that the high-level architecture and development means are in place and mature. c) Ensure that the necessary processes are defined and agreed on.

1B) Work package check: • Overall goal: Ensure that construction of a specific work package can safely start. This check is applied to each single work package. • Sub-goals: a) Ensure that the content which will be constructed within this work package is clearly defined. b) Determine that the internal design of the modules in the work package is defined. c) Ensure that the realization of the work package is planned, scheduled and staffed. Checkpoint 2: Result Handover Checkpoint (RHC) The RHC encompasses only one kind of evaluation. • •

Overall goal: Determine whether the result of work package construction is finished and completed according to the defined quality objectives. Sub-goals: a) Ensure that the result complies with the specification, the design and the architecture. b) Ensure that the result is complete and does comply with the quality objectives. c) Determine whether the estimation for the work package correct was correct.

We refined the sub-goals of the checkpoints into concrete checklist questions. These questions are augmented with concrete benchmarks derived from our completed GSD projects. These checklists are the central tool when we apply our handover checkpoints. Using handover checkpoints fits well to the use of agile methods: The onsite and offshore team members need to synchronize on the handover checkpoints but can use their own processes in between the checkpoints. This supports fast cooperation ramp up, as not team has to learn the processes of the other team in every detail [15]. Obviously this can be especially supportive when working with sub-contractors (e.g. in an offshore outsourcing mode). When using Scrum for example, the scope of a ‘sprint’ resembles to the scope of a work package. In the ‘sprint meeting’, the precise list of work units which are bundled by the work package and the schedule for the construction of the work package would be defined. The sprint meeting would be finished by the application of the WPHC. In turn, the RHC could be applied during the ‘retrospective meeting’ after completion of a sprint. Applying agile methods in GSD is however a challenging field and requires further research [16]. We believe that the discussed overall goals and the sub-goals of the checkpoints will look very similar even for different companies engaged in offshore custom software development. The concrete questions and benchmarks however might differ:

On the Use of Handover Checkpoints to Manage the GSD Process

273

This is the tailoring point, where a practitioner could derive his own questions from the sub-goals according to the needs of his company. At Capgemini sd&m, we already use so called ‘quality gates’ in order to assess the content of software requirements specifications [14, 18] and software architectures [19]. These quality gates however have the main goal to find major problems which put project success at risk, like for example the ignorance of non-functional requirements or missing alignment of the architecture to the business and user requirements. As such, they concentrate on the ‘higher-levels’ of software architecture and software requirements specifications. We apply the quality gates in GSD as well, but complement them by the finer grained checkpoints which concentrate on the specifics of GSD. This is also necessary due to the fact that in GSD, problems with single work packages get the attention of the management less easily than in collocated development settings: Awareness and insight into status is impeded by high distribution [9, 17].

4 Benefits from Using Work Packages Handover Checkpoints We now describe the benefits we obtained by using work packages and handover checkpoints in our GSD projects by showing, how our approach addresses the problems discussed in section 2. 1. Mitigation of problem ‘Too little process structure’ The handover checkpoints effectively stage the development process. They allow the transfer of responsibility in a defined manner. The comprehensive checklists used in the checkpoints ensure that the ‘receiving’ teams can safely start their work. 2. Mitigation of problem ‘Missing concept to bundle work units’ The definition of ‘work package’ helps to bundle cohesive and self-contained sets of work units. This helps to regulate the communication between distributed teams, as it reduces the need for repeatedly inquiring missing information. 3. Mitigation of the problem ‘Undefined acceptance criteria and quality objectives’. In the WPHC, the use of precisely defined acceptance criteria and quality objectives is checked. This makes clear, when a single work unit or a complete work package is ‘finished’, and allows effective earned value analysis. In the RHC, compliance of the result to the defined criteria and objectives is checked. 4. Mitigation of problem ‘Missing alignment of engineering disciplines’ In the RHC it is checked whether work packages results where constructed within time and budget, while meeting the defined quality objectives. It is also checked, how deviations to the plan are considered by the project management, and whether their impact on the overall schedule is estimated. This continuously re-aligns the engineering disciplines with the management disciplines. 5. Mitigation of problem ‘Insufficient knowledge transfer’ In both handover checkpoints it is assessed, how knowledge transfer was carried out and maintained. The checkpoints also mandate the controlling of the knowledge transfer, i.e., the project must implement mechanisms to ensure the effectiveness of the knowledge transfer.

274

F. Salger

Taken together, the notions of ‘handover checkpoints’ and ‘work packages’ supports clear handovers of responsibilities based on precisely defined work packages, allow earned value analysis, align the engineering disciplines and ensure effective knowledge transfer in GSD.

5 Conclusion and Future Work We discussed some of the most prevalent problems encountered in managing global software development (GSD). These were • • • • •

Too little process structure Missing concept to bundle work units Undefined acceptance criteria and quality objectives Missing alignment of engineering disciplines Insufficient knowledge transfer.

Based on this discussion, we motivated the need for handover checkpoints. We then presented an overview on the handover checkpoints used at Capgemini sd&m to safely manage GSD. Finally, we reported on the benefits already gained at Capgemini sd&m from applying our notion of work packages and handover checkpoints. These are: • • • • •

Precisely defined, cohesive and self-contained sets of work units Clear handover of responsibilities Support for management discipline (e.g. by supporting earned value analysis) Alignment of the management with the engineering disciplines Effective knowledge transfer

We are continuously applying the notion of work packages and the handover checkpoints within our GSD projects very successfully. In short, the use of work packages and handover checkpoints allow clear handovers of responsibilities based on precisely defined work packages. This in turn allows earned value analysis, aligns the engineering disciplines and ensures effective knowledge transfer for large GSD projects. Further research is however necessary in order to economically optimize our approach: • •

• •

How can the application of handover checkpoints be supported by tools? Here, some promising results are already available (see e.g. [20]). How can we avoid isolating the distributed teams from each other if we further decrease communication by using strong modularization? How can we avoid, that the teams only concentrate on their work package while neglecting to consider the overall big picture of the system (see also [21, 22])? How do handover checkpoints fit into different process models like the Rational Unified Process [23] or Scrum [16]? How do handover checkpoints fit to other models of work distribution (see, e.g., [24]).

On the Use of Handover Checkpoints to Manage the GSD Process

275

References 1. Cusumano, M.A.: Managing Software Development in Globally Distributed Teams. Communications of the ACM 51(2), 15–17 (2008) 2. Sangwan, R., Bass, M., Mullik, N., Paulish, D., Kazmeier, J.: Global Software Development Handbook. Auerbach Publications (2006) 3. Battin, R.D., Crocker, R., Kreidler, J., Subramanian, K.: Leveraging Resources in Global Software Development. IEEE Software 18(2), 70–72 (2001) 4. Cusick, J., Prasad, A.: A Practical Management and Engineering Approach to Offshore Collaboration. IEEE Software 123(5), 20–29 (2006) 5. Kommeren, R., Parviainen, P.: Philips Experiences in Global Distributed Software Development. Empirical Software Engineering 2(6), 647–660 (2007) 6. Hussey, J.M., Hall, S.E.: Managing Global Development Risks. Auerbach Publications (2007) 7. Smite, D.: Requirements Management in Distributed Projects. Journal of Universal Knowledge Management, J.UKM 1(2), 69–76 (2006) 8. Herbsleb, J.D.: Global Software Engineering: The Future of Socio-technical Coordination. In: Proc. of Future of Software Engineering, pp. 188–198. IEEE Computer Society Press, Los Alamitos (2007) 9. Damian, D., Chisan, J., Allen, P., Corrie, B.: Awareness meets requirements management: awareness needs in global software development. In: Proc. of the International Workshop on Global Software Development, International Conference on Software Engineering, pp. 7–11 (2003) 10. Parnas, D.L.: On the Criteria To Be Used in Decomposing Systems into Modules. Communications of the ACM 15(12), 1053–1058 (1972) 11. Conway, M.: How Do Committees Invent? Datamation 14(4), 28–31 (1968) 12. Herbsleb, J.D., Grinter, R.E.: Architectures, Coordination, and Distance: Conway’s Law and Beyond. IEEE Software 16(5), 63–70 (1999) 13. Herbsleb, J.D., Grinter, R.E.: Splitting the Organisation and Integrating the Code: Conway’s Law Revisited. In: Proc. of the 21th International Conference on Software Engineering, pp. 85–95. IEEE Computer Society Press, Los Alamitos (1999) 14. Salger, F., Sauer, S., Engels, G.: An Integrated Quality Assurance Framework for Specifying Business Information Systems. In: Proc. of the Forum at the 21th International Conference on Advanced Information Systems, pp. 25–30. CEUR (2009) 15. Paasivaara, M., Lassenius, C.: Collaboration Practices in Global Inter-organizational Software Development Projects. Software Process Improvement and Practice 8, 183–199 (2004) 16. Hossain, E., Babar, M.A., Paik, H.: Using Scrum in Global Software Development: A Systematic Literatur Review. In: Proc. of the 4th International Conference on Global Software Engineering. IEEE Press, Los Alamitos (2009) 17. Herbsleb, J.D., Paulish, D.J., Bass, M.: Global Software Development at Siemens. Experience from Nine Projects. In: Proc. of the 27th International Conference on Software Engineering, pp. 524–533. IEEE Press, Los Alamitos (2005) 18. Salger, F., Engels, G., Hofmann, A.: Inspection Effectiveness for Different Quality Attributes of Software Requirement Specifications: An Industrial Case Study. In: Proc. of the 7th ICSE Workshop on Software Quality, pp. 15–21. IEEE Computer Society Press, Los Alamitos (2009)

276

F. Salger

19. Salger, F., Bennicke, M., Engels, G., Lewerentz, C.: Comprehensive Architecture Evaluation and Management in Large Software-Systems. In: Becker, S., Plasil, F., Reussner, R. (eds.) QoSA 2008. LNCS, vol. 5281, pp. 205–219. Springer, Heidelberg (2008) 20. Gupta, A.: The 24-Hours Knowledge Factory: Can it Replace the Graveyard Shift? Computer 42(1) (2009) 21. Cataldo, M., Bass, M., Herbsleb, J.D., Bass, L.: Managing Complexity in Collaborative Software Developoment: On the Limits of Modularity. In: Proc. of the Workshop on Supporting the Social Side of Large-Scale Software Development, Conference on Computer Supported Cooperative Work 2006. ACM, New York (2006) 22. Ebert, C., Neve, P.: Surviving Global Software Development. IEEE Software 18(2), 62–69 (2001) 23. Rational Unified Process. IBM Coporation. Version 7.0.1. 2000 (2007) 24. Carmel, E.: Global Software Teams. Prentice Hall PTR, Englewood Cliffs (1999)

Exploiting Process Knowledge for Event Processing in Distributed Business Applications Holger Ziekow International Computer Science Institute 1947 Center Street, Berkeley, CA 94704, USA [email protected]

Abstract. In this paper, we address event processing for applications in distributed business processes. For this application context we present an approach for improving in-network processing of events. We highlight the role of a priori process knowledge for query optimization and describe distributed event processing based on decision points in the process.

1

Introduction

Event-based interaction plays a central role in a number of emerging distributed business processes. A prominent example is monitoring logistic events in supply chains. In such applications we can observe two trends: (1) emerging technologies like RFID and smart sensors increase the level of detail for event capturing; and (2) globalization increases the dynamics and complexity of value chains. The value chain processes spread out across countries and organizations and partner relations change frequently. Business applications face the challenge to efficiently handle events in this environment. The foremost technological challenges are (a) the inherent distribution of event sources, (b) the large number of events, and (c) the dynamics of the underlying business processes. Distributed event-based systems (DEBS) provide the technological basis for addressing these challenges. They allow decentralizing tasks of event dissemination and processing. In this paper we tailor technologies of DEBS to applications where events are generated by business processes. By exploiting process knowledge we are able to realize optimizations that go beyond optimizations in generic event-based system. The remainder of the paper is structured as follows. In Section 2 we review related work. Section 3 provides background information about the application context. It introduces an exemplary system setup from the RFID domain that we will use for illustrating our approach. Section 4 presents a mechanism for using process knowledge in distributed event processing and illustrates the benefits along a basic example. Section 5 concludes the paper and outlines future work. 

The author’s second affiliation is the Institute of Information Systems at the Humboldt-Universit¨ at zu Berlin.

R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 277–281, 2009. c Springer-Verlag Berlin Heidelberg 2009 

278

2

H. Ziekow

Related Work

Over the past few years, technologies for event processing gained increasing attention in the research community [2,3]. Most relevant to our approach is existing work on in-network processing. Solutions for in-network processing are concerned with deploying operators into a network of processing resources. Much work has been done in the field of sensor networks. Examples from this domain are TinyDB [4] and HiFi [5]. These systems aim to apply operators in the sensing network for reducing energy consuming communication. Srivastava et al. optimize operator placement for hierarchical networks of heterogeneous devices [8]. Pietzuch et al. use network coordinates for efficient operator placement in networks of large scale [7]. Due to space limitations we refrain from an more exhaustive discussion of related work. However, all approaches to our knowledge optimize operator deployment solely based on the query and some information on the processing network. Our work additionally uses process knowledge and thereby introduces new measures for optimization.

3

Events in Collaborative Business Applications

A business event is a happening of interest in the business world [6]. In collaborative value chains, the processes are distributed across several locations that belong to different organizations. Collaborating companies exchange business events to streamline their processes. A prominent example is an RFIDenabled supply chain, where supply chain partners exchange events to monitor the shipment process. We will use this example for illustration throughout the paper. The push based exchange of RFID related events is supported by the EPCIS standard [1]. This standard allows for ad-hoc queries as well as standing queries for RFID events. Companies can query the EPCIS of their partners to capture RFID events along the supply chain. The underlying event model is based on the Electronic Product Code (EPC) that provides a globally unique numbering scheme for physical objects. The event model allows associating the observation of an object with a timestamp, a location, and the corresponding business step. The EPCIS interface enables continuous queries with filters on the event attributes. However, correlation of events from different sources is not supported. Monitoring business distributed processes therefore requires event correlation at the query sink (i.e., the monitoring application). This architecture is inefficient compared to solutions that support processing in the network [7]. We therefore propose to use a processing network that links event sources with applications (see Figure 1). The network provides distributed resources that can run parts of the monitoring query. It has been shown that such an architecture improves efficiency [7]. Our work targets query processing in such an infrastructure. We subsequently show how we can exploit particularities of the application domain to optimize distributed event processing.

Exploiting Process Knowledge

279

MonitoringApplication CorrelatedRFIDEvents

DistributedProcessingNetwork FilteredRFIDEvents EPCISCompany1 RFIDEvents

EPCISCompany2 RFIDEvents

B

A

C

ProcessCompany1

D

E

ProcessCompany2

Fig. 1. System architecture

4

Optimization with Process Knowledge

In this paper we describe how to exploit timing information and decision points in process models for query optimization. Using this a priori process knowledge allows optimizing event processing for each instantiation of a process. Our goal is to optimize the query deployment. That is, we optimize the mapping of query operators to processing resources and the data flow between them. Optimizing a query deployment for a certain process instance necessarily yields better results than a generic deployment which considers all options for the process. However, when the process starts, it is not known what the instance will look like; i.e. how decisions will be made at decision points. We must therefore evaluate decision points as the process runs, in order to consecutively align the deployment to the current process instance. We can thereby come close to an optimal query deployment for each process instance. The basic idea is as follows: Passing a decision point during process execution narrows down the options for how the process continuous. To exploit this, we deploy a query such that evaluation of the first decision point in the process is possible. We then direct event messages according to the remaining options for the process. We thereby adapt distributed processing to the current process instance. For illustration consider the process in Figure 2. It shows a simple process that is distributed across five organizations. Instantiations of this process can create event sequences of the form (A,B1,D1), (A,B1,D2), or (A,B2,D2). Further consider the simple sequence query A→B→D2 that matches process instances of the form (A,B1,D2) and (A,B2,D2). Without process knowledge, one must register for all event sources and detect the instances that end with D2 (see operator 1 in Figure 3, left side). However, we can exploit process knowledge as

280

H. Ziekow

5Ͳ7days Org2 Org1

A

Org3 1Ͳ2days

Org5

B1

Org4

B2

D1

D2

Fig. 2. Sample process

Withknowledgeabouttiming

Stateoftheart Query sink

Query sink

A,B1,D2 orA,B2,D2 Org1

B1

Org4

OrgN

Eventsourceat organizationN Eventstream thatneedsfiltering

D2 Org4

B2

B2 Org3

A’

2 Org1 A

D2

Org2

3 B1

A,B2

1

A

A,B1,D2 orD2

Org2

Org5

Org5

Org3

1

Eventprocessingoperator Runninginthenetwork

Streamwithlow bandwidth consumption

Streamwithlow bandwidth consumption

Fig. 3. Query deployment with/without process knowledge

follows: We first detect the decision at the first decision point in the process. We therefore simply register a query at A and B2 (see operator 2 in Figure 3, right side). Given the process knowledge, we can infer that the current instance will generate the event sequence (A,B2,D2) if B2 follows A within 2 days. At this point we already know that the query will match and send the events A,B2 right to the sink. If we get a timeout for B2, we know that process may generate the sequences (A,B1,D1) or (A,B1,D2) and further processing is required. We then forward the corresponding events A’ to a query deployment that is optimized for detecting (A,B1,D2) (see operator 3 in Figure 3, right side). This operator matches incoming events A,B1,D2 and forwards them to the sink. Incoming D2 without preceding events A,B1 are forwarded to the sink as well. This is because we know from the process model that A,B2 must have occurred before. Figure 3 illustrates the effect on query deployment in the network. The figure visualizes event sources, locations for query operators, and the query sink in

Exploiting Process Knowledge

281

a latency space. The arrows mark the data flow. The thickness of the arrows roughly corresponds to the consumed bandwidth. Dotted arrows mark event streams where a portion is filtered out by the operators. An efficient deployment decentralizes processing and minimizes the product of bandwidth and latency. Figure 3 illustrates that high bandwidth event streams travel shorter distances when using process knowledge for optimization. This reduces the overall network load in the system and thereby the efficiency of the query processing. Another advantage is that the optimized deployment distributes load more evenly across resources than the original one. Note, that each operator must handle fewer events in the optimized deployment.

5

Conclusions and Future Work

In this paper we presented optimizations for in-network processing based on process knowledge. We illustrated how to exploit timing information and decision points. In future work we plan to quantify the effect of our optimizations with simulations and experiments in distributed computer network PlanetLab.

References 1. EPCglobal. Epc information services (epcis) version 1.0.1 specification (2007), http://www.epcglobalinc.org/standards/epcis/ epcis 1 0 1-standard-20070921.pdf (last accessed 10/6/2009) 2. Fiege, L., Muhl, G., Pietzuch, P.R.: Distributed Event-based Systems. Springer, Heidelberg (2006) 3. Luckham, D.C.: The Power of Events: An Introduction to Complex Event Processing in Distributed Enterprise Systems. Addison-Wesley Longman Publishing Co., Inc., Boston (2001) 4. Madden, S.R., Franklin, M.J., Hellerstein, J.M., Hong, W.: Tinydb: an acquisitional query processing system for sensor networks. ACM Trans. Database Syst. 30(1), 122–173 (2005) 5. Owen, S.D., Cooper, O., Edakkunni, A., Franklin, M.J., Hong, W., Jeffery, S.R., Krishnamurthy, S., Reiss, F., Rizvi, S., Wu, E.: Hifi: A unified architecture for high fan-in systems. In: VLDB, pp. 1357–1360. Demo (2004) 6. Patankar, A., Segev, A.: An architecture and construction of a business event manager. In: Etzion, O., Jajodia, S., Sripada, S. (eds.) Dagstuhl Seminar 1997. LNCS, vol. 1399, pp. 257–280. Springer, Heidelberg (1998) 7. Pietzuch, P., Ledlie, J., Shneidman, J., Roussopoulos, M., Welsh, M., Seltzer, M.: Network-aware operator placement for stream-processing systems. In: ICDE 2006, Washington, DC, USA, p. 49. IEEE Computer Society, Los Alamitos (2006) 8. Srivastava, U., Munagala, K., Widom, J.: Operator placement for in-network stream query processing. In: PODS 2005, pp. 250–258. ACM Press, New York (2005)

Distributed Information System Development: Review of Some Management Issues Deepti Mishra and Alok Mishra Department of Computer Engineering Atilim University, Ankara, Turkey [email protected], [email protected]

Abstract. Due to the proliferation of the Internet and globalization, distributed information system development is becoming popular. In this paper we have reviewed some significant management issues like process management, project management, requirements management and knowledge management issues which have received much attention in distributed development perspective. In this literature review we found that areas like quality and risk management issues could get only scant attention in distributed information system development. Keywords: Global software development, Distributed information system development, Distributed Software Development.

1 Introduction More and more organizations have distributed their software development projects in different sites around the globe. As the software community appreciates, the economy of merging diverse development skills and domain expertise, and as communication media become more sophisticated, the cost and technology pushes more companies toward global software development [45]. With the need of reduced software product development cost and time and improved software quality, software products are increasingly developed via collaborations across people, organizations, and countries [5][56]. The accounts about cheaper work and “follow the sun” approaches are fading, while factors like proximity to the markets, access to specific expertise, productive friction and innovation capability tend to take the lead in driving the trend toward global software development [2]. This change is having a profound impact on the way products are conceived, designed, constructed, tested and delivered to customers [45][27][13]. Thus, the structure needed to support this kind of development is different from the ones used in collocated environments [45]. Therefore it is important to take into account this evolving paradigm of distributed information system development from different perspectives. It is significant to note that although software implementation tasks may be moved from countries with high labor costs to countries with low cost relatively easily due to the Internet and common programming environments, tasks requiring intensive customer interaction , such as requirement analysis and specification, software design, R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 282–291, 2009. © Springer-Verlag Berlin Heidelberg 2009

Distributed Information System Development: Review of Some Management Issues

283

and verification and validation, are hard to migrate [34]. High organizational complexity, scheduling, task assignment and cost estimation become more problematic in distributed environments as a result of volatile requirements, changing specifications, cultural diversity and lack of informal communication [10]. Due to many conflicts, global software development projects are often more complex to manage. Engineers, managers and executives face formidable challenges on many levels, from the technical to the social and cultural [22]. Environments and processes in typical software development are not fully adapted to the needs of global software development [41]. In particular, they do not have all the capabilities necessary for cross-site collaboration [41]. In their recent report, Smite et al. [50] concluded that the state of practice in the GSE (Global Software Engineering) area is still unclear and evolving. There are very few review studies [50][24] in literature. Although systematic literature reviews provide a summary of research and references but still lack in presenting coherent and similar views on emerging sub areas. After an extensive literature survey, we found that knowledge management, process management, project management and requirements management have received much attention among researchers while studies on risk management, quality management, strategic management issues are very limited in distributed information system development. Jimenez et al. [24] have also supported in their recent study that maturity models such as CMMI or ISO represent only 17% of all analyzed works. Therefore this paper presents cohesive and recent trends in these areas which are getting much attention among researchers and also suggest those areas which require further research in software development in distributed environment. The paper is organized as follows. The next section describes significant management issues based on literature review for distributed software development (Knowledge Management, Process Management, Project Management and Requirements Management). Finally, it concludes with discussions.

2 Management Issues in Distributed Information System Development 2.1 Knowledge Management The knowledge-intensive nature of global software development efforts poses interesting challenges for organizations. Knowledge must be managed in all stages of software development from the encapsulation of design requirements, to program creation and testing, to software’s installation and maintenance-and even extends to the improvement of organizational software development processes and practices [14]. More often, distributed projects require them to coordinate and integrate multiple knowledge sources, often under severe time pressure and resource and budgetary constraints. For workers to succeed in these engagements, the organization must have a robust knowledge management program [14]. Knowledge management issues becomes exponentially salient in the context of distributed and global software development efforts as knowledge is spread across locations and coordinating and synthesizing this knowledge is challenging [15]. A recurring theme in distributed

284

D. Mishra and A. Mishra

software development is that informal communication is critical for rapidly disseminating implicit knowledge, in particular, with respect to change and unforeseen events [8] which increases dramatically as the size and complexity of the software increases [31]. Without effective information and knowledge-sharing mechanisms, managers cannot exploit GSDs benefits. For instance, they might fail to promptly and uniformly share information from customers and the market among the development teams [22]. Common knowledge management problems in global software efforts include the inability to seek out relevant knowledge, poor aggregation and integration procedures for knowledge synthesis, and delays or blockages of knowledge transfer [14]. Unless organizations manage knowledge and leverage it appropriately in global software development efforts, the vitality of such efforts is compromised, and they become a burden rather than a competitive advantage [14]. Desouza and Evaristo [15] found three strategies that are currently in use for setting up knowledge management programs: -

In a headquartered-commissioned-and-executed strategy In a headquarters-commissioned-and regionally-executed strategy A regionally-commissioned-and-locally-executed strategy

Desouza et al. [14] mentioned that once the strategy is adopted it is important to setup a knowledge management system (KMSs) which can be from the client-server model, the peer-to-peer model, and the hybrid model. In their recent paper, Lopez et al. [35] suggested that in the Knowledge Management and Awareness area more research should be done, as 100% of its safeguards are proposed. Studies focusing on global software team performance point to the importance of knowledge sharing in building trust and improving effectiveness, while recognizing the additional complexity in sharing knowledge across geographically dispersed sites, not least because of the tacit dimension of so much knowledge [29][43]. Despite the fact that most of the problems reported in global software projects are fundamentally to do with information and knowledge, past research not focused on the role of knowledge sharing and social aspects of global software projects [30]. They found in their studies and suggested that managers should consider their organization in terms of knowledge processes, not just information flows and must focus on how coordination mechanisms facilitate knowledge processes. They argued that coordination mechanisms become knowledge management instruments, with a focus on their contribution to the coherence of knowledge processes and activities in achieving a coordinated outcome. Kotlarsky et al. [30] proposed a research model on coordination for a knowledge-based perspective and concluded that technologies are most useful for amplifying knowledge management processes to allow knowledge sharing while organization design facilitates knowledge flows across organizations and teams. Work-based mechanisms make knowledge explicit and accessible, while social mechanisms are needed to build social capital and exchange knowledge and ideas. Distributed environments must facilitate knowledge sharing by maintaining a product/process repository focused on well understood functionality by linking content from sources such as e-mail, and online discussions, and sharing metadata information among several tools [24]. To overcome drawbacks caused by distribution, Babar [3] proposes the application of an electronic workspace paradigm to capture and share metadata information among several tools. Zhuge [57] introduced a knowledge repository in which information

Distributed Information System Development: Review of Some Management Issues

285

related to each project is saved by using internet-based communication tools, thus enabling a new team member to become quickly experienced by learning the knowledge stored. Mohan and Ramesh [36] provided an approach based on a traceability framework that identifies the key knowledge elements which are to be integrated and a prototype system that supports the acquisition, integration, and use of knowledge elements, allowing the knowledge fragements stored in diverse environment to be integrated and used by various stakeholders in order to facilitate a common understanding. 2.2 Process Management The selection of the right development approach is necessary to address issues such as lack of users’ knowledge of application, lack of users’ involvement, missing, incorrect and evolving requirements, and risks associated with new technology and poor quality [7]. The software development process is considered one of the most important success factors for distributed projects [45]. Unclear requirements and new technologies make the waterfall model unsuitable for offshore developing strategic systems [47]. Although the use of a spiral model is uncommon in the development of business information systems, the strategic importance of a system warrants detailed planning, experimentation, verification, validation and risk management provided by the spiral model [47]. According to Simons [49], an iterative model seems to work well in distributed environment and can eliminate some of the problems that distribution brings. Moreover, iterative development with frequent deliveries provides increased visibility into project status, which makes it easier for project managers and customers to follow project progress [49]. Fowler [18] and Simons [49] emphasize that the main benefits of using agile development in their projects have been the high responsiveness to change and fast delivery of business value and these benefits have outweighed the challenges of distributed development. Layman et al. [33] conducted an industrial case study to understand how a globally distributed team created a successful project in a new problem domain using eXtreme Programming (XP) that is dependent on informal face-to-face communication. They found that many of the hallmarks of the face-to-face communication advocated in XP are adquately approximated through the team’s use of three essential communication practices: an email listserv, globally-available project management tool and an intermediary development manager who played a strong role in both groups. Nisar and Hameed [42] and Xiaohu et al. [54] describe their experiences in using XP in offshore teams collaborating with onshore customers. Both papers discuss projects where the development work is done in offshore teams only but the onshore customer is tightly involved in project communication. They concluded that the reported projects have been very successful and XP principles they have followed have proven to work [42][54]. Karlsson [26] and Farmer [17] found the XP practices useful but hard to implement in distributed projects. Sangwan and Laplante [48] reported that geographically distributed development teams in large projects can realize Test Driven Development’s (TDD) considerable advantages. With good communication and judicious use of automated testing, they can overcome many problems [48]. The transition from unit to system level testing is challenging for TDD, as in general TDD

286

D. Mishra and A. Mishra

is not intended to address system and integration testing – certainly not for globally distributed development teams at any rate [48]. Still developers can realize the advantages of TDD through increased informal and formal communication, facilitated by appropriate change management and notification tools [48]. Test frameworks like the Xunit family are also appropriate at the systems level if developers are sufficiently disciplined in developing test cases [48]. Finally, the use of commercial or open source test workbenches and bug repositories to track test case dependencies and test failures is essential [48]. The maturity of the process becomes a key success factor. Passivaara and Lassenius proposed incremental integration and frequent deliveries by following informing and monitoring practices [44]. Recently, SoftFab tool infrastructure which enables projects to automate the building and test process and which manages all the tasks remotely by a control center was given by Spanjers et al. [51]. The automation of the process through an adaptable tool is consequently necessary in order to manage tasks and metrics through customizable reports managed by a central server and ensuring the application of the development processes in compliance with a predefined standard [24]. There is still scope towards defining the process framework and maturity level standards like CMMI, SPICE etc. for distributed software development towards quality. 2.3 Project Management Global software development literature brings up many challenges related to distributed development, e.g., interdependencies among work items to be distributed, difficulties of coordination, difficulties of dividing the work into modules that could be assigned to different locations, conflicting implicit assumptions that are not noticed as fast as in collocated work and communication challenges [40]. Managing a global virtual team is more complex than managing a local virtual team [39]. Effort estimation in software development is a major problem of project management [25]. Currently available tools may not provide an accurate estimation of development efforts in virtual environment [47]. It has been reported that multi-site software development introduces additional delay and thus takes much longer than single-site development [21]. However, the projects studied do not seem to have utilised the time difference between sites and thus have not exploited an ‘around the clock’ work pattern [52]. The global software development model opens up the possibility of 24-hour software development by effectively utilizing the time zone differences [23]. To harness the potential of the 24hour software development model for reducing the overall development time, a key issue is the allocation of project tasks to the resources in the distributed teams [23]. The project tasks have vaious constraints for its execution: operational constraints, skill constraints, resource constraints etc. [23]. In some projects there may be some tasks that have collocation requirements i.e. engineering working on these tasks should be together [16]. Clearly, to maximize the reduction in completion time through the 24 hour model, task assignment needs to be done carefully, so that the project can be completed in minimum execution time while satisfying all the constraints [23]. Literature suggests dividing the work into separate modules that then can be distributed to different sites to be developed [20]. These modules should be

Distributed Information System Development: Review of Some Management Issues

287

independent in order to minimize communication between sites [20]. Frequent deliveries are also recommended as a successful GSD collaboration practice [44]. The project manager has a greater role to co-ordinate, communicate, facilitate the group process and ensure participation of all members [4]. They act as mentors, exhibit empathy, are assertive without being overbearing, articulate role relationships, build relationships and trust and provide detailed and regular communications with the group members [28]. In addition, they define the interaction protocol for guiding the group behavior in virtual environment [9] and ensure prompt interactions in asynchronous communications [47]. Layman et al. [33] suggested that high process visibility is important for the customers to guide the project effectively while the developers are working on a new and unfamiliar problem. A major study of a global virtual group has many recommendations for an effective virtual group process [38]. The effectiveness depends on a match between the message complexity in the group process and the form of interaction medium [47]. Increased task interdependence in a group process will increase the interaction frequency, and increased task complexity will increase the messge complexity, which in turn, affects the choice of the interaction medium [47]. Computer-mediated asynchronous communication is suitable for structured and well-defined tasks [37][38] such as coding according to system specifications. Such type of global software development tasks still needs early face-to-face communication to define team members roles and to enhance the effectiveness of later computer-mediated communications [32]. 2.4 Requirement Management Most requirements are difficult to identify and identified requirements are unclear and not well organized [13]. These problems are exacerbated in global software development [13]. A key issue to achieve success in GSD is overcoming the pitfalls which GSD poses to RE [35]. Cheng and Atlee [11] recently identified globalization as a hot research topic regarding Requirements Engineering (RE). This new paradigm implies that many of the RE activities have to undergo changes, as it is no longer possible to carry them out as if the participants were collocated. Initial studies show that distributed quality assurance of software code is feasible [6][19], but distributed quality assurance of requirements definition that need high user involvement would have a high task coupling until requirement definitions are formalized and made user-friendly [47]. During software requirement elicitation, lack of fluent communication is one of the most important challenges in discussion [55]. Therefore various factors affecting communication should be considered when analyzing virtual teams working on requirements definition, minimizing communication problems towards ensuring quality of the software in construction [1]. As requirements management activities are primarily impacted by distance [12], GSD projects benefit from requirements specifications well defined at the onset of the project [53], thus avoiding the need to reiterate feature understanding. These specifications are often used in planning processes, important in the organization and managing of distributed projects [46]. Layman et al [33] suggested that an identifiable customer authority is necessary to manage and resolve requirements related issues in a globally distributed team using XP.

288

D. Mishra and A. Mishra

3 Discussions and Conclusion In this paper, we have reviewed some significant management issues like process and project management, requirements management and knowledge management issues from a global/distributed software/information system development perspective. Distributed software development is an evolving area. It is important to know the latest development through rigorous literature review to learn further new knowledge in different significant dimensions. As a future work, we would like to extend this review on various other attributes, dimensions and comparisons. Further we would like to include that area which could get only scant attention in distributed software development, for instance quality, and risk management issues. Various case studies may be included to enrich these management perspectives related with distributed information system development. However it is interesting to note as observed by Smite et al. [50] that these studies present results from significantly different contexts and backgrounds and may not applicable as a general standard in all contexts. They further viewed that unclarities inherited in reported studies may not only burden the reader’s understanding, but also drive “lessons learned” applied in to be wrong way. Therefore there is a need to build the body of knowledge on how to manage global software development projects which will classify experiences and practices that will help to achieve positive results, in order to understand circumstances and also contexts.

References 1. Aranda, G.N., Vizcaino, A., Cechich, A., Piattini, M.: Technology Selection to Improve Global Collaboration. In: Proceedings of the IEEE international Conference on Global Software Engineering, ICGSE, October 16-19, pp. 223–232. IEEE Computer Society, Washington (2006) 2. Avram, G.: Of Deadlocks and Peopleware - Collaborative Work Practices in Global Software Development. In: Proceedings of the international Conference on Global Software Engineering, ICGSE, August 27- 30, pp. 91–102. IEEE Computer Society, Washington (2007) 3. Babar, M.A.: The application of knowledge-sharing workspace paradigm for software architecture processes. In: Proceedings of the 3rd international Workshop on Sharing and Reusing Architectural Knowledge, SHARK 2008, Leipzig, Germany, May 13, pp. 45–48. ACM, New York (2008) 4. Bal, J., Foster, P.: Managing the virtual team and controlling effectiveness. International Journal of Production Research 38(17), 4019–4032 (2000) 5. Bass, M., Paulish, D.: Global software development process research at Siemens. In: Proc. of Intl. workshop on global software development, Edinburgh, Scotland 6. Bianchi, A., Caivano, D., Lanubile, F., Visaggio, G.: Defect Detection in a Distributed Software Maintenance Project. In: Proc. of the International Workshop on Global Software Development (GSD 2003), Portland, Oregon, USA, May 2003, pp. 48–52 (2003) 7. Boehm, B.W.: Software risk management. IEEE computer society Press, New York (1989) 8. Bruegge, B., Dutoit, A.H., Wolf, T.: Sysiphus: Enabling informal collaboration in global software development. In: Proceedings of the IEEE international Conference on Global Software Engineering, ICGSE, October 16-19, pp. 139–148. IEEE Computer Society, Washington (2006)

Distributed Information System Development: Review of Some Management Issues

289

9. Cascio, W.: Managing a virtual workplace. Academy of Management Executive 14(3), 81– 90 (2000) 10. Casey, V., Richardson, I.: Project Management Within Virtual Software Teams. In: 2006 IEEE International Conference on Global Software Engineering, ICGSE 2006. Proceedings, Florianopolis, Brazil, October 16-19, pp. 33–42 (2006) 11. Cheng, B.H., Atlee, J.M.: Research directions in requirements engineering. In: Future of Software Engineering, FOSE 2007, pp. 285–303 (2007) 12. Damian, D.E., Zowghi, D.: RE challenges in multi-site software development organisations. Requirements Engineering Journal 8, 149–160 (2003) 13. Damian, D.E., Zowghi, D.: The Impact of Stakeholders? Geographical Distribution on Managing Requirements in a Multi-Site Organization. In: Proceedings of the 10th Anniversary IEEE Joint international Conference on Requirements Engineering, RE, September 9-13, pp. 319–330. IEEE Computer Society, Washington (2002) 14. Desouza Kevin, C., Awazu, Y., Baloh, P.: Managing Knowledge in Global Software Development Efforts: Issues and Practices. IEEE Software 23(5), 30–37 (2006) 15. Desouza, Evaristo: Managing Knowledge in distributed projects. Communications of the ACM 47(4), 87–91 (2004) 16. Ebert, C., De Neve, P.: Surviving Global Software Development. IEEE Softw. 18(2), 62– 69 (2001) 17. Farmer, M.: DecisionSpace Infrastructure: Agile Development in a Large, Distributed Team. In: Proceedings of the Agile Development Conference, ADC, June 22-26, pp. 95– 99. IEEE Computer Society, Washington (2004) 18. Fowler, M.: Using agile software process with offshore development, http://martinfowler.com/articles/agileOffshore.html 19. Hedberg, H., Harjumaa, L.: Virtual Software Inspections for Distributed Software Engineering Projects. In: Proceedings of International Workshop on Global Software Development (Co-located with ICSE 2002), Orlando, Florida (2002) 20. Herbsleb, J.D., Grinter, R.E.: Architectures, Coordination, and Distance: Conway’s Law and Beyond. IEEE Softw. 16(5), 63–70 (1999) 21. Herbsleb, J.D., Mockus, A., Finholt, T.A., Grinter, R.E.: An empirical study of global software development: distance and speed. In: Proceedings of the 23rd international Conference on Software Engineering, Toronto, Ontario, Canada, May 12-19, pp. 81–90. IEEE Computer Society, Washington (2001) 22. Herbsleb, J.D., Moitra, D.: Guest Editors’ Introduction: Global Software Development. IEEE Softw. 18(2), 16–20 (2001) 23. Jalote, P., Jain, G.: Assigning Tasks in a 24-Hour Software Development Model. In: Proceedings of the 11th Asia-Pacific Software Engineering Conference, APSEC, November 30 - December 3, pp. 309–315. IEEE Computer Society, Washington (2004) 24. Jimenez, M., Piattini, M., Vizcaino, A.: Challenges and Improvements in Distributed Software Development: A Systematic Review. Advances in Software Engineering 2009, 1–14 (2009) 25. Jones, C.: Why software fails. Software Development 4(1), 49–54 (1996) 26. Karlsson, E., Andersson, L., Leion, P.: Daily build and feature development in large distributed projects. In: Proceedings of the 22nd international Conference on Software Engineering, ICSE 2000, Limerick, Ireland, June 4-11, pp. 649–658. ACM, New York (2000) 27. Karolak, D.W.: Global software development managing virtual teams and environments. IEEE Computer Society, Los Alamitos (1998)

290

D. Mishra and A. Mishra

28. Kayworth, T.R., Leidner, D.E.: Leadership Effectiveness in Global Virtual Teams. J. Manage. Inf. Syst. 18(3), 7–40 (2002) 29. Kotlarsky, J., Oshri, I.: Social ties, knowledge sharing and successful collaboration in globally distributed system development projects. Eur. J. Inf. Syst. 14(1), 37–48 (2005) 30. Kotlarsky, J., Van Fenema, P.C., Willcocks, L.P.: Developing a knowledge-based perspective on coordination: the case of global software projects. Information and management 45(2), 96–108 (2008) 31. Kraut, R.E., Streeter, L.A.: Coordination in software development. Commun. ACM 38(3), 69–81 (1995) 32. Kruempel, K.: Making the right (interactive) moves for knowledge-producing tasks in computer-mediated groups. IEEE Transactions on Professional Communication 43, 185– 195 (2000) 33. Layman, L., Williams, L., Damian, D., Bures, H.: Essential communication practices for extreme programming in a global software development team. Information and Software Technology 48(9), 781–794 (2006) 34. Liu, X.: (Frank) Collaborative Global Software Development and Education. In: Proceedings of the 29th Annual International Computer Software and Applications Conference, COMPSAC 2005 (2005) 35. Lopez, A., Nicolas, J., Toval, A.: Risks and Safeguards for the Requirements Engineering Process in Global Software Development. In: 4th International Conference on Global Software Engineering. IEEE Press, Los Alamitos (2009) 36. Mohan, K., Ramesh, B.: Traceability-based Knowledge Integration in group decision and negotiation activities. Decision Support Systems 43(3), 968–989 (2007) 37. Majchzak, A., Rice, R.E., King, N., Malhotra, A., Ba, S.: Computer-mediated interorganizational knowledge-sharing: Insights from a virtual team innovating using a collaborative tool. Inf. Resour. Manage. J. 13(1), 44–53 (2000) 38. Maznevski, M.L., Chudoba, K.M.: Bridging Space Over Time: Global Virtual Team Dynamics and Effectiveness. Organization Science 11(5), 473–492 (2000) 39. McDonough, E.F., Kahn, K.B., Barczak, G.: An investigation of the use of global, virtual, and collocated new product development teams. Journal of Product Innovation Management 18(2), 110–120 (2001) 40. Mockus, A., Herbsleb, J.: Challenges of global software development. In: Software Metrics Symposium, METRICS 2001. Proceedings. Seventh International, pp. 182–184 (2001) 41. Mullick, N., Bass, M., Houda, Z., Paulish, P., Cataldo, M.: Siemens Global Studio Project: Experiences Adopting an Integrated GSD Infrastructure. In: Proceedings of the IEEE international Conference on Global Software Engineering, ICGSE, October 16-19, pp. 203–212. IEEE Computer Society, Washington (2006) 42. Nisar, M.F., Hameed, T.: Agile methods handling offshore software development issues. In: Multitopic Conference, 2004. Proceedings of INMIC 2004. 8th International, pp. 417– 422 (2004) 43. Orlikowski, W.J.: Knowing in Practice: Enacting a Collective. Capability in Distributed Organizing 13(3), 249–273 (2002) 44. Paasivaara, M., Lassenius, C.: Collaboration practices in global inter-organizational software development projects. Software Process: Improvement and Practice 8(4), 183– 199 (2004) 45. Prikladnicki, R., Audy, J.L.N., Evaristo, R.: A Reference Model for Global Software Development: Findings from a Case Study. In: Proc. IEEE Int’l Conference on Global Software Engineering (ICGSE 2006), Florianópolis, Brazil, pp. 18–25. IEEE Computer Society Press, Los Alamitos (2006)

Distributed Information System Development: Review of Some Management Issues

291

46. Prikladnicki, R., Audy, J.L.N., Evaristo, R.: Global software development in practice lessons learned. Software Process: Improvement and Practice 8(4), 267–281 (2003) 47. Sakthivel, S.: Virtual workgroups in offshore systems development. Information and Software Technology 47(5), 305–318 (2005) 48. Sangwan, R.S., LaPlante, P.A.: Test-Driven Development in Large Projects. IT Professional 8(5), 25–29 (2006) 49. Simons, M.: Internationally Agile. InformIT (March 15, 2002) 50. Smite, D., Wohlin, C., Feldt, R., Gorschek, T.: Reporting Empirical Research in Global Software Engineering: A Classification Scheme. In: 2008 IEEE International Conference on Global Software Engineering, ICGSE, pp. 173–181 (2008) 51. Spanjers, H., ter Huurne, M., Graaf, M., Lormans, M., Bendas, D., van Solingen, R.: Tool support for distributed software engineering. In: Proceedings of the IEEE International Conference on Global Software Engineering (ICGSE 2006), Florianopolis, Brazil, October 2006, pp. 187–198 (2006) 52. Taweel, A., Brereton, P.: Modelling software development across time zones. Information and Software Technology 48(1), 1–11 (2006) 53. Tiwana, A.: Beyond the Black Box: Knowledge Overlaps in Software Outsourcing. IEEE Softw. 21(5), 51–58 (2004) 54. Xiaohu, Y., Bin, X., Zhijun, H., Maddineni, S.R.: Extreme programming in global software development. In: Canadian Conference on Electrical and Computer Engineering, 2004, vol. 4, pp. 1845–1848 (2004) 55. Young, R.: Recommended Requirements Gathering Practices. CROSSTALK The Journal of Defence Software Engineering, 9–12 (2002) 56. Zamiska, N.: Quality lures software outsourcing. The Wall Street Journal ( May 5, 2005) 57. Zhuge, H.: Knowledge flow management for distributed team software development. Knowledge-Based Systems 15(8), 465–471 (2002)

IWSSA 2009 PC Co-chairs’ Message Important changes in society are being predicted for the very near future. In many countries, governments look ahead by increasing reserve funds and budgets for strategically critical areas in order to identify key issues and find effective solutions. Not surprisingly, many institutions are launching research and development programs focused on health-care, elderly people, quality of life, social inclusion, energy, education, ecology, etc. Innovation is required for systems supporting such a new assisted, interactive and collaborative world. System and software designers have to be able to address how to reflect in the same system/software architecture a great amount of (sometimes conflicting) requirements. In particular, user-oriented nonfunctional requirements and developer-oriented non-functional requirements (or design constraints) gain special relevance due to the new environments in which the systems have to operate. These are the proceedings of the 8th International Workshop on System/Software Architectures (IWSSA 2009), and it was the second time that the workshop was held in association with On The Move Federated Conferences and Workshops (OTM). As in the previous series of this workshop, the present edition received an ever increasing response with a total of 36 abstract submissions out of which, on the basis of the reviews and of the topics of the workshop, 15 papers were finally selected as full papers. The rest of the papers also deserve special mention because they were well rated – we regret that we could not accommodate more papers, but we hope to be able to see submissions of improved versions to IWSSA 2010. This time again, authors of selected quality papers, from those presented at IWSSA 2009, were invited to submit significantly extended and improved versions to the review process for a special issue of a well-recognized journal. The papers included in the proceedings address cutting-edge techniques, methodologies and processes for designing system and software architectures intended to connect requirements (both functional and non-functional) to architectural models and work spaces. In particular, the selected papers cover important quality attributes of software systems ranging from users’ requirements (security, reliability, usability, collaboration, etc.) to developers’ requirements (reusability, change management and evolution, maintainability, scalability, etc.). These papers highlight what appears to be a clear trend in recent technologies (model-driven approaches, aspects, services, business process modeling, etc.) towards developing quality architectures along different phases in the software lifecycle, namely: requirements modeling, design, implementation and assessment, etc. Most papers include both theoretical contents and real case studies for systems with varying traditional scopes and applications, such as enterprise and collaboration, and also for emerging ones such as mobile and ubiquitous computing and ambient assisted living. These papers contributed to a successful workshop with enriching discussions. The workshop aimed at being an appropriate forum where the sharing of knowledge and experiences about system/software architectures promotes new advances in both research and development. We hope that readers can enjoy the papers in the proceedings.

R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 292–293, 2009. © Springer-Verlag Berlin Heidelberg 2009

Preface

293

We would like sincerely to thank all OTM organizers for their constant help and support, the Program Committee members for their excellent work and invaluable support during the review process, and most importantly the authors of the papers for their very interesting and quality contributions, which make possible this workshop series every year. August 2009

Lawrence Chung Manuel Noguera Nary Subramanian José Luis Garrido

Towards a Fault-Tolerant Architecture for Enterprise Application Integration Solutions Rafael Z. Frantz1 , Rafael Corchuelo2, and Carlos Molina-Jimenez3 1

2

UNIJU´I, Departamento de Tecnologia - Iju´ı, RS, Brazil [email protected] Universidad de Sevilla, ETSI Inform´atica - Avda. Reina Mercedes, s/n. Sevilla 41012, Spain [email protected] 3 School of Computing Science, University of Newcastle, UK [email protected]

Abstract. Enterprise Application Integration (EAI) solutions rely on process support systems to implement exogenous message workflows whereby one can devise and deploy a process that helps keep a number of applications’ data in synchrony or develop new functionality on top of them. EAI solutions are prone to failures due to the fact that they are highly distributed and combine stand-alone applications with specific-purpose integration processes. The literature provides two execution models for workflows, namely, synchronous and asynchronous. In this paper, we report on an architecture that addresses the problem of endowing the asynchronous model with fault-tolerance capabilities, which is a problem for which the literature does not provide a conclusion. Keywords: Enterprise Application Integration, Fault-Tolerance.

1 Introduction The computer infrastructure of a typical today’s enterprise can be conceived as an heterogenous set of applications (termed the software ecosystem [15]) that includes tens of applications purchased from different providers or built at home in the last 20 years or even earlier. Examples of typical applications are payroll and sales systems. A recurrent challenge that appears in these scenarios is to make the existing application interoperate with each other to keep the data used by them synchronised or to create new funcionality[9]. This problem is known as Enterprise Application Integration (EAI). In either case, the challenge is about devising and deploying a number of wrapping processes responsible for interacting with the individual applications and a number of integration processes responsible for managing the flow of messages among the applications. A good alternative to support the design of the integration process is the use of Process Support Systems (PSS): a piece of middleware which, among other functionalities, provides means for specifying distributed processes (e.g. EAI solutions) and for monitoring their executions [8]. Good examples of PSSs are conventional workflow systems [8]. PSSs based on BPEL [18] are discussed in [21]. Examples of PSSs with focus on EAI solutions are BizTalk [4], Tibco [20], Camel [6] and Mule [17]. R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 294–303, 2009. c Springer-Verlag Berlin Heidelberg 2009 

Towards a Fault-Tolerant Architecture for EAI Solutions

295

A typical approach in the design of EAI is the use of a database to store inbound messages (messages coming from the individual applications to the integration process) until all the messages needed to start the integration process arrive. A distinctive feature of this approach is that it involves only a simple message workflow composed by several tasks that receive, transform and send outbound messages (messages out of the integration process to the applications); tasks might also request a wrapping process to interact with an application, fork the message workflow, and so on. A notorious limitation of this approach is that it uses memory inefficiently in applications where requests issued by tasks to individual applications take long (hours or days) to fulfil. In these situations the integration process instance remains blocked until the response arrives. Though some techniques have been proposed to ease this limitation (notably, dehydration and rehydration [4,21]), we consider the synchronous approach unsatisfactory; thus in this article we explore the suitability of asynchronous integration processes. The distinctive feature of the asynchronous approach is that it uses a single multi-threaded process instance per wrapping or integration process to handle all the messages. Consequently, processes that require multiple inbound messages need to include tasks to correlate messages internally. The appealing side of this approach is its efficiency in resource consumption[7,11]. EAI solutions are inherently distributed: they involve several applications that might fail and communicate over networks that might unexpectedly delay, corrupt or even loose messages. Thus they are susceptible to a wide variety of failures [8,19]. To be of practical use, EAI solutions need to include fault–tolerance mechanisms [1]. Fault–tolerance in the context of PSS is not a new topic; several authors have studied the problem before but only within the context of the synchronous approach discussed above and with a single process in mind, i.e., overlooking typical EAI solutions that involve several wrapping and integration processes. To help cover, this gap in this paper we propose a solution based on an asynchronous approach with fault-tolerance features. The only assumption we make is that messages produced by integration processes are enriched with information about the original messages used to produce them. The remainder of this paper is structured as follows: Section 2 discusses related literature; Section 3, introduces relevant concepts. The architecture that we propose is presented in Section 4; Section 5, presents a case study; finally, we draw conclusions in Section 6.

2 Related Work Our discussion on fault-tolerance in EAI is closely related to the issue of distributed long-running transactions introduced in[16]. This seminal work inspired research aimed at the design of process support systems with fault–tolerance features. The effort resulted in several proposals that can be roughly categorised into two classes: algorithm–based where algorithms are used to handle faults automatically and fault– handling–based where faults are handled by rules defined by the designer. An abstract model for workflows with fault–tolerance features is discussed in [3]; this paper also provides a good survey on fault-tolerance approaches. An algorithm for implementing transactions in distributed applications where the participating applications co–operate

296

R.Z. Frantz, R. Corchuelo, and C. Molina-Jimenez

to implement a distributed protocol is presented in [1]. An algorithm for the execution of BPEL processes with relaxed transactions where the all or nothing property is relaxed is presented in [12]. In [13] the authors enhance their approach with a rule–based language for defining specific-purpose recovery rules. An algorithm for handling faults automatically in applications integrated by means of workflow management systems and amenable to compensation actions or to the two– phase commit protocol, is suggested in [8]. Exception handling in applications where compensation actions are difficult or infeasible to implement is discussed in [14]. [2] proposed an architecture to implement fault-tolerance based on ad–hoc workflows. For instance using a web server as a front-end, an application server, a database server and a logging system. They assume that a workflow is always activated on arrival of one request message which flows through the components of the workflow; thus, their recovery mechanism relies on the trace of every message through the system. An architecture for fault–tolerant workflows, based finite state machines (message sequence charts) that recognise valid sequence of messages of the workflow is discussed in [5]. Recovery actions are triggered when a message is found to be invalid, or the execution time of the state machine goes beyond the expected time. An approach to provide fault–tolerance to already implemented Petri net controllers is presented in [11] and [7]. The original controller is embedded unaltered into a new controller with the original functionality but enlarged with additional places, connections, and tokens, aimed at detecting failures. A discussion on how to provide Petri net–modelled discrete event systems is also presented. From the analysis of the previous proposals, we conclude that they share a number of common issues. They all deal with a single process, except for [2], which can neither deal with multiple inbound messages. This is a shortcoming because a typical EAI solution involves several wrapping and integration processes; note, too, that the inability to deal with multiple inbound messages is problematical insofar an integration process can be activated by a single application, but there are many applications where an integration process is started by the occurrence of multiple inbound messages arriving from different applications. Another common limitation among the works mentioned above is that, with the exception of [7,11], they support only the synchronous execution model. In addition, the proposals that deal with the asynchronous model focus on Petri Net controllers, i.e., they neglect the problems of distributedness, software ecosystems, and so on.

3 Definitions 3.1 EAI Solutions As shwon in Fig. 1, a typical EAI solution has several wrapping processes used to communicate the solution with applications and several integration processes that implement the integration business logic. Processes use ports to communicate with each other or with applications over communication channels. Ports encapsulate tasks functionalities like receive, request and send; and help abstract away from the details of the communication mechanism, which may range from an RPC-based protocol over HTTP to a document-based protocol implemented on a database management system.

Towards a Fault-Tolerant Architecture for EAI Solutions

297

Fig. 1. Layers of a typical EAI solution

3.2 Failure Semantics A dependable system is one on which reliance can be placed on the service that it delivers. Fault-tolerance is an important means to achieve dependability. Faults, errors and failures represent impairments to dependability [10]. A fault may be internal to the EAI solution or external (within the software ecosystem). In both cases, when they occur, they are the cause for errors that impact the EAI solution. Errors represent the point where the EAI solution deviates from its normal processing and if not handled lead the solution to a failure perceived by the user. The general assumption we make about the reliability of the components involved in an EAI solution is that they might occasionally fail. Internal faults might occur in components of the EAI solution, such as processes, ports and communication channels; furthermore, external faults might occur in the software ecosystem. To provide EAI solutions with a mechanism to tolerate failures, we first need to identify the failure semantics that its components are likely to exhibit and stipulate what kind of errors the EAI solution should be able to tolerate: detect at runtime and execute a corresponding error recovery action to handle the specific error. Our architecture accounts for the following failures: omission, response, timing, and message processing failures. Omission Failures (OMF): We assume that once a communication operation is started by a port, it terminates within a strictly defined time interval and reports either success or failure. OMF model situations where network, application and communication channel problems prevent ports from sending or receiving a piece of data within the time interval. Response Failures (REF): REF are caused by responders (an application or communication channel) sending incorrect messages. Thus before being acceptable for processing, messages need to satisfy a validation test (e.g., headers and body inspected) that results in either success of failure. Timing Failures (TMF): A message has a deadline to reach the end of the flow, which is verified by ports. Ports report success for timely messages and failure for messages with overrun deadlines. Both internal and external faults influence TMF. Message Processing Failures (MPF): Ports and processes signal MPF when they are unable to complete the process of a message; otherwise success is signalled.

298

R.Z. Frantz, R. Corchuelo, and C. Molina-Jimenez

4 Architectural Proposal The architecture we propose to provide fault-tolerance for EAI solutions is shown in Fig. 2 as a metamodel. This metamodel introduces the components involved in the construction of rules, exchange patterns, and mechanisms for error detection and recovery. As depicted in the metamodel, an EAISolution can define multiple ExchangePatterns (MEPs) and Rules. Events are notifications to the monitor, generated by Sources inside the EAI solution, that in conformance with our failure semantics have type EventTriggerMessageType to report successes or failures during the workflow execution. Source can be a Port or a Process. Each MEP defines a set of inbound and outbound source ports, from which events are reported. A rule is composed of a Condition and an Action. So, a condition can be SimpleCondition, represented by only a single event, or CompositeCondition, which contains two conditions connected by a LogicalOperator. When the condition is true, action executes the corresponding error recovery action defined by the rule. The Monitor observes one or more EAI solutions to detect potential failures and triggers mechanisms to handle them. As shown in Fig. 3 the monitor is composed of a Log, a SessionCorrelator, an ExchangeEngine, a RuleEngine, an EntryPort, and ExitPorts. 4.1 The Logging System The logging systems is represented by the Log where all success and failure events reported by sources inside EAI solutions are permanently stored. The monitor receives

Fig. 2. Metamodel of an EAI solution with fault–tolerance

Towards a Fault-Tolerant Architecture for EAI Solutions

299

Fig. 3. Abstract view of the monitor

events through an entry port and stores them in the log from where they are available to the other components of the monitor. Roughly speaking, the log is composed of several LogEntries that record information about events, such as, the fully qualified event source name, date and time of occurrence, and a copy of the message under process at the time of occurrence of the event. By qualified, we mean the name of the EAI solution that originated the event, followed by the unique name of the source inside the solution. Name uniqueness of sources of events allows the monitor to observe one or more EAI solutions simultaneously. The log is shared by the session correlator, the exchange engine, and the rule engine. It can also provide information to a MonitoringSystem, interested in assessing the health state of an EAI solution. 4.2 The Session Correlator The session correlator session-correlates messages inside the log. Its output is used by the exchange engine to determine the state of MEPs instances and to trigger recovery actions. Since in our architecture a task within a process can take several input messages and produce several output messages, it is not trivial to determine what messages belong to different workflow sessions. To solve the problem, we enrich composed messages with information about the original messages used to compose them; next we establish a parent–child relationship between messages to session–correlate them: two arbitrary messages ma and mb are session–correlated if ma is the parent of mb or mb is the parent of ma . Likewise, three messages ma , mb and mc are session-correlated if mc is an ancestor of both ma and mb . 4.3 The Exchange Engine The exchange engine is responsible for managing MEPs. A MEP represents a sequence of message exchange among the participating applications. The textual notation we use to specify MEPs is shown in Fig. 4. An EAI solution can have one or more MEPs, thus different message workflows can occur inside a given EAI solution. MEPs deal only with messages of success type from the ports listed in Inbound and Outbound sets, so there is no need to explicitly specify types. When the exchange engine finds two or more session-correlated messages in the log which came from different ports in a MEP, it creates an instance of this MEP and associates to it a max time– to–live parameter; max time–to–live is global and imposes a deadline on the instance to successfully complete. The session-correlated messages may fit into more than one

300

R.Z. Frantz, R. Corchuelo, and C. Molina-Jimenez

Fig. 4. Syntax of Exchange Patterns and Rules

MEP, so in this case an instance of each MEP will be created. Inbound contains a set of fully qualified port names, from where inbound messages come. Similarly, Outbound contains a set of port names to where outbound messages are reported. The syntax for a fully qualified name is as follows: eai solution name:: process name::port name, where eai solution name defaults to EAISolution. The job of the exchange engine is to detect completed, in-progress and incomplete MEPs in an EAI solution; also it detects messages that has been in the log for a long time without participating in any MEPs; we call them odd messages. A completed MEP instance indicates that several correlated inbound messages were processed successfully by an EAI solution’s workflow within the max time-to-live deadline; the exchange engine detects them by finding all session-correlated outbound messages for this MEP instance in the log. An in-progress MEP instance contains two or more correlated messages (not necessary outbound) in the log, has not overrun its max time-to-live deadline, and is waiting for more outbound message(s) to arrive. An in-progress MEP instance is declared incomplete when its deadline expires. MEP instances fail to complete due to failures detected during their workflow execution, thus they trigger the rule engine which, if necessary, initiates the execution of error recovery actions (see Fig. 5). It is possible that an incomplete MEP instance might be completed beyond its deadline and after the execution of its error recovery action. Situations like this are detected and signalled by the monitoring system. 4.4 The Rule Engine The rule engine is responsible for managing the Event–Condition–Action (ECA) rules of EAI solutions. When the condition of a rule evaluates to true, i.e., a set of sessioncorrelated messages that activate it is found, the rule engine creates an error recovery message and invokes an error recovery action by means of an exit port. The error recovery action contains the logic to handle the error. Error recovery actions are external to the monitor, and, although they are designed specially to be executed against an application or communication channel, they can be reused if necessary. Rules take into account both success and failure events. Additionally, events came not only from ports but also from processes, and contain source–name and event–type, cf. Fig. 2. The general syntax is: eai solution name::source name:event type. If the source is a port, then it must also include the name of the process to which the port belongs, cf. Fig. 5.

Towards a Fault-Tolerant Architecture for EAI Solutions

301

Fig. 5. Example of EAI solution with fault-tolerance

5 Case Study To illustrate our approach, an EAI solution for a fictitious company is shown in Fig. 5. It integrates five applications deployed before the EAI solution which were not designed with EAI integration in mind and run independently from each other. The EAI solution has one integration process and five wrapping processes, one for each application. i The main goal of the solution is to collect bills from the Billing System (BS), merge them with their corresponding order(s) provided by the Inventory System (IS) and to produce a single merged message. A copy of the merged message is sent to the CRM System (CS) while a second copy is sent to the Notification System (NS) which is responsible for notifying the customer about his or her purchase. Finally, a third copy of the message is sent to the Purchase System (PS) which stores records of purchases. A bill may be associated with more than one order; in this case the order number is used to compute local correlation. To better illustrate some features of our architecture we assume some constraints imposed on the EAI solution. First, the merged message must be successfully sent to the CS and PS by Port 3 and Port 4, respectively. Any failure that prevents one of the applications from receiving the session-correlated message triggers the execution of a recovery action against the application that succeeded. Second, inbound message(s) are successfully processed in two situations: when all target applications (CS, PS and NS) receive the session-correlated message, or when only the CS and the PS receive it. Failures in Port 5 do not invalidate the workflow execution, they only trigger the execution of an error recovery action that stores records stating that the customer could not be notified. The design of error recovery actions are out of the scope of this paper. The last constraint to this EAI solution is that orders and bills are delivered within 2 to 5 seconds to the target applications.

302

R.Z. Frantz, R. Corchuelo, and C. Molina-Jimenez

To account for these constraints, the EAI solution has two MEPs and three rules, cf. Fig. 5. The first MEP defines two inbound ports and two outbound ports. This implies that a MEP instance is completed when session-correlated messages for all these ports are found in the log. The second MEP also includes Port 5 in the outbound list; this represents another alternative for the EAI solution to complete successfully. In cases when an incomplete MEP is detected by the exchange engine, the rules are evaluated by the rule engine and the corresponding recovery actions are executed.

6 Conclusion We have proposed an architecture for EAI solutions enhanced with fault–tolerant features, in the context of process support systems. We argued that existing proposals that deal with fault-tolerance in the context of process support systems are based on synchronous execution models and consequently, are memory consumption inefficient. In response, we explored an asynchronous execution model. We introduced our architecture proposal from the perspective of its metamodel; it includes a monitor that detects failures and triggers recovery actions. We discussed and addressed different classes of failures. MEPs and rules are configured by means of an ECA-based language that is part of the proposed architecture. Incomplete MEPs cause the activation of rules to execute error recovery actions. To support our ideas we presented a case study. Acknowledgements. The first author conducted part of this work at the University of Newcastle, UK as visiting member of staff. His work is partially funded by the Evangelischer Entwicklungsdienst e.V. (EED). The second and first authors are partially funded by the Spanish National R&D&I Plan under grant TIN2007-64119, the Andalusian Local Government under grant P07-TIC-02602 and the research programme of the University of Seville. The third author is partially funded by UK EPSRC Platform Grant No. EP/D037743/1.

References 1. Campbell, R.H., Randell, B.: Error recovery in asynchronous systems. IEEE Trans. Soft. Eng. 12(8), 811–826 (1986) 2. Chen, M.Y., Accardi, A., Kiciman, E., Lloyd, J., Patterson, D., Fox, A., Brewer, E.: Pathbased faliure and evolution management. In: Proc. Int’l Symp. Netw. Syst. Des. and Impl., p. 23 (2004) 3. Chiu, D., Li, Q., Karlapalem, K.: A meta modelng approach to workflow management systems supporting exception handling. Inf. Syst. 24(2), 159–184 (1999) 4. Dunphy, G., Metwally, A.: Pro BizTalk 2006. Apress (2006) 5. Ermagan, V., Kruger, I., Menarini, M.: A fault tolerance approach for enterprise applications. In: Proc. IEEE Int’l Conf. Serv. Comput., vol. 2, pp. 63–72 (2008) 6. Apache Foundation. Apache Camel: Book In One Page (2008) 7. Hadjicostis, C.N., Verghese, G.C.: Monitoring discrete event systems using petri net embeddings. In: Proc. 20th Int’l Conf. Appl. and Theory of Petri Nets, pp. 188–207 (1999) 8. Hagen, C., Alonso, G.: Exception handling in workflow management systems. IEEE Trans. Softw. Eng. 26(10), 943–958 (2000)

Towards a Fault-Tolerant Architecture for EAI Solutions

303

9. Hohpe, G., Woolf, B.: Enterprise Integration Patterns - Designing, Building, and Deploying Messaging Solutions. Addison-Wesley, Reading (2003) 10. Laprie, J.C.: Dependability - its attributes, impairments and means. In: Predicting Dependable Computing Systems, pp. 3–24 (1995) 11. Li, L., Hadjicostis, C.N., Sreenivas, R.S.: Designs of bisimilar petri net controllers with fault tolerance capabilities. IEEE Trans. Syst. Man Cybern. Part A: Syst. Humans 38(1), 207–217 (2008) 12. Liu, A., Huang, L., Li, Q., Xiao, M.: Fault-tolerant orchestration of transactional web services. In: Proc. Int’l Conf. Web Inf. Syst. Eng., pp. 90–101 (2006) 13. Liu, A., Li, Q., Huang, L., Xiao, M.: A declarative approach to enhancing the reliability of bpel processes. In: Proc. IEEE Int’l Conf. Web Services, pp. 272–279 (2007) 14. Liu, C., Orlowska, M.E., Lin, X., Zhou, X.: Improving backward recovery in workflow systems. In: Proc. 7th Int’l Conf. Database Syst. Adv. Appl., p. 276 (2001) 15. Messerschmitt, D., Szyperski, C.: Software Ecosystem: Understanding an Indispensable Technology and Industry. MIT Press, Cambridge (2003) 16. Molina, H.G., Salem, K.: Sagas. SIGMOD Rec. 16(3), 249–259 (1987) 17. MuleSource. Mule 2.x User Guide (2008) 18. OASIS. Web Services Business Process Execution Language Version 2.0 Specification (2007) 19. Peltz, C.: Web services orchestration: a review of emerging technologies, tools, and standards. Technical report, Hewlett-Packard Company (2003) 20. TIBCO. Tibco application integration software (June 2009) 21. Wright, M., Reynolds, A.: Oracle SOA Suite Developer’s Guide. Packt Publishing (2009)

Architectural Stability Rami Bahsoon1 and Wolfgang Emmerich2 1

School of Computer Science, The University of Birmingham Edgbaston, B15 2TT, Birmingham, UK [email protected] 2 London Software Systems, Dept. of Computer Science, University College London, Gower Street, WC1E 6BT, London, UK w.emmerich @cs.ucl.ac.uk

Abstract. One of the major indicators of the success (failure) of software evolution is the extent to which the software system can endure changes in requirements, while leaving the architecture of the software system intact. The presence of this “intuitive” phenomenon is referred to as architectural stability. The concept is still far from being understood and many architectural stability related questions are remained unanswered. Reflecting on our extensive research into the problem, we explore perspectives in handling the problem. We review existing research effort and discuss their limitations. We outline research challenges and opportunities.

1 Introduction Software requirements, whether functional or non-functional, are generally volatile; they are likely to change and evolve over time. The change is inevitable as it reflects changes in stakeholders’ needs and the environment in which the software system works. Software architecture is the earliest design artifact, which realizes the requirements of the software system. It is the manifestation of the earliest design decisions, which comprise the architectural structure (i.e., components and interfaces), the architectural topology (i.e., the architectural style), the architectural infrastructure (e.g., the middleware), the relationship among them, and their relationship to the other software artifacts (e.g., low-level design). One of the major implications of a software architecture is to render particular kinds of changes easy or difficult, thus constraining the software’s evolution possibilities [1]. A change may “break” the software architecture necessitating changes to the architectural structure (e.g., changes to components and interfaces), architectural topology, or even changes to the underlying architectural infrastructure. It may be expensive and difficult to change the architecture as requirements evolve. Conversely, failing to accommodate the change leads ultimately to the degradation of the usefulness of the system. Hence, there is a pressing need for flexible software architectures that tend to be stable as the requirements evolve. By a stable architecture, we mean the extent to which a software system can endure changes in requirements, while leaving the architecture of the software system intact. We refer to the presence of this “intuitive” phenomenon as architectural stability. R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 304–315, 2009. © Springer-Verlag Berlin Heidelberg 2009

Architectural Stability

305

Developing and evolving architectures, which are stable in the presence of change and flexible enough to be customized and adapted to the changing requirements is one of the key challenges in software engineering [2]. Ongoing research on relating requirements to software architectures has considered the architectural stability problem as an open research challenge [3; 4]. This is because the conflict between requirements volatility and architectural stability is a difficult one to handle [3]. As a result, many architectural stability related questions are remained unanswered [4]: For example, what software architectures (or architectural styles) are stable in the presence of the changing requirements, and how do we select them? What kinds of changes are systems likely to experience in their lifetime, and how do we manage requirements and architectures (and their development processes) in order to manage the impact of these changes? Meanwhile, industrial evidence reveals situations where high requirements volatility is the norm and much of the promise is leaved to the architecture in accommodating the changes. For example, the number of mergers between companies is increasing and this trend is bound to continue. The different divisions of a newly merged company have to deliver unified services to their customers and this usually demands an integration of their IT systems into the core architecture. The time frame is often so short that building a new system is not an option and therefore existing system components have to be integrated into a distributed system architecture to appear as an integrated computing facility. Secondly, the trend of providing new services or evolving existing services to target new customers, devises and platforms, and distribution settings (e.g., mobility setting) is increasing. For example, moving from a fixed distributed setting to mobility carries critical changes, mainly to non-functionalities, such as changes in availability, security, and scalability requirements. Often the core “fixed” architecture falls short in accommodating the requirements; henceforth, changes to the architecture becomes necessary. Thirdly, it is often the case that components are procured off-the-shelf, rather than built from scratch, in response to changes in requirements and then need to be integrated into the core architecture. These components often have incompatible requirements on the hardware and operating system platforms they run on. In many software systems, the architecture is the level that has the greatest inertia when external circumstances change and consequently incurs the highest maintenance costs when evolution becomes unavoidable [5]. Hence, a stable architecture which addresses such changes in requirements within limited resources and shorter time-tomarket is a significant asset for surviving the business, cutting down maintenance costs and creating value. Reflecting on our extensive research into the problem, we define architectural stability and explore perspectives in handling the problem. We review existing research effort and discuss their limitations. We outline research challenges and opportunities. The paper is further structured as follows. Section 2 looks at architectures and evolution. Section 3 explores perspectives in handling the architectural stability problem. Section 4 outlines research challenges and opportunities. Section 5 concludes.

306

R. Bahsoon and W. Emmerich

2 Architecture-Centric Evolution In Lehman’s terminology [6], there are two types of systems: these are E-type systems and S-type systems. E-Type systems that are embedded in real world applications and are used by humans for everyday business functions. Examples might be customer service, order entry, payroll, operating systems, databases engines. S-Type systems are executable models of a formal specification. The success of this software is judged by how well it meets the specification. For E-Type systems the “real world” is dynamic and ever changing. As the real world changes the specification changes and the E-Type systems need to adapt to these changes. Hence, E-Type systems tend to be evolvable. For S-Type systems the specification becomes invalid in the presence of change. In this paper, we deal with evolution and architectural stability of E-type systems. In software engineering, it has been known that focusing the change on program code leads to loss of structure and maintainability [7]. Upon managing the change of requirements considerable emphasis is thus placed on the architecture of the software system as the key artifact involved [2]. Architecture-centric evolution approaches pursue the software architecture as the appropriate level of abstraction for reasoning about, managing and guiding the evolution of complex software systems, and “synchronizing” the software requirements with its detailed design and implementation. A distinctive feature of these approaches is that they explicitly account for the non-functional requirements, the so-called quality attributes. As the quality attributes comprise the most substantial properties of the system, the evolution of such properties can be best reasoned about and managed at the architectural level. For example, the current trend is to build distributed systems architectures with middleware technologies such as Java 2 Enterprise Edition (J2EE) and the Common Object Request Broker Architecture (CORBA), resulting in the so-called middlewareinduced architectures. Middleware-induced architectures follow an architecturalcentric evolution approach, as the emphasis is placed on the induced architecture for simplifying the construction of distributed systems by providing high-level primitives for realizing quality attributes. Another example is from product-line architectures. Product lines, a family of products sharing the same architecture, inherently require domain-specific variation and evolution of various products. Due to the higher level of interdependency between the various software artifacts in a product-line, software evolution is too complex to be dealt with at the code level. An essential property of these architectures is that they should be stable over the projected life of the system.

3 Perspectives into Architectural Stability 3.1 Requirements Engineering Perspective Ongoing research on relating requirements to software architectures has considered the architectural stability problem as an open research challenge and difficult to handle. [4] proposed the “Twin Peaks” model, a partial and simplified version of the spiral model. The cornerstone of this model is that a system’s requirements and its architecture are developed concurrently; that is, they are “inevitably intertwined” and

Architectural Stability

307

their development is interleaved. [4] advocated the use of various kinds of patterns – requirements, architectures, and designs- to achieve the model objectives. As far as architectural stability is concerned, Nuseibeh had only exposed a tip of the “iceberg”: development processes that embody characteristics of the Twin Peaks are the first steps towards developing architectures that are stable in the face of inevitable changes in requirements. Nuseibeh noted that many architectural stability related questions are difficult and remain unanswered. Examples include: what software architectures (or architectural styles) are stable in the presence of changing requirements, and how do we select them? What kinds of changes are systems likely to experience in their lifetime, and how do we manage requirements and architectures (and their development processes) in order to manage the impact of these changes? With the motivation of bridging the gaps between requirements and software architectures, [3] noted that the goal-oriented approach to requirements engineering may support building and evolving software architectures guaranteed to meet its functional and non-functional requirements. In [8; 9], we reflected on the architectural stability problem with a particular focus on developing distributed software architectures induced by middleware. We advocated adjusting requirements elicitation and management techniques to elicit not just the current non-functional requirements, but also to assess the way in which they will develop over the lifetime of the architecture. These ranges of requirements may then inform the selection of distributed components technology, and subsequently the selection of application server products. Specifically, we considered the architecture stability problem from the distributed components technology in the face of changes in non-functional requirements. We argued that addition or changes in functional requirements could be easily addressed in distributed component-based architectures by adding or upgrading the components in the business logic. However, changes in non-functional requirements are more critical; they can stress architecture considerably, leading to architectural “breakdown”. Such a “breakdown” often occurs at the middleware level and is due to the incapability of the middleware to cope with the change in nonfunctional requirements (e.g., increased load demands). This may drive the architect/developer to consider ad-hoc or propriety solutions to realize the change, such as modifying the middleware, extending the middleware primitives, implementing additional interfaces, etc. Such solutions could be costly and unacceptable [9]. 3.2 A Value-Driven Design Perspective An established route to manage the change and facilitate evolution is a universal “design for change” philosophy, where the architecture is conceived and developed such that evolution is possible [12]. Parnas’s notion of the “design for change” is based on the recognition that much of the total lifecycle cost of a system is expended in the change and incurred in evolution. A system that is not designed for evolution will incur tremendous costs, which are disapropionate to the benefits. For a system to create value, the cost of a change increment should be proportional to the benefits delivered [21]. “Design for change” is thus promoted as a value-maximizing strategy provided one could anticipate changes [27]. The “Design for change” philosophy is believed to be a useful heuristic for developing flexible architectures that tend to be

308

R. Bahsoon and W. Emmerich

stable as requirements evolve. However, the challenge is that there is a general lack of adequate models and methods, which connect this technical engineering philosophy to value creation under given circumstances [27].[27] notes, “The problem in the field is that no serious attempt is made to characterize the link between structural decisions and value added”. That is, the traditional focus of software architecture is more on structural and technical perfection than on value. In addressing the architectural stability problem, linking structural decisions to future value becomes more necessary, as presumably evolvable but stable architecture should add value to the system that outweigh what expended in designing for change, as the change materializes[9]. Furthermore, from an economic perspective, the change in requirements is a source of uncertainty that confronts an architecture during the evolution of the software system. The change places the investment in a particular architecture at risk. Conversely, designing for change incurs upfront costs and may not render future benefits. The benefits are uncertain, for the demand and the nature of the future changes are uncertain. The worthiness of designing or re-engineering an architecture for change should involve a tradeoff between the upfront cost of enabling the change and the future value added by the architecture, if the change materializes. The value added, as a result of enabling the change on a given architecture, is a powerful heuristic which can provide a basis for analyzing: (i) the worthiness of designing for change, (ii) the worthiness of re-engineering the architecture, (iii) the retiring and replacement decisions of the architecture or its associated design artifacts, (iv) the decisions of selecting an architecture, architectural style, middleware, and/or design with desired stability requirements, and/or (v) the success (failure) of evolution. In ArchOptions [9], we have taken an economics-driven software engineering perspective to evaluate architectural stability using real options theory. We have adopted the view that software design and engineering activity is one of investing valuable resources under uncertainty with the goal of maximizing the value added. In particular, we have viewed evolving software as a value-seeking and valuemaximizing activity: software evolution is a process in which software is undergoing an incremental change and seeking value [9]. We attribute the added value to the flexibility of the architecture in enduring changes in requirements. Means for achieving flexibility are typical architectural mechanisms or strategies that are built-in or adapted into the architecture with the objective of facilitating evolution and future growth. This could be in response to changes in functional (e.g., changes in features) or non-functional requirements (e.g., changes in scalability demands). As we are assuming that the added value is attributed to flexibility, arriving at a “more” stable software architecture requires finding an architecture which maximizes the yield in the embedded or the adapted flexibility in an architecture relative to the likely changing requirements [9]. Optimally, a stable architecture is an architecture that shall add value to the enterprise and the system as the requirements evolve. By valuing the flexibility of an architecture to change, we have aimed at providing the architect/analyst with a useful tool for reasoning about a crucial but previously intangible source of value. This value can be then used for deriving “insights” into architectural stability and investment decisions related to evolving software. To value flexibility, we have contributed to a novel model, ArchOptions, which builds on an analogy with real options theory [9]. The model examines some critical likely changes in requirements and values the extent to which the architecture is flexible to endure

Architectural Stability

309

these changes. The model views an investment in an architecture as an upfront investment plus “continual” increments of future investments in likely changes in requirements. We have applied ArchOptions to two architecture-centric evolution problems: assessing the worthiness of re-engineering a “more” stable architecture in face of likely changes in future requirements, where we have taken refactoring as an example of re-engineering [9]; and informing the selection of a “more” stable middleware-induced software architecture in the face of future changes in nonfunctional requirements [9]. Our perspective has provided a compromise through linking technical issues to value creation. The approach has the promise to provide insights and a basis for analyses to support many of the concerns highlighted in previous sections. 3.3 Architectural Evaluation Perspective Evaluating architectural stability aims at assessing the extent to which the system of a given architecture is evolvable, while leaving the architecture and its associated design decisions unchanged as the requirements change. Approaches to evaluating software architectures for stability can be retrospective or predictive [1]. Both approaches start with the assumption that the software architecture’s primary goal is to facilitate the system’s evolution. Retrospective evaluation looks at successive releases of the software system to analyze how smoothly the evolution took place. Predictive evaluation provides insights into the evolution of the software system based on examining a set of likely changes and the extent to which the architecture can endure these changes. Retrospective Approaches. Jazayeri [1] motivated the use of retrospective approaches for evaluating software architectures for stability. His analyses rely on comparing properties from one release of the software to the next. The intuition is to see if the system’s architectural decisions remained intact throughout the evolution of the system, that is, through successive releases of the software. Jazayeri refers to this “intuitive” phenomenon as architectural stability. Retrospective analysis can be used for empirically evaluating an architecture for stability; calibrating the predictive evaluation results; and predicting trends in the system evolution [1] or to identify the components most likely that require attention, need restructuring or replacements, or to decide if it is time to entirely retire the system. Jazayeri’s approach uses simple metrics such as software size metrics, coupling metrics, and color visualization to summarize the evolution pattern of the software system across its successive releases. The evaluation assumes that the system already exists and has evolved. This approach is therefore tend to be unpreventive and unsuitable for early evaluation (unless the evolution pattern is used to predict the stability of the next release). Predictive Approaches. Predictive approaches to evaluating architectural stability can be applied during the early stages of the development life cycle to predict threats of the change on the stability of the architecture. Unlike retrospective approaches, predictive approaches are preventive; the evaluation aims to understand the impact of the change on the stability of the architecture if the likely changes need to be accommodated, so corrective design measures can be taken. Therefore, in predictive

310

R. Bahsoon and W. Emmerich

approaches, the effort to evaluation is justified as the evaluation is generally cost effective, when compared to retrospective approaches. A comprehensive survey [10] of architectural evaluation methods indicates that current approaches to architectural evaluation focus explicitly on construction and only implicitly, if not at all, on the phenomenon of software “evolution”. The survey includes representative methods like ATAM [11], SAAM [12], ARID [14], PASA/SPE [15] and ABAS [17]. These methods provide frameworks for software architects to evaluate architectural decisions with respect to quality attributes such as performance, security, reliability, and modifiability. Despite the concern with “change” and accommodating changes, none of these methods, addresses stability of an architecture over time. For example, ATAM and SAAM indicate places where the architecture fails to meet its modifiability requirements and in some cases shows obvious alternative designs that would work better. The evaluation decisions using these methods tend to be driven by ways that are not connected to, and usually not optimal for value creation. Factors such as flexibility, time to market, cost and risk reduction often have high impact on value creation [16]. Such ignorance is in stark contrast to the objective of architectural evaluation and where cost reduction, risk mitigation, and long-term value creation are among the major drivers behind conducting an evaluation for stability [9]. Such provision is important for it assists the objective assessment of the lifetime costs and benefits of evolving software, and the identification of legacy situations, where a system or component is indispensable but can no longer be evolved to meet changing needs at economic cost [5]. Interested reader may refer to [9], where we have highlighted the requirements for evaluating architectural stability, which address the pitfalls in existing methods.

4 Architecture Stability: Challenges and Opportunities Rapid technological advances and industrial evidence are showing that the architecture is creating its own maintenance, evolution, and economics problems. Part of the problem stems in (i) the rapid technological advancements where evolution is not limited to a specific domain but extends to “horizontally” cover several domains, (ii) the current practice in engineering requirements, which ignore the above, (iii) and the improper management of the evolution of these requirements and across different design artifacts of the software system. In subsequent sections, we highlight some open issues that future research may consider to address some architectural-centric software evolution problems. 4.1 Architectures Description Languages Although software evaluation methods are typically human-centred, formal notations for representing and analyzing architectural designs, generically referred to as Architectures Description Languages (ADLs), have provided new opportunities for architectural analysis [2] and validation ADLs are languages that provide features for modelling a software system’s conceptual architecture [18]. ADLs provide a concrete syntax and a conceptual framework for characterizing architectures. Examples are ACME[19], Darwin [20], C2, Rapide [22], Wright [14], UniCon [23], SADL [24],

Architectural Stability

311

etc. ADLs are often intended to model large, distributed, and concurrent systems. Evaluating the properties of such systems upstream, at the architectural level, can substantially lessen the costs of any errors. The formality of ADL renders them suitable for the manipulation by tools for architectural analysis. In the context of architectural evaluation, the usefulness of an ADL is directly related to the kind of analyses a particular ADL tends to support. The type of analyses and evaluation for which an ADL is well suited depends on its underlying semantic model. No notable research effort has explored the role of ADLs in supporting evaluating architectural stability. However, ADLs have the potential to support such evaluation. For instance comparing properties of ADL specifications for different releases of a software can provide insights on how the change(s) or the likely change(s) tends to threat the stability of the architecture. This can be achieved by analyzing the parts of newer versions that represent syntactic and semantic changes. Moreover, the analysis can provide insights into possible architectural breakdown upon accommodating the change. For example, the analysis may show how the change may break the architectural topology (e.g., style) and/or the architectural structure (e.g., components, connectors, interfaces ect.). We note that ADLs have potential for performing retrospective evaluation for stability, where the evaluation can be performed at a correspondingly high level of abstraction. Hence, the evaluation may be relatively less expensive as when compared, for example, to the approach taken by [1]. 4.2 Coping with Rapid Technological Advancements and Changes in Domain Assume that a distributed e-shopping system architecture, which relies on a fixed network needs to evolve to support new services, such as the provision of mobile eshopping. Moving to mobility, the transition may not be straightforward: the original distributed system’s architecture may not be respected, for mobility poses its own non-functional requirements for dynamicity that are not prevalent in traditional distributed setting such as change in location; resource availability; variability of network bandwidth; the support of different communication protocols; losses of connectivity when the host need to be moved; and so forth. These requirements may not be satisfied by the current fixed architecture, the built-in architectural caching mechanisms, and/or the underlying middleware. Replacement of the current architecture may be required. The challenge is thus to cope with the co-evolution of both the architecture and the non-functional requirements as we change domains. This poses challenges in understanding the evolution trends of non-functional requirements; designing architectures, which are aware of how these requirements will change over the projected lifetime of the software system and tend to evolve through the different domains. In software engineering, the use of technology roadmapping, for example, is left unexplored in predicting and eliciting change in requirements. Technology roadmapping is an effective technology planning tool which help identifying product needs, map them into technology alternatives, and develop project plans to ensure that the required technologies will be available when needed [25]. Technology roadmapping, as a practice, emerged from industry as a practical method of planning for new technology and product requirements. According to [25], a roadmap is not a prediction of future breakthroughs in the technology, but rather an articulation of requirements to support future technical

312

R. Bahsoon and W. Emmerich

Source: http://www.3g-generation.com/

Fig. 1. Company’s x technology road mapping showing the evolution of its mobile services as it moves from 2G to 3G and its value to the end user

needs. A roadmap is part of the business and/or the product strategy towards growth and evolution. Figure 1 is a product roadmapping of Company x, a mobile service provider. Figure 1 shows how the mobile services are said to evolve as we transit from 2G to 3G networking. As the bandwidth is improved, an emerging number of content-based services, ranging from voice, multi-media, data, and location-based services might be possible. This, in turn, will translate into future requirements (functional and nonfunctional), which need to be planned in advance so it can be accommodated by the architecture responsible for delivering the services. Note that many of the likely changes in the requirements may be derived from the roadmapping process, rather than the roadmap itself. As an example, M-banking is a service, which allows customers to check bank balances, view statements, and carry bank transactions using mobile phones. A distributed architecture of a banking system, which envisions providing such a service as the bandwidth is improved, may need to anticipate changes due to mobility like changes in security requirements, load, availability, etc. The architect may anticipate relevant change scenarios and ways of accommodating them on the architecture. 4.3 Traceability of Requirements to Architectures According [7], there is a positive feedback between the loss of software architecture coherence and the loss of software knowledge. Less coherent architectures requires more extensive knowledge in order to evolve the system of the given architecture. However, if the knowledge necessary for evolution is lost, the changes in the software will lead to faster deterioration of the architecture. Hence, planning for evolution and stable software architectures urges the need for traceability techniques, which traces requirements and their evolution back and forth into the architecture and aid in “preserving” the team knowledge. We define requirement to architecture traceability as the ability to describe the “life” of a requirement through the requirements engineering phase to the architecture phase in both forwards and backwards. Forwards demonstrates which (and how) architectural element(s) satisfy an individual requirement in the requirements specification. Backwards demonstrates which requirement(s) in the requirements specification an individual architectural element relate to and satisfy. Current architectural practices, however, do not provide support for traceability from the requirements specification to the architectural description. Maintaining traceability

Architectural Stability

313

“links” is necessary for managing the change, the co-evolution of both the requirements and the architecture, confining the change, understanding the change impact on both the structure and the other requirements, providing a support for automated reasoning about a change at a high level of abstraction. Further, such traceability “links” make it easier to preserve the acquired knowledge of the team through guided documentation. This may then minimize the impact of personnel losses, and may allow the enterprise to make changes in the software system without damaging the architectural integrity and making the software system unevolvable. 4.4 Architectural Change Impact Analysis Although change impact analysis techniques are widely used at lower levels of abstractions (e.g., code level) and on a relatively abstract levels (e.g., classes in O.O. paradigm), little effort has been done on the architectural level (i.e., architectural impact analysis). Notable effort using dependency analysis on the architectural level includes the “chaining” technique suggested by [26]. The technique is analogous in concept and application to program slicing. In chaining, dependence relationships that exist in an architectural specification are referred to as links. Links connect elements of the specification that are directly related. The links produce a chain of dependencies that can be followed during analysis. The technique focuses the analysis on components and their interconnections. Forward and/or backward chaining are then performed to discover related components. The applicability of this technique is demonstrated on small scale architectures and could be extended to address current architectural development paradigms. For example, how such a concept could be refined to perform what-if analysis on large-scale software architectures such as product-line or model-driven architectures? For product-line architectures, this is necessary for reasoning about how the change could impact the commonality, variability, and their interdependence. These techniques could be then complemented by analysis tools, which could facilitate automated reasoning and provide a basis for what-if analyses to manage the change across instances of the core architecture. Understanding how the change could then ripple across different products might be feasible. For modeldriven architectures, for example, this could help in reasoning about how the change could affect the Platform Independent Model (PIM) and ripple to affect the Platform Specific Models (PSM). These techniques could be complemented by automated reasoning to manage evolution. When combined with traceability links, the combination could provide a comprehensive framework for managing the change and guiding evolution.

5 Conclusion Reflecting on our research into the problem, we have defined architectural stability and explored perspectives in handling the problem. We have reviewed existing research effort, have discussed their limitations, and have outlined research challenges and opportunities. The implications of such contribution need not be overstated: advancing the understanding of the architectural stability, stimulating and possibly motivating future research in architectural stability and related problems.

314

R. Bahsoon and W. Emmerich

References 1. Jazayeri, M.: On Architectural Stability and Evolution. LNCS, pp. 13–23. Springer, Heidelberg (2002) 2. Garlan, D.: Software Architecture: A Roadmap. In: Finkelstein, A. (ed.) The Future of Software Engineering, pp. 91–101. ACM Press, New York (2000) 3. van Lamsweerde, A.: Requirements Engineering in the Year 00: A Research perspective. In: Proc. 22nd Int. Conf. on Software Engineering, pp. 5–19. ACM Press, New York (2000) 4. Nuseibeh, B.: Weaving the Software Development Process between Requirements and Architectures. In: Proc. of the First Int. workshop from Software Requirements to Architectures, Toronto, Canada (2001) 5. Cook, S., Ji, H., Harrison, R.: Dynamic and Static Views of Software Evolution. In: Int. Conf. on Software Maintenance, Florence, Italy, pp. 592–601. IEEE CS, Los Alamitos (2001) 6. Lehman, M.M.: Feedback, Evolution and Software Technology, FEAST 1-2, http://www-dse.doc.ic.ac.uk/~mml/feast/ 7. Bennet, K., Rajilich, V.: Software Maintenance and Evolution: A Roadmap. In: Finkelstein, A. (ed.) The Future of Software Engineering, pp. 73–90. ACM Press, New York (2000) 8. Emmerich, W.: Software Engineering and Middleware: A Road Map. In: Finkelstein, A. (ed.) Future of Software Engineering, pp. 117–129. ACM Press, New York (2000b) 9. Bahsoon, R.: Evalauting Architectural Stability with Real Options Theory, PhD thesis, U. of London, UK (2005) 10. Bahsoon, R., Emmerich, W.: Evaluating Software Architectures: Development, Stability, and Evolution. In: Proc. of IEEE/ACS Computer Systems and Applications, pp. 47–57. IEEE CS Press, Los Alamitos (2003a) 11. Kazman, R., Klein, M., Barbacci, M., Lipson, H., Longstaff, T., Carrière, S.J.: The Architecture Tradeoff Analysis Method. In: Proc. of 4th. Int. Conf. on Engineering of Complex Computer Systems, pp. 68–78. IEEE CS Press, Los Alamitos (1998) 12. Kazman, R., Abowd, G., Bass, L., Webb, M.: SAAM: A Method for Analyzing the Properties of Software Architectures. In: Proc. of 16th Int. Conf. on Software Engineering, pp. 81–90. IEEE CS, Los Alamitos (1994) 13. Parnas, D.L.: Designing Software for Ease of Extension and Contraction. IEEE Transaction on Software Engineering 5(2) (1979) 14. Allen, R., Garlan, D.: Formalizing Architectural Connection. In: Proc. of the 14th Int. Conf. on Software Engineering, pp. 71–80. ACM Press, New York (1994) 15. Smith, C., Woodside, M.: System Performance Evaluation: Methodologies and Applications. CRC Press, Boca Raton (1999) 16. Boehm, B., Sullivan, K.J.: Software Economics: A Roadmap. In: Finkelstein, A. (ed.) The Future of Software Engineering, pp. 320–343. ACM Press, New York (2000) 17. Klein, M., Kazman, R.: Attribute-Based Architectural Styles. CMU/SEI-99-TR-22, Software Engineering Institute (1999) 18. Medvidovic, N., Taylor, R.: A Framework for Classifying and Comparing Architecture Description Languages. In: Proc. of 6th. European Software Engineering Conf., with the Fifth ACM SIGSOFT Symp. on the Foundations of Software Engineering, pp. 60–76. ACM Press, New York (1997) 19. Garlan, D., Monroe, R., Wile, D.: ACME: An Architectural Interconnection Language. Technical Report, CMU-CS-95-219 (1995)

Architectural Stability

315

20. Magee, J., Dulay, D., Eisenbach, N., Kramer, J.: Specifying Distributed Software Architecture. In: Botella, P., Schäfer, W. (eds.) ESEC 1995. LNCS, vol. 989, pp. 137–153. Springer, Heidelberg (1995) 21. Parnas, D.L.: On the Criteria to Be Used in Decomposing Systems into Modules. Communications of the Association of Computing Machinery 15(12), 1053–1058 (1972) 22. Luckham, D.C., Vera, J.: An Event-Based Architecture Definition Language. IEEE Trans. on Software Engineering 29(9), 717–734 (1995) 23. Shaw, M., DeLine, R., Klein, D., Ross, T., Young, D.: Abstractions for Software Architecture and Tools to Support them. IEEE Transactions on Software Engineering 21(4), 314–335 (1995) 24. Moriconi, M., Qian, X., Riemenschneider, R.: Correct Architecture Refinement. IEEE Trans. on Software Engineering 21(4), 356–372 (1995) 25. Schaller, R.R.: Technology Roadmaps: Implications for Innovation, Strategy, and Policy, The institute of Public Policy, George Mason University Fairfax, VA (1999) 26. Stafford, J.A., Wolf, A.W.: Architecture-Level Dependence Analysis for Software System. International Journal of Software Engineering and Knowledge Engineering 11(4), 431–453 (2001) 27. Sullivan, K.J., Chalasani, P., Jha, S., Sazawal, V.: Software Design as an Investment Activity: A Real Options Perspective. In: Trigeorgis, L. (ed.) Real Options and Business Strategy: Applications to Decision-Making, pp. 215–260. Risk Books (1999)

Connecting Architecture and Implementation Georg Buchgeher1 and Rainer Weinreich2 1

Software Competence Center Hagenberg, Austria [email protected] 2 Johannes Kepler University Linz, Austria [email protected]

Abstract. Software architectures are still typically defined and described independently from implementation. To avoid architectural erosion and drift, architectural representation needs to be continuously updated and synchronized with system implementation. Existing approaches for architecture representation like informal architecture documentation, UML diagrams, and Architecture Description Languages (ADLs) provide only limited support for connecting architecture descriptions and implementations. Architecture management tools like Lattix, SonarJ, and Sotoarc and UML-tools tackle this problem by extracting architecture information directly from code. This approach works for low-level architectural abstractions like classes and interfaces in object-oriented systems but fails to support architectural abstractions not found in programming languages. In this paper we present an approach for linking and continuously synchronizing a formalized architecture representation to an implementation. The approach is a synthesis of functionality provided by code-centric architecture management and UML tools and higher-level architecture analysis approaches like ADLs.

1

Introduction

Software architecture is an abstract view of a software system. As such it abstracts from implementation details and data structures [1] and describes important elements, externally visible properties of these elements, and relationships among elements [1]. Different approaches for describing software architecture exist. Informal approaches and UML diagrams are typically used for architecture documentation. Formal approaches like Architecture Description Languages (ADLs) and architecture models [2] are used for automatically analyzing specific system properties. Keeping an architecture description up to date and ensuring that the prescriptive (as-intended) architecture corresponds to the descriptive (implemented) architecture are still central problems in software development [2][3][4]. Approaches addressing these problems exist. For example, UML-tools may extract architectural abstractions from an implementation and thus provide a view of the currently implemented architecture. Architecture management tools like Lattix [5], SonarJ and Sotoarc [6] additionally support comparison and synchronization of R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 316–326, 2009. c Springer-Verlag Berlin Heidelberg 2009 

Connecting Architecture and Implementation

317

the intended and the implemented architecture. However, these approaches operate on the concepts at the low abstraction level provided by object-oriented programming languages (classes and interfaces). They fail to support higher-level abstractions like components, systems, and systems of systems. Typically they also work only for homogenous programs and do not inherently support heterogeneous software systems, like service-oriented software architectures. Approaches extracting architecture information from code also typically lack validation capabilities like ADLs. On the other hand, general-purpose ADLs like xADL [7] and ACME [8] provide only limited support for connecting architecture description and code and offer no synchronization support. In this paper we describe an approach for connecting and synchronizing architecture description and system implementation. The approach is a synthesis of functionality provided by code-centric architecture management and UML tools and higher-level architecture analysis tools like ADLs. It supports both the description of high-level architectural elements like components and systems and of low-level concepts like classes and interfaces. Low-level abstractions are extracted from an implementation similar to reverse engineering and architecture management tools and can be synchronized with a prescribed architecture. High-level abstractions are either defined manually or extracted from a system implementation. In the latter case, the system analyses technology-specific component code, meta-data and configuration files to extract the needed information. Since we use an ADL for architecture representation, the approach also supports architecture validation based on constraints. Heterogeneous systems are supported through different technology bindings. The remainder of this paper is structured as follows. In Section 2 we describe the basic elements of our approach, which are an ADL for architecture description and a toolset working on this ADL. The toolset provides visual editors for visualizing and manipulating an ADL-based architecture model, functionality for extracting information from an implementation, and functionality for synchronizing prescriptive and descriptive architecture. In Section 3 we provide an example to illustrate our approach. In Section 4 we describe related work in more detail. The paper is concluded in Section 5.

2

Approach

The main elements of our approach are an ADL, called LISA (Language for Integrated Software Architecture), and a toolkit working on LISA-based architecture models, the LISA-Toolkit (see Figure 1). The toolkit is implemented on the basis of the Eclipse platform and provides a number of plug-ins for architecture modelling, visualization, validation, and implementation synchronization. Some of the available editors and views for architecture modelling and visualization are shown in the next section. The LISA-ADL is an extensible XML-based language for representing structural relationships of heterogeneous software systems. It is implemented by XML-based metamodels for describing different aspects of a software system. We

318

G. Buchgeher and R. Weinreich LISA Toolkit Architecture Modeling

Architecture Visualization

Architecture Validation

Implementation Synchronization

LISA Architecture Model System Layer Component Layer Basic Structure Layer

Technology Technology Binding Binding Models Models

Fig. 1. LISA Overview

provide no dedicated alternative textual representation, since LISA-based architecture models are created and manipulated visually using the LISA-toolkit. As shown in Figure 1, LISA provides concepts and models for describing the architecture of a software system at different abstraction layers. The basic structure layer is used for describing low-level abstractions like classes, interfaces, and packages, but also contains elements for defining elementary structures and constraints like modules, subsystems, and layers. Most architecture management tools are working at this layer. Some elements at this layer, like classes, can be extracted from an implementation through language connectors, other elements like layers need to be defined manually. The component layer provides concepts for describing component-based architectures like components, ports, and contracts. In our model, components denote elements meant for late composition. Components may provide services to other components through service ports and they may reference other components through reference ports. Ports specify additional composition semantics. Examples are whether a connection is optional, whether it is created automatically or manually, and which connectors can be used for connections. Components and ports are independent from a particular implementation paradigm. If components are implemented through an object-oriented language, their implementation description can be refined through elements at the basic structure layer. However, LISA also supports bindings to other (non object-oriented) implementation technologies through technology bindings. Technology bindings are defined by means of technology-specific binding models (see Figure 1). Currently, we support technology bindings for EJB, Spring, OSGi, Spring Dynamic Modules, and SCA. The system layer is used for describing the architecture of a whole system or application. A system consists of configured and connected component instances. Since components may be implemented differently, heterogeneous systems can be described. Hierarchical decomposition of systems is supported through composites. Even at this level, technology bindings are used for connecting and synchronizing architectural elements like systems and composites to technology-specific configuration files.

Connecting Architecture and Implementation

System Implementation

319

Architecture Description

- Source Code (Classes) - Configurations (XML)

Fig. 2. Implementation/Architecture Mapping

Figure 2 shows the basic approach for mapping elements from a system implementation to the architecture description by means of actual views provided by our toolkit. The left side of Figure 2 shows the typical project structure of an eclipse based SCA/Java project. In the example shown, the project consists of one package with two Java classes, a Java interface, and of a configuration file describing an SCA-based system configuration (ordering.composite). The right side of Figure 2 shows the architecture decomposition editor of the LISAtoolkit. An architecture description (see top level element at the right side) is partitioned into modules and may contain layers (see order.processing.jar and ordering.core in Figure 2). The figure also shows components (Account, OrderProcessing), one contract (AccountContract ) and one system definition (System). The dashed arrows in Figure 2 show the actual mapping of implementation artifacts to elements of the architecture model. The mapping is described using technology-specifc bindings, which are also shown in Figure 2. If possible, technology bindings are extracted from implementation artifacts by analyzing code, metadata, and configuration files. In cases where no implementation is available (yet) or when information can only partly by extracted from an implementation, technology bindings need to be created or completed manually. The actual process of synchronizing architecture and implementation is shown in Figure 3. A system implementation is created and manipulated by editors that are part of the Eclipse IDE or of third party plug-ins like the Spring IDE. The architecture description is created and modified through architecture editors provided by the LISA toolkit. Both representations are continuously being observed for changes. Changes of the system implementation are detected by extending the Eclipse project builder infrastructure. Whenever resources are changed an incremental build process is started. An Architecture Project Builder analyzes the changed resources. Language Builder Extensions are used for extracting information about low-level architectural elements like classes and interfaces from an implementation and for creating the architecture model at the Basic Structure Layer.

320

G. Buchgeher and R. Weinreich

Source Code Editors (provided by IDE)

Architecture Editors edit

edit System Implementation

Architecture Description

observe

listen

Architecture Project Builder

Model Validator

validates

delegate Language Builder Extensions (Java, C#)

Component Model Extensions (Spring, J2EE, SCA, OSGi)

Constraints Constraints Constraints

Consistency Consistency Consistency Checker Checker Checker

Fig. 3. Synchronization Approach

Technology-specific Component Model Extensions search the source code for component meta-data, analyze component configuration files, and create and validate architecture elements at the component layer. The architecture model is observed by a Model Validator, which validates an extensible set of constraints whenever the architecture description is modified. Consistency Checkers are responsible for comparing architecture description and system implementation. Differences between both representations are visualized as validation problems and shown in both representations. Problems can then either be resolved by changing the system implementation, or by changing the architecture description.

3

Example

In this section we show some of the described concepts by means of a small example for order processing. The example is intended to illustrate three aspects of our approach. In a first step we show how components and systems can be modeled at a high-level of abstraction without any implementation binding. In a second step, we will show how technology-specific implementation bindings can be defined. The last step will illustrate how low-level architectural abstractions like classes and interfaces that are created as part of an implementation are connected to the high-level abstractions that were defined during system modeling. The presented scenario is only one of several possible ways to use our approach. We will discuss alternative ways at the end of this section.

Connecting Architecture and Implementation

321

Fig. 4. Component Diagram

Step 1: Component and System Modeling We start by modeling a system from scratch. This means we follow a top-down approach. First we define components and contracts for the order processing system. Modeling can be performed in different graphical diagram editors provided by the toolkit. The result of the modeling process is shown in the component diagram depicted in Figure 4. The diagram shows components, their ports, as well as component/contractdependencies (no connections). For example, the OrderProcessing component provides one service port (Monitor ) and several reference ports, which can be connected to other components. The ShipOrder reference port has a multiplicity of 1..1 and must be connected to another component supporting the Shipping contract. The figure shows that currently two components (StandardShipping, ExpressShipping) support this contract and can be used in a concrete configuration of the OrderProcessingComponent. After defining components, instances of these components can be used for defining a system configuration1 . Figure 5 shows the configuration of the OrderProcessing system. As shown in the figure, the system consists of two main parts which have been placed in different layers. The business logic layer contains an instance of the OrderProcessing component, which has been connected to instances of CheckAccount, StandardShipping, and BillOrder. The figure shows an additional aspect: the described configuration at the business logic layer forms the implementation of a newly defined composite component (OrderingSystemComposite). Since the OrderingSystemComposite is itself a component, the described model would allow defining multiple instances of this composite component. The OrderMonitor is part of the UI layer and has been connected to the ordering system. As described before, layers are used for 1

Component instances are configured components, where values are supplied for properties, and connections. Multiple run-time instances of a component instance are possible.

322

G. Buchgeher and R. Weinreich

Fig. 5. System Diagram

constraining architectural structures. In our approach, layering constraints can also be used at the level of component configurations. The validation engine of the LISA toolkit continuously validates the architecture description. Examples for problems that are detected at the level of component and system modeling are missing connections, unset property values, and layer violations. Step 2: Definition of Technology Bindings After modeling components and systems, the defined components can be bound to technologies and to component implementations. A component definition can be directly bound to an implementation in a specific technology. However, it is also possible to define the technology first and provide the implementation afterwards. This way it is possible to make technology-specific decisions and to perform technology-related validation before actually providing an implementation. Technology decisions are modeled with technology-specific implementation bindings. Figure 6 shows the defined components in a different diagram. In this diagram, SCA bindings have been attached to the different components. Since SCA provides itself an implementation abstraction, the selected bindings are SCA Java (for binding to SCA components implemented in Java) and SCA Composite (for binding to SCA composites). As described in Section 2, bindings to different technologies are possible, even within the same system. The error annotations that are displayed on every implementation binding indicate that the implementation of the components is still missing, i.e., the binding is incomplete. Step 3: Connecting to Implementation-Level Abstractions In the final step of this scenario, the defined components are implemented and implementations are bound to component definitions. The toolset supports technology connectors for different component technologies and programming

Connecting Architecture and Implementation

323

Fig. 6. Components with Technology Fig. 7. Architecture Model with LanBindings guage Abstractions

languages. In the case of the presented example, it uses technology connectors for SCA and Java to extract architecture-related information from an implementation. Architecture information at the component-level like SCA component definitions (derived from Java annotations in code) and SCA composite configurations (extracted from composite definitions) are used for validating and synchronizing architecture information with the implementation. For example, the toolkit detects when the component definition in an implementation differs from the component definition in the architecture model and vice versa. Low-level architectural elements, like classes, interfaces, and static dependencies are automatically extracted by language connectors. The extracted elements have to be assigned manually to the concepts at a higher-level of abstraction. Figure 7 shows the model from Figure 6 with classes extracted from an implementation. Some of the extracted classes have been assigned to components (ordering.core.OrderProcessing and ordering.core.Shipping); others still need to be assigned (ordering.core.Account and ordering.core.Billing). The resulting architecture model now contains abstractions at higher and lower levels of abstraction and is continuously synchronized with an implementation. The additional elements and dependencies at the language level can now be analyzed with regard to the higher-level elements as shown in Figure 8. The figure shows that the component implementations introduce static dependencies between components (shown as red lines in Figure 8). These are potentially unwanted dependencies because components may be directly affected through changes to the implementation of another component and components cannot

324

G. Buchgeher and R. Weinreich

Fig. 8. Static component dependencies

Fig. 9. Architecture without static component dependencies

be deployed independently from each other. The toolkit is able to detect such potential problems and an architect or developer may change the implementation to remove direct dependencies between component implementations. The result of such a refactoring is shown in Figure 9, where interfaces implementing a contract have been introduced and moved to a separate library. In the example we used a top-down approach. We started by modeling at a high-level of abstraction and eventually provided technology bindings and component implementations. It would also be possible to start with an implementation and to define higher-level concepts later in the process. This way an architecture description can be provided for already implemented systems. Also, a combination of both approaches can be used. The elements of an architecture model may be partly implemented and partly specified. This is useful for modeling and analyzing the impact of extending an existing system.

4

Related Work

Our approach is based on an ADL, which is continuously synchronized with a system implementation and which supports the description of heterogeneous distributed system architectures. ADLs are primarily a means for system modeling and automated analysis. Connecting architecture description and code is a long known deficiency of ADLs [9].

Connecting Architecture and Implementation

325

xADL [7] and its related toolkit ArchStudio [10] allow specifying unidirectional connections from the ADL to implementation artifacts (by extending an abstract implementation model). However, architecture and implementation are not synchronized. Changes to the architecture model affecting the implementation are not detected. Equally changes to the implementation affecting the architecture description are not identified. Additionally, xADL provides no explicit support for connecting to component models and technologies used in practice. Finally, there is no mapping from low-level structural models (like class relationships) to high-level concepts like components. As shown in the last section such integration enables important structural analysis, continuous conformance analysis, and seamless modeling from high-level to low-level abstractions. The Fractal ADL [11] has been designed as a configuration language for the Fractal Component Model. While theoretically possible, LISA has explicitly not been designed as a configuration model for a particular component technology. Rather LISA system models are mapped to and synchronized with system configurations of component technologies like Spring and SCA. Like in xADL, connections to an implementation are only one-way relationships in the Fractal ADL. Validation of consistency between architecture description and implementation, architecture synchronization, integration of low-level structural models, and seamless modeling as in our approach are equally not supported by the Fractal ADL. ArchJava [9] is an extension to Java, which unifies architecture description and implementation in one representation. The focus of ArchJava is to ensure that components only communicate via defined ports. This is called communication integrity in ArchJava. Communication integrity can also be checked in LISA (see Figure 8). Main drawbacks of ArchJava are its support for a single language and a single JVM. It also requires a compiler and defines its own component model. As a result, ArchJava does not support existing component technologies and cannot be applied for describing heterogeneous systems. Since it is bound to an implementation language, it also does not support architecture modeling. The Unified Modeling Language (UML) is a general purpose modeling language originally designed for the design of object-oriented systems. Improved support for the description of component-based systems and software architectures has been added as part of UML 2.0. Most UML tools offer reverse and forward engineering capabilities for creating UML diagrams from a system implementation and vice versa. However, this functionality is primarily available for class and sequence diagrams, i.e., for low-level architectural and implementation information. UML-based MDA tools like AndroMDA support code generation for specific component technologies. This is, however, restricted to forward engineering. Continuous and automated architecture analysis like in our approach is not supported by UML-tools [3].

5

Conclusion

We have presented an ADL-based approach for connecting architecture and implementation. The approach supports modeling of system architectures at

326

G. Buchgeher and R. Weinreich

different levels of abstraction, binding architectural concepts to different technologies, immediate conflict detection, and continuous synchronization of architecture and implementation. Like other ADLs our approach supports system modeling and architecture analysis at a high-level of abstraction. Contrary to other approaches we focus on connecting and continuously synchronizing the architecture description with system implementation. This ensures that the architecture model always reflects an abstract high-level and automatically analyzable view of the currently implemented architecture. Finally we combine static analysis as provided by architecture management tools with ADL concepts and support heterogeneous systems through different technology-bindings, even within one system.

References 1. Bass, L., Clements, P., Kazman, R.: Software Architecture in Practice, 2nd edn. Addison-Wesley Professional, Reading (2003) 2. Garlan, D.: Formal Modeling and Analysis of Software Architecture: Components, Connectors, and Events. In: Bernardo, M., Inverardi, P. (eds.) SFM 2003. LNCS, vol. 2804, pp. 1–24. Springer, Heidelberg (2003) 3. Shaw, M., Clements, P.: The Golden Age of Software Architecture. IEEE Softw. 23(2), 31–39 (2006) 4. van Gurp, J., Bosch, J.: Design Erosion: Problems and Causes. Journal of Systems and Software 61(2), 105–119 (2002) 5. Sangal, N., Jordan, E., Sinha, V., Jackson, D.: Using Dependency Models to Manage Complex Software Architecture. SIGPLAN Not. 40(10), 167–176 (2005) 6. hello2morrow GmbH: Sotoarc and SonarJ (2009), http://www.hello2morrow.com (accessed: June 17, 2009) 7. Dashofy, E.M., van der Hoek, A., Taylor, R.N.: A Comprehensive Approach for the Development of Modular Software Architecture Description Languages. ACM Trans. Softw. Eng. Methodol. 14(2), 199–245 (2005) 8. Garlan, D., Monroe, R., Wile, D.: Acme: An Architecture Description Interchange Language. In: CASCON 1997: Proceedings of the 1997 conference of the Centre for Advanced Studies on Collaborative research. IBM Press (1997) 9. Aldrich, J., Chambers, C., Notkin, D.: ArchJava: Connecting Software Architecture to Implementation. In: ICSE 2002: Proceedings of the 24th International Conference on Software Engineering, pp. 187–197. ACM Press, New York (2002) 10. Institute for Software Research - University of California: ArchStudio 4 (2009), http://www.isr.uci.edu/projects/archstudio/ (accessed: June 17, 2009) 11. ObjectWeb Consortium: Fractal ADL (2009), http://fractal.ow2.org/fractaladl/index.html (accessed: June 17, 2009)

Confirming and Reconfirming Architectural Decisions on Scalability: A Goal-Driven Simulation Approach Tom Hill, Sam Supakkul, and Lawrence Chung Department of Computer Science, The University of Texas at Dallas, 800 West Campbell Road Richardson, Texas 75080-3021, USA [email protected], [email protected], [email protected]

Abstract. Scalability, which refers to an ability to support increased loads with acceptable performance, is among the key issues in deciding on an architecture with its essential components, together with relationships between such components, as well as constraints on such components and relationships. As with just about any design, the architectural design space is potentially huge, if not infinite, while the quality of the final system to be implemented inevitably depends largely on various decisions made during the architectural design phase. Unfortunately, however, it often times seems difficult to analyze if an architectural design incorporates good decisions or even bad ones, since an architectural design is (supposed to stay) at a high-level of abstraction and not concrete enough on its performance and scalability behavior, before we commit to the time-consuming and costly lower level design, implementation and testing. In this paper, we propose an integration of goal-orientation, which is qualitative in nature, and simulation, which is quantitative in nature. Keywords: performance, scalability, architecture, design decision, NFR framework, goal-oriented, simulation-based, softgoal interdependency graph.

1 Introduction Scalability, which refers to an ability to support increased workloads with adequate service levels or performance [1], is among the key issues in deciding on an architecture. It is costly to retrofit an architecture after the fact if it is found not to provide the expected scalability. The classic nineteen seventies German text ‘Engineering Design’, established the seven steps of the systems approach used today in the design activity in most design domains, including software design:(State Analysis, Goal Setting, Solution Variants Development, Analysis, Evaluation, Decision, and Implementation)[2]. The focus of this paper is on two of the architectural design activities: goal setting and solution variants development. The primary goals of the modern software architectural design activity are to create and communicate a lasting rational design. The design is a structured model of a future software implementation. Architecture, as a profession, is about demystifying the underlying structure of objects (buildings, bridges, spacecrafts, computers and software). A system’s structure is defined by essential components, interactions between components and constraints attached to both. R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 327–336, 2009. © Springer-Verlag Berlin Heidelberg 2009

328

T. Hill, S. Supakkul, and L. Chung

The primary contribution of this paper is a methodology which integrates goalorientation and simulation to analyze the design decisions on scalability and other Non-Functional Requirements (NFRs) such as cost and reliability related architectural issues to qualitatively explore and confirm architectural decisions, and either reconfirm the validity of such decisions or make corrections to them. Additionally, we propose the use of simulation to reconfirm early architecture design decisions and build confidence in the designer’s ability to predict the behavior of future system implementations. Confidence is reinforced by the observation of system behaviors, model consistency, model completeness, and the discovery of new system components [3]. “We believe what we see,” and simulation affords us the opportunity to quickly see into the future of the system under study. For this work, we adopt ideas from Goal-Oriented Requirements Engineering (GORE) (see, for example, [4] [5] [6] [7] for more details) and borrow general techniques from simulation (see, for example, [8] [9] [10] [11] for more details). While each of these two areas addresses either goal-orientation or simulation, our distinctives lie in the integration of the work from these two areas of research and practice. Section 2 describes an overview of the Health Reimbursement System (HRS) we use for the purpose of illustration and also for our own case study. Section 3 describes the three main steps in our methodology. At the end, we summarize the paper, along with future directions.

2 Application Domain Overview: Health Reimbursement System The paper focuses throughout on a case study detailing one of the world’s largest health care systems to ensure the models are realistic and applicable to solve problems in the real world (please note that the actual numbers used in examples and models have been obfuscated to protect proprietary information). Figure 1 shows the context of the case study for a Healthcare Reimbursements System (HRS).

Fig. 1. The Healthcare Reimbursements System (HRS) case study context

Confirming and Reconfirming Architectural Decisions on Scalability

329

Quickly tracing through the simplified context diagram above, the patient visits a healthcare provider (physician, hospital, or managed care). Care is given and the provider submits a request for reimbursement to the HRS. The HRS, via data entry/conversion, re-formats the data and verifies the validity of the following: coding; insured; provider; insurer; eligibility; plan; contract and; pricing. The HRS sends a claim to the insurer and receives an authorization to pay. In the final step, funds are transferred by a bank and the reimbursement is sent to the healthcare provider. 2.1 HRS Stakeholder Non-functional Requirements Table 1 shows a set of informal non-functional requirements labeled by the primary stakeholder of a large health care system as system architecture principles. The architecture principles (NFRs) are presented in priority order. The HRS case study will examine the highest priority NFRs, performance and scalability, in detail. Table 1. HRS stakeholder-provided initial architecture principles, non-functional requirements

Given Table 1, the experienced healthcare-domain requirements engineer can begin to quickly understand user requirements and obtain agreement on a more formal description of the requirements. The production of a requirements scenario is the first step required to reduce the infinite design space to a more manageable performance and scalability subset. 2.2 HRS Architecture Design Decisions The HRS architect is faced with a task to ensure that the HRS be able to support the initial performance requirements of 150,000 reimbursements per hour and be able to scale to support the estimated future performance of 300,000 per hour. In both cases, the corresponding batch processing must be completed within the batch cycle window of 8 hours. This scenario creates several looming architectural design decisions based on non-functional requirements: Which optimizing technique should be used to satisfy the response time constraints? Which method should be selected to guarantee that the batch cycle will complete within the time window requirements? How can the system perform and remain scalable?

330

T. Hill, S. Supakkul, and L. Chung

3 A Goal-Driven Simulation Approach to Design Decisions In this section, we present the three main steps of our methodology: Section 3.1 Non-functional Requirements Goal Setting; Section 3.2 - Constructing a Key-decision Simulation Model; and, Section 3.3 - Executing and Analyzing Simulation Model Experiments. 3.1 Non-functional Requirements Goal Setting In this step, informally elicited non-functional requirements that may impact on architectural decisions are analyzed and represented as softgoals to be achieved by the system. For instance, user defined requirements in Table 1 and the quantitative performance requirements described in Section 2 can be mapped to softgoals in a Softgoal Interdependency Graph (SIG) [5] as shown in Figure 2.

Fig. 2. A derived goal model constructed from the stakeholder requirements in Table 1

In Figure 2, quality of the system is refined using an AND-decomposition to cost, scalability, reliability, flexibility, development time, and maintainability softgoals (denoted by cloud icons), with scalability having the highest priority (very critical as denoted by !!) and cost having medium priority (critical as denoted by !). The scalability is further AND-decomposed to high volume of reimbursement processing and performance of reimbursement processing Softgoals, and subsequent other subgoals. These softgoals may be refined to more concrete softgoals that specify quantitative requirements such as "4 seconds/transaction" for response time requirement and "completed in 8 hours" for fixed cycle throughput time. The “eql” symbol identifies an equal contribution from the two sub-goals real-time requirements and batch requirements. During this step, goal-oriented analysis is used to explore and confirm architectural decisions by treating conceptual softgoals in a SIG as softgoals to be achieved. Figure 3 is a refined SIG based on the SIG in Figure 2, that focuses on the scalability softgoal.

Confirming and Reconfirming Architectural Decisions on Scalability

331

Fig. 3. Initial Softgoal Interdependency Graph (SIG) showing architectural decisions using goal-oriented analysis

To achieve the performance aspect of the scalability, two common techniques to implement scalability are explored, including scaling out or adding similar resources to the processing resources and scaling up or replacing resources with more powerful resources. Scale-up is known to provide better response time and fixed cycle throughput because it minimizes the effort required in design, implementation, and operation, therefore selected for the system (denoted by a check mark). It is also found to be more costly than the scale out alternative (denoted by a red-dash line labeled with Hurt/-- toward cost. On the other hand, scale out alternative is decided to be less desirable - Help/--. In exploring alternatives for high volume real-time data entry, we find real-time architectural style is a highly desirable alternative (denoted by Make/++), however with a negative side-effect on high volume of batch processing (denoted by a dashline labeled with Hurt/-). Conversely, batch architectural style is highly positive for achieving high volume of batch processing - Make/++, but has a negative side-effect on high volume of real-time data entry - Hurt/-. Since the HRS needs to support high volume workload in both real-time and batch processing both, the architects agree to use both, as well as real-time and batch hybrid solution that has a positive contribution toward both softgoals. The solutions that are marked with a check mark represent initial architectural decisions based on a qualitative evaluation. For the performance sub-goals of response time and fixed cycle throughput time, we examined the operationalization methods of real-time processing, batch processing, and a hybrid data collection to batch processing. When we drew our first high-level softgoal interdependency graph, figure 3, we were quickly able to observe the major design dilemmas, their relationships and some tradeoffs. 3.2 Construct a Key-Decision Simulation Model The architectural decision SIG, figure 3, is used to develop simulation models, such as the one shown in Figure 4.

332

T. Hill, S. Supakkul, and L. Chung

Fig. 4. HRS case study design decision simulation model topology diagram

Simulation modeling is designed to answer the questions posed in section 2: Which optimizing technique should be used to satisfy the response time constraints? Which method should be selected to guarantee that the batch cycle will complete within the time window requirements? How can the system perform and remain scalable? These questions can only be answered by understanding the behavior of a system over time. The first step in constructing a simulation model is to understand the questions that the model must answer. The second step is to build a topological model to represent the infrastructure, resources, workload, and work flow. Like the softgoal interdependency graph, the topological model is another observable abstract representation of the HRS. However the HRS simulation model abstraction is capable of representing the behavior of the system over time [8]. Figure 4, shows the topology of the model created for the HRS case study. The creation of the HRS topology, figure 4, is basically a re-write activity, taking the softgoal interdependency graph, figure 3, as input and re-writing it into a simulation model configuration using the graphical editor provided by the HyPerformix Simulation System [8]. 3.3 Execute and Analyze Simulation Experiments The next step in building a simulation model, is to code experiments to answer the HRS case study questions by modifying the variables: workload (from 150,000 reimbursements per hour to 300,000); number of resources (servers); power of resources (server type); and the selection of reporting variables (elapsed time, number of transactions completed, response time average, throughput time, and utilization of

Confirming and Reconfirming Architectural Decisions on Scalability

333

Table 2. HRS case study simulation experiments and results summary

resources). The functionality to report these variables is built-in to most commercial simulation systems, including the HyPerformix Simulation System. The following serves as a detailed audit-trail describing each simulation experiment 1 through 11 in table 2: 1. Experiment to verify that a base-level server (low-CPU-power, 4 Intel Itanium2 DC 9050 - 1.6 GHz) can provide four second response time at 150,000 transactions per hour. The simulation failed when it determined that 100% of the server would be needed. 2. Scale-out experiment to find if two base-level servers would provide the necessary resources. The simulation gave 5.18 second response time for a short period of time, then failed after determining 100% of the server would be needed. 3. A scale-out experiment to discover if four servers would provide four second response time for 150,000 transactions per hour. The simulation settled down to a constant service with an average response time of 3.58 seconds. 4. An additional scale-out experiment to determine if ten base-level servers would process 1,200,000 batch transactions within the required eight-hour window (the batch processes carry out the bulk of HRS processing in the system [approximately twice the process load of the real-time processes]). The simulation settled to a constant processing rate to produce the desired effect. 5. The scale-out experiment to determine if four servers would provide enough resources to double the real time input volume to be processed per hour (3000,000 transactions). The simulation failed as expected. 6. The scale-out experiment to discover if four second response time can be maintained if ten servers are used. 3.88 seconds response time was reported and the simulation passed. 7. The final scale-out experiment was conducted using twenty-four servers to process twice the normal load (2,400,000). The simulation provided a constant successful result.

334

T. Hill, S. Supakkul, and L. Chung

8. The first scale-up experiment was conducted to increase the power of a baselevel single server to ten CPUs. The single server provided close the required response time (4.18 seconds) and passed the test. 9. The scale-up experiments 9, 10, and 11 were to use a high-CPU-power server, 64 Intel Itanium2 - 1.6 GHz to provide increased power. The simulation tool did not contain the performance characteristics for a highCPU-power server. An analytical computation was used to determine if the high-CPU-power server with a TPC-C benchmark [12] of [4,092,000, or 10 times the TPC-C power of base-level server] would provide the necessary power to process 1,200,000 batch transactions in the eight-hour window. The calculation was positive. The last two calculations on the scale-up experiment (10 and 11) to double the load, were too close to be comfortable, using all of the 4 million TPC-C power at a cost of almost $ 12 million USD. An application-specific benchmark should be constructed to determine the feasibility of this alternative. The true test of the simulation model and the coded experiments is “did it answer the design questions posed in section 2” in a timely manner: Which optimizing technique should be used to satisfy the response time constraints? Answer – Both optimizing techniques will satisfy the response time constraints. Which method should be selected to guarantee that the batch cycle will complete within the time window requirements? Answer – Only the scale-out technique will satisfy this constraint. How can the system perform and remain scalable? Answer - The system can perform and remain scalable, if the scale-out technique is used. The eight HRS simulation experiments, in table 2, executed in less than one elapsed-day. Additionally, did the simulation model experiments reconfirm the earlier HRS architectural design decisions? Answer – It confirmed one design decision, and brought the scale-up decision into question. Has our confidence in decisions been raised? Answer – Our confidence has been elevated in the scale-out decision. Did we gain any insight by discovering new architecture components? Answer – Yes, we learned the importance of the cost component (e.g. the cost of ten scale-out servers, required to satisfy the maximum response time constraint, is one-half the cost of a questionable large scale-up server). Can we now create a more comprehensive SIG and a more comprehensive simulation model? Answer - Yes, the key design decision is now, how do we approach the eight-hour batch cycle window in the scale-out implementation? The answers to these questions are summarized in table 2.

4 Related Work and Discussion Goal-oriented analysis has been used to qualitatively explore and make architectural decisions [13], and has been extended to capture concrete quantitative performance requirements. However, integrating goal-oriented analysis with simulation appears to be novel and could be helpful in providing confidence in the architectural decisions and models, and perhaps could prevent potentially expensive architectural rework if the architecture is found not to provide adequate scalability. For example, in our running example, the initial analysis determined that scale-up solution was desirable based on past experience; however, the simulation showed that the approach would

Confirming and Reconfirming Architectural Decisions on Scalability

335

not be sufficiently scalable to handle future expected workload within the 8 hours window constraint. Prior to our experimental study, Kim and Ellis constructed performance analytic models to observe the performance and scalability behavior of workflow systems and found that single server architectures are not very scalable [14]. The findings of this study encouraged us to take the next step into modeling and discrete event simulation, which was confirmed by our simulation. As the result, the goal-driven simulation could also provide an attractive alternative to the quantitative analysis, as simulation is based on the same architectural design model and also provides easy to understand and tangible results. A comprehensive view of the production-ready HRS Softgoal Interdependency Graph and the simulation model topology diagram can be found in earlier analysis working papers [15].

5 Conclusion and Research Direction Two key issues during architectural design are performance and scalability. In this paper, we have presented a methodology which integrates goal-orientation and simulation to analyze the design decisions on performance- and scalability-related architectural issues, and either re-confirm the validity of such decisions or make corrections on them. At least through one case study, we have shown that goalorientation and simulation modeling complement each other in exploring, and narrowing, the performance and scalability design space. Goal oriented design provides structure and formal input to simulation model creation - something that has been needed for a long time. Early simulation modeling and experimentation can provide a goal-oriented architectural design with a closed-loop feedback mechanism to reconfirm design decisions without committing to detailed/component design and implementation of the system. Lessons learned from our case study suggest that future research direction should involve providing simulation techniques for additional nonfunctional requirements. For example, how do we reconfirm our decisions on security-related NFRs, concerning operationalization methods such as a two-factor authentication? What repeatable experiments [attacks] can be devised to test this sub-goal? Acknowledgment. Thanks for encouragement and recognition is given to Alfonso Lopez, EDS Distinguished SE, for building the initial system simulation model.

References 1. Menasce, D., Vigilio, A.: Scaling for E-Business: Technologies, Models, Performance, and Capacity Planning. Prentice Hall PTR, Englewood Cliffs (2000) 2. Pahl, G., Beitz, W.: Engineering Design: A Systematic Approach. Springer, Berlin (German 1977, English 1995) 3. Giorgini, P., Mylopoulos, J., Nicchiaelli, E., Sebastiani, R.: Reasoning with Goal Models, pp. 167–181. Springer, Heidelberg (2002) 4. Dardenne, A., Lamsweerde, A., Fickas, S.: Goal-directed requirements acquisition. Science of computer Programming (1993)

336

T. Hill, S. Supakkul, and L. Chung

5. Chung, L., Nixon, B., Yu, E., Mylopoulos, J.: Non-Functional Requirements in Software Engineering. Kluwer Academic Publishers, Dordrecht (2000) 6. Mylopoulos, J., Chung, L., Nixon, B.: Representing and using nonfunctional requirements: a process-oriented approach. IEEE Transactions on Software Engineering 18(6), 483–497 (1992) 7. Yu, E., Mylopoulos, J.: Understanding “why” in software process modeling, analysis, and design. In: Proc. 16th int’l conference on Software engineering, pp. 159–168 (1994) 8. Smith, K., Wescott, B.: Fundamentals of Performance Engineering. HyPerformix Press, Austin (2007) 9. Law, A., Kelton, D.: Simulation Modeling and Analysis. McGraw Hill, USA (1991) 10. Pritsker, A.: Introduction to Simulation and SLAM II. Wiley Systems, New York (1995) 11. Forrester, J.: Industrial Dynamics. Productivity Press, Cambridge (1961) 12. The Transaction Processing Performance Council, http://www.tcp.org 13. Hill, R., Wang, J., Narhstedt, K.: Towards a Framework for Qualifying Non-Functional Requirements. In: IEEE International Requirements Engineering Conference (RE 2004), pp. 1–6 (2004) 14. Kim, K., Ellis, C.: Narhstedt.: Workflow Performance and Scalability Analysis Using the Layered Queuing Modeling Methodology. In: GROUP 2001, pp. 135–143. ACM, New York (2001); 1-58113-294-8/01/0009 15. Hill, T., Supakkul, S., Chung, L.: Analyzing Architectural Decisions on Scalability: A Goal-Driven Simulation Approach (2009)

Transforming Functional Requirements from UML into BPEL to Efficiently Develop SOA-Based Systems Anisha Vemulapalli and Nary Subramanian Department of Computer Science, The University of Texas at Tyler, Texas, USA [email protected], [email protected]

Abstract. The intended behavior of any system such as services, tasks or functions can be captured by functional requirements of the system. As our dependence on online services has grown steadily, the web applications are being developed employing the SOA. BPEL4WS provides a means for expressing functional requirements of an SOA-based system by providing constructs to capture business goals and objectives for the system. In this paper we propose an approach for transforming user-centered requirements captured using UML into a corresponding BPEL specification, where the business processes are captured by means of use-cases from which UML sequence diagrams and activity diagrams are extracted. Subsequently these UML models are mapped to BPEL specifications that capture the essence of the initial business requirements to develop the SOA-based system by employing CASE tools. A student housing system is used as a case study to illustrate this approach and the system is validated using NetBeans. Keywords: Service-Oriented Architecture (SOA), Business Process Execution Language for Web Services (BPEL4WS or BPEL), Unified modeling Language (UML), Visual Paradigm for UML (VP – UML).

1 Introduction Analyzing the business domain and capturing the user requirements is the primary step to develop a web application. The user requirements can be captured by userstories or requirements-gathering meetings. Technically, the user requirements are classified into functional requirements and non-functional requirements. The intended behavior of the system which user requires the system to perform is captured by functional requirements. Good software design can be achieved by analysis of functional requirements. UML is a general-purpose modeling language that models real-world objects. Use cases are a means to typically capture functional requirements in UML. Use case diagrams are used to capture the actors, use cases and the relationships between them but, not the flow of control of the business process which is the key aspect of SOA. Sequence diagrams and activity diagrams capture the flow of control in UML. The web applications developed employing SOA is a combination of BPEL4WS and a collection of loosely coupled web services with each web service accomplishing partial function of the overall system. The interactions between multiple web services R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 337–349, 2009. © Springer-Verlag Berlin Heidelberg 2009

338

A. Vemulapalli and N. Subramanian

UML Functional Requirements

Model the processes with BPEL4WS or BPEL Specification

Obtain processes BPEL/WSDL Requirements Design Service-oriented Architecture (SOA)

Fig. 1. A process of developing SOA-based system using BPEL specification derived from UML Functional Requirements

can be defined using BPEL4WS or BPEL. BPEL is an XML (Extensible Markup Language)-based description language for web services. The essence of the initial business requirements are captured by mapping the UML models to the BPEL specifications. These BPEL specifications can be used to develop SOA based systems. Figure 1 depicts the process of transforming UML diagrams into BPEL for developing a SOA-based system. In this paper we focus our attention on transformation of functional requirements from UML into BPEL. In our approach, the business processes that the software application should satisfy are captured by means of use-cases from which UML sequence diagrams and activity diagrams are extracted. However, the transformation from UML to BPEL is not a direct transformation. The UML model is first exported into an XMI (XML Metadata Interchange) document which uses XML, and in the second step the BPEL, WSDL and XSD files are generated from the obtained transformation of XMI from UML. Transformation of functional requirements from UML into BPEL must be consistent with the requirements captured from user-stories. We define the mapping rules and the support tools for the transformation. This transformation generates Web Services Definition Language (WSDL) artifacts, XML Schema Definition (XSD) Language artifacts, and a BPEL file. Related Works We can find some related works in the literature. Mantell explores a method for translating UML activity diagrams into bpel4ws 1.0 specification, and Li Zhang and Wei Jiang from Beihang University proposes a MDA-based approach to develop work-flow oriented web applications by modeling and analyzing the business requirements, and modeling the transformation of business process into BPEL through a well-defined mapping. In this paper we focus on transforming the functional requirements captured in UML into BPEL specifications which allow us to efficiently develop SOA-based systems. Mantell proposes a methodology using Rational Rose software from IBM to transform UML to BPEL. In this paper, we propose a more convenient and different approach in which, we make use of VP – UML for constructing UML diagrams and transforming the diagrams to an XMI document, and later, we make use of NetBeans to use the created XMI document and generate the BPEL code. The main contribution of this paper is to facilitate a

Transforming Functional Requirements from UML into BPEL

339

transformation approach, starting from capturing the functional requirements of the system being developed; for that purpose UML diagrams are very useful, as they capture the behavior of the system and the communication between objects in a more appropriate way. Then, we see how we can translate those diagrams into BPEL specifications. Overview The paper is structured as follows. In the next section of this paper, why UML diagrams are used is introduced in more detail. Section 3 introduces BPEL and business processes in more detail. Section 4 proposes an approach to transform the captured functional requirements from UML models into BPEL specifications. Section 5 elaborates the transformation by presenting a case study of a web application - student housing system including the validation of mapping rules and transformation tools. Finally, the conclusions and future work are presented in Section 6.

2 Why UML Diagrams UML is an object-oriented analysis and design language for visualizing and constructing the artifacts and developing business models of a system from Object Management Group (OMG). UML uses graphical notations to describe the system providing abstraction by suppressing the lower level details. Graphical models are easy to understand, and if necessary re-implementation of design can be done with a minimum knowledge. There are twelve diagrams in UML divided into three categories. Structural diagrams capture the elements of a system. Interaction diagrams capture the interactions among objects; these diagrams are subset of behavior diagrams. Behavioral diagrams capture the behavioral features of a system. The architecture of the application is driven by functional requirements. Use cases have become a traditional way to capture the functional requirements providing interactions between actors and, the system being developed. UML Use case diagrams give the overview of the system being developed, show the actors and use cases in the system. The instance of a use case is called a scenario. Decomposing the system into small scenarios increases the readability of the system by the user. These scenarios can be captured by constructing sequence diagrams which show the behavior of a use case and the sequence of communication between objects. Also, use case models provide a systematic way for developing activity diagrams which describe the overall flow of control of the software being developed making use of the information sources like use cases and actors from which activities are derived.

3 BPEL4WS or BPEL The BPEL4WS or BPEL is a XML-based language which uses a combination of web services to enable task-sharing. BPEL is originated from WSFL (Web Services Flow Language) and XLANG (An extension of WSDL-Web Services Description Language) supporting a combination of graph oriented processes and structural constructs for processes, and hence can be used to describe the interfaces for business

340

A. Vemulapalli and N. Subramanian

BPEL/Partner Link Type

BPEL Process

Partner Link Type Partner Link

Action

Port Type Operation

Role

Message Message Type

Input Output

WSDL

Fault

Fig. 2. Relation mapping between the BPEL process and the WSDL

processes. Process oriented approach is very important to SOA which can be achieved by combining BPEL4WS with web services. BPEL interacts with its partners to provide for business process behavior based in web services. WSDL defines service model on top of which the BPEL model is layered which is defined by BPEL. Figure 2 describes the relation mapping between the BPEL process and the WSDL. The interactions are modeled as a flow consisting of sequence of activities beginning, a defined behavior and an end. BPEL contains the following components. BPEL Designer. This includes a graphical user interface to define a business process without giving any technical details. Process Flow Template. The flow logic of the business process is captured by process flow template which is generated from BPEL designer at design time. BPEL Engine. The generated process flow template is executed to make it compatible to BPEL standard. BPEL engine handles errors, maps the data content and invokes the web services. To capture the process information BPEL provides the following elements: Partner Link Types. The relationship between two services and their interaction is represented by the Partner Link Types defining the roles played by each of the services. Process. The process section includes variables, partner Link types, fault handlers and event handlers. Two types of business processes are supported by BPEL, the executable processes and the abstract processes business protocols). The actual behavior of a participant in a business interaction is modeled by the execution processes.

Transforming Functional Requirements from UML into BPEL

341

Activities. BPEL defines two types of activities, basic activities and the structured activities. The basic activities include invoke, assign, receive and reply. Invoke activity calls the web services; it requires input and output variables. The partner link type, port type and the operation are specified by the receive activity. The response to the receive activity is sent by reply activity. The data to the variables is copied by assign activity for further processing. The basic activities are composed by structured activities. Sequence, switch, while, flow and pick are the activities that are included in structured activities.

4 Modeling Approach and Validation Tools Initially, the functional requirements of the system are captured from user stories. These requirements are graphically represented with the UML use case diagrams which can be generated from UML-based modeling tools by identifying the use cases and actors. Use cases represent the business processes in BPEL. Hence the web services and the user of the BPEL processes are modeled as actors as they interact with the use cases. Visual Paradigm for UML 7.0 Enterprise Edition is one of the UML Diagrams Gather Functional Requirements

1. 2. …………………. n.

Use case Diagram: Identify use cases and actors

Class Diagram: Identify the classes

Sequence Diagram: Identify the sequence of actions

Activity Diagram: Identify sequence of activities

XMI Document

BPEL4WS

<process> …….. ……..

Web service A

Web service B

……. ……..

Fig. 3. The methodology for transforming UML Functional Requirements into BPEL Specification

342

A. Vemulapalli and N. Subramanian

UML-based modeling tools used to generate the UML diagrams. Use cases define a collection of scenarios. The UML activity diagrams capture the actual activity that a particular scenario does without including any technical details. In the first step, activities are derived from use cases and later the order of actions is identified. Then the required classes’ entity classes, boundary classes and the control classes are identified for the system. Using these classes, the sequence of actions that the system should perform for a scenario is captured graphically from UML sequence diagrams. The captured sequence diagrams and activity diagrams are then transformed to XMI document with the VP – UML by exporting the UML Diagrams to XMI document, as XMI is generally used to enable meta-model exchanges. The XMI document is then transformed into BPEL executable code by importing the XMI file and generating the BPEL using the CASE tool NetBeans. The transformation includes WSDL artifacts, XSD artifacts and a BPEL file. NetBeans enables the user to import the XMI file from the system and generate the corresponding BPEL code accordingly. Figure 3 describes the methodology for transforming UML Functional Requirements into a BPEL Specification. VP – UML is an environment where UML diagrams can be developed. But, the UML modeling tool must be integrated with the NetBeans in order to generate the BPEL specification. Once the integration is successful, XMI documents can be generated from the VP – UML and can be imported into NetBeans to generate WSDL artifacts, XSD artifacts and BPEL file. The mapping between the UML components ant the BPEL transformations is listed in the section below. 4.1 Mapping UML Components to BPEL Transformations The transformation mechanism from UML into BPEL can be described in four steps as follows: Step 1: Gather the functional requirements. Step 2: Transform the functional requirements into UML Diagrams Step 3: Export the UML diagrams into a XMI (XML Metadata Interchange) document. Step 4: Transform the XMI document into BPEL file. During the transformation from UML to BPEL the UML components are transformed to executable code in BPEL. Figure 4 shows the corresponding mapping between UML components and BPEL transformations. UML Component

BPEL Transformation

Actor

Partners represent the participants in the interaction.

Class and objects Attribute

Business process Variables include variable name, message type and element. Activity represents the basic behavior of a web service.

Activity Graph Messages

Includes partner link type, role, port type and message (receive or reply or request)

Fig. 4. Mapping of UML components to BPEL transformations

Transforming Functional Requirements from UML into BPEL

343

5 Student Housing System Case Study Student Housing System, a common web application is considered as a case study for illustration of how functional requirements are transformed from UML diagrams into BPEL executable code for business analysts. The transformation mechanism of BPEL executable code from the UML diagrams is illustrated with the case study in a sep-bystep manner. Step-1: In the first step, the system that is being developed is described in a single paragraph and the functional requirements of what the system has to do are noted. Later, the use cases and actors are identified from the list of the functional requirements to figure the business model which is usually captured by the UML use case diagram. System Description The Student first goes to the website and applies for the lease using his student email and password. On receiving the lease application, the student identification number (SID) is verified with the list of Student id’s in the Blacklisted Students by the staff member. If the SID is not found in the blacklist then the availability of the room according to the selected floor plan in the lease application is verified. If the selected floor plan is available, the student is sent an approval letter mentioning the amount of deposit he needs to send for hold of the room. The student has to sign the approval letter and send the deposit amount to the lease office and can occupy the room according to his convenience. Functional Requirements 1. To login to the system by the student or the staff member or the administrator. 2. To apply for lease by the student. 3. To verify whether the student is among the blacklisted students. 4. To estimate the available rooms according to the requested floor plan. 5. To maintain the student records and room records. 6. To update the records when the tenant pays the monthly rent. 7. To keep a record of the complaints given by tenants. Step 2: From the functional requirements a business model is developed to understand what the system has to do. According to the system description the system has ‘staff member’, ‘administrator’, and ‘student’ as the actors. Once the student signs the lease he becomes a ‘tenant’, hence ‘tenant’ is yet another actor that is to be included in the system. The actor ‘tenant’ is included just for understanding purpose. In later stages of this paper, ‘tenant’ is not taken into account. From the functional requirements of the system, ‘login’, ‘apply for lease’, ‘verify blacklist’, ‘estimate available rooms’, ‘pay rent’, ‘complaints’ and ‘maintain records’ are identified as the use cases for the system. The maintain records use case includes maintaining both the ‘student records’ and the ‘room records’. Figure 5 depicts the generation of final UML use case model using VP – UML with four actors and seven use cases.

344

A. Vemulapalli and N. Subramanian

Fig. 5. Use case Diagram generated from VP – UML

Fig. 6. Activity Diagram in VP – UML for Lease approval process

After capturing the activity diagram, the classes are identified for the scenario from the use cases. A ‘Records’ class is identified as a boundary class, modeling the control behavior of ‘Records’ use case with ‘create student’, ‘modify student’, ‘delete student’, ‘create room’, ‘update room’, ‘delete room’, ‘create staff’, ‘modify staff’, and ‘delete staff’ as methods. A ‘userinterface’ is identified as a boundary class modeling the interaction between system’s surroundings and its inner workings. The ‘staffmember’ is the entity classes which exchange the information with the ‘records’ class, and the ‘student’ class is yet another entity class interacting with the system. The sequence of actions in a scenario is captured by means of a sequence diagram. The identified classes are used to generate the sequence diagram. Figure 7 depicts the sequence diagram for the Lease approval scenario.

Transforming Functional Requirements from UML into BPEL

345

Fig. 7. Sequence Diagram in VP – UML for Lease approval business process

In the first step, the ‘student’ fills the application and clicks the submit button. In the second step, the ‘staffmember’ checks if there are any new applications. In the third step, ‘verifyBlacklist’ method is called to check if the ‘student’ is in blacklist. In the fourth step, if the ‘student’ is found in blacklist the ‘approvalStatus’ is sent as ‘denial ’to the student. In the fifth step, if the ‘student’ is not found in the blacklist, the message is displayed to the ‘staffmember’. In the sixth step, the ‘staffmember’ checks for the availability of the floor plan through ‘chckAvailability’ method. If the room is available a message is displayed to the ‘staffmember’ in seventh step. Later an ‘approvalStatus’ message is sent as ‘accept’ to the ‘userinterface’ by the ‘staffmember’ in the eighth step. In the ninth step, ‘student’ verifies his application status. Step 3: The generated UML diagrams are exported to XMI to NetBeans from VP – UML. VP – UML provides a direct means to export the generated UML diagrams into an XMI document by selecting File->Export->XMI… from main menu. An Export XMI dialog box is displayed on the screen. We have to locate the XMI file and click OK to export the project to the specified path in the dialog box. The UML diagrams and models are exported as an XMI file from the VP – UML project upon finishing. XMI does not include any visual information; its main purpose is to enable metamodel exchanges among the UML based modeling tools. Figure 8 shows how the UML diagrams can be exported to an XMI document in VP – UML. Step 4: The obtained XMI document is then transformed into BPEL file using NetBeans. Once the NetBeans is integrated with VP – UML the XMI document generated from the step 3 can be imported directly into the NetBeans environment which is later transformed into BPEL executable code as shown in Figure 9. This can be done by selecting File->SDE EE-NB Import->XMI… from the main menu in

346

A. Vemulapalli and N. Subramanian

Fig. 8. Exporting UML diagrams into XMI document in VP – UML

Fig. 9. Transformation of XMI document into BPEL executable Code

NetBeans. An Import XMI dialog box is displayed on the screen. We have to locate the XMI file and click OK to import the XMI file into the NetBeans. The imported XMI file can be found along with the list in the projects window. On right clicking on the imported XMI file, Generate BPEL can be found. Upon clicking generate BPEL in the window, the BPEL generation dialog is displayed and upon completion, BPEL file can be found in the projects window. The files are usually displayed in the Design view in NetBeans. To view the BPEL specification we need to switch to Source view from Design view. The BPEL specification generated from NetBeans is shown in Figure 10. As we have discussed earlier, the use cases in UML are depicted by the business processes in BPEL. From the BPEL specification, we can observe that the actors ‘student’, ‘staffmember’, and ‘Admin’ as the partner links ‘student’, ‘staffmember’ and ‘Admin’ accordingly.

Transforming Functional Requirements from UML into BPEL

347

Initially, the ‘student’ applies for the lease by submitting the lease application online. This can be observed as an “applicationsubmissionmessage” in the BPEL specification. Then the student id is verified with the ‘blacklisted students’ using a “verifyblacklist” variable. If the ‘student’ is not in the blacklist, the requested room is checked for availability with a “chckRoomAvailability” message. If the requested floor plan is free, the ‘staffmember’ sends the ‘approval information’ as a lease approval to the student. <process name="leaseAppApprovalProcess" targetNamespace="http://enterprise.netbeans.org/bpel/StudentHousingSystem/SHS" <partnerLinks> <partnerLink name="student" partnerLinkType="appL:applyForLease" partnerRole="applyLeaseRole" myRole="applyLeaseCallRole"> <partnerLink name="staffmember" partnerLinkType="aprL:approveLease" partnerRole="approveLeaseRole" myRole="approveLeaseCallRole"> <partnerLink name="Admin" partnerLinkType="mrec:maintainRecords" partnerRole="maintainRecordsRole" myRole="maintainRecCallRole"> <source linkName="receive-to-response" transitionCondition="bpws:getVariableData('request', 'studentId')='studentId'"/> <source linkName="receive-to-approve" transitionCondition="bpws:getVariableData('request', 'studentID') !='studentId'"/> <source linkName="response-to-setMessage" transitionCondition="bpws:getVariableData('blacklistVerification', 'blacklistId')='studentId'"/> <source linkName="response-to-approve" transitionCondition="bpws:getVariableData('blacklistVerification', 'blacklistId')!='studentId'"/> <source linkName="response-to-setMessage" transitionCondition="bpws:getVariableData('roomAvailability', 'occupancy')!='free'"/>

Fig. 10. BPEL specification for the Lease approval process

348

A. Vemulapalli and N. Subramanian

<source linkName="response-to-approve" transitionCondition="bpws:getVariableData('roomAvailability', 'ocupancy')!='free'"/> <source linkName="setMessage-to-reply"/>

Fig. 10. (continued)

6 Conclusion In this paper, we propose an approach for transforming the functional requirements captured from UML diagrams into BPEL specifications to develop SOA-based systems. In our approach, we develop business requirements models and, using the VP – UML and NetBeans initially the UML diagrams are exported into an XMI document and later the generated XMI document is transformed to build BPEL file. The approach is validated using a student housing system. Our future work will focus on the analysis of the business process models considering the non-functional requirements – security, adaptability, reliability, performance and usability and, these non-functional requirements are validated using the NFR-Framework [11]. We also plan to evaluate the consistency of business requirements captured by user-centered techniques with BPEL descriptions in future.

Acknowledgements The author wishes to thank the anonymous reviewers of this paper for their detailed and thorough comments which helped us significantly improve this paper.

References: 1. Mantell, K.: From UML to BPEL, https://www.ibm.com/developerworks/webservices/library/ ws-uml2bpel/ 2. Zhang, L., Jiang, W.: Transforming Business Requirements into BPEL: a MDA-Based Approach to Web Application Development. In: IEEE International Workshop on Semantic Computing and systems, pp. 61–66 (2008) 3. Cambronero, M.E., Diaz, G., Pardo, J.J., Valero, V.: Second International Conference on Internet and Web Applications and Services, pp. 24–24 (2007)

Transforming Functional Requirements from UML into BPEL

349

4. Korherr, B., List, B.: Extending the UML 2 Activity Diagram with Business Process Goals and Performance Measures and the Mapping to BPEL. 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., Mišić, V.B., Poels, G., Song, I.-Y., Trujillo, J., Vangenot, C. (eds.) ER Workshops 2006. LNCS, vol. 4231, pp. 7–18. Springer, Heidelberg (2006) 5. Kurahata, H., Fuji, T., Miyamoto, T., Kumagai, S.: A UML Simulator for Behavioral Validation of Systems Based on SOA. In: International conference on Next Generation Web Services Practices, pp. 3–10 (2006) 6. Business processes in a Web services world, http://www.ibm.com/developerworks/webservices/library/ ws-bpelwp/#code1 7. Web Services Business Process Execution Language Version 2.0, http://docs.oasis-open.org/wsbpel/2.0/ wsbpel-specification-draft.html 8. Transformation to SOA: Part 4, How Web services transform from UML to BPEL, http://www.ibm.com/developerworks/rational/library/08/ 0318_pattathe/index.html 9. Transformation to SOA: Part 3, UML to SOA, http://www.ibm.com/developerworks/rational/library/08/ 0115_gorelik/ 10. Mathew, B., Juric, M., Sarang, P.: Business Process Execution Language for Web Services, 2nd edn. PACKT (2006) 11. Chung, L., Nixon, A., Yu, E., Mylopoulos, J.: Non-Functional Requirements in Software Engineering. Kluwer Academic, Boston (2000)

Using an Architecture-Centric Model-Driven Approach for Developing Service-Oriented Solutions: A Case Study Marcos López-Sanz, César J. Acuña, Valeria de Castro, Esperanza Marcos, and Carlos E. Cuesta Department of Computing Languages and Systems II, Rey Juan Carlos University C/ Tulipán, s/n – 28933 Móstoles, Madrid, Spain {marcos.lopez, cesar.acuna, valeria.decastro, esperanza.marcos, carlos.cuesta}@urjc.es

Abstract. As services continue achieving more importance in the development of software solutions for the Internet, software developers and researchers turn their attention to strategies based on the SOC (Service-Oriented Computing) paradigm. One of these development approaches is SOD-M specifically designed for building service-oriented solutions. In this article we present the results of redesigning a real-world Web-based Information System, called MEDiWIS, using SOD-M. The main goal of the redesigned MEDiWIS system is to support the storage and management of digital medical images and related information by presenting its functionalities as software services. We analyze in detail the main challenges we have found using an ACMDA (Architecture-Centric Model-Driven Architecture) approach to achieve this goal. Keywords: Service-Oriented Architecture (SOA), Model-Driven Architecture, Architecture-Centric Development, ACMDA.

1 Introduction In the last years, with the diversification of companies and the emergence of multiorganizational business processes, a new computing paradigm has been rocketed to the first row of attention: Service-Oriented Computing (SOC)[1]. The architectural viewpoint of this paradigm, Service-Oriented Architecture (SOA)[8], supports the development of dynamic, loosely-coupled and cross-organizational solutions. These features represent the main issues companies are currently demanding, from the technological point of view, to accomplish their goals [14]. However, this shift of direction to the service-oriented approach requires the precise definition of adequate development methods, techniques and methodologies able to overcome the challenges that arise with that change in the way of thinking. To face these issues, two important points should be taken into account: first, the existence of a vast amount of languages and standards supporting SOA [28]; and, secondly, the increasing importance of using approaches allowing for the reflection and implementation of the concepts that come along with the features of new R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 350–359, 2009. © Springer-Verlag Berlin Heidelberg 2009

Using an Architecture-Centric Model-Driven Approach

351

businesses. Within the software engineering field, the model-driven approaches have resulted of great value in order to tackle this challenges ([3][4][15] etc.). The Model-Driven Engineering (MDE) approach considers models as the basic artefact to be used in system development and advocates the definition of transformation rules to automatically generate the desired software solution [25]. Using this view as starting point it is possible to reason about the concepts describing a system without constraining to the restrictions imposed by any specific language or technology, and, more importantly, to evolve from a high level conception of the system to obtain models closer to the implementation level. Among the initiatives following that approach we can mention Software Factories [10], from Microsoft, or MDA [22], proposed by the OMG consortium. In particular, the MDA approach has gained a lot of attention in the research community. It suggests a separation of models in several abstraction levels: CIM (Computation Independent Models), PIM (Platform Independent Models) and PSM (Platform Specific Models). Additionally, MDA encourages model evolution to be done through the definition of transformation rules at the metamodel level. In this article we explore the benefits of using together both the MDA approach and SOA in order to redefine and adapt an existing Web Information System (WIS) for the storage and management of digital medical images called MEDiWIS [1]. We focus specially on the architectural aspect since the methodology we use, MIDAS, is considered to follow an ACMDA approach as it will be explained later. This system was originally developed using a traditional 3-layer architecture approach, in which the presentation layer was represented by several Web pages, the persistence layer was implemented by using a commercial XML-DB solution; and the system business logic (behavioural layer) based on the .Net technology. However, the scope where this tool was used continued to broaden, to the extent of requiring either a complete development from scratch, or a redesign of the existing components by upgrading them with new features. The final decision taken was to transform the system into a service-oriented solution which is what we detail in this article. Additionally, the redesign of the MEDiWIS system allows us to demonstrate the suitability of the combination of MDA and SOA for the development of software systems from a methodological point of view. To achieve this, we have focused on the architectural view of the SOD-M (Service-Oriented Development Method) method, as presented in previous work [7]. By transforming MEDiWIS into a serviceoriented solution, we prepare the system to be used not only by a human being, but also as a data source for other multi-purpose applications and integration solutions. In addition, we allow the system to be upgraded easily with new features, such as image co-registration, multi-disciplinary image share, security issues, etc. The structure of the article is as follows: Section 2 gives a detailed description of the initial build of the MEDiWIS system. Section 3 is devoted to explain the redesign of the MEDiWIS system. In that section the SOD-M and associated methodological framework are also briefly explained. Section 4 gathers some of the most relevant related work and, finally, Section 5 puts together the main conclusions and lessons learned from the work presented in this article.

352

M. López-Sanz et al.

2 The Case of the MEDiWIS System MEDiWIS is a WIS for the management and processing of medical images through the Web developed at the Rey Juan Carlos University [12]. This WIS was developed to manage the information related to scientific studies in the neuroscience research field. The initial goal of the system was to offer neuroscience researchers historical medical images storage with easy access and the normalized processing and analysis of medical images. Original medical images are usually obtained, directly from clinical instrumentation machines, in two formats: DICOM and Analyze, which are the accepted standards for the exchange of medical image information [16]. As these standards are primarily used in the medical scope, in order to gain interoperability with other systems, the original MEDiWIS was designed focusing on the XML language for the representation of the exchanged information. Although the MEDiWIS system represents a fully-functional software solution, it was developed focusing specially from the content point of view. The aim of the redesign effort puts more attention to the functional aspect maintaining the importance of XML within the new system. The overall Web architecture, which can be seen in Figure 1, was structured in three layers: presentation, behavioural and persistence layer. -

Presentation Layer. This layer comprises a Web user interface in which a module supporting the upload of sets of image files is included. This interface also allows users to store and properly manage and classify the uploaded files. - Behavioural Layer. This layer is composed of five modules: Query Processor, Image Processor, Image Viewer, XML Generator and Data Transformation. The XML Generator takes DICOM or Analyze files and transforms them into XML documents. In order to improve the modularity and portability of the system, and before inserting them into the database, it is necessary to obtain an intermediate representation of the DICOM and Analyze files. The Data Transformation module takes, as input, the intermediate XML files generated by the XML Generator module and transforms them into a different XML document adapted to the requirements of the actual database schema. The Query Processor is responsible for building the queries matching the user criteria in order to execute them on the DBMS (Database Management System), and showing the results of the queries through the Web interface module. The Image Processor module, in turn, allows to perform medical image processing, including registration, filtering and statistical analysis. The results and the information of the procedures used for obtaining those results are stored jointly in the database for further browsing or ulterior inspection. Finally, the Image Viewer module is the responsible for transferring the results, in the form of parametric mappings superimposed over anatomical images to the presentation layer. • Persistence Layer. This layer allows the storage of all the clinical study images together with the results from the subsequent image processing. The database works as a massive, historical storage repository, which can be queried an accessed through the Internet in ongoing studies and research projects. To support that issue, we used a commercial solution based on the XML-DB principles. From a conceptual model for clinical trials [12], we developed a database XML schema according to the proposal specified in [26].

Using an Architecture-Centric Model-Driven Approach Dicom file

Presentation Layer

Web User Interface

Image Processor

Persistence Layer

Analyze file

Image File Uploader

XML Generator

Query Processor

Behavioural Layer

353

Image Viewer

Data Transformation

XML-DB

Fig. 1. Architectural Description of MEDiWIS

3 Development of the MEDiWIS System Using an ACMDA Approach In this section we present the benefits of combining together MDA and SOA. First, we describe the SOD-M method and, second, its application to the redesign of the MEDiWIS system. 3.1 SOD-M and the MIDAS Framework The research work presented in this article focuses on the architectural modelling aspect of SOD-M, an integrated method for the development of information systems that uses the concept of ‘service’ as core concept to represent the behaviour of a system. SOD-M is the part of the MIDAS methodological framework [6] devoted to model the behaviour of the system. MIDAS is a methodological framework that proposes the development of information systems following an Architecture-Centric Model-Driven Architecture (ACMDA) approach [19]. As a consequence of this, the architectural aspect affects both the PIM and PSM levels of the model architecture. The architecture is considered to be the driving aspect of the model-driven development process. It allows the specification of which models in each level and which elements inside models are needed according to the software architecture design. The architectural models are divided into two levels corresponding to the PIM and PSM levels. The reason to make this division is that, with an architectural view of the system at PIM-level [17], we ensure that there are no technology or implementation constraints in the model, besides facilitating the possibility of establishing different PSM-level models according to the specific target platform and derived from one unique PIM-model. Moreover, and applying this conception to a system following the SOA paradigm, the services that appear at the PIM-level architecture model will be understood as conceptual services, classified depending on the role or functionality given and the entities that group those services. Of course, the dependencies and limitations among

354

M. López-Sanz et al.

«serviceContract» ImageUpload -MEP = 'Dialogue'

Neuroscience Researcher «serviceContract» ImageVisualization -MEP = 'Q/R'

«interactionServ» File Uploader

+

+ «serviceContract» FileTransformation -MEP = 'Q/R'

«service» Format Mapper

«service» Bank Service

«compositeServ» Query Processor {policy = orchestration}

«interactionServ» Image Viewer

«serviceContract» feeTransfer -MEP = 'Q/R'

«serviceContract» ImageRetrieval -MEP = 'Q/R'

«serviceContract» ImageMapping -MEP = 'Q/R'

«service» Image Processing

«serviceContract» ImageManagement -MEP = 'One-Way'

«serviceContract» feeTransfer -MEP = 'Q/R'

«outerProvider» Bank System

«innerProvider» Image Manager System

«serviceContract» ImageDataStorage -MEP = 'Q/R'

+

«outerProvider» Computation System

«serviceContract» ImageProcess -MEP = 'Dialogue'

«service» DB Manager

+

«outerProvider» Storage System

Fig. 2. Service-oriented MEDiWIS: PIM-level architectural model

the services, entities and other components will be modelled without reflecting, in any case, any implementation or platform feature or restriction. The elements to appear at the PSM level will be the same as in the PIM level but refined and applied over a specific service implementation technology. 3.2 Architectural Modelling of the MEDiWIS System Although the development process includes several other models, ranging from the CIM level to the PSM level, and involving the additional concerns of MIDAS (content, hypertext, etc.), here we will only focus on the architectural models (both PIM and PSM) plus the business level models (CIM models), since they gather the great majority of the changes needed in the new version of MEDiWIS. First models to be built are those at the CIM level of the MDA proposal. Since these models depict the business and domain environment in which the system is located, both the original and the redesigned version will share the models at that level. For that reason and due to space restrictions we do not show here that model (refer to [7] to see it). In subsequent models of the model architecture, business entities will help to decide the grouping of the services and how responsibilities are assigned to each of them. Because the system functionality must persist throughout the redesign of the system, MEDiWIS must provide an interface to be used by neuroscience researchers, and therefore it has to cope with the transformation of medical standards to XML. The service-oriented version of MEDiWIS will be comprised of several services in charge of achieving the original functionality. This aspect can be observed in the architectural representation of the system at the platform independent model (PIM) shown in Figure 2. In it, all conceptual services involved in the construction of the system are modelled to build the architectural view of the MEDiWIS system, conforming to the metamodel specified in [17] (service attributes and operations have been removed for the sake of clarity). Any potential client of the system is represented through the specification of two interaction services. The redesigned system is not only devoted to provide

Using an Architecture-Centric Model-Driven Approach

355

functionality to human beings (neuroscience researchers) but is also prepared to be used by any other application, which does not necessarily use a Web interface. Consequently, MEDiWIS is now prepared to take part of a future global interaction solution. On the core functionality side, the system still needs to transform the original medical formats to a common language (functionality accomplished by the formatMapper service) and has to be able to process queries and data information as a result of the user interaction (queryProcessor service). Finally, there exist now a much independent support for image processing and storage. By specifying both the imageProcessing and DBManager services we ensure that the system remains independent from the storage policy and from the processing capabilities. The database support now is understood as the access to services in charge of controlling and managing a storage resource and the inner business logic is modelled as specialized services composed following an orchestration coordination strategy. Once the PIM level view of the architecture has been modelled, several other models should be created as indicated by the SOD-M method and the MIDAS framework. Due to space limitations, the concrete models have been left out of the article. The reader might refer to the bibliography to check how the hypertext of the system [20], the concrete behaviour [7] and the database schema at PIM level [26] should be modelled. In order to obtain a workable version of the system, the features of the specific implementation technology should be included in the already designed models. This will be done through the specification of the models at the PSM level. The corresponding architectural model of the system at PSM level is shown in Figure 3. That model for the platform dependent level must represent which technologies are used to implement each of the services that build the software solution. In that sense, this model will represent services, understood as computational entities providing functionalities through a well known interface; service components, identified with components not necessarily connected to web technologies, i.e., components usually found on hybrid architectures such as pre-existent components or COTS (Commercial Off-The Shelf) ones; and, finally, the resources that are managed, controlled and accessible through a service. Figure 3 depicts service components such as imageViewerInterface and uploaderInterface that will be implemented, in a first step, using a Web interface (as indicated by the value given to the Tech property) to maintain the original MEDiWIS functionality. The formatMapper service is considered to be a computational entity that will be built upon the standard Web Service technology [27]. The composite service specified in the PIM model is split into two Web services at the PSM level: resultBuilder and infoManager. The main task of the former will be to prepare the images to be processed and invoke the external imageProcessing service. The infoManager, in turn, will be responsible of executing, among other responsibilities, the workflow associated to the retrieval, transformation and subsequent storage of results. Apart from the imageProcessing service, there exist two more external services: BankService, in charge of managing the economical information related to the operations performed by any user over the system; and DBAccessManager, which is a Web Service that represents the unique way to access and manage the external storage for the digital medical images and related information.

356

M. López-Sanz et al.

Neuroscience Researcher

«servComp» UploaderInterface {Tech = Web Interface, Java}

«service» Format Mapper {Tech = WS}

«asynchOp» +uploadImages() «asynchOp» +updateImageFile()

«synchOp» +fromXMLtoDICOM() «synchOp» +fromXMLtoAnalyze() «synchOp» +extractXMLData()

«servComp» ImageViewerInterface {Tech = Web Interface, .Net}

«service» infoManager {Tech = BPEL}

«synchOp» +retrieveImages() «synchOp» +normalizeImages() «synchOp» +segmentImage() «synchOp» +updateRelatedInformation()

«asynchOp» +storeImages() «synchOp» +retrieveImages() «synchOp» +retrieveInformation() «asynchOp» +executeImageTask()

«service» Bank Service {Tech = WS} «asynchOp» +updateCredit()

«service» DBAccessManager {Tech = WS}

«service» resultBuilder {Tech = WS} «synchOp» +prepareImage() «asynchOp» +configureAlgorithm() «synchOp» +buildResultStats()

«service» Image Processing {Tech = WS} «asynchOp» +processImages()

«resource» Storage {Type = DBMS}

«synchOp» +executeQuery()

Fig. 3. Service-oriented MEDiWIS: PSM-level architectural model

The imageProcessing service is one of the most important services at the PSM level. From the point of view of the capability of the system, as it has been implemented as an external and independent entity, it allows the system to be upgraded and extended with new functionalities very easily. At this moment, this service is only a simple Web service in charge of image normalization and segmentation, however, we are currently moving the algorithms to a Grid Computing [9] environment, and, as a result, this service will be much more complex in a near future. The contracts that were specified in the PIM-level architectural model have been transformed into simple communication connections among the different services identified at the PSM-level. This is due to the fact that the way in which the communication among two elements is implemented will depend on the technology selected. In most of the cases, the communication control will simply be embedded in the implementation of the elements connected (a Web Service invocation from the Web interface will be coded within the code of the server Web page). In the cases in which a more complex communication takes place, i.e., in Dialogue service contracts, a ‘mediator’ element will be needed. This element will implement the message exchange pattern and control the communication as the involved services shift turns.

4 Related Works In this section we study the most representative proposals concerning service enactment and definition, software architecture modelling and model-driven service development. About the identification of the elements to appear in service architectures there are different points of view. Baresi et al.[5], for example, consider that any SOA development is built upon service clients, providers and service discovering agents. This vision constraints the scope in which SOA can be used since their proposal cannot be generalized to other execution. Starting from that proposal, Heckel et al. [11] define a UML profile for SOA modelling. Their UML profile only allows to

Using an Architecture-Centric Model-Driven Approach

357

define two distinct kinds of services (provider and registry) and does not include any facility to model semantic or constraint. Wada et al. [29] present a solution based also on UML. They focus on the representation of non-functional aspects and the definition of services, messages, connectors and pipes as only first-class elements. There are other proposals whose set of concepts is more complete and adequate for the definition of a general SOA model. Papazoglou et al. [23], for example, make a classification of the concepts involved in SOA development but from the viewpoint of the role given to each component. Autili et al. [4], in turn, define a complete service concept model for the development of service-based applications focusing on quality of service features in pervasive systems. This approach is also worth mentioning as it is one of the few proposals that include a specific element to handle user interaction. Several other proposals have come up from the enterprise research world; however, most of them are based on Web Services technologies. This circumstance appears in works such as the ones by Aiello et al. [2], Lublinsky et al. [18], Erl [8], or Krafzig et al. [14]. This is mainly due to the fact that they start from the definition of service (and SOA by extension) given by the W3C [28], where a service is defined as a stateless distributed entity. This represents a strong restriction when trying to define the system architecture at a conceptual and generic level and supporting technologically neutral architectures. Concerning the definition of the architecture itself, that is, the architectural model containing the service concepts and elements, most of the proposals use UML as notation. They develop service metamodels ([30]) or UML profiles to be used in SOA modelling ([11][29]). Following the principles of Web services, Amir et al. [3] define 5 different profiles, each of them associated to a SOA concept: resource, service, message, policy and agent. This proposal is too close to the implementation technology and so it wouldn't be suitable to develop a generic SOA system where a platform exchange should happen. It is also worth mentioning the proposal by IBM and its UML 2.0 profile [13], which we think is one of the most complete and accurate approaches for SOA modelling. There are also proposals of ADLs for the description of SOA such as the ones by Krüger et al. [15] or Rennie et al. [24], but this is a topic beyond the scope of this article. As MDD is currently a leading trend in software development, many initiatives follow this approach. For example, Zdun et al. [30] use models to integrate processdriven service-oriented architecture models. Heckel et al. [11] define a UML profile for SOA modelling taking into account the MDA principles, that is, the separation of PIM and PSM levels. In summary, there are not many proposals which gather simultaneously all the features of the work presented: first, all the concepts involved in SOA: the enactment of service composition, the description of service boundaries with the environment, the definition of architectural constraints within the model, etc.; second, a sufficient abstraction level, enough to be independent of the target platform and underlying technologies in order to allow a flexible development of service-based solutions; and, third, a methodological solution in which SOA architectural models play the guiding role throughout the entire software development process.

358

M. López-Sanz et al.

5 Conclusions In this work we have presented the redesign of a system for the storage and management of medical digital images called MEDiWIS. The output we have obtained during the redesign process has served us to check the suitability of the SOD-M method for the development of next generation software following an ACMDA approach and service-oriented. By using an architecture-centric perspective we ensure, first, an adequate control of the system evolution since the architectural model will reflect all the structural and behavioural changes that affect the system; and, second, the proper way of representing any reconfiguration occurred within the system and its elements. By following a model-driven approach we allow the semi-automatic evolution not only during the software lifecycle (through the control of the architectural changes) but, more importantly, during the software development process itself. In order to achieve automatic transitions form one model to another, transformation rules should be defined. However, and due to space limitations, we have left this aspect for future work. Finally, by taking into consideration the principles of the MDA proposal, we benefit from a model architecture that allows us to clearly separate and identify the main business domain needs at high level (CIM level). Moreover, by having a model describing the software solution at a platform and technologically ‘agnostic’ level, we define a satisfactory support for interoperability among systems. Models defined at PIM level also favour the migration of the system from one platform to another. This goal will be achieved just by indicating the target technology of election at PSM level and defining its correspondent transformation rules.

Acknowledgements This research is partially funded by projects MODEL-CAOS (TIN2008-03582/TIN) and AT (CONSOLIDER CSD2007-0022, INGENIO 2010) from the Spanish Ministry of Science and Innovation.

References [1] Acuña, C.J., Marcos, E., de Castro, V., Hernández, J.A.: A web information system for medical image management. In: Barreiro, J.M., Martín-Sánchez, F., Maojo, V., Sanz, F. (eds.) ISBMDA 2004. LNCS, vol. 3337, pp. 49–59. Springer, Heidelberg (2004) [2] Aiello, M., Dustdar, S.: Service Oriented Computing: Service Foundations. In: Proc. of the Dagstuhl Seminar 2006. Service Oriented Computing, vol. 05462 (2006) [3] Amir, R., Zeid, A.: A UML profile for service oriented architectures. In: OOPSLA 2004 Companion, Vancouver, Canada, October 2004, pp. 192–193 (2004) [4] Autili, M., Cortellessa, V., Di Marco, M., Inverardi, P.: A Conceptual Model for Adaptable Context-aware Services. In: Proc. of WS-MaTe 2006, Palermo, Italy (2006) [5] Baresi, L., Heckel, R., Thone, S., Varro, D.: Modeling and validation of service-oriented architectures: Application vs. style. In: Proc. ESEC/FSE 2003, Helsinki, Finland (September 2003) [6] Cáceres, P., Marcos, E., Vela, B.: A MDA-Based Approach for Web Information System Development. In: Workshop in Software Model Engineering (2003)

Using an Architecture-Centric Model-Driven Approach

359

[7] De Castro, V., Marcos, E., López-Sanz, M.: A model driven method for service composition modelling: a case study. Int. J. Web Eng. Technol. 2(4), 335–353 (2006) [8] Erl, T.: Service-Oriented Architecture: Concepts, Technology, and Design. Prentice Hall PTR, Upper Saddle River (2005) [9] Foster, I., Kesselman, C.: The Grid: Blueprint for a New Computing Infrastructure. Morgan Kauffmann, San Francisco (1998) [10] Greenfield, J., Short, K., Cook, S.: Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools. John Wiley & Sons, Chichester (2004) [11] Heckel, R., Küster, J., Thöne, S., Voigt, H.: Towards a UML Profile for Service-Oriented Architectures. In: Proc. of MDAFA 2003, Enschede (June 2003) [12] Hernandez, J.A., Acuna, C.J., de Castro, M.V., et al.: Web-PACS for Multicenter Clinical Trials. IEEE Trans. on Inf. Technology in Biomedicine 11(1), 87–93 (2007) [13] Johnston, S.: UML profile for software services. IBM DeveloperWorks Site (13 April 2005), http://www-128.ibm.com/developerworks/rational/library/ 05/419_soa/ [14] Krafzig, D., Banke, K., Slama, D.: Enterprise SOA: Service Oriented Architecture Best Practices. Prentice Hall PTR, Upper Saddle River (2004) [15] Krüger, I.H., Mathew, R.: Systematic Development and Exploration of Service-Oriented Software Architectures. In: Proc. of WICSA 2004, Oslo, Norway, pp. 177–187 (2004) [16] Kush, R.: Clinical Data Interchange Standards Consortium. In: Proc. of CDISC 2003 (2003), http://www.cdisc.org/pdf/CDISC2003RebeccaKush.pdf [17] López-Sanz, M., Acuña, C.J., Cuesta, C.E., Marcos, E.: Defining Service-Oriented Software Architecture Models for a MDA-based Development Process at the PIM-level. In: Proc.of WICSA 2008, Vancouver, BC, Canada (2008) [18] Lublinsky, B.: Defining SOA as an architectural style: Align your business model with technology. IBM DeveloperWorks site, http://www-128.ibm.com/ developerworks/webservices/library/ar-soastyle/index.html [19] Marcos, E., Acuña, C.J., Cuesta, C.E.: Integrating Software Architecture into a MDA Framework. In: Gruhn, V., Oquendo, F. (eds.) EWSA 2006. LNCS, vol. 4344, pp. 127– 143. Springer, Heidelberg (2006) [20] Marcos, E., Cáceres, P., de Castro, V.: Modeling the Navigation with Services. In: ICWI 2004, pp. 723–730 (2004) [21] OASIS. Reference Model for Service Oriented Architecture. Committee draft 1.0, http://www.oasis-open.org/committees/wd-soa-rm-cd1ED.pdf [22] Miller, J., Mukerji, J. (eds.): OMG. Model Driven Architecture. Document No. ormsc/2001-07-01, http://www.omg.com/mda [23] Papazoglou, M.P.: Service-Oriented Computing: Concepts, Characteristics and Directions. In: Proc. of WISE 2003, Roma, Italy, December 10-12, pp. 3–12 (2003) [24] Rennie, M.W., Misic, V.B.: Towards a Service-Based Architecture Description Language. TR 04/08, Technical Report, University of Manitoba, Canada (August 2004) [25] Stahl, T., Voelter, M., Czarnecki, K.: Model-Driven Software Development: Technology, Engineering, Management. John Wiley & Sons, Chichester (2006) [26] Vela, B., Marcos, E.: Extending UML to represent XML Schemas. In: Eder, J., Welzer, T. (eds.) Proc. of CAISE 2003 FORUM (2003) [27] Vela, B., Acuña, C., Marcos, E.: A Model Driven Approach for XML Database Development. In: Atzeni, P., Chu, W., Lu, H., Zhou, S., Ling, T.-W. (eds.) ER 2004. LNCS, vol. 3288, pp. 780–794. Springer, Heidelberg (2004) [28] W3C. Web Services Activity and Standards, http://www.w3.org/2002/ws/ [29] Wada, H., Suzuki, J., Oba, K.: Modeling Non-Functional Aspects in Service Oriented Architecture. In: Proc. of the ICSOC 2006, Chicago, IL (September 2006) [30] Zdun, U., Dustdar, S.: Model-Driven Integration of Process-Driven SOA Models. Intl. J. of Business Process Integration and Management 2(2), 109–119 (2007)

Using AOSD and MDD to Enhance the Architectural Design Phase M´ onica Pinto, Lidia Fuentes, Luis Fern´ andez, and Juan A. Valenzuela Dept. Lenguajes y Ciencias de la Computaci´ on, University of M´ alaga, Spain {pinto,lff,lfernandez,valenzuela}@lcc.uma.es http://caosd.lcc.uma.es

Abstract. This paper describes an MDD process that enhances the architectural design phase by closing the gap between ADLs and the notations used at the detailed design phase. We have defined modelto-model transformation rules to automatically generate either aspectoriented or object-oriented UML 2.0 models from high-level architectural specifications specified using AO-ADL. These rules have been integrated in the AO-ADL Tool Suite, providing support to automatically generate a skeleton of the detailed design that preserves the crosscutting and the non-crosscutting functionalities identified at the architecture level.

1

Introduction

Architecture description languages (ADLs) deal with the description, analysis and reuse of software architectures, providing an appropriate high-level view of complex software systems. However, in spite of the importance of describing the software architecture of a system, ADLs are not extensively used. This is not due to the lack of ADLs, since there is an important number of them, not only those based on formalisms (ACME [1], RAPIDE [2] and C2 [3]), but more modern ones based on XML (xADL [4]) or based on aspect-oriented (AO) separation of concerns (PRISMA [5] and AO-ADL [6]). We consider that the reasons are instead related to the lack of appropriate architectural tool support and the lack of connection with next phases of the software development. On the one hand, there is a clear gap between ADLs and the notations used in later phases of the software development – while most ADLs are based either on formalisms, XML or specifically defined notations, the most widely used modelling language for detailed design is UML. The consequence is that software engineers do not usually take advantage of the power of ADLs. When a high-level architecture is provided it is usually modelled using the UML component diagrams, which define a very restricted version of the concept of ADLs connectors. On the other hand, tool support is needed to model, reuse and reason about software architectures. Moreover, tool support to be able to generate a skeleton of the detailed design from information available at the software architecture, 

Supported by Spanish Project TIN2008-01942 and European Project AMPLE IST-033710.

R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 360–369, 2009. c Springer-Verlag Berlin Heidelberg 2009 

Using AOSD and MDD to Enhance the Architectural Design Phase

361

without loss of relevant information, is also required. Finally, it would be desirable that the skeletons were automatically generated. These shortcomings can be solved by defining mappings between ADL and UML 2.0 metamodels, and by implementing the required tool support. Both things can be appropriately done using current Model-Driven Development (MDD) [7] technologies. In this paper we show our experience using MDD to enhance the architectural design phase by closing the gap with the detailed design. After this introduction, an overview of our MDD process is provided in Section 2, while the details are provided in Section 3 using a running example. Section 4 describes the AO-ADL Tool Suite, Section 5 the related work and Section 6 our conclusions.

2

Our MDD Process

Using MDD, a software system is created through the definition of different models at different abstraction layers, where models of a certain abstraction layer – i.e. output models, are automatically derived from models of the upper abstraction layer – i.e. input models, by means of model transformations. In order to make a model transformation feasible, both the input and the output models must conform to a metamodel, which specifies their precise abstract syntax [8]. The model transformation specifies the rules for automatically generating the corresponding output model from an input model. These transformations are specified using a model transformation language, such as QVT or ATL [9]. In this section we provide an overview of the MDD process that we have defined to automatically transform a software architecture, described using an aspect-oriented ADL (in this case the AO-ADL language [6]), into a skeleton of its detailed design, using either plain UML 2.0 or an AO extension of UML, like Theme/UML [10]. Figure 1 shows the main models and transformations of our process. Although the starting point is always an AO version of the software architecture (box (1)), an important contribution of this process is that in the lower levels it allows choosing between following an AO development methodology (left side of Figure 1) or an OO development methodology (right side of Figure 1). Following this approach, our main goal is the definition of an automatic process that can be useful for both AO and OO designers and implementers. Taking as input an AO-ADL software architecture, the following step in our MDD process is the automatic generation of a skeleton of its detailed design. Two alternative outputs are possible. The first transformation (box (2)) automatically generates an AO version of the detailed design using Theme/UML, an AO extension of UML. In this case we would be following an AO development methodology, so the separation of concerns identified and modelled at the architectural level is explicitly maintained at the design level. The second transformation (box (6)) generates a skeleton of the detailed design of such architecture in plain UML 2.0. In this case, we would be using an OO development methodology, so the crosscutting concerns identified at the architectural level are not explicitly separated at the design level. Instead, they are weaved at the design level with the non-crosscutting concerns. The generated design models will conform to the Theme/UML metamodel (box (3)), or to the UML

362

M. Pinto et al. AO-ADL specification (conforming to the AO-ADL metamodel )

AO-ADL 2 Theme/UML MDD Transformation

(2)

(6)

AO-ADL 2 UML 2.0 MDD Transformation

Theme/UML specification (conforming to the

UML 2.0 specification (conforming to the

Theme/UML metamode l)

UML 2.0 metamodel )

MDD Transformation

AO language (AspectJ, CaesarJ ...)

(3)

(7)

(4)

(8)

(5)

(9)

Transformation

OO Development Methodology

AO Development Methodology

(1)

OO language (Java, C++)

Fig. 1. MDD Process in the Software Development Lifecycle using AO-ADL

2.0 metamodel (box (7)), respectively. These designs need to be completed using any existing UML editor. Once the detailed design is completed, the last step is the automatic generation of code (boxes (4) and (8)), either AO code (box (5)) or OO code (box (9)). These are third-party transformations [11] that can be integrated into our MDD process, although they are not included in this paper.

3

An Example Step by Step

In this section our MDD process is followed step by step using an auction system running example. Basically, in an auction system ”sellers initiates auctions offering items to be sold, and buyers bid for them. The sellers set the initial and minimum bid and initiate the auction. Buyers join auctions, bid for items and increase their previous bids”. Additionally to these functional requirements, several extra-functional requirements are identified: (1) Encryption: the communication between users and the auction system must be encrypted, (2) Consistency: minimum bids, bid prices and bid increments must be valid, and (3) Synchronization: more than one buyer can simultaneously bid for the same item. 3.1

AO-ADL Specification

The main building blocks in AO-ADL1 are components and connectors. Components model both non-crosscutting and crosscutting concerns, and are described by their provided/required ports. The composition (e.g. weaving in AO) between components modelling crosscutting and non-crosscutting concerns is specified as part of connectors. Thus, the semantic of connectors is extended with the definition of aspectual bindings. Also, aspectual roles are a new kind of role in AO-ADL. 1

The AO-ADL metamodel [6] is not shown here due to the lack of space.

Using AOSD and MDD to Enhance the Architectural Design Phase

363

<provided_interface uri ="//interface[@name='Encryption Service ']" type="MSG" portName="Encryption"/> (1) (4)

Encryption (1)

Consistency (2)

Synchronization (3)

Encryption

Synchronization Service

(4) Service

encrypt(..) decrypt(..) Encryption

(6) Buyer

User GUI > BuyerService

Buyer Connector

(5) join(..) bid(..) Increase(..)

Auction

Auction > BuyerService

(5) ... ... (6) <pointcut_specification> <pointcut> (//provided_role[@name='Buyer']) and (//operation[@name='*']) (6.5) (6.4) (6.1) (6.2) (6.3) ...

(a)

(b)

Fig. 2. AO-ADL Architecture of the Auction System

Components connected to aspectual roles behave as aspectual components, while those connected to provided /required roles behave as base components. Figure 2.(a) shows five different components connected through a connector. On the one hand, there is an interaction between the User GUI and the Auction base components, which model the user and the auction non-crosscutting concerns. On the other hand, the Encryption, Consistency and Synchronization aspectual components model crosscutting concerns. The auction system shown in Figure 2.(a) is specified by a set of XML files in Figure 2.(b), where XML code partially describing the Encryption component and the BuyerConnector connector is shown. The code (4) describes the Encryption Service interface with two operations: encrypt and decrypt. This interface is used in the description of the Encryption component (code (1)) that provides the Encryption Service interface by means of its port Encryption. The code (5) specifies the aspectual part of the BuyerConnector connector. On the one hand, the Encryption Service interface is associated with an aspectual role of the connector, named Encryption. This means that a component connected to this role will behave as an aspect affecting the interaction between base components, according to the information specified in the aspectual binding part of the connector (code (6)). Concretely, the pointcut specification (code (6.1)) describes that the encrypt method (code (6.2)) of the aspectual component connected to the Encryption role (code (6.3)) will affect to any operation of the provided role Buyer. Moreover, it will be injected before (code (6.4)) any call intercepted by the pointcut. 3.2

Transformation to Theme/UML

Theme/UML is an UML profile that extends the UML metamodel to define some new elements specifically created to aspect-oriented design. The most relevant

364

M. Pinto et al.

elements are the themes. A theme is a UML packet that contains all the UML elements that are needed to model a particular concern. It also defines two new relationships that can be established between themes: the merge and the bind relationships. The merge relationship models the relationships between concerns and the bind relationship models the aspectual bindings of crosscutting concerns. In order to implement this transformation, the first step is the definition of the mapping between the metamodels of AO-ADL and Theme/UML. This mapping was defined as a collaboration with the Trinity College of Dublin (creators of Theme/UML) [12]. A summary of this mapping is shown in table 1. We have then implemented it using MDD, specifically the ATL language. The transformation is carried out by the application of a set of ATL rules that describe how elements of the source model (one or several elements of AO-ADL) are transformed into elements of the target model (one or several elements of Theme/UML). Three different possibilities are offered in our approach to transform AOADL elements into Theme/UML elements. They are motivated by the fact that in Theme/UML a theme represents a single concern. However, in AO-ADL, components of low granularity can be associated with a single concern, but more complex components and, in particular, composite components are usually modelling more than one concern. In order to cope with this difference, our MDD process includes a manual step, previous to the automatic transformation, in which an expert in the domain of the architecture to be transformed must choose the kind of transformation to be performed: (1) An AO-ADL component models a single concern and is mapped to only one theme; (2) Each interface in the component models a different concern and thus each interface is mapped to a different theme, or (3) Each operation in the interfaces of the component models a different concern and thus each operation is mapped to different themes. Notice that these options can be combined so the designer can tune the design model. Following with our example, Figure 3 partly shows the Theme/UML model automatically generated from Figure 2. In this particular case, each architectural component is modelling a single concern and thus we chosen to transform

Table 1. Theme/UML Mapping Rules AO-ADL Element

Theme/UML Element

Rationale

Interface and Op- Interface and Operations. Basically a 1:1 translation process. A theme is generated erations Optionally, a theme can be for each of them depending on the selected mapping opgenerated from each of them. tion. Component (base or aspectual components, there is no distinction in AO-ADL)

- A set of themes for AO-ADL base components. - A set of parameterized themes for AO-ADL aspectual components. - Both themes and parameterized themes composed by means of a merge operator.

Connector

One single theme, containing This rule transforms a connector in the context of a partica set of UML components. ular architectural configuration, considering the AO-ADL components attached to the roles of AO-ADL connectors.

Configuration

A Theme/UML model.

In AO-ADL the same component can play a base or aspectual role depending on how it is attached to connectors. Theme/UML differentiates between two kinds of themes, distinguishing the representation of aspectual themes.

All the elements transformed by previous rules are part of the Theme/UML model, creating a UML representation of an AO-ADL software architecture.

Using AOSD and MDD to Enhance the Architectural Design Phase

365

Fig. 3. Architecture of the Auction System in Theme/UML

each AO-ADL component into a theme. Thus, according to table 1, a theme is generated for each component in the software architecture. Moreover, an additional transformation is performed for those components that play the role of aspectual components in AO-ADL, consisting on two steps: (1) the previously generated theme is transformed into a parameterized theme, and (2) a new theme is generated for each operation in the interface of the aspectual component. Those additional themes model the aspect advice. In our example, the Encryption component is an aspectual component connected to an aspectual role of the BuyerConnector connector with two advice: encrypt and decrypt. Thus, two new themes are created modelling the advice. According to the Theme/UML metamodel, these new themes are related to the Encryption theme by means of merge relationships. The union of these three themes represents the whole behaviour of the Encryption component. Notice that Figure 3.(a) is a simplification of the real transformation since more themes should appear modelling the advice of the rest of aspectual components in the software architecture. While, in AO-ADL, the aspectual information – i.e. pointcuts and aspectual bindings, is encapsulated as part of the connectors, in Theme/UML, pointcuts and aspectual bindings are specified by means of bind relationships between themes. In our example, the encrypt and decrypt themes interfere with the behaviour of BuyerConnector by means of two bind relationships, which specify the pointcuts where the aspectual theme affects to the behaviour of the base theme. In our example these points are the increase(), bid() and join() operations of the Buyer provided role shown in Figure 2.(a), as we can see in the binding attribute of the bind relationship (binding=”<Buyer.increase(), bid(), join()>” ). In addition to Figure 3.(a), Figure 3.(b) shows the internal design of the encrypt theme, in which an Encryption component is related with a generic component Component through the EncryptionService interface. Moreover, the sequence diagram in Figure 3.(c.1) shows the precise way in which the encrypt advice behaves in relation to the interfered method. Concretely, the encrypt() advice is executed when a method comes to Port before transmit it to the inside

366

M. Pinto et al. Table 2. UML 2.0 Mapping Rules

AO-ADL Element

UML 2.0 Element

Rationale

Interface/Operations

Interface and Operations.

Basically a 1:1 translation process.

Component

A UML 2.0 component.

Basically a 1:1 translation process.

Connector

- Base components related with the connector, connect themselves directly through the interfaces. - Aspectual components related with the connector, connect through the new crosscuts relationship.

All the aspectual information contained in the connector is translated to sequence diagrams where it is represented the aspectual interaction between the components connected to the connector.

Configuration

A UML 2.0 model.

All the elements transformed by previous rules are included in the new UML 2.0 model.

of the Component. The diagram shown in Figure 3.(b) is a template to be instantiated with the binding information of the bind relationship shown in Figure 3.(a). In our example, the Component would be instantiated to the BuyerConnector connector, the Port to the provided role Buyer and the method() is instantiated to the increase(), bid() and join() operations of the Buyer role. Notice that by means of these diagrams the Theme/UML model maintains all the aspectual information included in the AO-ADL architecture. 3.3

Transformation to UML 2.0

UML is the de facto standard language at the design stage. In this transformation the main goal is to generate a UML 2.0 design that contain all the relevant information expressed in AO-ADL, but without the requirement of learning an specific aspect-oriented design approach to be able to continue the software development process. In order to do that we have defined a mapping between the AO-ADL and the UML 2.0 metamodels. We have only introduced a new stereotype named crosscuts that allows us to make explicit that the source of the relationship was identified as an aspectual component at the architectural level, and the target was identified as a base component at the architectural level. Notice however, that the use of this stereotyped relationship is optional and can be omitted without changing the semantic of the model. This is possible because the information contained in an AO-ADL architecture is transformed into two kind of UML diagrams: statics and dynamics. As indicated in table 2, components in an AO-ADL configuration are always mapped to a single UML static diagram, a component diagram, where every AO-ADL component is transformed into a UML component. The information encapsulated in AO-ADL connectors is represented partly in component diagrams and partly in sequence diagrams. Thus, even if the crosscuts relationships are not specified in the component diagrams, the aspectual interactions between components encapsulated in the AO-ADL connectors are always transformed into a set of sequence diagrams. Notice that sequence diagrams have to be seen as the result of applying the weaving process between AO-ADL base and aspectual components, according to the aspectual binding information specified in AO-ADL connectors. Following with our example, the output model generated by the transformation from AO-ADL to UML 2.0 is shown in Figure 4. Figure 4.(a) shows a

Using AOSD and MDD to Enhance the Architectural Design Phase

367

Fig. 4. Architecture of the Auction System in UML 2.0

component diagram (the static diagram) where we can observe that the components that were joined by the BuyerConnector at the architectural level are now directly connected by means of the BuyerService interface. Meanwhile, the components that had an aspectual behaviour at the architecture level (Encryption, Consistency and Synchronization) interfere with this relation by means of the crosscuts relationship. All the aspectual information that was contained in the BuyerConnector is transformed into dynamic diagrams like the sequence diagram we can see in Figure 4.(b). This figure shows how the User GUI component invokes the join() method through its Buyer port and that before transmitting the message to the corresponding port of the Auction component the encrypt() method is invoked, just as it was specified in the BuyerConnector. 3.4

Comparison

The output of the transformation to Theme/UML is an aspect-oriented design. This means that both the separation between crosscutting and non-crosscutting concerns and all the aspectual information identified at the architectural level is preserved in the design model. The design in Theme/UML enhances the aspectual vision of the architecture, since what you see in the design is a group of themes (e.g. concerns) and the interactions among them. The aspectual information is also well delimit into: (a) the themes that represent aspectual behaviour, and (b) the bind relationships. Finally, the AO-ADL connectors are explicitly represented in the design by using themes. On the other hand, the result of the transformation to UML 2.0 weaves the aspectual information into the model, making easier to implement the model using a general purpose programming language. The configuration of the architecture (the components and their relationships) is clearly visible in the static part of the design, but the aspectual information is translated from the AO-ADL connectors into the dynamic sequence diagrams, so the separation disappears from the design model.

368

4

M. Pinto et al.

The AO-ADL Tool Suite

Our MDD process is supported by the AO-ADL Tool Suite2 , an Eclipse plugin that provides: (1) graphical support to describe and manipulate AO-ADL software architectures, covering the first step of our MDD process, and (2) integration of the architecture to design MDD transformations previously described, covering the second step of our MDD process. Finally, the designs generated with ATL do not contain graphical information, basically because this information is specific of each particular UML editor. Thus, our tool prepares the output of ATL transformations in order to automatically generate graphical information required to visualize the design in MagicDraw UML. This makes easier to continue the design of the system using an existing UML editor.

5

Related Work

AOSD and MDD can be considered complementary technologies. the main motivation for applying AOSD to MDD is to solve the problem that MDD presents regarding the lack of specific mechanisms for the separation of crosscutting concerns within each level of abstraction [13]. If all concerns can be modeled separately at a certain level, that level will become more manageable, extensible and maintainable. Most approaches combining MDD and AOSD follow this approach [13,14] where their main goal is to obtain “separation of aspects” in each MDA level. An alternative approach, closer to ours, consists of applying the MDD philosophy to the development of AO applications, by proposing MDD generation processes to transform AO models at different phases of the software life cycle. An example of this approach is our work in [15], in which MDA helped us to identify that there were different models in our aspect-component proposal [16]. Other examples are [17,18] that use MDD to transform AO requirement specifications into AO software architectures using a CAM profile and PRISMA respectively. The proposal in [11] transforms an Theme/UML AO detailed design into an AspectJ implementation. Our approach in this paper complements this approach in the sense that we use MDD to transform AO software architectures into Theme/UML AO detailed design. Finally, another example is the AOMDF (AO Model Driven Framework) proposal [19]. AOMDF combines both approaches, proposing an MDD framework that provides mechanisms supporting both vertical and horizontal separation of concerns.

6

Conclusions and Future Work

In this paper we have shown how the use of MDD can be used to bridge the gap between between AO architecture and (AO) detailed design. We have completely implemented the model-to-model transformations using ATL, integrating them into the AO-ADL tool suite. The complete mapping information and the main ATL rules are available in the AO-ADL web site. They have not been included in 2

Downloadable from our website (http://caosd.lcc.uma.es/aoadl/download.htm).

Using AOSD and MDD to Enhance the Architectural Design Phase

369

the paper due to the lack of space. Interested readers can download the running example used in the paper, as well as other examples, from our web page, in order to use our tool to reproduce the MDD process presented in the paper. One current limitation of our approach is that pointcuts in UML do not capture all the expressiveness of AO-ADL pointcuts. In order to preserve the expressiveness of AO-ADL pointcuts at design, our next step is the definition of new transformations to the Join Point Designation Diagrams (JPDDs), which allow the specification of contextual static and dynamic join point selection criteria.

References 1. Garlan, D., et al.: ACME: An architecture description interchange language. In: Johnson, J.H. (ed.) Proc. of CASCON, Toronto, Ontario, pp. 169–183. IBM Press (1997) 2. Luckham, D.C., et al.: Specification and analysis of system architecture using Rapide. IEEE Transactions on Software Engineering 21(4), 336–355 (1995) 3. Medvidovic, N., et al.: Using object-oriented typing to support architectural design in the C2 style. In: Gollmann, D. (ed.) FSE 1996. LNCS, vol. 1039, pp. 24–32. Springer, Heidelberg (1996) 4. Dashofy, E.M., et al.: A highly-extensible, xml-based architecture description language. In: Proc. of WICSA, Amsterdam, The Netherlands, pp. 103–112 (2001) 5. P´erez, J., et al.: PRISMA:Towards Quality, Aspect-Oriented and Dynamic Software Architectures. In: QSIC 2003, pp. 59–66 (2003) 6. Pinto, M., Fuentes, L.: AO-ADL: An ADL for Describing Aspect-Oriented Architectures. In: Moreira, A., Grundy, J. (eds.) Early Aspects Workshop 2007 and EACSL 2007. LNCS, vol. 4765, pp. 94–114. Springer, Heidelberg (2007) 7. Beydeda, S., et al.: Model-driven development. Springer, Heidelberg (2005) 8. K¨ uhne, T.: Matters of (meta-)modeling. Software and Systems Modeling (SoSyM) 5(4), 369–385 (2006) 9. Jouault, F., Kurtev, I.: Transforming Models with ATL. In: Bruel, J.-M. (ed.) MoDELS 2005. LNCS, vol. 3844, pp. 128–138. Springer, Heidelberg (2006) 10. Clarke, S., et al.: Aspect Oriented Analysis and Design. The Theme Approach. Aw Professional (2005) 11. Jackson, A., et al.: Mapping design to implementation. Technical Report AOSDEurope Deliverable D111 12. Chitchyan, R., et al.: Mapping and refinement of requirements level aspects. Technical Report AOSD-Europe Deliverable D63 13. Amaya, P., et al.: MDA and separation of aspects: An approach based on multiple views and subject oriented design. In: AOM Workshop (2005) 14. Atkinson, C., et al.: Aspect-oriented development with stratified frameworks. IEEE Software 20(1), 81–89 (2003) 15. Fuentes, L., et al.: How MDA can help designing component- and aspect-based applications. In: Proc. of EDOC, pp. 124–135 (2003) 16. Pinto, M., Fuentes, L., Troya, J.M.: A Dynamic Component and Aspect-Oriented Platform. The Computer Journal 48(4), 401–420 (2005) 17. S´ anchez, P., Magno, J., Fuentes, L., Moreira, A., Ara´ ujo, J.: Towards MDD transformations from AO requirements into AO architecture. In: Gruhn, V., Oquendo, F. (eds.) EWSA 2006. LNCS, vol. 4344, pp. 159–174. Springer, Heidelberg (2006) 18. Navarro, E.: ATRIUM: Architecture traced from requirements applying a unified methodology, Ph.D thesis (2007) 19. Simmonds, D., et al.: An Aspect Oriented model driven framework. In: EDOC 2005, pp. 119–130 (2005)

A Model Transformation Approach to Derive Architectural Models from Goal-Oriented Requirements Models Marcia Lucena1,2, Jaelson Castro1, Carla Silva3, Fernanda Alencar1, Emanuel Santos1, and João Pimentel1 1

Federal University of Pernambuco (UFPE) – Recife/PE, Brazil [email protected] 2 Federal University of Rio Grande do Norte (UFRN) – Natal/RN, Brazil 3 Federal University of Paraíba (UFPB) – Rio Tinto/PB, Brazil {mjnrl,jbc,ebs}@cin.ufpe.br, [email protected], [email protected]

Abstract. Requirements engineering and architectural design are key activities for successful development of software systems. Both activities are strongly intertwined and interrelated, but many steps toward generating architecture models from requirements models are driven by intuition and architectural knowledge. Thus, systematic approaches that integrate requirements engineering and architectural design activities are needed. This paper presents an approach based on model transformations to generate architectural models from requirements models. The source and target languages are respectively the i* modeling language and Acme architectural description language (ADL). A real web-based recommendation system is used as case study to illustrate our approach. Keywords: Requirements Transformation.

engineering,

Architectural

design,

Models

1 Introduction The Requirements Engineering (RE) [12] and Software Architecture (SA) [8] are initial activities of software systems development that have been emerging both in research as in practice. Currently, software systems present characteristics such as increased size, complexity, diversity and longevity. Thus, their development must consider proper requirements elicitation and modeling approaches, as well as use systematic architectural design methods. A great challenge is the development of systematic methods for building architectural design that satisfies the requirements specification. Some efforts have been made to understand the interaction between RE and SA activities [3], [1]. Therefore, many approaches claim that there is a semantic gap between these two activities. However, with the widely use of iterative and incremental software development process as the de facto standard, a strong integration between requirements and architectural design activities can facilitate traceability and the propagations of changes between these models efficiently [15]. In this context, we can highlight the twin peaks model [14], which emphasizes the co-development of requirements and architectures, incrementally elaborating details. R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 370–380, 2009. © Springer-Verlag Berlin Heidelberg 2009

A Model Transformation Approach to Derive Architectural Models

371

Recognizing the close relation between architectural design and requirements specification [5], the Model-driven Development (MDD) [11] appears as an effective way to generate architectural models from requirements models by using model transformations rules, in which the correlation between requirements and architectural models can be specified accurately. Thus, in this paper, we show an approach to generate architectural models from requirements model that includes horizontal and vertical transformations rules. The horizontal transformations are applied to requirements models and results in other requirements models closer to architectural model. While the vertical transformations map these resulting requirement models in architectural models. The main contribution is on the vertical transformation rules that complement the horizontal transformation rules presented in [13]. In our approach, architectural models are described using Acme ADL [6], which provides a simple structural framework for representing architectures, whereas requirements models are described using the modeling language offered by the i* [18], a goal-oriented approach to describe both the system and its environment in terms of strategic actors and social dependencies among them. This paper is organized as follows. Section 2 introduces our case study and overviews the main concepts of the i* and Acme languages. Section 3 presents our approach based on model transformation rules. Section 4 describes related works. Finally, Section 5 summarizes our work and points out open issues.

2 Background This section presents our case study and briefly reviews the requirements modeling and architectural description languages used in our approach.

Fig. 1. Partial BTW Strategic Rationale Model

2.1 BTW Project The BTW-UFPE project [2], presented in the SCORE contest held at ICSE 2009 [16], is used to illustrate our approach. BTW consists in a route-planning system that helps users through the recommendation of advices about a specific route searched by the

372

M. Lucena et al.

user. This information is posted by other users and might be filtered to provide the user only with relevant information about the place that he/she intends to visit. The BTW-UFPE team generated artifacts that include i* requirement models. We chose this project by two reasons: it is a real case study that resulted in a software system; and the produced i* models are not large but have enough complexity to illustrate the benefits of our approach. Fig. 1 shows a partial SR model for BTW. Its complete models can be found in [2]. 2.2 The Source: i* Requirements Goal Model i* defines models to describe both the system and its environment in terms of intentional dependencies among strategic actors [18].There are two different models: the Strategic Dependency (SD) describes information about dependencies and the Strategic Rationale (SR) describes details about each actor. The SR model complements the information provided by the SD model by adding internal details for each strategic actor to describe how the dependencies are accomplished. In i* models, a depending actor is called a depender, and an actor that is depended upon is a dependee. Fig. 1 presents dependencies between Advice Giver and BTW actors. Considering the Advice be Published goal dependency, the BTW actor is the depender actor whereas the Advice Giver actor is the dependee actor of this dependency. BTW represents the software system to be developed. Thus, an actor can depend upon another one to achieve a goal, execute a task, provide a resource or satisfy a softgoal. Softgoals are associated to non-functional requirements, while goals, tasks and resources are associated to system functionalities [19]. Actor’s internal details also include tasks, goals, resources and softgoals, which are further refined using task-decomposition, means-end and contribution links. The task-decomposition links describe what should be done to perform a certain task (e.g., the relationship between the Filter Advices for a route task and the Access Maps database task). The means-end links suggest that one intentional element can be offered as a means to achieve another intentional element (e.g., relationship between the Select Advice by User History task and the Relevant Advice be chose goal). Finally, the contributions links suggest how a task can contribute (positively or negatively) to satisfy a softgoal (e.g., the relationship between the Write information about a point task and the Precise Advices softgoal). In this paper, we are concerned with how to manage the internal complexity of the software actor (BTW) and how to produce architectural models from it. 2.3 The Target: ACME Architecture Models A set of elements are important when describing instances of architectural designs. According to [17], these elements include Components, Connectors, Interfaces, Configurations and Rationale. Acme ADL [6] supports each of these concepts but also adds ports, roles, properties, and representations. Besides, Acme has a textual and a graphical language. Acme Components represent computational units of a system. Connectors represent and mediate interactions between components. Ports correspond to external interfaces of components. Roles represent external interfaces of connectors. Ports and roles (interface) are points of interaction, respectively, between components and connectors. Systems (Configurations) are collections of components,

A Model Transformation Approach to Derive Architectural Models

373

connectors and a description of the topology of the components and connectors. Systems are captured via graphs whose nodes represent components and connector and whose edges represent their interconnectivity. Properties are annotations that save additional information about elements (components, connectors, ports, roles, and systems). Representations allow a component, connector, port, and role to describe its design in detail by specifying a sub-architecture that refines the parent element. Properties and representations could be associated to the rationale of the architecture, i.e., information that explains why particular architectural decisions were made, and for what purpose various elements serve [17]. Architectural design is not a trivial task, even using specific concepts to describe architecture. It depends on the expertise of the architects and on how they understand the requirements. To make this task more systematic, we propose a MDD approach to derivate an early architectural design from requirements models.

3 Architectural Design by Using Model Transformations To generate Acme architectural models from i* models, we propose a process composed of three major activities: (i) analysis of internal elements, (ii) application of horizontal rules and (iii) application of vertical rules. This process recognizes that i* models are intrinsically complex and this complexity need to be managed. The first two activities are concerned to this while the last activity is concerned with the development of architectural design. To perform these activities, it is required to use, respectively: (i) conditions to guide the software actor’s decomposition, (ii) model transformation rules to generate modular i* models, and (iii) model transformation rules to generate Acme architectural models. This process is semi-automatic, since interventions of the requirements engineer are likely to be necessary to take some decisions. The activity (i), in particular, uses some conditions to assist the requirements engineer to choose elements that can be moved to another software actor to balance the responsibilities of an actor. The other activities can be developed with few interventions. In this paper, we concentrate on the activity (iii), as the activities (i) and (ii) have already been presented in [13]. We only present them briefly in the Section 3.1 and 3.2, respectively. 3.1 Analysis of Internal Elements The decomposition criterion is based on the separation and modularization of elements that are not strongly related to the application domain. For example, in the BTW SR model (Fig 1), which captures the web recommendation system requirements [2], we can identify those elements that are not fully related to the application domain (recommendation). At this point, a requirements engineer must perform the analysis. Some sub-graphs internal to the BTW actor are considered independent from the recommendation application domain and, therefore, can be moved to new software actors. Thus, sorting out the independent elements into other actors can improve reusability and maintainability of system specification at the requirements level. In fact, considering the BTW SR model, the following elements could be used as part of

374

M. Lucena et al.

a system of a different application domain: Map to be Handled, User Access and Information to be published. 3.2 Application of Transformation Rules In this activity, an appropriate horizontal transformation rule must be applied. The rule to be applied depends on the type of relationship between the elements to be moved and the elements that will remain in the original system actor. The general purpose of the horizontal rules is to delegate internal elements from the system actor to other actors [13]. This delegation establishes a dependence relationship between the new actors and the original actor, maintaining the semantics of the original model in the resulting model. These horizontal rules will be briefly presented in this section (for more details see [13]).

Fig. 2. Modular SR i* model

HTR1 is a transformation rule that moves a sub-element present in a taskdecomposition to another actor. HTR2 considers the situation where the sub-graph to be moved has the root element as a “means” in a means-end relationship. After applying rules HTR1 and HTR2, the resulting model may not be in conformity with the i* notation. In this case, we need to use a corrective rule, such as HTR3. This rule was defined to preserve the information about contribution links and maintain the information about contribution links and coherence of i* models as it is proposed in [9]. And HTR4 is applied when the sub-graph to be moved out has a sub-element shared with other sub-graphs. After applying the horizontal rules to the selected elements in Analysis activity, three new actors are created related to sub-graphs of Map be Handled, User Access be Controlled and Information be published in Map goals (Fig. 2). As these new actors receive the name of their elements (goal or task), we suggest to use a specific noun related to the domain of these elements. Thus, we have respectively Mapping Handler, User Access Controller, and Map Information Publisher. In this activity, the main rules used were HTR3 and HTR4. As the horizontal rules are applied, the i* model is transformed into an i* model closer to an early architectural design. This modularized i* model is an entry to the activity of vertical rules application. All new created actors, the main software actor

A Model Transformation Approach to Derive Architectural Models

375

and their dependencies among each other will be used in the vertical transformation rules. Next section presents the rationale behind the vertical transformation rules to produce Acme architectural models from i* requirements models. 3.3 Generating Architectural Models The models associated with different activities of the software development process are created using specific model description language. Therefore, how models will be generated from a stage to another depend on how the transformation rules are defined considering the main elements of each involved modeling language. We start to establish the vertical transformation rules considering only actors and dependencies to map i* elements to Acme elements, as it is presented in [4]. Fig. 3 shows a generic mapping without considering the type of dependency between actors and dependencies, in i*, to components and connectors in Acme graphical and textual language.

I* Model

Acme Model

1 System ClientServer = { 2 Component DependerActor = { 3 Port port1 = { 4 Property Required : boolean = true; } } 5 Component DependeeActor = { 6 Port port2 = { 7 Property Provided : boolean = true; } } 8 Connector ConnDependency = { 9 Role depender = { } 10 Role dependee = { } } 11 Attachment DependerActor.port1 to connDependency.depender; 12 Attachment DependeeActor.port2 to ConnDependency.dependee;}

Fig. 3. Mapping a generic dependency between i* actors to ACME

A component in software architecture is a unit of computation or a data store having a set of interaction points (ports) to interact with external world [17]. An actor in i* is an active entity that carries out actions to achieve goals by exercising its knowhow [18]. The actor representing the software establishes a correspondence with modules or components [7]. In addition, an actor may have as many interactions points as needed. Hence, an actor in i* can be represented in terms of a component in Acme (Fig. 3). Connectors are architectural building blocks that regulate interactions among components [17]. In Acme, connectors mediate the communication and coordination activities among components. In i*, a dependency describes an agreement between two actors playing the roles of depender and dependee, respectively [4]. Thus, we can represent a dependency as an Acme connector. Interfaces are points of access among components and connectors. However there are not ports in i*, but points where dependencies interact with actors. Depending on role of dependency (depender or dependee) we can know when an actor is a depender or a depended upon actor. Hence, the roles of depender and dependee are mapped to connector roles that are comprised by the connector (Fig. 3). Thus, we can distinguish between required ports (where the

376

M. Lucena et al.

actor is a depender) and provided ports (where actor is a dependee). For instance, Fig. 3 shows the use of property Required (line 4) and property Provided (line 7) indicating the direction of communication between the DependerActor and DependeeActor components. Therefore, in i* a depender actor depends on a dependee actor to accomplish a type of dependency. In Acme, a component needs that another component carries out a service and the requisition of this service is done by a required port, while the result of this service is done by a provided port, thus, a connector allows the communication between these ports. A component offers services to another component using provided ports and a component require services using its required port. Applying this mapping in BTW project (Fig. 2) we will have four components: BTW, Mapping Handler, User Access Controler, and Information map Publisher. Each dependency is mapped to a connector and the roles of their connectors will be depender and dependee according the direction of dependency. For instance, when an actor has at least one dependency as a dependee, its equivalent component will have at least one provided port (Fig. 3). Therefore, the Mapping Handler component will have a provided port considering the Placemark resource dependency. Having all components, ports, connectors and roles mapped and defined, the next step is analyze each type of dependency.

i* Model 5 6 7 8

Acme Model

Component DependeeActor = { Port port2 = { Property Provided : boolean = true; Property goal: boolean; } }

Fig. 4. Mapping a goal dependency to ACME

In i*, the type of dependency between two actors describes the nature of the agreement established between these actors. There are four types of dependency: goals, softgoals, tasks and resources. Each type of dependency will define different architectural elements in connectors and in ports that play their interfaces. A goal dependency is mapped to a Boolean propriety related to a provided port of the component that offers this port (Fig. 4, line 8). This property represents a goal that this component is responsible to fulfill by using a provided port. The type of property is Boolean in order to represent the goal satisfaction (true) or no satisfaction (false). Applying this goal dependency mapping in BTW case study implies that BTW and Information Publisher components will add new Boolean properties in respectively provided ports. A task dependency represent that an actor depends on another to execute a task [18] and that a task describes or involves processing [7]. Since port in Acme port correspond to external interfaces of components and offer services, as it was said before. Hence, a task dependency is mapped directly to a provided port of component that offers this port (Fig. 5, line 6). In our BTW example we do not have task dependencies related to software actors (Fig. 2).

A Model Transformation Approach to Derive Architectural Models

Acme Model

i* Model 5 6 7

Component DependeeActor = { Port Task = { Property Provided : boolean = true;

377

}

}

Fig. 5. Mapping a task dependency to Acme

In a resource dependency, an actor depends on another actor to provide information. Therefore, a resource dependency is mapped to a return type of a property of a provided port (Fig. 6, line 8). This return type represents the type of the resulting product that an operation related to some service that the component is responsible to perform. This mapping is to show that while a task is generate by an actor in a component, it is generated by an element inside of port. In Fig. 2, there is one case of resource dependency that is placemark resource dependency. Thus, the provided port of Mapping Handler component receives a property with a method that generates this resource.

Acme Model

i* Model 4 Property Type Resource; 5 Component DependeeActor = { 6 Port port2 = { 7 Property Provided : boolean = true; 8 Property getResource : Resource; }

}

Fig. 6. Mapping a resource dependency to Acme

A softgoal dependency is similar to goal dependency but its fulfillment cannot be defined precisely. A softgoal is related to a non-functional requirement that will be treated by a task or a softgoal more specific. Hence, a softgoal dependency is mapped to a property with enumerated type present into the port that plays the dependee role of the connector (Fig. 7, line 9). This enumerated type is used to describe the degree of satisfaction of the softgoal. For the BTW example, the Publisher component has a provided port that interface with Precise Advices connector by the dependee role. This provided port will have a property softgoal defined as enumeration type. The same mapping is done with the security dependency between BTW and Access User Controller component. Acme graphical language uses labels to highlight added elements used in textual part. However, using AcmeStudio tool, information of types of dependency only is presented in textual language. Each mapping presented will be formalized by vertical transformation rules following the same structure of horizontal transformation rules [13].

378

M. Lucena et al.

i* Model 4 5 6 7 8 9

Acme Model

Property Type SoftgoalType = enum {make,somePos,help,unkown,break,someNeg,hurt}; Component DependeeActor = { Port port2 = { Property Provided : boolean = true; Property softgoal: SoftgoalType; } }

Fig. 7. Mapping a softgoal dependency to Acme

4 Related Work We highlight two goal-oriented approaches [20][21] and a MDD approach [15]. The SIRA approach [20] focuses on a systematic way to assist the transition from requirements to architecture. It describes a software system from the perspective of an organization in the context of the Tropos methodology. The requirements and architectural models are described in i*. An organizational architectural style is chosen based on the non-functional requirements. Thus, an architectural model is created considering similarities of elements of requirements and organizational style. In our proposal, we also use i* goal model as input model, but we modularize these models to reach an architectural configuration. Moreover, we also present a systematic way to treat non-functional requirements and we use a target model based on a generic architectural language (Acme). In [20] it is not clear how the architectural model is structured. Lamsweerde [21] defines a method to generate architectural models from KAOS requirements models. In this approach, specifications are gradually refined to meet specific architectural constraints of the domain and an abstract architectural draft is generated from functional specifications. The resulting architecture is recursively refined to meet the various non-functional goals analyzed during the requirements activities. It is used KAOS models, which consist of a graphical tree and a formal language. In our approach, we use another goal model as input model, the i* models. The relation between i* notation and software architecture facilitate the mapping between these models, while this is not occur in KAOS models. In contrast, that approach provides guidelines to refine an initial architecture applying architectural styles and patterns, while in our approach we provide a preliminary architecture. In [15] is proposed a set of mapping rules between the AspectualOV-graph (AOVgraph) and the AspectualACME, an architecture description language. Each element (goal/softgoal/task) present in an AOV-graph is mapped to an element of AspectualACME, depending on the position that each element is in the graph hierarchy. The information about the source of each element is registered in the properties of a component or a port. These properties make it possible to keep traceability and change propagation between AspectualACME to AOV-graph models and vice-versa. We also propose a set of mapping rules between a goals model i*, but considers the nonaspectual version of ACME ADL.

A Model Transformation Approach to Derive Architectural Models

379

5 Conclusions and Future Works Our approach generates an initial architectural model described in Acme, from i* requirements models. To achieve this, it was necessary to balance the responsibilities of a system actor, delegating them to other new system actors. A set of horizontal rules proposed in [13] were used to generate modular i*models which are closer to architectural design. From the modular i* model we derive an Acme model through a set of mappings between the concepts of both languages. These mappings were based on [4] which the purpose was to map i* architectural models to architectural models described using UML-RT, since i* was not conceived to be an ADL. Besides, UMLRT is a language specific to Object Orientation paradigm. The difference from this work to ours is that we are concerned in creating an architectural design from a requirement specification and not just mapping between languages for architectural description. Since our mapping relates requirements and architectural models, allowing better traceability and propagation change. Furthermore, using a more general architectural language led us to propose more generic mapping rules, which in turn can serve as a guide to derive architectural models in other ADLs. We assessed our approach using a web recommendation system (BTW) that is a real system developed for a Software Engineering contest at ICSE 2009 [2]. An issue that needs to be further explored is the systemic nature of some NFRs. Currently we are also defining formally our transformation rules (horizontal and vertical) using Alloy language to ensure that the resulting models will be well formed. The use of Alloy will enable us to define the transformation rules and verify their soundness. However, in order to implement our proposal we rely on a specific model transformation language, namely ATL. Other future work includes automating this approach through the implementation of our transformation rules in the Istar Tool [10], a tool based on MDD and Eclipse Platform. This will allow us to investigate the scalability of our approach in some real life complex projects.

References 1. Berry, D.M., Kazman, R., Wieringa, R.: 2nd Intl Ws on From SofTware Requirements to Architectures (STRAW 2003) at ICSE 2003, Portland, USA (2003) 2. Borba, C., Pimentel, J., Xavier, L.: BTW: if you go, my advice to you Project (July 2009), https://jaqueira.cin.ufpe.br/jhcp/docs/ 3. Castro, J., Kramer, J.: 1st Intl. Workshop on From SofTware Requirements to Architectures (STRAW 2001) at ICSE 2001, Toronto, Canada (2001) 4. Castro, J., Silva, C., Mylopoulos, J.: Modeling Organizational Architectural Styles in UML. In: Eder, J., Missikoff, M. (eds.) CAiSE 2003. LNCS, vol. 2681, pp. 111–126. Springer, Heidelberg (2003) 5. Deboer, R., Vanvliet, H.: On the similarity between requirements and architecture. Journal of Systems and Software (2008) 6. Garlan, D., Monroe, R., Wile, D.: ACME: An Architecture Description Interchange Language. In: Proc. of the CASCON 1997 (1997)

380

M. Lucena et al.

7. Grau, G., Franch, X.: On the Adequacy of i* Models for Representing and Analyzing Software Architectures. In: Hainaut, J.-L., Rundensteiner, E.A., Kirchberg, M., Bertolotto, M., Brochhausen, M., Chen, Y.-P.P., Cherfi, S.S.-S., Doerr, M., Han, H., Hartmann, S., Parsons, J., Poels, G., Rolland, C., Trujillo, J., Yu, E., Zimányie, E. (eds.) ER Workshops 2007. LNCS, vol. 4802, pp. 296–305. Springer, Heidelberg (2007) 8. Hofmeister, C., Nord, R., Soni, D.: Applied Software Architecture. Addison-Wesley, Reading (2000) 9. Horkoff, J.: Using i* modeling for evaluation, Master’s Thesis, University of Toronto, Department of Computer Science (2007) 10. IStarTool Project: A Model Driven Tool for Modeling i* models (July 2009), http://portal.cin.ufpe.br/ler/Projects/IstarTool.aspx 11. Kleppe, A., Warmer, J., Bast, W.: MDA Explained - The Model Driven Architecture: Practice and Promise. Addison-Wesley, Reading (2003) 12. Kotonya, G., Sommerville, I.: Requirements Engineering: Processes and Techniques. Wiley, John & Sons Inc. (1998) 13. Lucena, M., Silva, C., Santos, E., Alencar, F., Castro, J.: Applying Transformation Rules to Improve i* Models. In: SEKE 2009, USA, pp. 43–48 (2009) 14. Nuseibeh, B.: Weaving Together Requirements and Architectures. IEEE Computer 34(3), 115–117 (2001) 15. Silva, L., Batista, T., Garcia, A., Medeiros, A., Minora, L.: On the Symbiosis of AspectOriented Requirements and Architectural Descriptions. In: Moreira, A., Grundy, J. (eds.) Early Aspects Workshop 2007 and EACSL 2007. LNCS, vol. 4765, pp. 75–93. Springer, Heidelberg (2007) 16. The SCORE 2009 (July 2009), http://score.elet.polimi.it/index.html 17. Taylor, R.N., Medvidovi, N., Dashofy, I.E.: Software Architecture: Foundations, Theory, and Practice. John Wiley & Sons, Chichester (2009) 18. Yu, E.: Modeling Strategic Relationships for Process Reengineering. Ph.D. thesis. Department of Computer Science, University of Toronto, Canada (1995) 19. Yu, E., et al.: i-star Tutorial in RE 2008, Spain, pp. 1–60. IEEE Computer Society, Los Alamitos (2008) 20. Bastos, L., Castro, J.: From requirements to multi-agent architecture using organisa-tional concepts. ACM SIGSOFT Software Engineering Notes 30(4), 1–7 (2005) 21. Van Lamsweerde, A.: From System Goals to Software Architecture. In: Bernardo, M., Inverardi, P. (eds.) SFM 2003. LNCS, vol. 2804, pp. 25–43. Springer, Heidelberg (2003)

Applying Formal Verification Techniques to Ambient Assisted Living Systems Kawtar Benghazi, Mar´ıa Visitaci´on Hurtado, Mar´ıa Luisa Rodr´ıguez, and Manuel Noguera Software Engineering Department, University of Granada, Spain {benghazi,mhurtado,mlra,mnoguera}@ugr.es http://lsi.ugr.es

Abstract. This paper presents a verification approach based on timed traces semantics and MEDISTAM-RT [1] to check the fulfillment of non-functional requirements, such as timeliness and safety, and assure the correct functioning of the Ambient Assisted Living (AAL) systems. We validate this approach by its application to an Emergency Assistance System for monitoring people suffering from cardiac alteration with syncope. Key words: Ambient assisted living, safety, timeliness.

1

Introduction

Advances in networking, sensors and embedded devices have made it feasible to monitor and provide medical and other assistance to people at home. The general goal of Ambient Assisted Living (AAL) solutions is to apply ambient intelligence technology to enable people with specific demands, e.g. handicapped or elderly, to live in their preferred environment. In order to achieve this goal, different kinds of AAL systems can be proposed and most of them pose reliability issues and describe important constraints upon the development of software systems [13]. In this regard, the specification and verification of non-functional requirements in the early stages of their development cycle is crucial issue [5]. In [7] non-functional requirements for these systems such as robustness, availability, extensibility, safety, security, timeliness, resource efficiency are summarizes. In this paper we focus on safety and timeliness properties. Additionally, AAL systems require clear and precise specifications in order to describe the system behavior and its environment. The formal specification of the system behavior supported by mathematical analysis and reasoning techniques improve the development process and enable the verification of these systems. The main purpose of this paper is to present a verification approach based on MEDISTAM-RT and timed traces to assure the correct functioning of AAL systems and show the applicability of this methodology in the context of this kind of systems. In the area of specifying and verifying security properties, tracebased formalism have been adopted [4] [6]. R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 381–390, 2009. c Springer-Verlag Berlin Heidelberg 2009 

382

K. Benghazi et al.

Other proposals that use formal methods in AAL systems have been developed. Formal description techniques and particularly the ICO (Interactive Cooperative Objects) notation, based on Petri nets, support usability evaluation, contextual help and incident and accident investigation in health care systems is presented in [9]. In [10], an advanced counseling system in health care is generated out by a formal specification (a process calculus for specifications in space and time). However, verification of non-functional properties such us safety and timeliness have not been considered. The paper is organized as follows: in the next section we present our approach to formalization of non-functional requirements and formal systems verification. In section 3, a case study highlighting the applicability of the proposed technique is showed. Finally, section 4 concludes the paper with a discussion of the contributions of our approach.

2

Systems Specification and Verification

In this section we explain how we carry out the specification and verification of critical systems starting by modeling the system using a semiformal notation based on UML-RT. The behavior of each one of the components of a critical system architecture has strong requirements that should always be satisfied. The formal specification of this behavior and the requirements these components should fulfill allows to verify that the components work as expected. In our approach, we use CSP+T to specify the behavior of each system component and timed traces to describe the requirements the component must satisfy and to specify the valid sequences of messages that the components interchange through its ports. Notation: – A timed trace s = (s1 , t1 ), (s2 , t2 ) . . . (sn , tn ), represents a sequence of timed events (si , ti ) than can be observed during the execution of a system. – s ↑ [t1 , t2 ], represents the projection of the timed traces s on an interval of time [t1 , t2 ]. – σ(s), represents the elements of a trace s. – t : event  → R+ is the function that maps events to its time occurrence. 2.1

Formalization of Non-functional Requirement

The properties to be satisfied by a system or a process are defined in terms of timed traces. This definition characterizes some traces as acceptable and some as non-acceptable. A process complies with its specification if all its executions are acceptable, that is, none of its executions by the system violates its specification. Likewise, if S(tr) is a predicate in the timed trace tr, then it is said that P satisf ies or complies with S(tr) if S(tr) holds for any timed trace tr ∈ FT T (P ). P sat S(tr) ⇔ ∀tr ∈ FT T (P ); S(tr)

Applying Formal Verification Techniques to AAL Systems

383

For example, when smoke is detected in a room (in a time ts ), a firefighting system must check if the door is closed to try to avoid the spreading of the fire, but only when the room is empty. Otherwise, if there are people inside the room, the system should allow people to exit first. We can formalize this situation by means of a property that the system must comply in order to avoid risks: ∀tr ∈ FT T (P ) S(tr) = if (closed, tc ) ∈ σ(tr) ⇒ (empty, te ) ∈ σ(tr ↑ [ts , tc ])

The process Q = smoke  ts → empty  te → closed  tc → Q is defined by the set of timed traces FTT (Q) ={ , (smoke, ts ) , (smoke, ts )  (empty, te ) , (smoke, ts ) (empty, te ) (closed, tc ) }

and for all tr ∈ FT T (Q) the property S(tr) is satisfied, that is: Q sat if (closed, tc ) ∈ σ(tr) ⇒ (empty, te ) ∈ σ(tr ↑ [ts , tc ])

The specification of a system in the timed trace model or in the general trace model, allows safety properties and conditions to be defined. These properties require that “nothing bad happens” [11]. In our context, something bad is modeled by means of timed traces which do not satisfy S(tr). Thus, the specification of safety properties can be modeled by forbidding the occurrence of a timed trace s during the execution of a process P , or by forbidding the occurrence of an event in a period of time ∀tr ∈ FT T (P ). S(tr) = s not in tr 2.2

Formal System Specification Using MEDISTAM-RT

MEDISTAM-RT [2] [1] provides a methodological framework to the formal specification of real–time systems by combining semiformal languages based on UML-RT [8] and formal language based on process algebra[12] (see Fig. 1). This combination is based on the strategy of integration by derivation [3], which consists in firstly designing the semi-formal models (UML-RT models) and then obtaining (by applying a set of transformation rules, described in [2]) their equivalents in the formal language CSP+T . In this methodology, the system is designed in a stepwise refinement manner, where the components are divided hierarchically into subcomponents until obtaining basic components1 . The behavior of these basic components are separately designed by a Timed State Diagram (TSD), and the behavior of the composite ones are deduced from the behavior of its constituents by following a compositional specification process based on CSP+T [12].

1

Indecomposable components, i.e. those that not contains any subcomponents.

384

K. Benghazi et al.

To p

Up

System Context Diagram

P

Decomposition

Composition

Composite Capsules Composite Structure Diagram

P1

Protocols Behaviour Timed Sequence Diagrams

Composition

…

Pj

…

Composition

Pn

Composition

Transformation

Down

Basic Capsules Timed State Diagram

Modeling Process

P10 … P1k … Pj0 … Pjk’ … Pn0 … Pnk’

Transformation rules

Bottom

Formal Specification Process

Fig. 1. Methodological framework MEDISTAM–RT

2.3

System Verification

The protocols determines the pattern of interchange of messages between the involved ports, which belong to different components. Actually, a timed sequence diagram (TSeD) representing the behavior of a given protocol gives a general view of the interaction between components. Hence, the protocol TSeD specify the valid sequences and time restrictions of the messages interchange between a component and its environment In this way, a component is correct if the temporal constraints and message order in the TSeD of the protocol is maintained in the component behaviour. As it is shown in figure 2, our verification approach take place in two stages: 1. Verify that the valid sequences obtained by transforming the timed sequence diagram into timed traces satisfies the component requirements2 .

Natural language Requirements Timed traces Timing and safety Requirement

UML-RT

?

Protocols Behavior Components Behavior

Satisfaction

Valid Sequences CSP+T Specification

Potential Behavior

? Refinement

Fig. 2. Verification approach

2. The potential behavior of the system obtained by transforming the timed state diagram into CSP+T (using the set of rules presented in previous work [1]) and 2

Described by timed traces as well.

Applying Formal Verification Techniques to AAL Systems

385

then into timed traces (applying the semantic function FT T : CSP +T process → timed traces defined in [1]) refine the valid sequences for the system. 

3

Case Study

As a case study we have modeled an Emergency Assistance System for monitoring people suffering from cardiac alteration with syncope. In this case, biomedical sensors that are usually embedded into textiles are used. These sensors are equipped with data storage capabilities and wireless transceiver systems. The data are sent to a Home Care System (HCS) where they are analyzed. In case of anomaly, and considering context information (e.g., patient’s medical record), the HCS will determine the degree of seriousness of the situation and will act accordingly, namely: 1. Make a warning call to the patient. 2. Call a health center and monitor ambient conditions of the room or house (i.e., air temperature). 3. Call the Emergency Medical Service and monitor ambient conditions of the room or house. Home is equipped with a series of sensors and actuators (i.e., temperature sensors and an air conditioner controller). Patients may communicate, by means of a PDA, that they are carrying out certain activities which may influence in their cardiac variations (e.g., because he/she is doing exercises) and are part of the context information. Although the one described it is not a hard real-time system, some of their actuations must be carried out within a window of time. Figure 3 depicts the logic system architecture of the system described. Home

Home Care System

Sensor

Biosensor

Emergency Medical Service

Hospital

Urgency

Fig. 3. Logical Architecture of the Emergency Assistance System

3.1

Requirements in Timed Traces

The CareSystem should satisfies the following timing and safety requirements: 1. No more than (6, 3, 2) units of time can elapse since it has been detected that a patients pulse is high before notifying the patient, hospital or the urgency respectively (We annotate this time by tp). Formally,

386

K. Benghazi et al. ∀tr ∈ FT T (CareSystem), ⎧ tp ⎪ ⎪ ⎪ ⎪ ⎨ S1 (tr) = tp ⎪ ⎪ ⎪ ⎪ ⎩ tp

< t(Advise) ≤ tp + 6 and < t(W arning) ≤ tp + 3 and < t(Alert) ≤ tp + 2

2. Before sending the advice to the patient or warning to the hospital, the system may ask the patient whether he/she is exercising. Formally, ∀tr ∈ FT T (CareSystem), S2 (tr) = if (Advise, t(Advice) ∈ σ(tr ↑ [tp, tp + 6)])) ⇒ Ask if exercise ∈ σ(tr ↑ [tp, tp + 3)])) and S3 (tr) = if (W arning, t(W arning) ∈ σ(tr ↑ [tp, tp + 3)])) ⇒ Ask if exercise ∈ σ(tr ↑ [tp, tp + 3)]))

3.2

CareSystem Specification and Verification

We model the Emergency Assistance system following the MEDISTAM-RT methodology. Table 1 shows the context of the Emergency Assistance system and its internal structure. Table 2 shows the timed sequence diagram of the CareSystem which describes the protocols behavior of the CareSystem ports.

Table 1. Context and Composite Structure Diagrams

Advice

Ask_if_Exercising

Emergency_Assistance

Warning

Exercise

+ / P2 : PCS~ + / P3 : UCS~ + / P4 : HCS~

Patient

Hospital

CD Alert

Urgency

Pu: UCS

Pp: PCS

P2: PCS~ P3: UCS~

Ph: HCS

P4: HCS~

P7: ACS~

CareSystem

Air_condi CSD

P1: ACS~

P9: PuCS

P6: PuCS~ P8: TCS

Pulse_sensor Emergence_Assistance

P5: TCS~

Temp_sensor

Applying Formal Verification Techniques to AAL Systems

387

Table 2. CareSystem Timed Sequence Diagram

TSD

of

Care System

Table 3 resume the mapping of this diagram into timed traces applying a set of rules established in [1].

Table 3. Mapping of Timed Sequence Diagram into Timed traces  TSeD =(?Hight pulse, tp) Mapping to

 (((Ask if Exercising, t1) (?Exercise, tp < t ≤ tp + 5)   |(timeout, tp + 5) (?advise, t2)) Delay(10))  (((Ask if Exercising, t1)

Timed



Traces

 T SeD  Acond Delay(5))  ((Alarm, tp < t < tp + 2)  Read temp  T SeDAcond Delay(30))

 (?Exercise, tp < t ≤ tp + 1)|(timeout, tp + 1) (?W arning, t2))

Comparing the specification T SeD in Table 3 and the specification of the requirement S1 (tr), S2 (tr) and S3 (tr), we deduce that:  T SeD sat Si (tr) (1) i∈1..3

Table 4 shows the timed state diagram of the CareSystem which is designed to describe it’s internal behavior and the mapping of this diagram into syntactical

388

K. Benghazi et al. Table 4. CareSystem Timed State Diagram

Timed State Diagram of Care System

Table 5. Mapping of Timed State Diagram into CSP+T TSD =(∗.0 → W aiting)  W aiting =((?Hight pulse[102 < P u ≤ 127]  tp) (Ask if Exercising) → W CI) Hight pulse[127 < P u ≤ 150]  tp) (Ask if Exercising) → S1)  |(?Hight pulse[P u > 150]  tp) I[tp, tp + 2].Alarm → Readt emp → S4) W CI =(I[tp, tp + 5].Exercise → W D)|

Mapping to CSP+T processes

  (timeout I[tp, tp + 6].Advise Delay(10) → W aiting)  W D =Delay(10) W aiting S1 =(I[tp, tp + 1].Exercise → S2)|     (timeout I[tp, tp + 3] W arning Readt emp Delay(10) → S4) S4 =(temp[T > 28] Switcho n → S3) |(temp[T < 18]



Switcho f f → S5)

S3 =On → Delay(30) → W aiting S5 =Of f



Delay(30) → W aiting

process CSP+T. To be able to verify the refinement relation between timed state diagram into timed sequence diagram we transform T SD (in Table 4) into timed traces applying the semantic function FT T described in [1]. The result of this mapping is showed in Table 5 and 6, respectively.

Applying Formal Verification Techniques to AAL Systems

389

Table 6. Mapping the TSD specification into timed Traces Timed behaviour of CareSystem in terms of timed traces  FTT (TSD) =(∗, 0) FT T (W aiting)  FT T (W aiting) =(?Hight pulse, tp) ((Ask if Exercising, t1) 

 (FT T (W CI)|FT T (S1))|((Alarm, tp < t < tp + 2)

(Read temp, t) FT T (S4) FT T (W CI) =(?Exercise, tp < t ≤ tp + 5)|    (timeout, tp + 5) (?advise, t2)) Delay(10)) FT T (W aiting)   FT T (S1) =(?Exercise, tp < t ≤ tp + 1) Delay(5) FT T (W aiting)    FT T (S4) =(temp, t2) ((Switch on On|((Switch of f Of f ) 

 Delay(30) FT T (W aiting)

Comparing the specifications T SD and T SeD, we conclude that: T SD |= T SeD From the equation 1 and 2, we deduce that:  T SD sat Si (tr)

(2)

(3)

i∈1..3

The equation 3 means that the component CareSystem fulfill its requirements.

4

Conclusions

Ambient Intelligence technologies are widely developed to construct safe environments around assisted people and help them maintain independent living. In order to enable elderly people and people with specific needs to live an independent and safe life, AAL systems have to cope with a series of non-functional requirements (i.e., safety and timeliness). To assure the correct functioning of these systems we have presented a verification approach based on the methodology MEDISTAM-RT, whereby both requirements and system behavior are captured in timed traces. The satisfaction and refinement relations can be checked in the timed traces semantic model. As a consequence, we can verify whether a system behavior specification fulfills its requirements. An emergency assistance system for monitoring people suffering from cardiac alteration has been used to specify and verify non-functional requirements by means of the proposed approach. Acknowledgments. This research is funded by the Spanish Government’s Ministry of Science and Innovation, via the project TIN2008-05995/TSI.

390

K. Benghazi et al.

References 1. Benghazi, K.: MEDISTAM–RT: Metodolog´ıa de dise˜ no y an´ alisis de sistemas de tiempo real. PhD Thesis, University of Granada, Spain (2009) 2. Benghazi, K., Capel, M.I., Holgado, J.A., Mendoza, L.E.: A methodological approach to the formal specification of real-time systems by transformation of UMLRT design models. Science of Computer Programming 65(1), 41–56 (2007) 3. Fraser, M.D., Kumar, K., Vaishnavi, V.K.: Strategies for incorporating formal specifications in software development. Commun. ACM 37(10), 74–86 (1994) 4. Gray, J.W., McLean, J.: Using Temporal Logic to Specify and Verify Cryptographic Protocols. In: Proc. Eighth Comp. Sec. Found. Workshop (CSFW 1995), pp. 108– 117 (1995) 5. Nehmer, J., Becker, M., Karshmer, A., Lamm, R.: Living assistance systems: an ambient intelligence approach. In: ICSE 2006: Proceeding of the 28th international conference on Software engineering, pp. 43–50. ACM Press, New York (2006) 6. Mantel, M., Sabelfeld, A.: A Generic Approach to the Security of Multithreaded Programs. In: Proc. 14th Comp. Sec. Found. Workshop (CSFW 2001), Cape Breton, Nova Scotia, Canada, June 2001, pp. 126–142 (2001) 7. Ras, E., Becker, M., Koch, J.: Engineering Tele-Health Solutions in the Ambient Assisted Living Lab. In: 21st International Conference on Advanced Information Networking and Applications (AINA), Niagara Falls, Canada (2007) 8. Selic, B., Rumbaugh, J.: Using UML for Modeling Complex Real-Time Systems, ObjecTime Limited/Rational Software whitepaper (1998) 9. Palanque, P., Basnyat, S., Navarre, D.: Improving Interactive Systems Usability Using Formal Description Techniques: Application to Health Care. In: Holzinger, A. (ed.) USAB 2007. LNCS, vol. 4799, pp. 21–40. Springer, Heidelberg (2007) 10. Herzberg, D., Marsden, N., Leonhardt, C., K¨ ubler, P., Jung, H., Thomanek, S., Becker, A.: Using Formal Specification Techniques for Advanced Counseling Systems in Health Care. In: Holzinger, A. (ed.) USAB 2007. LNCS, vol. 4799, pp. 41–54. Springer, Heidelberg (2007) 11. Schneider, S.: Concurrent and real-time systems the CSP approach. John Wiley & Sons, Ltd., Chichester (2000) 12. Zic, J.: CSP+T: a Formalism for Describing Real-Time Systems. PhD Thesis, University of Sydney, Australia (1991) 13. Cleland-Huang, J., Settimi, R., Zou, X., Solc, P.: Automated classification of nonfunctional requirements. Requirements Eng. (12), 103–120 (2007)

Software Architecture Evaluation in Global Software Development Projects Frank Salger Capgemini sd&m, Carl-Wery-Straße 42, 81739 Munich, Germany [email protected]

Abstract. Due to ever increasing system complexity, comprehensive methods for software architecture evaluation become more and more important. This is further stressed in global software development (GSD), where the software architecture acts as a central knowledge and coordination mechanism. However, existing methods for architecture evaluation do not take characteristics of GSD into account. In this paper we discuss what aspects are specific for architecture evaluations in GSD. Our experiences from GSD projects at Capgemini sd&m indicate, that architecture evaluations differ in how rigorously one has to assess modularization, architecturally relevant processes, knowledge transfer and process alignment. From our project experiences, we derive nine good practices, the compliance to which should be checked in architecture evaluations in GSD. As an example, we discuss how far the standard architecture evaluation method used at Capgemini sd&m already considers the GSD-specific good practices, and outline what extensions are necessary to achieve a comprehensive architecture evaluation framework for GSD.

1 Introduction In software development projects, the software architecture constitutes the “glue” between requirements, design and, ultimately, the code base. It determines whether the nonfunctional requirements will be met, and whether the code base will eventually embody a homogenous texture. In global software development (GSD), high quality software architectures play an even more important role than in co-located development projects: Architectural structure determines organizational structure and vice versa [1, 2]. It is more difficult to enforce compliance to architectural rules, and to have them “sink in” [3, 4]. Finally, unplanned and informal contact between team members where architecturally important information is casually exchanged does not take place between remote teams in GSD [5]. Hence, some aspects of architecting a software system seem to be different in GSD as compared to co-located software development. Today, powerful and mature methods to evaluate software architectures are at hand (see e.g. [6, 7], and [8] for an overview). Comprehensive guidance on how to conduct architecture evaluations is available [9, 10, 11]. However, despite the fact that architectural work is considerable different in GSD, current approaches to architecture evaluation do not answer the important question: “How should architecture evaluations differ when applied in the context of GSD?” R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 391–400, 2009. © Springer-Verlag Berlin Heidelberg 2009

392

F. Salger

With this paper we try to give some first answers to the above question and further stimulate the discussion what aspects are specific for architecture evaluations in GSD. In the next section, we present experiences from various GSD projects at Cap gemini sd&m and compare them to existing research literature. We then derive nine architecture good practices, which we believe should be checked in an architecture evaluation method used in GSD. In section 3, we describe the standard method to evaluate software architectures at Capgemini sd&m. We explain some shortcomings of this method when applied in GSD settings, and discuss how it can be improved in order to increase its effectiveness for GSD settings. We draw our conclusion in section 4 and outline our future research agenda.

2 Hot Spots for Architecture Evaluation in GSD Practice What are the pressing architecture related problems in GSD in the industrial practice? To approach this question, we discuss the lessons learned gained at Capgemini sd&m from numerous GSD projects for custom development of large scale business information systems. We match our experiences to results from the GSD literature, thereby confirming both, our experiences as well as the respective research results. To structure the rest of the paper, we observe that the word “architecture” is often used to describe three aspects of architectural work [6]: the organization of a system (the ‘product’), the description of this organization (the ‘documentation’), and finally the process of elaborating these descriptions (the ‘process’). We will use these three clusters when we subsequently discuss our project experiences and compile a list of our architecture good practices for GSD. 2.1 Lessons Learned from GSD Projects at Capgemini sd&m Capgemini sd&m is the Technology Services unit of the Capgemini Group in Germany and Switzerland and offers its customers end-to-end process and software solutions that have a crucial impact on their competitiveness. The Capgemini Group runs captive centers for offshoring software development in several countries, including India. We now discuss the some experiences distilled from various GSD projects carried out at Capgemini sd&m. We here solely focus on projects for custom software development of business information systems. When we use the acronym ‘GSD’ in the following, we always refer to this kind of projects. 2.1.1 Product Issue 1: In one of the biggest GSD projects at Capgemini sd&m (encompassing several hundred use cases), the modules where defined too coarse grained: They bundled the functionality of several dozen use cases not all of which where closely related to each other from a functional point of view. Some modules where too big to be handled by one team. Time pressure forced to assign dislocated teams to work on the same modules. These teams experienced a lot of extra communication: They had to repeatedly sort out, which team had to develop which functionality. Time pressure further decreased communication, which finally let to an increased amount of code duplicates. We thus affirm existing results that one of the most challenging product

Software Architecture Evaluation in Global Software Development Projects

393

related issues is to find the right modularization supporting the communication of distributed teams [1, 2, 5, 12]. This is a very intriguing issue to resolve. A naïve approach would be to minimize all communication between teams that reside at different shores. But this increases the risk of isolating the distributed teams thereby decreasing mutual awareness of remote team members for each others working status. Issue 2: This project also suffered from a mismatch between the use cases and the business processes of the customer. This became obvious too late in the project and let to considerable rework of the use case model. We experienced that such structural changes are more difficult to deal with in GSD than in co-located settings. Issue 3: Another recurring problem is the instability of the architecturally significant decisions which often result from instable or overlooked non-functional requirements. In this project, the technical proof-of-concept was insufficient. As a consequence, some of the core frameworks had to be repeatedly adapted after development team ramp up. This led to considerable unplanned extra effort to adapt the rest of the code base to these structural changes. Starting with a firm technical basis and stable non-functional requirements is mandatory in GSD. This matches the observations in [2, 13]. 2.1.2 Documentation Issue 4: One core learning from GSD projects at Capgemini sd&m is the need for comprehensive documentation to compensate communication and coordination issues. We observed however, that a GSD project does not necessarily need to document more than a co-located project. Often it is necessary to change how to document. As one example, not all software architecture documents written by German architects at Capgemini sd&m adhere to the 4+1 view format for architectures as suggested by the Rational Unified Process (RUP). But RUP is usually employed as main process model at Capgemini’s captive centers in India. Therefore it is crucial to agree on a format for the architecture document which supports all development teams doing their work. We also experienced the importance of the right balance between codification and personalization of architectural knowledge (see also [14]). In our GSD projects we complement concise architecture documentation with intensive coaching. Issue 5: Another stumbling point we encountered in our GSD projects is the problem of translation. Although the software engineers are well educated, it is sometimes challenging to write a software specification or an architecture document in a foreign language. Programming languages, architectural styles or design pattern constitute to some extend a universal language to software engineers. But complex non-functional requirements are already hard to capture precisely in the native language, but much harder in a foreign one. The same holds for specific terminology of less standardized and still evolving business domains. It is difficult to systematically translate a couple of thousand pages consistently. We sometimes experienced that terms in figures where translated differently to the according terms within the text. Also, short names of entities where not translated analogous to the long names of the entities. Usually, it was necessary to review the every translation. 2.1.3 Process Issue 6: In one of our early GSD projects, we did not employ tools and processes to rigorously manage and control architecture evolution and prohibit architecture

394

F. Salger

erosion. This ultimately let to many headaches at the integration points: only there it became obvious that many architecture violations existed, which entailed laborious rework and refactoring phases. These unplanned efforts increased time pressure, which in turn further decreased the willingness to control architecture evolution. We also experienced that compliance to rules and processes was difficult to enforce. This matches the results in [3, 4]. Issue 7: These problems were further intensified by an inappropriate integration strategy: Formal code integration was done only on a monthly basis. This repeatedly lead to the undesirable big bang effect, where it became obvious that large extends of the code did not fit to each other. We thus confirm existing literature which stresses the importance of regularly and often integrating the whole code base [13, 15]. Issue 8: At the beginning, this project was planned as pure onsite, co-located development project. Offshore development had been “planned in” only after the project was well underway. The project then suffered from the fact that both, the business analyst and the technical architect joined the team much too late. It was very hard for the offshore team to catch up the same level of technical and business knowledge as the onsite team. We learned that collocating the onsite and offshore architects during the high-level architecture phase is crucial. The offshore architects can than act as ‘architecture evangelists’ when they are back in their home office. These experiences coincide with known good practices for architectural knowledge management [14]. 2.2 Architecture Good Practices From the discussion above, we can now derive our architecture good practices for GSD. These serve as an input for the subsequent discussion, what aspects should be assessed in architecture evaluations in GSD. 2.2.1 Product GP1: Ensure that the architecture fits to the organizational structure. Establish a product architecture that minimizes communication of distributed teams but at the same time avoids communication breakdown. This addresses issue 1. GP2: Ensure that the architecture is aligned to business drivers. Make sure that the architecturally significant decisions satisfy the architecturally significant requirements (ASR). Ensure that the alignment of the ASR to the relevant business drivers has been verified by the business analyst. This avoids potentially disastrous additional effort to adapt the architecture which becomes necessary if core ASR are changed. This good practice helps to mitigate issue 2. GP3: Ensure that the architecture is stable. Assess the maturity and stability of the high-level architecture before programming starts to avoid that structural problems surface after lots of low level code has been written. This mitigates issue 3. 2.2.2 Documentation GP4: Consider the developers point of view. Write the architecture document such that the offshore development team understands it and control that the team can actually work with it. Take the differing architectural approaches, methods, terminology and background of distributed teams into account. This alleviates issue 4.

Software Architecture Evaluation in Global Software Development Projects

395

GP5: Check all translations. Ensure that translations of the architecture are correct to avoid ambiguities and repeated rounds of clarification. This helps to avoid issue 5. 2.2.3 Process GP6: Co-locate architects during high-level architecture activity. Co-locate offshore and onsite architects during the high-level architecture phase to efficiently disseminate core architectural knowledge and foster a common view on the system under construction. This good practice helps to avoid issue 8. GP7: Implement ongoing architecture management. Make sure that architecture management processes are in place (and in use), to avoid architecture erosion. Make use of automatic tools to check for architecture compliance. This mitigates issues 6, 7. GP8: Invest in architecture knowledge transfer and control it. Knowledge transfer is more difficult in GSD that in co-located development [3]. For example it is known, that in Eastern countries, power distance is higher than in Western countries [15]. This can, for example, lead to situations, where the offshore developer does not pinpoint a flaw in the architecture to avoid that the onsite architect ‘looses his face’. We experienced however, that such effects quickly fade out, as soon as the ‘one-teamspirit’ kicks in. This avoids issue 8. GP9: Enforce clearly defined configuration management policies. Invest in clear policies for configuration-, build- and integration-management. Keep the knowledge about all involved processes up to date and control strict adherence to processes and policies. This mitigates issue 7. From these nine good practices, GP 4, 5, 6 (and to some extend 8) are specific for GSD. The importance of the others however is usually strongly amplified in GSD, as the literature exemplifies [13]. We believe that assessing compliance to the above listed good practices is important and should be done in any architecture evaluation method applied at GSD of business information systems. These issues might not be the only ones which must be assessed. But we think that they lead the focus on issues with a potentially disastrous impact on project success, if they are not carefully addressed. In the next section, we describe the ‘architecture quality gate’. We discuss which architecture related problems of GSD are not yet addressed by this method.

3 The Architecture Quality Gate Used at Capgemini sd&m One of the business areas of Capgemini sd&m is the development of information systems for business-critical processes of our customers. Soundness, appropriateness and maintainability of our software architectures are major success factor of such projects. We thus devised a comprehensive architecture evaluation method which is used throughout Capgemini sd&m, the so called ‘architecture quality gate’ (QG-Arch) [17]. Figure 1 depicts the embedding of the quality gates within the overall quality assurance framework of Capgemini sd&m. It shows how the quality gates are complemented with ongoing quality assurance processes, like testing.

396

F. Salger

ec Sp

QG

a ti ific

er nd Te

ion rat eg

Specification

Int

re c tu

on

ite r ch :A QG

QG

QG Tender

Design Implementation

Integration test

Production

Gathering and control of maturity level metrics Component acceptance procedure Continuous integration Test of functional requirements Test of non-functional requirements

Fig. 1. Quality gates in context [17]

The high-level objectives of the QG-Arch are: • • • •

To evaluate, whether the customer needs are met by the software architecture. To determine, whether the architecture is an appropriate solution for the problem. To secure, that the architecture is viable for the following development activities. To enforce the defined fundament for the following development activities.

The QG-Arch consists of six evaluation steps. In the first step, the software requirements specification is checked whether (1) functional requirements be understood by the developers, and (2) the specification was continued in the way, it was approved by our ‘specification quality gate’ (see [18] for details on this gate). In the second step, we apply a multi-level checklist in order to get an overview on the overall architecture. This serves as an input for the third step, where we apply ‘lightweight-ATAM’, an adaptation of the ‘Architecture Tradeoff Analysis Method’ [6] specifically tailored to our purposes. There, we verify the architecturally significant decisions against the quality model of the relevant stakeholders. In the fourth step we check, whether the evolutionary prototype is sufficiently mature to serve as a template (for example, compliance to coding style, robustness). Further, we check whether the behaviour of the system to be built can really be inferred from the exploratory prototypes. The fifth step serves to generate an explicit list of the main architectural problems together with a detailed investigation of these problems. In the last step, we assess the employed project management and the quality management with respect to architectural concerns. All these steps are supported by comprehensive usage concepts, guidelines, checklists and templates. The effectiveness of these steps has been proved in several large scale projects [17]. In the following, we describe how the QG-Arch addresses the core issues as listed in the last section, as well as the weaknesses of the QG-Arch with respect to GSD. We state in brackets which good practices are addressed by the QG-Arch, and which are not.

Software Architecture Evaluation in Global Software Development Projects

397

3.1 Product-Related Evaluation Current practice in QG-Arch: Capgemini sd&m established a life-cycle encompassing method framework for crafting highly cohesive, loosely coupled architectures, which at the same time helps to avoid over-engineering. The framework consists of constructive and analytical methods which keep the business drivers of the customer aligned with the resulting system architectures throughout the development process: Starting at the enterprise level, we use Quasar Enterprise to build true service oriented architectures which support the customers’ business processes and keep the application landscape architecture flexible [19]. At the “one-system”-level, we apply Quasar [20] to create flexible systems composed out of cohesive and loosely coupled modules. We check compliance to Quasar in the QG-Arch (GP1 partly covered). Alignment of the architecturally significant decisions to the architecturally significant requirements is checked with the ‘lightweight-ATAM’ [17] (GP2 covered). We also check, that the architecture is reasonable stable which the project usually proves by developing a proof of concept or prototype (GP3 covered). Loose ends of QG-Arch with respect to GSD: In GSD, the right approach is to minimize the kind of ‘unwanted’ communication induced by highly dependent components by carefully crafting highly cohesive and loosely coupled components. But at the same time we seek to intensify the ‘precious’ communication about the overall system goals and context in order to repeatedly align the common view on the system under construction. Literature exists on distribution models (see e.g. [21]), but little is known about measuring how well the organisation fits the architecture [12]. Though Quasar helps us to build cohesive and loosely coupled architectures and QG-Arch checks compliance to Quasar, we believe that GP1 is not yet fully addressed. 3.2 Documentation-Related Check Current practice in QG-Arch: The lightweight-ATAM checks whether architecturally significant requirements are explicitly documented (see [17]). Loose ends of QG-Arch with respect to GSD: Assessing the architecture documentation as such is only insufficiently captured in the current version of the QG-Arch. The focus clearly lies on checking the appropriateness of the architecturally relevant decisions with respect to the architecturally relevant requirements. The QG-Arch does not explicitly assess readability and usability of the architecture document from the viewpoint of the developer. This however would be especially important in GSD, due to differing terminologies between the onsite and the offshore team. As the QG-Arch was mainly designed for the assessment of pure onsite projects, potential translation issues where also not taken into account. (GP 4, 5 not covered) 3.3 Process-Related Check Current practice in QG-Arch: Here, we check whether precise quality objectives are defined for architecture artifacts, and how they will be monitored. How requirements will be traced back, how configuration and change management is implemented, how

398

F. Salger

architecturally related risks are determined and tracked, and how architecture management is implemented in order to cope with an evolving architecture. We also check that architecturally related milestones are defined, progress for architecture development is controlled and that all key roles are staffed with the right persons. Loose ends of QG-Arch with respect to GSD: In co-located projects, it is common that the architects have a weekly meeting together with the business analyst and the project manager. We do not check explicitly in the QG-Arch that such meetings are carried out. (GP 6 not covered) Although the use of automatic architecture management tools is by now commodity at Capgemini sd&m projects [17], we still have to investigate in which way configurations of these tools could be different for GSD as opposed to pure onsite projects. There are indicators, that hampered coordination and communication might mandate the use of smaller modules than usual. For the same reason it might be necessary to use stricter configurations for automatic tools, like code duplicate checkers. (GP 7 covered) Knowledge transfer is not explicitly checked in the QG-Arch, since all Capgemini sd&m employees are repeatedly trained in the Capgemini sd&m methodologies like Quasar Enterprise [19], Quasar [20], or the Specification Methodology [18]. Although we carry out intensive trainings for our offshore colleagues, this cannot provide an equally strong common ground. We thus have to augment the QG-Arch by checks assuring an ongoing knowledge transfer as needed in GSD (GP 8 not covered). Although we have standard policies for configuration, version, build and integration management, we do currently not comprehensively check compliance to them in the QG-Arch (GP 9 partly covered). In summary, we found that the QG-Arch is already provides a good fundament which can be extended to an architecture evaluation method for GSD, although it does not yet cover the good practices GP 4, 5, 6 and 8. This is not surprising since it was originally devised for the use in multi-site onshore projects. However, moving to global multi-site software development introduces new challenges like communication and coordination problems, language problems and cultural differences [3]. Apart from extending the QG-Arch such that it also covers the missing good practices, we have discovered another topic for future work: The main goal we want to achieve with the QG-Arch is to avoid major problems with the software architecture [17]. As such, the QG-Arch was not designed to assess the lower level design within modules which however is important, since modules are often used as ‘work packages’ which can be handed over between distributed development teams. It is well known that such ‘handover checkpoints’ are an important means to manage the distributed development process [16]. We will thus devise a handover checkpoint, where the completeness of work packages and their compliance to previously agreed quality objectives is assessed jointly by the onsite and offshore team. Within the QG-Arch, we also carefully assess architecturally relevant processes. This can be seen as an advantage over existing architecture evaluation methods like ATAM or SAAM [6], which purely concentrate on assessing the ‘product’- and ‘documentation’-aspects of software architectures. It is well known that assessing architecture-relevant processes is especially important in GSD [3, 4].

Software Architecture Evaluation in Global Software Development Projects

399

4 Conclusion In this paper, we investigated how architecture evaluation methods should be adapted in order to take the characteristics of global software development (GSD) into account. To this end, we first discussed typical problems which we encountered in large scale commercial GSD projects at Capgemini sd&m. From this discussion, we distilled a list of good practices for GSD of large business information systems. Product: o o o

Ensure that the architecture fits to the organizational structure Ensure that architecture is aligned to the business drivers Ensure that the architecture is stable

Documentation: o o

Consider the developers point of view Check all translations

o o o o

Co-locate architects during high-level architecture activity Implement in ongoing architecture management Invest in architecture knowledge transfer and control it Enforce clearly defined configuration management policies

Process:

We argued that a software architecture evaluation method for GSD should check compliance to these good practices. We then investigated to what extend the standard architecture evaluation method of Capgemini sd&m (the ‘architecture quality gate’, QG-Arch for short) already takes these results into account. We identified some shortcomings of the QG-Arch with respect to its effectiveness in GSD. Finally we discussed how to fill these loopholes of the QG-Arch. We also motivated that the QG-Arch should be complemented by handover checkpoints, where the internal design of modules is assessed, and which are jointly applied by the offshore and onsite architects. Our main conclusions are that architecture evaluations which where devised for colocated project settings must be extended in two ways: 1) Architecture documentation must be carefully evaluated from an offshore developer point of view, and 2) the effectiveness of processes like architecture knowledge transfer must be assessed.

References 1. Conway, M.: How Do Committees Invent? Datamation 14(4), 28–31 (1968) 2. Herbsleb, J.D., Grinter, R.E.: Architectures, Coordination, and Distance: Conway’s Law and Beyond. IEEE Software 16(5), 63–70 (1999) 3. Clerc, V., Lago, P., van Vliet, H.: Global Software Development: Are Architectural Rules the Answer? In: Proc. of the 2nd International Conference on Global Software Engineering, pp. 225–234. IEEE Computer Society Press, Los Alamitos (2007) 4. Clerc, V., Lago, P., van Vliet, H.: Assessing a Multi-Site Development Organization for Architectural Compliance. In: Proc. of 6th Working IEEE/IFIP Conference on Software Architecture (WICSA 2007), p. 10. IEEE Computer Society Press, Los Alamitos (2007)

400

F. Salger

5. Herbsleb, J.D., Grinter, R.E.: Splitting the Organisation and Integrating the Code: Conway’s Law Revisited. In: Proc. of the 21st International Conference on Software Engineering, pp. 85–95. IEEE Computer Society Press, Los Alamitos (1999) 6. Clements, P., Kazman, R., Klein, M.: Evaluating Software Architectures Methods and Case Studies. Addison-Wesley, Reading (2002) 7. Choi, H., Yeom, K.: An Approach to Software Architecture Evaluation with the 4+1 View Model of Architecture. In: Proc. of the 9th Asian-Pacific Software Engineering Conference, pp. 286–293. IEEE Computer Society Press, Los Alamitos (2002) 8. Dobrica, L., Niemelä, E.: A survey on software architecture analysis methods. IEEE Transactions on Software Engineering 28(7), 638–653 (2002) 9. Maranzano, J.F., Rozsypal, S.A., Zimmerman, G.H., Warnken, G.W., Wirth, P.E., Weiss, D.M.: Architecture Reviews: Practice and Experience. IEEE Software 22(2), 34–43 (2005) 10. Bass, L., Nord, R., Wood, W., Zubrow, D.: Risk Themes Discovered Trough Architecture Evaluations. In: Proc. of 6th Working IEEE/IFIP Conference on Software Architecture (WICSA 2007). IEEE Computer Society Press, Los Alamitos (2007) 11. Kazman, R., Bass, L.: Making Architecture Reviews Work in the Real World. IEEE Software 19(1), 67–73 (2002) 12. Herbsleb, J.D.: Global Software Engineering: The Future of Socio-technical Coordination. In: Proc. of Future of Software Engineering, pp. 188–198. IEEE Computer Society Press, Los Alamitos (2007) 13. Sangwan, R., Bass, M., Mullik, N., Paulish, D.J., Kazmeier, J.: Global Software Development Handbook. Auerbach Publications (2006) 14. Clerc, V.: Towards Architectural Knowledge Management Practices for Global Software Development. In: Proc. of the 8th International Workshop on Sharing and Reusing Architectural Knowledge, pp. 23–28. ACM, New York (2008) 15. Carl, D., Gupta, V., Javidan, M.: Power Distance. In: House, R.J., Hanges, P.J., Javidan, M., Dorfman, P.W., Gupta, V. (eds.) Culture, Leadership, and Organizations. The GLOBE Study of 62 Societies. Sage, Thousand Oaks (2004) 16. Cusumano, M.A.: Managing Software Development in Globally Distributed Teams. Communications of the ACM 51(2), 15–17 (2008) 17. Salger, F., Bennicke, M., Engels, G., Lewerentz, C.: Comprehensive Architecture Evaluation and Management in Large Software-Systems. In: Becker, S., Plasil, F., Reussner, R. (eds.) QoSA 2008. LNCS, vol. 5281, pp. 205–219. Springer, Heidelberg (2008) 18. Salger, F., Sauer, S., Engels, G.: An Integrated Quality Assurance Framework for Specifying Business Information Systems. In: Proc. of the Forum at the 21st International Conference on Advanced Information Systems, pp. 25–30. CEUR (2009) 19. Engels, G., Hess, A., Humm, B., Juwig, O., Lohman, M., Richter, J.P., Voß, M., Willkomm, J.: A Method for Engineering a True Service-Oriented Architecture. In: Proc. of the 10h International Conference on Enterprise Information Systems, vol. 2, pp. 272– 281 (2008) 20. Haft, M., Humm, B., Siedersleben, J.: The Architect’s Dilemma – Will Reference Architectures Help? In: Reussner, R., Mayer, J., Stafford, J.A., Overhage, S., Becker, S., Schroeder, P.J. (eds.) QoSA 2005 and SOQUA 2005. LNCS, vol. 3712, pp. 106–122. Springer, Heidelberg (2005) 21. Carmel, E.: Global Software Teams. Prentice Hall PTR, Englewood Cliffs (1999) 22. Sangwan, R., Ros, J.: Architecture Leadership and Management in Globally Distributed Software Development. In: Proc. of the 1st International Workshop on Leadership and Management in Software Architecture, pp. 17–22. ACM, New York (2008)

An Architectural Pattern for Mobile Groupware Platforms Andrés Neyem1, Sergio F. Ochoa2, José A. Pino2, and Dario Franco3 1

Department of Computer Science, Pontificia Universidad Católica de Chile [email protected] 2 Department of Computer Science, Universidad de Chile {sochoa, jpino}@dcc.uchile.cl 3 CIGIP Group, Universidad Politécnica de Valencia, Spain [email protected]

Abstract. Architectural patterns have been proposed in many domains to capture recurring design problems that arise in specific design situations. This article presents an architectural pattern to help modeling the coordination and communication services required by mobile groupware platforms. This pattern serves as educational media for developers, students or researchers on how to design coordination and communication services for mobile groupware systems. The pattern also fosters the reuse of proven solutions. Keywords: Coordination patterns, Communication patterns, Mobile Groupware, Mobile collaboration.

1 Introduction Mobile groupware platforms can be built in various ways, used on several devices, operate over many different networks, and integrate with various back-end systems. The task of building a mobile groupware solution can often be daunting given the many technology choices and implementation approaches. Thus, the software architecture becomes the key for the development of these systems. This paper presents an architectural pattern which can be advantageously applied in the development of mobile groupware platforms. The architectural pattern presents solutions for recurring problems associated with coordination and communication services required to support mobile collaboration. In addition, the article presents an autonomous software infrastructure as an implementation of the proposed architectural pattern. This infrastructure contains generic components to support development, deployment and execution of mobile groupware applications. Examples of functionality provided by its components include provision of services to coordinate the operations on shared resources and services. The reuse of services is the most emphasized benefit of using services platforms support. Embedding common complex tasks into the platform and making them uniformly available for reuse can greatly enhance the efficiency of application development. R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 401–410, 2009. © Springer-Verlag Berlin Heidelberg 2009

402

A. Neyem et al.

Next section presents the main challenges to be met when designing a solution to support mobile groupware systems. Section 3 describes the architectural pattern and its implementation to deal with the design challenges of coordination and communication services. Section 4 discusses related work. Section 5 presents the conclusions and future work.

2 Requirements for Mobile Groupware Systems This section describes general requirements that are usually present in the development of mobile groupware systems. Some requirements influencing mobile collaboration, in terms of communication and coordination support, are the following ones: ƒ Flexibility: Mobile groupware systems must support frequent changes in group size and structure, as mobility may cause group participants to connect or disconnect from the group [12]. Two mechanisms to provide flexibility are the following ones: automatic user detection and user connection / disconnection. The first one provides contextual information to implement awareness mechanisms. The second one allows applications to work offline and switch to online use on-demand. ƒ Shared Information Support: Frequent disconnections and autonomous work usually cause inconsistencies and unavailability of the resources which are being shared by the group members [12]. Some requirements supporting consistency and availability of data are explicit data replication, caching and conflict resolution. ƒ Mobile Awareness: Since a mobile groupware system supports collaborative work, it must provide awareness mechanisms to improve the users’ understanding of the group’s work [16]. The system should offer offline and online awareness, both of which should be updated as information becomes available. ƒ Safety: Mobile groupware systems must incorporate measures ensuring the work of each user is protected [13]. Some of these measures are: work sessions, user privacy and security. ƒ Integration: Regardless of the mobile device used to access the mobile application, a person should be able to interact with any collaborator using the same mobile groupware application [12]. Differences among devices are a burden to the users who should be eased by the collaborative system. Heterogeneity and interoperability are requirements which must be considered. ƒ Communication: Mobile groupware system users need to communicate with each other by exchanging messages [16]. Since the users are on the move to carry out their activities, some of them could be unreachable during some time period. Therefore, the system should provide mechanisms for synchronous/asynchronous communication and attended/unattended message delivery. ƒ Networking: Many work scenarios do not provide wireless communication support; in those cases the mobile groupware application should work based on a Mobile Ad-hoc Network (MANET) [12]. Networking issues should be transparent for the end-user. Otherwise, the collaboration capability is at risk.

An Architectural Pattern for Mobile Groupware Platforms

403

3 An Architectural Pattern

Collaboration Layer

Coordination Layer Solutions for Coordinate Operations among Mobile Workers Communication Layer

Back-End

CrossLayer

Mobile Groupware Applications

Front-End

A layered and fully-distributed architecture is recommended for mobile groupware applications since collaboration is based on communication and coordination [6]. The advantages of the layered architecture have already been discussed and recognized by the software engineering community [4]. Fig. 1 shows the Crosslayer pattern, which structures the basic functionality of a mobile groupware system.

Solutions for Messages Interchange among Mobile Applications

Fig. 1. Layered architecture to support mobile collaboration

The coordination layer provides solutions to support the typical groupware design aspects, but considering work contexts that involve unstable communication services. The communication layer focuses on the provision of services for message interchange among mobile workers’ applications. Next section briefly describes this pattern following the nomenclature proposed in [18]. 3.1 Context and Problem A mobile groupware environment consists of various independent applications, distributed over several mobile nodes connected via a wireless network. These applications need to interact with each other, exchanging data or accessing each other’s services in order to coordinate the work performed by a group of collaborators who pursue a common goal. It is clear that collaboration support requires communication and coordination services [6]. Thus, mobile groupware systems require separate functionality in three basic concerns: communication, coordination and collaboration. Each layer provides services and records data related to such services. These services are different in terms of concerns and granularity. The interaction between services related to two concerns is hierarchical: communication coordination and coordination collaboration. Integration of these services is required to support mobile collaboration, because frequently the service provider and the consumer run on different computing devices. Therefore, if the services provided by the mobile groupware system are not well structured, the system will be limited in terms of scalability, maintainability and adaptability.

404

A. Neyem et al.

3.2 Solution The services related to different concerns can be grouped in distinct layers (Fig. 1). Designers can thus separate concerns and increase the system scalability, maintainability and adaptability. The lower layer provides services for message interchange. The coordination layer focuses on coordinating the operations of mobile workers in order to provide a consistent view of the group tasks. Finally, the collaboration layer provides support for managing interactions among mobile workers trying to reach the group goals. Next subsections present the solutions used to structure the coordination and communication services. 3.2.1 Coordination Solutions The coordination solutions concern the provision of services required by mobile workers’ applications to coordinate the operations of mobile workers on the shared resources (e.g. files, sessions and services). These solutions use services provided by the communication layer. This layer must separate functionality in the three basic concerns and implement it in components such as the following ones: Distributed Sessions, Users and Roles Management. This component provides services which allow multiple work sessions involving users playing several roles. The rights are related to the role each user has for each session s/he is working on. Sessions, users and roles management should be fully-distributed since the workers have to keep their autonomy. Moreover, the loosely coupled work requires ondemand collaboration, information sharing and data synchronization; thus, explicit session management [16] should be provided by this component. In explicit sessions, participants must intentionally connect with other clients in order to interchange information or carry out opportunistic collaboration. The type of explicit work sessions matching loosely coupled work are the following ones: ad-hoc, publicsubscribe and private-subscribe. Distributed Management of Shared and Private Resources. This component should provide several services for every mobile user. First, a local (private) repository to store the private resources and second, a shared (public) repository to store resources the users want to share. The shared repository contains two types of information resources: reconcilable and irreconcilable. A reconcilable resource is a piece of information which can be synchronized with other copies of such resource in order to obtain a consistent representation of it. On the other hand, the irreconcilable resources are pieces of information which cannot be synchronized. Typically, the system has no information about the internal structure of these files. These resources are shared through file transfer mechanisms. Context Management. This component must provide functionality for everything that can influence the behavior of mobile groupware applications. It includes hardware resources of computing devices and also external factors (e.g. bandwidth or quality of the network connection). This component has to be fully distributed and it must store, update and monitor current status of the context. This context manager has also to be carefully engineered in order to reduce the use of limited resources, such as battery, CPU, memory or network bandwidth.

An Architectural Pattern for Mobile Groupware Platforms

405

Figure 2 shows the class diagram representing the structure that provides the functionality for the three main concerns. Group A are classes for services which allow multiple work sessions involving users playing several roles. Group B, C and D are classes for managing shared and private resources. Finally, group E are classes for context management. A detailed description of this structure can be found in [13]. class Coordination Layer MobileNodeAddress

E

MobileNodeContext

B

SharedTool

+has +has MobileUser +has

+has

FilterResourcesView

0..*

1..* 1..* +has

UserProfile

+has

MobileLocalUser

MobileRemoteUser

ResourcesView

+has

Resource 0..*

1

1..*

0..*

MobileWorkspace

+uses

SessionManager

+manages

1..* Session

+has

SharedRepository

«XmlSchema» ApplicationSpecificPolicy

+has IrreconcilableResource AdHocSession

C

0..*

FileTransferTicket +uses

+has

ReconcilableResource

SubscribeSession

«XDocument» LatestCommonEdition

«XDocument» CurrentEdition

+has PrivateSubscribeSession

PublicSubscribeSession

FileStream

+uses 0..*

MobileUserRole

+creates FileTransferWorkItem

RoleSchema

SyncResourceTicket

+has

+has

SessionRole

+has

UserPermission

1..*

1..*

0..*

+handles

0..*

FileTransferManger

A

+has 1..*

0..*

+has +creates +uses

ResourcesSynchronizationManager

+handles

D

SyncResourceWorkItem 0..*

Fig. 2. Class diagram of the coordination layer

3.2.2 Communication Solutions The communication layer is typically in charge of providing the support for messages interchange among mobile units. This component allows a user to send a message to other users in the wireless network in several ways: to those connected to a session, to a specified group of users, or to a single user. Based on that infrastructure, a mobile groupware application can send messages to other users. This layer must separate functionality in two main concerns: communication middleware and wireless routing. Communication Middleware. This component provides a common programming model able to support several communication strategies, which can help developers to minimize the complexity of a mobile groupware application. The architecture of this component separates the design concerns in two layers: service and messaging layer. The service layer provides a service-oriented approach and it lets mobile groupware systems to be extensible, flexible and interoperable in terms of services discovery, consumption and provision [12]. Thus, this layer provides functionality for service design and execution. The service external structure includes a service description and a collection of endpoints (Fig. 3). The service description provides essential information about what particular services (i.e. functions) this component

406

A. Neyem et al.

Service Contract

Binding protocol

Address

can provide and how they can be accessed. These service descriptions are specified and communicated using several standards. The internal structure of a service contains the binding protocol, contracts and implementation code (Fig. 3). The binding protocol describes how a service should be accessed. The contracts describe contextual information related to such service, e.g. its behavior, structure, or understandable message format. The implementation contains all the code that will be executed once the service is invoked. A fundamental part of the service design is the definition of contracts. Service There are two kinds of contracts: a) Service contracts, which describe Implementation Endpoints the operations a service can perform, and b) Data contracts, which define information structures passed to Service Description service operations. The endpoints are in charge of linking a contract and a binding protocol with a service Fig. 3. Internal view of a service address. On the other hand, the messaging layer provides the general model allowing the message communication. In this layer, the messages are serialized and transmitted using the selected transport, protocol rules (like reliable messaging) and security policies (like encryption). A key component of this layer is the channel, which represents the highway over which the messages travel. This channel is an abstraction hiding all the underlying details of the communication process. For example, before two mobile groupware applications can exchange messages, a channel must be established between them. The first step involves a client trying to create a channel towards the endpoint of the service provider. If the service is available and reachable at that destination address, a channel can be established and the message exchange can take place. Once communication is completed, the channel can be turned down. Wireless Routing Layer. This layer provides a transparent solution when mobile groupware applications are running in ad hoc wireless mode. The solution involves the provision of a message router which consumes messages from different message channels, and it split them in packets which are routed to the receiver. Finally, this router rebuilds the message based on the received packets. The packet delivery service should offer an intermediate solution between the routing and flooding techniques in order to achieve high reliability with moderate degradation of performance. Figure 4 describes the structure including the main concerns of the communication layer. A detailed description of these functionalities can be found in [12]. Services are represented as a series of objects containing the service description, program code and runtime information. The service description includes the service contracts, behaviors and endpoints. The program code for the service is represented through the service type. The runtime information includes channels, instances of the service type, and extensions to the service. For each service there exists a master class, representing a service at runtime, called ServiceDispatcher. The ServiceDispatcher object contains the service type. When a ServiceDispatcher object is created, the service type is specified. From the client side, this application is responsible for triggering the

An Architectural Pattern for Mobile Groupware Platforms

407

processing in a service-oriented solution by initiating the communication. Since services can call other services, client code can appear in both client and service programs. Any program initiating messages is acting as a client, even if that program is also a service. Clients talk to services via proxies. A client accesses service operations by calling proxy methods. Mobile Application B

Mobile Application A Service Layer

Proxy Operation 1

Service Instance Operation 1

Operation 2

Operation 2

ServiceDispatcher

Messaging Layer Protocol Channel

Protocol Channel

Channel Mode OneWay

RequestRespons

Channel Mode OneWay

Dual

RequestRespons

Message

Dual

Message

Transport

Transport Channel Pipeline

Channel Pipeline Wireless Routing Layer Packets

Packets

Message Router

Fig. 4. Conceptual overview of the communication layer

The transport indicates the protocol the channel is going to use. If the transport is TCP/IP then the applications will interact with other mobile applications using sockets. The channel transport is always the lowest level of the channel component. From the service consumer’s perspective, the channel is the last component in the communication pipeline. However, from the receiver’s perspective, it is the first one. Over the transport, several channel protocols can be implemented. These protocols are responsible for performing additional functionalities on the message objects, e.g. encryption/des-encryption, or format transformations. Finally, the channel mode allows the channel pipeline to change the messaging patterns. Three messaging patterns can be used: One-way, Request-Response and Dual. These patterns are not all necessarily available for any transport protocol. For example, the transport does not support dual communication for Message Queuing. 3.3 Pattern Implementation A pattern provides a generic solution for a recurring problem: a solution which can be implemented in many ways without necessarily being ‘twice the same’ [4]. This section briefly presents the implementation of the architectural pattern defined in the previous section. A detailed description of these functionalities can be found in [13].

408

A. Neyem et al.

Middleware

Communication Layer

Coordination Layer

The Service-Oriented Mobile Unit (SOMU) is a lightweight platform running over wireless Mobile Groupware Applications networks (i.e. infrastructure and ad hoc mode), where the mobile Information Session Management Sharing/Synchronization nodes compose a mesh. The platform enables each mobile Awareness of User/Role Management File Transfer User Proximity computing device to produce and consume services from other Service Layer peers connected to the mesh [13]. The SOMU architecture consists Messaging Layer of components organized in two layers (see Fig. 5): coordination Wireless Routing Layer and communication. The layers manage the corresponding groupFig. 5. SOMU basic architecture ware services and a shared data space. These components communicate with the adjacent one through an API. Mobile groupware applications developed on SOMU can use the general solutions implemented in that platform. These solutions include the management of sessions, users, messages delivery, shared objects and repositories; and it partially allows management of the work context. Mobile groupware applications inherit the capabilities for interacting with applications running on others mobile units. It helps developers to focus on the application’s main goal, freeing them to deal with lowlevel interaction processes (i.e. communication and coordination). Developed applications over this platform include mobile collaborative software to support disaster relief operations [10], to conduct inspections on construction sites [15] and to manage exams in computer science courses [14].

4 Related Work There are several experiences reporting the use of mobile groupware applications [3], [7]. Although some of these applications are fully-distributed, they do not describe or evaluate the strategies used to deal with the typical coordination services (e.g. distributed sessions, shared information support and context management) and communication services in mobile groupware (e.g. communication channels, protocols and routing). Thus, the potential design solutions cannot be evaluated when they are formalized through design patterns or reused in future applications. Schümmer and Lukosch argue groupware reuse should focus on design reuse rather than code reuse [18]. These researchers also propose a patterns system for groupware for stationary scenarios, therefore they do not consider the users mobility. Jørstad et al. have proposed and described a set of generic coordination services for distributed (but stable) work scenarios [8]. These services include locking, presentation control, user presence management and communication control. Other researchers have also proposed similar solutions to support coordination and communication on fixed networks [2]. However, the contextual variables influencing the collaboration scenario and the mobile work make such solutions unsuitable to support mobile collaboration.

An Architectural Pattern for Mobile Groupware Platforms

409

On the other hand, there are several middleware and platforms that provide different mechanisms and techniques to enable communication between distributed components [4]. Examples of these middleware are RPC-based middleware (e.g. JINI [1]), message-oriented middleware (e.g. Sun’s Java Message Queue [11]), publishsubscribe middleware (e.g. JEDI [5]), tuple-based middleware system derived from LINDA (e.g. FT-LINDA, PLinda, TSpaces, Lime, JavaSpaces, and TOTA [17]) and data sharing-oriented middleware (e.g. XMIDDLE [9]). However, a middleware able to combine more than one approach is required in order to cover a wide range of mobile work scenarios. For example, the asynchronous model of interaction between hosts, such as the message-oriented style, would offer potential solutions and drastically enhance middleware possibilities in ad-hoc environments. In addition, keeping the middleware lightweight and taking the context awareness as a functional requirement could help dealing with the instability of the work contexts. Furthermore, efficient adaptable resource discovery mechanisms, specifically intended for mobile ad hoc environments, could provide robustness and flexibility to the solutions, mainly in terms of handling the frequent changes in network components and topology.

5 Conclusions and Further Work Developing mobile groupware platforms to support collaborative work is a challenging task, since this is a recent area and software must overcome challenges in technical implementation, collaboration support and users’ adoption. This paper presents an architectural pattern to support the design of coordination and communication services required by mobile groupware systems. This pattern deals with most of the stated requirements and serves as educational and communicative media for developers, students or researchers on how to design coordination and communication mechanisms for mobile groupware applications. It also fosters the reuse of proven solutions. At the moment, the architectural pattern has shown to be useful to design both, mobile groupware applications and a middleware to support collaborative systems [13]. The reuse of these designs and the implementation of the proposed solutions have been quite simple. However, the authors have been involved in each one of these testing experiences. Therefore, future work is required to carry out evaluations with external groupware developers in order to determine the real contribution of this proposal. Moreover, the solutions proposed by the architectural pattern should be extended to support devices using mobile telephone systems (i.e. 3.5G). Acknowledgements. This work was partially supported by Fondecyt (Chile), grants Nº: 11060467 and 1080352 and LACCIR grant Nº R0308LAC005.

References 1. Arnold, K., O’Sullivan, B., Scheifler, R.W., Waldo, J., Wollrath, A.: The Jini Specification. Addison-Wesley, Reading (1999) 2. Avgeriou, P., Tandler, P.: Architectural Patterns for Collaborative Applications. Int. J. of Computer Applications in Technology 25(2/3), 86–101 (2006)

410

A. Neyem et al.

3. Baloian, N., Zurita, G., Antunes, P., Baytelman, F.: A Flexible, Lightweight Middleware Supporting the Development of Distributed Applications across Platforms. In: 11th Int. Conf. on Comp. Supported Coop. Work in Design, Australia, pp. 92–97 (2007) 4. Buschmann, F., Henney, K., Schmidt, D.C.: Pattern-Oriented Software Architecture. A Pattern Language for Distributed Computing, vol. 4. John Wiley & Sons, Chichester (2007) 5. Cugola, G., Di Nitto, E., Fuggetta, A.: The JEDI event-based infrastructure and its application to the development of the OPSS WFMS. IEEE Trans. on Software Engineering 27(9), 827–850 (2001) 6. Ellis, C.A., Gibbs, S., Rein, G.L.: Groupware: some issues and experiences. Communications of the ACM 43(1), 38–58 (1991) 7. Herskovic, V., Ochoa, S.F., Pino, J.A.: Modeling Groupware for Mobile Collaborative Work. In: 13th Int. Conf. on Comp. Supported Coop. Work in Design, pp. 384–389. IEEE CS Press, Chile (2009) 8. Jørstad, I., Dustdar, S., Van Thanh, D.: Service Oriented Architecture Framework for collaborative services. In: 14th IEEE Int. Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprise, pp. 121–125. IEEE Press, New York (2005) 9. Mascolo, C., Capra, L., Zachariadis, S., Emmerich, W.: XMIDDLE: A Data-Sharing Middleware for Mobile Computing. J. on Pers. and Wireless Comm. 21(1), 77–103 (2002) 10. Monares, A., Ochoa, S.F., Pino, J.A., Herskovic, V., Neyem, A.: MobileMap: A collaborative application to support emergency situations in urban areas. In: 13th Int. Conf. on Comp. Supported Coop. Work in Design, Chile, pp. 432–437 (2009) 11. Monson-Haefel, R., Chappell, D.A., Loukides, M.: Java Message Service. O’Reilly & Associates, Sebastopol (2000) 12. Neyem, A., Ochoa, S., Pino, J.: Integrating Service-Oriented Mobile Units to Support Collaboration in Ad-hoc Scenarios. J. of Universal Comp. Science 14(1), 88–122 (2008) 13. Neyem, A.: A Framework for Supporting Development of Groupware Systems for Mobile Communication Infrastructures. Ph.D. Thesis, Universidad de Chile (November 2008) 14. Ochoa, S.F., Neyem, A., Bravo, G., Ormeño, E.: MOCET: a MObile Collaborative Examination Tool. In: Smith, M.J., Salvendy, G. (eds.) HCII 2007. LNCS, vol. 4558, pp. 440–449. Springer, Heidelberg (2007) 15. Ochoa, S.F., Pino, J.A., Bravo, G., Dujovne, N., Neyem, A.: Mobile Shared Workspaces to Support Construction Inspection Activities. In: IFIP Int. Conf. on Collaborative Decision Making (CDM), France, pp. 270–280 (2008) 16. Pinelle, D., Gutwin, C.: A Groupware Design Framework for Loosely Coupled Workgroups. In: 9th Europ. Conf. on CSCW, pp. 65–82 (2005) 17. Russello, G., Chaudron, M., van Steen, M.: An experimental evaluation of self-managing availability in shared data spaces. Science of Comp. Programming 64(2), 246–262 (2007) 18. Schümmer, T., Lukosch, S.: Patterns for Computer-Mediated Interaction. John Wiley & Sons, West Sussex (2007)

Refinement of Software Product Line Architectures through Recursive Modeling Techniques Sofia Azevedo1, Ricardo J. Machado1, Dirk Muthig2, and Hugo Ribeiro3 1 University of Minho, Portugal {sofia.azevedo,rmac}@dsi.uminho.pt 2 Lufthansa Systems, Germany [email protected] 3 Primavera Business Software Solutions, Portugal [email protected]

Abstract. Currently, modeling methods applicable to software product line architectures do not explicitly comprise refinement, which implies dealing with a lot of complexity during their application to a high number of requirements. This paper suggests the extension of a modeling method applicable to product line architectural modeling, the 4SRS (Four Step Rule Set), to support the refinement of product lines. We have used the GoPhone case study to illustrate the approach and the recursion capability of the method as a solution to the challenges of modeling product line architectures. The strength of our approach resides in its stepwise nature and in allowing the modeler to work at the user requirements level without delving into lower abstraction concerns. Keywords: software product line architectural modeling, logical architecture, refinement, recursion.

1 Introduction A logical architecture can be faced as a view of a system composed of a set of problem-specific abstractions supporting functional requirements and it is represented as objects or object classes [1]. In this paper, logical architectures will be represented as component diagrams. The software product line architecture, in the context of this contribute, is the design artifact representing the functionality-based structure of the product line, and embraces both the product line’s reusable components and the foundation from which the architectures of the product line members can be isolated. The non-functional requirements are out of the scope of this paper, although they will have to be considered, most likely through the application of patterns, in moments following the product line logical architecture’s design. Product line architectures can be obtained from functional requirements expressed in use cases with variability exposure [2, 3]. Since use cases can be more or less detailed, architectural components can be refined according to the detail level of the use cases they originate from. But the relation between use case and component is not one-to-one. It may be the case that many components are affected by the refinement of a use case and many more than the original set. R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 411–422, 2009. © Springer-Verlag Berlin Heidelberg 2009

412

S. Azevedo et al.

The refinement of product line logical architectures may be due to two reasons: (1) the addition of detail to the product line logical architecture; and (2) the transition from a phase of user requirements to a phase of system requirements in the product line development. Currently, the modeling approaches that support product line architecture design do not take refinement into consideration at the user requirements level, at the use cases level and in a stepwise way (see Section 2 for evidence to support this statement). Not considering refinement when modeling a product line architecture using a specific product line modeling method, in our case, the 4SRS (Four Step Rule Set) [4], constitutes a problem of complexity in the modeling activity. The pertinence of refinement resides in large-scale contexts, even though we are going to demonstrate our approach to refinement with GoPhone [5], which is of small-scale. Our intention is to expose our contribution and the concepts we want the reader to understand in a straightforward way. In order to circumvent the scale problem, we propose to extend the 4SRS modeling method to support the refinement of product line architectures. The motivation for the extension of the 4SRS is not restricted to addressing a limitation or weakness of the method, rather it is based on an unsolved problem or need in the product line engineering as evidenced by the related work analysis we will present in the next section of the paper. We will address the recursive character of the 4SRS as solution for the refinement. The Fraunhofer IESE’s GoPhone case study presents a series of use cases for a part of a mobile phone product line, particularly concerning the interaction between the user and the mobile phone software. The use cases had to be extended with a variability mechanism for product line modeling. Actors and use cases can be variant if they are not supported by every product of the product family. Variant use cases can be alternative to other use cases or they can be optional (refer to Section From Components to Use Cases for more information on the different stereotypes that can be applied to the use cases). Figure 1a depicts the user level use cases concerning the messaging domain. The remainder of this paper is structured as follows. Section 2 is targeted at describing the strengths of our approach when compared to other approaches. Section 3 describes the 4SRS general approach. Section 4 explains the filtering and collapsing techniques that we use in refinement contexts. Section 5 is dedicated to the technical details on the derivation of use cases from components. Section 6 affords the recursion of the 4SRS. Section 7 provides for some concluding remarks.

2 Related Work There are other approaches to variability modeling besides the 4SRS, such as FODA, KobrA or FAST [6-8]. None of them explicitly approaches refinement through recursion incorporated in the modeling method itself. Smaragdakis and Batory [9] mention refinement in their work on collaborationbased design of large-scale software applications, applicable to the design of product line architectures. In their approach, refinement is achieved through collaborations. In our approach, we use a method that considers user level requirements in the first

Refinement of Software Product Line Architectures

413

place, before dealing with artifacts that would reside in product line conception phases posterior to the product line architecture definition and refinement (artifacts like collaborations). This allows us to work at the level of the user requirements, without having to make finer grained design decisions in the beginning of the product line architecture’s conception.

Fig. 1. Use case diagrams from the GoPhone case study

Working at the level of the user requirements is our strength when comparing our perception to the perception of refinement that also Greenfield and Short [10] and Egyed et al. [11] have. Batory also created a model, the AHEAD model [12], for expressing the refinement of system representations as equations. Despite his approach being based on stepwise refinement, he worked at a code-oriented level. The work we are presenting in this paper allows refining, also in a stepwise manner, software models that shall be handled before code is handled during the software construction phase. Gomaa [13] explored refinement in the context of feature modeling, where a feature can be a refinement of another. But in order to get to the features, use cases have to be modeled and mapped to features. Our approach eliminates the mapping activity. Eriksson et al. [14] have an understanding of refinement similar to the Gomaa’s. PuLSE comprises the refinement of partial product line architectures [15] (a partial product line architecture is a product line architecture that can be popped in the one

414

S. Azevedo et al.

whose refinement originated it; product line architectures going to be refined are also partial product line architectures), but the refinement is not conducted in a stepwise manner. PuLSE’s approach includes testing steps to assure that the architecture supports the requirements from which it was conceived. Ours doesn’t include such kind of steps, yet. Despite that, our approach is stronger than PuLSE’s in allowing the refinement in a stepwise, thus, guided mode. The 4SRS is a method to allow the iterative and incremental model-based transformation of user level functional requirements in the shape of use cases into logical architectures in the shape of component diagrams. Originally, the 4SRS didn’t support variability considerations in the modeling of software systems, which didn’t allow for the method to support product line modeling. But after some extension, that was possible [2].

3 General Principals of the 4SRS Shortly, the 4SRS is composed of the following steps: (1) Component Creation, whose goal is to create three kinds of components for each use case: an interface component, a control component and a data component; (2) Component Elimination, whose goal is to remove redundant requirements and to find missing requirements (this step is vital in order to validate the components blindly created in the previous step and it includes eliminating the components whose requirements are already represented by other components); (3) Component Packaging and Aggregation, whose goal is to semantically group components in packages; and (4) Component Association, whose goal is to introduce associations of components with each other into the component diagram. In the past, the 4SRS has been extended to support tabular transformations in the execution of its steps, as well as some filtering and collapsing techniques to enable the refinement of logical architectures [4]. After that, the method has been extended to support product line logical architecture modeling, which added the notion of variability to it [2]. Our work in this paper is both the conjunction and the prosecution of these previous works on the 4SRS as it will allow for a systematic application of filtering and collapsing techniques for the refinement of product line logical architectures. Software product line architectural modeling (see [1] for an example of a logical architecture representation through models) may be conducted with specific instruments tailored to explicitly expose the variability of the product line, like the 4SRS method with its extension to variability support. Architectural refinement is the approach the 4SRS takes to increment a primary logical architecture with detail (by primary we mean the baseline architecture, the architecture that is going to be detailed). Recursion, in the context of this paper, is the ability of the modeling method to call itself within the process of modeling the architecture. Recursion leads to various executions of the method, an initial architecture and various partial architectures. The number of partial architectures is equal to the number of executions minus one. According to what was just stated, the method can be applied to product line architectural modeling. As depicted in Figure 2, the 4SRS may be applied recursively, in several executions. In the context of each one of those executions, various iterations can be performed. Although there is no stopping rule for iterating over the same use case diagram, it can be performed until the results obtained generate a logical architecture that does not benefit from additional iterations in terms of the

Refinement of Software Product Line Architectures

415

elimination of redundant requirements, the finding of missing requirements and the increasing of the cohesion of the logical architecture itself. In the case of refinement (by recursion), when one of the executions is considered to be finished by the modeler, the output of that execution’s last iteration is going to be transformed into the input of the subsequent execution’s first iteration. The task flow of the new execution is exactly the same as the task flow of the preceding one. Again, in the case of refinement (by recursion), the logical architectures the various executions produce over time are situated in lower levels of abstraction and cover less functionality than their preceding ones. Roadmap of the Extension We divided the extension of the 4SRS to product line architecture refinement into two parts: before the method execution and during the method execution. Before the recursive execution of the 4SRS, three steps must be performed: (1) the filtering and collapsing; (2) the derivation of use cases from components; and (3) the detailing of use cases. The following is the new sequence of steps for the 4SRS: (1) Component Creation; (2) Component Elimination; (3) Component Packaging and Aggregation; (4) Component Association; (4+1) Filtering and Collapsing; and (4+2) From Components to Use Cases. The first four steps are the original steps and the other ones are what we call the new intermediate steps, which are performed in between executions of the 4SRS. We have extended step 4 of the 4SRS with rules for the association of components with each other, based on the inclusion and the extension of use cases, as well as on the categorization of components, according to the interface-control-data heuristic, performed when they are created in step 1.

Fig. 2. Schematic representation of the recursive execution of the 4SRS

416

S. Azevedo et al.

4 Filtering and Collapsing We use techniques of filtering and collapsing in between executions of the 4SRS to achieve the refinement of the input product line logical architecture. The filtering is about allowing subsystem partitioning for further subsystem design and specification. The collapsing is about defining the border of the subsystem whose components are going to be refined. Later on, those components will be replaced, inside the limits of that same border, by others of lower abstraction level or higher detail level. The filtering is what we, in the current work, call the selection of components. This selection is concerned with choosing the components that shall be the input for the subsequent recursive execution of the 4SRS. Earlier, the filtering activity of the 4SRS consisted of considering some components as the subsystem for refinement and discarding those that were not related to them [4]. Now, in this work, the same applies, but we have systematized the choice of the most adequate components for refinement. Components can be classified into filtering types: (type 1) the components to which we may apply refinement; (type 2) the components to which we cannot apply refinement; and (type 3) the components that we are actually going to refine. The components in Figure 3 that have a white background are of type 1, whereas the ones marked with a cross are of type 2 and the ones with a grey background are of type 3. Components originated from use cases not marked with the stereotype «variant» (consider that this stereotype has been omitted from included use cases) have been classified as type 2 components. From the remaining components, the ones originated from decomposable use cases (those use cases not marked with the stereotype «final»; decomposable use cases cannot be either included use cases or extension points that cannot be decomposed any further) that are simultaneously leaf use cases have been classified as type 3 components. Despite type 2 components being originated from leaf use cases, they are neither longer refinable through inclusion relationships, nor through extension relationships at the use cases level. From the type 1 and the type 3 components, the type 1 components can be «final», therefore, not decomposable, or they can be not leaf use cases, which means that they are no longer extendable. Therefore, the reduction of the components to the selected ones is very much coupled with the decomposition extension capacity of the requirements they represent. For instance, the component {C 0.1.1.1e1.i} Phone Number from Address Book Choice UI, from Figure 3, originated from the use case {U 0.1.1.1e1} Choose Phone Number from Address Book, in Figure 4, has been classified as of type 2, since that use case has not been tagged with the stereotype «variant», which makes of it a variant use case. After the filtering is performed, the result obtained is the diagram in Figure 5. Only the type 3 components, along with the component which is associated with them (in this case it is only one) appear in the figure. The actor that relates to all the components is also represented in the diagram. Earlier, the collapsing activity of the 4SRS was about hiding package details [4]. Currently, in this work, the same applies with no change. As we can see from Figure 6a, the collapsed diagram is an evolution of the filtered diagram in Figure 5, as it presents a subsystem in place of the once classified as type 3 components. As the components have been removed from the subsystem to refine, the associations

Refinement of Software Product Line Architectures

417

between the component {C 0.1.2.i} Message Composition UI and those components have been removed as well and replaced by two interfaces, one for each of the components. The new components that will be placed inside the borders of the subsystem will have to comply with those interfaces.

Fig. 3. Component diagram, which resulted from the first execution of the 4SRS, with variability support, to the Send Message use case of the GoPhone case study, while being filtered

Fig. 4. Choose Recipient extension points

418

S. Azevedo et al.

Fig. 5. Filtered component diagram with regards to the object insertion and object attaching functionalities of the Send Message use case from the GoPhone case study

Fig. 6. a) Filtered and collapsed diagram for object insertion and attaching; b) Use case diagram for the first recursive execution of the 4SRS

5 From Components to Use Cases This intermediate step is composed of two intermediate substeps. The goal of the first one, the Deriving Use Cases from Components, is to derive, from the component diagram, the use cases to hand out as input for the succeeding recursive execution of the 4SRS. This is an important procedure as it will define the use cases that will feed the refinement process. These use cases are an expression of the requirements that the architecture of the subsystem defined in the collapsed diagram must represent. The components that survived the selection process were the {C 0.1.2e3.i} Object Insertion UI and the {C 0.1.2e4.i} Object Attaching UI. A use case diagram with the use cases derived from the components is depicted in Figure 6b. The use cases in the subsystem were defined taking into consideration the descriptions of the components that survived the selection process (those descriptions were elaborated during the execution of the prior step 2 from the 4SRS). It was concluded that there was no need to create new actors, based on those descriptions, so, the component which was associated with the subsystem in the collapsed diagram of Figure 6a is the only actor in the use case diagram of Figure 6b. The goal of the second intermediate substep, the Detailing Use Cases, is to elicit, from the use cases in the diagram in Figure 6b, the inclusion and extension relationships that will further on steer the recursive execution of the 4SRS. The use cases must be detailed in order for them to be decomposed through inclusion relationships. After determining the included use cases, they are analyzed in terms of

Refinement of Software Product Line Architectures

419

extension points, which originate the extending use cases. Next, we have to materialize, by means of diagrams, the inclusion and extension relationships. The result is going to be a use case model with the use case diagram in Figure 6b and another use case diagram for each one of the use cases in it with its included and extending use cases. Comparing the description of the use case Send Message in Figure 7 and the description of the use case Insert Object in Figure 8, we can see that the last one is the detailing of the three alternatives the step 7 comprised in the Send Message’s description. The step 7 of the Send Message’s description is the one that gave origin to the use case {U 0.1.2e3} Insert Object. 1. The user chooses the menu item to send a message. 2. The user chooses the menu item to start a new message. 3. The system may ask the user which kind of message he wants to send. 4. The system switches to a text editor. 5. The user enters the text message. 6. If T9 is supported and activated, the system compares the entered word with the dictionary. 7. Which kind of objects can be inserted into a message? The user can insert a picture into the message. The user can insert a picture or a draft text into the message. ø 8. The user may attach objects to a message. 9. The user chooses the menu item to send the message. 10. The system asks the user for a recipient. 11. The user chooses the recipient. 12. The system connects to the network and sends the message, then, the system waits for an acknowledgement. 13. The network sends an acknowledgement to the system. 14. The system shows an acknowledgement to the user that the message was successfully sent. 15. The system saves the message in the sent messages folder, directly or upon user request. 16. The system switches to the main menu.

Fig. 7. Send Message use case textual description 1.

Which kind of objects can be inserted into the message? The user can insert a picture into the message 1.1. The system shows the user a browsable directory of folders and/or picture files 1.2. The user browses the directory and selects a picture from it 1.3. The picture is inserted into the message and displayed to the user in the message area The user can insert a picture OR a draft text into the message The user chooses to insert a picture into the message 1.1. The system shows the user a browsable directory of folders and/or picture files 1.2. The user browses the directory and selects a picture from it 1.3. The picture is inserted into the message and displayed to the user in the message area The user chooses to insert a draft text into the message 1.1. The system shows the user a list of draft texts 1.2. The user browses the list and selects a draft text from it 1.3. The draft text is inserted into the message and displayed to the user in the message area The user cannot insert any object into the message

Fig. 8. Detailing of the use case Insert Object

420

S. Azevedo et al.

For instance, after analyzing the first two alternatives of Send Message’s step 7, we see that they have a common part, the insertion of a picture, which can be performed in each one of the alternatives. Hence, we repeated the detailing of the picture insertion in the detailing of alternatives 1 and 2. We have also divided the detailing of alternative 2 into the detailing of the picture insertion and of the draft text insertion, since these are functionalities of alternative 2 separated by a logical operator (OR). We are excluding the third alternative as there is no functionality attached to it. When detailing the functionalities of picture insertion and of draft text insertion, a common verbal expression emerged: display. The display object functionality is extendable by the display picture and the display draft text functionalities and included in the insert object functionality. Figure 9 illustrates a diagram of the object insertion functionality. The following stereotypes must be applied to the use cases, which are going to be the input for the recursive execution of the 4SRS, according to the following rules: (1) «mandatory», applicable to the use cases present in all product line members and to the inclusion relationships; (2) «alternative», applicable to the extending use cases; (3) «optional», applicable to the extending use cases as well, but only when the requirement may not exist or the use case may not be performed in the product line member; (4) «final», applicable to the included use cases and to the extension points that cannot be decomposed any further; and (5) «variant», applicable to the use cases which functionality can vary between the product line members.

6 The Recursive Execution of the 4SRS The goal of the recursive execution of the 4SRS is to actually apply the 4SRS after one or more executions of this modeling method have occurred beforehand. This process is about applying the tabular transformations 4SRS is composed of, as already explained in [4], to the target use cases. The result will be a list of components that shall be associated with each other. The association of components with each other can be an automatic process, based on predefined rules directly related to the inclusion and the extension relationships established between the use cases the components originate from. Hence, it is possible to systematically generate associations between components in the component diagram from the relationships established between the use cases in the use case diagram, as suggested in [2]. The value of this generation lies in the possibility of verifying the consistency of the component diagram with the system’s functional requirements, as well as of avoiding too many iterations to each one of the executions of the 4SRS. Taking figures 1c, 3 and 4 as an example, the component {C 0.1.2.i} Message Composition UI, originated from the use case {U 0.1.2} Compose Message, is associated with the component {C 0.1.2e1.i} Message Type Selection UI, originated from the use case {U 0.1.2e1} Select Type of Message. In the use case diagram, these two use cases are connected through an extension relationship. Consider the existence, for a single use case, of all the three corresponding components resulting from the 4SRS’ categorization, i, c and d. They shall always be connected in this order: the i component to the c and the c to the d. The resulting artifact from the execution of the 4SRS with refinement to the Send Message functionality of the GoPhone case study is the component diagram in Figure 10. This diagram has, then, to be integrated into the logical architecture the preceding execution of the 4SRS originated.

Refinement of Software Product Line Architectures

421

Fig. 9. Insert Object decomposition and included use case’s extension points

Fig. 10. Component diagram resulting from the recursive execution of the 4SRS

7 Conclusions The 4SRS considered refinement in past works, yet, so far, there hasn’t been any experimentation on the systematization of its recursive execution. The relevance of the exercise we presented in this paper resides on the demonstration that a modeling method is capable of dealing with the refinement of product line logical architectures systematically, which gains acute importance in the context of a high number of functionalities. With its extension, the 4SRS provides, now, for specific guidelines for modeling functional requirements when refining product line architectures. Besides the extension of a modeling method, we have worked on filtering and collapsing techniques in order to prepare the recursive execution of the modeling method over product line architectures. We were guided by the belief that not all components of product line architectures need refinement. We strongly believe that stepwise methods for the modeling of product line architectures would have a significant impact on the execution effort of some of their steps, if refinement was taken into account.

422

S. Azevedo et al.

References [1] Kruchten, P.: Architectural Blueprints - The "4+1" View Model of Software Architecture. IEEE Software 12, 42–50 (1995) [2] Bragança, A., Machado, R.J.: Deriving Software Product Line’s Architectural Requirements from Use Cases: An Experimental Approach. In: 2nd International Workshop on Model-Based Methodologies for Pervasive and Embedded Software (MOMPES 2005), Rennes, France. TUCS General Publications (2005) [3] Bragança, A., Machado, R.J.: Extending UML 2.0 Metamodel for Complementary Usages of the «extend» Relationship within Use Case Variability Specification. In: 10th International Software Product Line Conference (SPLC 2006), Baltimore, Maryland, USA. IEEE Computer Society, Los Alamitos (2006) [4] Machado, R.J., Fernandes, J.M., Monteiro, P., Rodrigues, H.: Transformation of UML Models for Service-Oriented Software Architectures. In: 12th IEEE International Conference and Workshops on the Engineering of Computer-Based Systems (ECBS 2005), Greenbelt, Maryland, USA. IEEE Computer Society, Los Alamitos (2005) [5] Muthig, D., John, I., Anastasopoulos, M., Forster, T., Dörr, J., Schmid, K.: GoPhone - A Software Product Line in the Mobile Phone Domain. Fraunhofer IESE, IESE-Report No. 025.04/E (March 5, 2004) [6] Kang, K., Cohen, S., Hess, J., Novak, W., Peterson, A.S.: Feature-Oriented Domain Analysis (FODA) Feasibility Study, Software Engineering Institute, Carnegie Mellon University, Technical Report (1990) [7] Atkinson, C., Bayer, J., Muthig, D.: Component-Based Product Line Development: The KobrA Approach. In: 1st Software Product Line Conference (SPLC 2000), Denver, Colorado, USA. Kluwer Academic Publishers, Dordrecht (2000) [8] Weiss, D.M.: Commonality Analysis: A Systematic Process for Defining Families. In: van der Linden, F.J. (ed.) Development and Evolution of Software Architectures for Product Families. LNCS, vol. 1429, pp. 214–222. Springer, Heidelberg (1998) [9] Smaragdakis, Y., Batory, D.: Mixin Layers: An Object-Oriented Implementation Technique for Refinements and Collaboration-Based Designs. ACM Transactions on Software Engineering and Methodology 11, 215–255 (2002) [10] Greenfield, J., Short, K.: Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools. Wiley, Indianapolis (2004) [11] Egyed, A., Mehta, N., Medvidovic, N.: Software Connectors and Refinement in Family Architectures. In: 3rd International Workshop on Development and Evolution of Software Architectures for Product Families (IWSAPF-3), Las Palmas de Gran Canaria, Spain. Springer, Heidelberg (2000) [12] Batory, D., Sarvela, J.N., Rauschmayer, A.: Scaling Step-Wise Refinement. IEEE Transactions on Software Engineering 30, 355–371 (2004) [13] Gomaa, H.: Designing Software Product Lines with UML: From Use Cases to PatternBased Software Architectures. Addison-Wesley, Boston (2004) [14] Eriksson, M., Börstler, J., Borg, K.: Software Product Line Modeling Made Practical. Communications of the ACM 49, 49–53 (2006) [15] Bayer, J., Flege, O., Gacek, C.: Creating Product Line Architectures. In: 3rd International Workshop on Development and Evolution of Software Architectures for Product Families (IWSAPF-3), Las Palmas de Gran Canaria, Spain. Springer, Heidelberg (2000)

Designing and Supporting Cooperative and Ubiquitous Learning Systems for People with Special Needs Álvaro Fernández López, María José Rodríguez Fórtiz, and Manuel Noguera García GEDES Research Group, Departamento de Lenguajes y Sistemas Informáticos, University of Granada, E.T.S.I. Informática y de Telecomunicación C/ Periodista Daniel Saucedo Aranda s/n, 18014 Granada, Spain {alvarofernandez,mjfortiz,mnoguera}@ugr.es

Abstract. Cooperative work in schools helps students to learn behaviour norms, tolerate their partners and educators, and make decisions or accept the decisions from other people. In case of students with cognitive disabilities, cooperative work contributes to the socialization of the students by improving the communication and the integration in the classroom. New technologies foster guided and cooperative learning through didactic exercises and educational activities that adapt the educative context to user's needs and abilities. For this objective, the design must take into account non-funcional requirements for provide a future adaptation. This paper presents the design of one of such systems and the main decisions made in order to improve usability, adaptation, flexibility, and accessibility in ubiquitous spaces of it. The general architecture of the system and the platform that supports the development process of its software for educational activities are described in a real case study. Keywords: Disability, Adaptation to User Impairments, Mobile Devices, Social Integration, Cooperative Learning, Adaptive Technologies.

1 Introduction End users must be considered from the early phases of software development. The design of applications for users with (special) educative needs and/or cognitive, sensorial or mobility impairments must take into account non-functional requirements, such as accessibility, usability, flexibility and adaptability to be obtained from a deep analysis of the system. Accessibility and usability policies call for the design of easy-to-use applications, ensuring that the users can interact with them and understand the tasks to be accomplished, and also the response of the system. Due to the fact that users may have different abilities, capacities and needs, tools must be flexible in order to adapt to different users. Configuration of applications allows their personalization in order to create customized applications for specific users from a generic design. Regarding educative applications, students with special needs special have requirements of autonomy, communication, socialization and cognitive increase. R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 423–432, 2009. © Springer-Verlag Berlin Heidelberg 2009

424

Á. Fernández López, M.J. Rodríguez Fórtiz, and M. Noguera García

Cooperative learning contributes to these aspects by providing [1][2]: • • • • •

Opportunities to do, to say and to feel. Self-regulation and group regulation. Models to be imitated: e.g. the educator and their classmates. Constant positive backing. Development of social, cognitive and affective abilities.

At a cognitive level, the main difficulties of these students are perception, memorization and attention [3]. Didactic exercises help to improve these aspects because they are the basis of learning. Several interactive environments such as learning and teaching tools have been developed, for example: • VTech [4] has commercialized multiple products that combine entertaining electronic formats and engaging contents that help children learn. However, these products are not targeted at children with special needs. • Clic [5] is an environment that allows the creation of individual activities, but it only runs on desktop computers. • Some learning applications have been developed for the iPhone system: iWriteWords [6] teaches children handwriting while playing an entertaining game; Proloquo2Go [7] is a product that provides a communication solution for people who have speaking difficulties. These applications are designed for individual use only and they are not configurable. None of the just mentioned systems propose an adaptive approach that takes into account professional directives in an educational context and user specific needs, neither provides mobility capabilities together with functionalities for cooperative work. During the last years, we have been working on applications for users with special needs, in concrete the Sc@ut Project [8]. This project consists of a platform to create adapted, ubiquitous, augmentative and alternative communication systems for people with communication problems (Fig. 1).

Fig. 1. Sc@ut Communicators for Pocket PC and NintendoDS

Based on this platform and on our experience in the requirements elicitation of this kind of users, we have devised a new platform to design educative applications for users with special needs [9]. The objective is to create individual and cooperative didactic exercises, which can be personalized at content and user interface levels through a design mainly centred on user requirements. Furthermore, in order to facilitate the participation of families and professionals during the learning process,

Designing and Supporting Cooperative and Ubiquitous Learning Systems

425

we improve the ubiquity of the learning platform by enabling it to run in mobile devices, specifically the iPod touch and iPhone devices. Section 2 shows the characteristics of the platform. The advantages provided by the selected mobile devices are described in Section 3. Section 4 presents conclusions and future work.

2 An Interactive, Cooperative and Ubiquitous Learning Platform Our research aims to promote the set-up of mobile applications in order to complete the more traditional psychological and educational procedures by offering a platform to support the learning process in the classroom. For this aim, we have designed a platform called picao (Interactive and Cooperative Platform to Support Learning). The objective is integrating in a single application features that allows children and experts (or teachers) to interact with different elements, according to the actions they will carry on and the educational approach (Fig. 2): • Teachers or educators will be able to design personalized learning exercises for people with special needs and impairments. • Students may perform the exercises cooperatively in order to increase their socialization and improving the learning process, and may do it anywhere thanks to use of mobile devices.

Fig. 2. System architecture

More innovating factors of the platform are: • It is designed like a mobile platform, following an approach where activities run on entertainment mobile devices that turn out to be more attractive to users. Moreover, mobility gives the chance to new interaction alternatives with physical

426

Á. Fernández López, M.J. Rodríguez Fórtiz, and M. Noguera García

objects and new mobile devices’ accelerometer built-in lets systems to react to movements and rotations of devices, allowing innovative interactions. • It provides support for group work, fostering integration and interaction with other students. • It has the capability of user adaptation: learning activities must be sufficiently flexible to adapt to the characteristics of each user and integrate the personal data of his own world, respecting his own work pace, and can be modified by educators according to user progress or changes in his environment. User adaptation is based on the model obtained from the observation of user interactions, the knowledge of therapists and our previous experience developing software for people with special needs [4]. We have analysed which aspects from the activities can be personalized (at individual and group level) and designed the applications to support the adaptation to the users at run time. Our approach aims to bring flexibility and adaptability in the education of children with special needs. Taking into account all previously mentioned requirements, we have devised a modular system architecture on the basis of a separation of concerns intended to facilitate the system design and implementation. The subsystems of the platform are related to the process followed by educators to create exercises and the support of the execution. They are (see Fig. 2): • • • • • •

User profile designer subsystem. Generic exercise designer subsystem. Personalization subsystem. Construction and use of exercises subsystem. Communication subsystem. Evaluation subsystem.

2.1 User Profile Designer In order to make a design centred on the users, their impairments, abilities, skills and capabilities must be determined. Contents to be taught in the exercises, awareness information (for cooperative use), structure and user interface of the applications are adapted depending on such requirements in order to get accessible applications. As each person is different, with limitations and needs at different levels, his/her singularities are to be considered by defining his/her user profile [10]. Table 1 shows which adaptations are necessary for different kinds of limitations (e.g., sensorial, cognitive or mobility impairment). Educators and families must fill a template to determine what specific adaptations are necessary for each user. As a result of this process, a XML specification capturing the user profile is generated. The sample template in Table 1 shows an example that includes questions about colours, size, contrast and magnification of pictures to be used in the exercises and whether the use of subtitles is necessary. Educators may also choose the best interaction mode from several types available taking into account user

Designing and Supporting Cooperative and Ubiquitous Learning Systems

427

Table 1. Example of a user profile template User Adaptations limitations Visual Colors, size, contrast, magnification. Do not use color as information Conversion of graphical information to text and use of synthesis of voice User interface components accessible by means of mouse or keyboard Hearing Alert sounds coded as text or graphic Adapted vocabulary Use of subtitles and language of gestures Mobility Adapted input and output devices Alternative selection of components (alt-keys, voice as input, scrolling,…) Time of scrolling, time for user selection, pace of the application Cognitive Simple interface without distracting elements Prioritary use of graphics

Example of personalization required for a specific user profile Multimedia: Exercises require big figures, without colour.

Multimedia, Interaction: Reinforcement by means of gesture language. Interaction: User interaction must be tactile, without pen or stick.

Multimedia, Interaction: No more than 4 images in the screen to be selected. Multimedia: Images must be pictograms, no photos. Awareness: Use of a pictogram to advertise when is his turn during cooperative work

mobility, cognitive level and sensorial capabilities. The educator decides, using the template, the characteristics that he/she thinks that are ideal for the user. If the exercises are tried but they do not meet user needs, the educator may use the template in order to perform changes in the user profile, and thereby adapting the exercise to the new profile. 2.2 Generic Exercise Designer The platform allows defining three kinds of exercises to be performed by the users that we have chosen in order to cover the main learning task prompts [11]. These kinds of activities are: • Association: the student must indicate relationships between elements (components) that belong to several sets. This activity covers exploratory task. • Puzzle: a decomposed image must be rebuilt from multiple pieces (components). Number, size and shape of pieces can be configured. It covers relational, cause and effect and interpretation tasks. • Exploration: navigation-based histories that let students learn concepts through the navigation of a hypermedia system with components (Fig. 3). This activity covers next learning tasks: action, priority, extension and examine assumptions.

428

Á. Fernández López, M.J. Rodríguez Fórtiz, and M. Noguera García

Fig. 3. Exploration activity: touching an element causes it to be rendered in full screen size. Touching a second time or shaking the device an associated sound is reproduced.

Using a template, the educator must select a kind of exercise and determine some aspects of it: number of components or concepts to be taught, screen composition, screen position (rotation or not), multimedia used to represent the components, difficulty level (goals of the exercise, calculus of the punctuation), reinforcements and helps to the users. Additionally, some rules to be considered during the performing can be defined as, for instance, the order to be followed when selecting components. If the learning exercises are going to be performed in a cooperative way, other characteristics must be specified (using a template to facilitate the task to the educator): the number of participants, the obligation or not of participation of all the users, if orderly turns are established or if the users can perform the exercise simultaneously, and the kind of awareness (context information) to be shown to the user. Goals and punctuation of the exercise when a group performs it must be also defined. The final result is a XML specification containing all of these aspects. 2.3 Personalization This subsystem generates XML specifications that can be used by the construction subsystem to personalize specific exercises modifying: • Multimedia, interaction and awareness (see example in Fig. 4). • Aspects relative to the exercise: components, difficulty, reinforcements, etc. • Characteristics of cooperation: participants, turns, etc. Personalization allows the creation of customised applications for specific users. 2.4 Construction and Use of Exercises From the generic exercises, specific exercises are constructed automatically, adapting the multimedia used, the interaction type and the awareness information to the user profile characteristics. Then, the personalization subsystem, varying some aspects more as we have seen above, can personalize the specific exercises.

Designing and Supporting Cooperative and Ubiquitous Learning Systems

429

Fig. 4. A same exercise running with different personalisation according to users needs

Fig. 4 shows two different versions of the same application generated for two different users from the same generic exercise. The exercise consists in associating animals with their natural environments. Differences between components, multimedia used and awareness information can be observed. For example, the application on the left hand side of Fig. 4 makes use of a landscape layout, while the one shown on the right hand side displays all the interface elements using the portrait mode. The interaction is also different: the first user must drop the animal component on its natural environment. The second one has limited mobility and is not able to displace his/her finger on the screen. He/she would only need to touch each component in order to associate one another. Backgrounds are also different to stimulate or not to distract the user. Awareness information about which users are playing and their punctuation is not shown to the second user in order to avoid he/she could head off and misinterpret it. Other differences are the multimedia used in the components (the first one needs pictograms instead of text because the user has difficulties to read), the number of concepts and the difficulty of the exercise, which are higher in the second one (perhaps because his/her cognitive level is higher). 2.5 Communication Cooperative learning requires appropriated communication mechanisms that allow students to interchange information; and coordination services so as to support group work in a same activity. Establishment of sessions (Fig. 5) offers a useful way to allow users to cooperate with each other. Peer-to-peer connectivity allows applications to create an ad-hoc Bluetooth or WiFi network between multiple mobile devices, providing ubiquity. Several copies of the application running on multiple devices may discover each other and exchange information, providing a simple and powerful way to perform activities in group. Furthermore, context information as the user location, time or state of the exercise (e.g., punctuation, objectives reached, etc.) can be used to decide how the exercise may be performed. For example, the application could get the number of students that are in a specific classroom and synchronize them in order to cooperatively perform an appropriate exercise for that classroom and time-slot.

430

Á. Fernández López, M.J. Rodríguez Fórtiz, and M. Noguera García

Fig. 5. WiFi or Bluetooth networking between applications

During the accomplishment of the task, information about students’ actions is propagated so as to provide feed-through. Feed-through concerns implicit information delivered to several users reporting actions executed by one user [12]. A very simple way to generate feed-through consists in multiplexing feedback information to several users [13]. Feed-through (Fig. 6) is essential so as to provide group awareness and construct meaningful contexts for cooperation.

Fig. 6. Information flows while an activity is performed in group

2.6 Evaluation This subsystem allows the log of user interactions with two purposes: • Help the educator to evaluate the user progress along time or the accomplishment of an exercise at run time. • Detecting automatically anomalous behaviours of the users. This can be used to adapt the applications to fit better to the users at run time or in future executions.

Designing and Supporting Cooperative and Ubiquitous Learning Systems

431

3 iPod Touch and iPhone Advantages Apple’s IPod touch and iPhone have been the selected devices for implementing the learning applications. Their main features are: • Mobility and desing: they provide portability necessary. Using integrated GPS and digital compass it is possible to know spatial position and orientation and make decisions according to this context information. Besides, their minimalist design (include only a frontal button) makes user acceptation easier. • Touch screen: the iPhone is the first fully finger-based (rather than stylus-based), multi-touch mobile. It has high quality responsiveness thanks to the incorporation of a capacitive touch screen and can detect interactions by means of gestures. • Interaction through motion: a built-in accelerometer detects the movement when a user rotates device from portrait to landscape and changes the display accordingly. Rotations or shakes can also be interpreted like a user input. • Accessibility: devices feature higher contrast function, zoom and a gesture-based screen reader. • Connectivity: Peer-to-peer connectivity using Apple Bonjour Services [14] allows applications to create an ad-hoc Bluetooth or WiFi network in group.

4 Conclusions and Future Works The use of mobile technologies and multimedia increases the interest of students, helping them to learn while they are entertaining. In the case of students with impairments, learning exercises must be individualized in order to meet their special needs. In this context, educators usually intervene during the learning process as qualified experts in order to foster the unfolding of their students’ capabilities. Educators are to prepare the exercises to be carried out, personalize them, and supervise and guide students during their accomplishment. With the objective of facilitating the use of the technology in class, we have designed a single application which runs in mobile devices and which is firstly used by the educators to create and modify exercises when they desire, and then, by the students to learn while carrying out such exercises. The mobility and connectivity functionalities of the devices to be used enable the cooperative achievement of the exercises in ubiquitous spaces, promoting the participation of the stakeholders in the learning process and the socialization of the students. We have selected a concrete device with recognized ease of use and accessibility required by this group of users and their educators, and supports communication and mobility. An architecture composed of several subsystems has been proposed in order to separate these concerns and following different phases in the design and use of the application: User profile design, Generic exercise design, Personalization, Construction of exercises, Communication and Evaluation. We are participating in a national project with several schools of Especial Education, which are collaborating with us. Their professionals are eliciting requirements that are being addressed in our specifications, design and prototypes. Prototypes allow functional and non-functional requirements to be specified, completed and validated. Up

432

Á. Fernández López, M.J. Rodríguez Fórtiz, and M. Noguera García

to now, we are obtaining encouraging results. We plan to finalize the implementation and undertake a study with a selected group of users the next year. This will allow the benefits of our platform to be evaluated and suggestions from families and professionals to be obtained in order to improve it. Acknowledgments. The University of Granada (CICODE) and the Spanish Government’s Ministry of Science and Innovation have funded this research via the project TIN2008-05995/TSI.

References 1. Johnson, D.W., Johnson, R.T., Stanne, M.B.: Cooperative Learning Methods: a Metaanalysis (2000), http://www.clcrc.com/pages/cl-methods.html 2. Smith, K.A.: Cooperative Learning: Making “Group Work” Work. New Directions for Teaching and Learning. Jossey-Bass, San Francisco (1996) 3. Barkley, E.F., Cross, K.P., Major, C.H.: Collaborative Learning Techniques. John Wiley, San Francisco (2005) 4. Clic Zone: Resources and information about Clic., http://clic.xtec.cat/es/index.htm 5. V-Tech., http://www.vtech.com/ 6. iWriteWords handwriting game, http://www.ptgdi.com/gdiplus/iWriteWords/ 7. Proloquo2go communication system, http://www.proloquo2go.com/ 8. Rodríguez-Fórtiz, M.J., González, J.L., Fernández, A., Entrena, M., Hornos, M.J., Pérez, A., Carrillo, A., Barragán, L.: Sc@ut: Developing Adapted Communicators for Special Education. Procedia - Social and Behavioral Sciences 1(1), 1348–1352 (2009) 9. Fernández López, A., Rodríguez Fórtiz, M.J., Bermúdez Edo, M.J., Noguera, M.: Improving the Cooperative Learning of People with Special Needs: A Sc@ut Platform Extension. In: Research, Reflections and Innovations in Integrating ICT in Education. Formatex Research Center, Lisboa (2005) 10. Rights and Dignity of Persons with Disabilities, http://www.un.org/disabilities 11. Ferreiro, R.: Estrategias Didácticas del Aprendizaje Cooperativo. El Constructivismo Social: una Nueva Forma de Enseñar y Aprender. Eduforma, Sevilla (2006) 12. Hill, J., Gutwin, C.: Awareness Support in a Groupware Widget Toolkit. In: Proceedings of the 2003 international ACM SIGGROUP Conference on Supporting Group Work, Sanibel Island, pp. 258–267. ACM Press, New York (2003), http://hci.usask.ca/publications/2003/maui-group03.pdf 13. Ferreira, A., Antunes, P., Pino, J.A.: Evaluating Shared Workspace Performance Using Human Information Processing Models. Information Research - An International Electronic Journal 14(1) ( March 2009) 14. Apple Bonjour Technology, http://www.apple.com/bonjour

Software System Understanding via Architectural Views Extraction According to Multiple Viewpoints Azadeh Razavizadeh1, Sorana Cˆımpan1 , Herv´e Verjus1 , and St´ephane Ducasse2 1 University of Savoie, LISTIC Lab, France INRIA Lille-Nord Europe, RMoD Team, France {razavizadeh,verjus,cimpan}@univ-savoie.fr

2

Abstract. Changes and evolution of software systems constantly generate new challenges for the recovery of software systems architectures. A system’s architecture, together with its elements and the way they interact, constitute valuable assets for understanding the system. We believe that offering multiple architectural views of a given system, using domain and pattern knowledge enhance understanding of the software system as a whole. To correlate different sources of information and existing software system, different viewpoints are considered. Viewpoints enable one to model such information and guide the extraction algorithms to extract multiple architectural views. We propose a recursive framework, an approach that expresses different kinds of information as viewpoints to guide the extraction process. These multiple viewpoints models improve the consideration of architectural, conceptual, and structural aspects of the system.

1

Introduction

Software systems need to evolve over time [15]. They get modified to improve their performance or change their functionality in response to new requirements, detected bugs, etc. Some changes are part of the system maintenance; others evolve the system, generally by adding new functionalities, modifying its architecture, etc. Thus, there are several evolution phases for which different processes may be employed. The evolution process ideally begins with the system comprehension and continues with finding a suitable set of system modifications. It has been measured that in maintenance and evolution phases, at least half of the engineers’ time is spent on the system comprehension [7]. Thus, to successfully evolve a complex system, it is essential to understand it. The understanding phase is time and effort consuming, due to several reasons, among which: the system size (large systems consist of millions lines of code), lack of overall views of the system, its previous evolutions (not necessarily documented), etc. This motivates us on supporting the software system understanding phases. Architectures serve thus as education means [1] and guide software evolution, by providing a high-level abstract model of existing software systems. Software R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 433–442, 2009. Springer-Verlag Berlin Heidelberg 2009

434

A. Razavizadeh et al.

architecture reconstruction is a reverse engineering approach that aims at reconstructing viable architectural views of software applications [7]. We focus on extracting architectural views of existing software systems. It is widely accepted that multiple architectural views are useful when describing the software architecture [13][5][1]. Many approaches focused on providing high abstraction level views in order to facilitate program understanding [11][8] [19]. Architecture relevant information can be found at different granularity levels of given systems and needs to be studied from different viewpoints. A viewpoint is a collection of patterns and conventions for constructing one type of view. It reflects stakeholders concerns and guides the construction of views [10]. We consider different viewpoints according to such concerns: business-based, pattern-based, cohesion-based, activity-based, etc. The main contributions of the proposal presented in this paper are a recursive framework for extracting architectural views and an enhanced definition or architectural viewpoints allowing their modularity and reuse. Structure of the paper: In the next section, we propose a recursive framework and its extraction process. Section 3 presents architectural viewpoints composed of viewpoint model and viewpoint extraction algorithm. Section 4 presents the architectural view. In Section 5, we use an example to illustrate our approach. Section 6 presents related work and the paper closes in section 7 with a conclusion.

2

A Recursive Framework

We adopt a generic and recursive framework (Figure 1) for extracting architectural views: at each recursion of the framework, a specific view is extracted (also results) from another view, using a guiding viewpoint. Our framework is reproductible by chaining horizontal and/or vertical recursions of the framework. – horizontal recursion: starting from a given architectural view (often the implementation view but other views can be considered) other architectural views can be elaborated, each based on a specific viewpoint; – vertical recursion: architectural views are organized in a pipe-line style, such that the output (view) of an extraction recursion is used as an input (view) for another one. Each horizontal or vertical recursion corresponds to an instance of the generic framework and thus extracts a new architectural view using a specific viewpoint. An extraction process corresponds to the recursive framework application: an architectural view that is extracted from a view given as input of an extraction process is considered as the view generated by the framework. Several views may be extracted from a given view, using different viewpoints. The recursive framework application always begins with the generation of an implementation view. This recursion re-engineers (using the Moose [6] re-engineering environment) the software system from its source code and produces a Famix model as an implementation view : it consists in generating an (architectural) implementation view of the source code (i.e., flat files containing the source code expressed in a OO Programming Language). This implementation view is composed of architectural

Software System Understanding via Architectural Views Extraction

435

Fig. 1. The recursive framework principle

elements such as classes, methods, and packages. Using this view as input, architectural views can be generated by horizontal recursions. Further on, generated architectural views can be used as input for vertical cascading of the framework (Figure 3). Thus, for obtaining an architectural view, at least two recursions of the framework are needed. The following section will present architectural viewpoints.

3

Architectural Viewpoints

The IEEE standard definition of viewpoints (previously presented) is the fundamental concerns of stakeholders and the convention for constructing the related views [10]. Our framework formalizes this by separating the concerns reflected in the viewpoint in a viewpoint model (VptM) and, the convention to extract these concerns in viewpoint extraction algorithms (VptEA). By this separation, the definition of a viewpoint model makes abstraction of the extraction mechanisms (see 3.1). Moreover, this separation enables us to generalize as much as possible the convention for constructing the views and to reuse the knowledge on view construction in the form of reusable generic extraction algorithms (see 3.2). Starting from an implementation view of the software system, we provide several architectural views according to different viewpoints. We propose two viewpoint classes: matching and discovering. Matching viewpoints are used when stakeholders can represent their expectations as models representing the main concepts present in the system. The extraction algorithm constructs then the architectural view by ”matching” the system’s elements to the expected representation. This allows us to have generic extraction algorithms that are (re)used in the definition of several viewpoints. It is clear that matching viewpoints put their force on the modeling side. Examples of such viewpoints are business domainbased viewpoints which consider the principal business domain concepts and their relationships, and software pattern-based viewpoints [9][23] which identify architectural elements conform to a given pattern. Discovering viewpoints focus on the algorithm side of the viewpoint (more than the modeling side). The specificity of such viewpoints is entailed in the extraction algorithm, which specify how the elements of the input view are to be grouped leading to architectural elements discovery. In this case, the model part of the viewpoint definition is less important. Examples of such viewpoints are the activity-based viewpoint which identifies the architectural elements according to their level of interaction with their environment, and the cohesion-based viewpoint [17][14] which identifies a

436

A. Razavizadeh et al.

set of related architectural elements according the strength of their dependencies. The framework can easily integrate other viewpoints. 3.1

Viewpoint Models

For defining a viewpoint model, several sources of information can be used: rough understanding of the system’s functionality, documentation skimming, demo interviewing, or even the available experts’s opinions [4]. Viewpoint models are mainly represented using concepts and relationships among them. As such models represent an expected architecture representation, they are represented similarly to architectural views. Thus, a subset of the Architectural Meta Model presented in section 4 is used, concepts being represented as architectural elements. Each viewpoint reveals certain aspects of the software system. For example, the extracted architectural view of the business domain-based viewpoint presents the system architectural elements organization in accordance with the business domain concepts. Such a view mainly provides an overall view of the system in terms of the business concepts and helps different stakeholders in their system understanding. Let us consider a Banking software application example. The business domain concepts of such an application can be Bank, Client, Account, Credit card. The corresponding VptM of the business domain-based viewpoint comprises these concepts as architectural elements and their relationships (i.e., a Bank may have more than one Client; a Client may have more than one account; a Credit card concerns a specific Account, etc.). This VptM supports and guides the architectural view extraction process. 3.2

Extraction Algorithms

Let us recall that we focus on extracting architectural views; and we start from an implementation view of the system. In the case of matching viewpoints, the extraction algorithm attempts to identify elements from the input view related to each viewpoint model concept. Then, it makes a group of these elements and links them to the architectural element of the viewpoint. The input view’s architectural elements that do not correspond to any concept of the VptM are grouped in another group labeled Outside domain. This first extraction result allows one to identify concepts which are not reflected in the code. Moreover, further analysis of the Outside domain’s elements may lead to the discovery of new concepts. In the case of discovery viewpoints, the algorithms mainly focus on the relationships among architectural elements of the input view but differ in the metrics they consider (i.e. number of intra/inter invocations, number of methods, etc). The process can also be considered at a finer grain level if needed: the extraction algorithm can target different architectural elements (i.e., classes, methods, packages) of the implementation view. Thus, different architectural views can be generated accordingly. Moreover, at the implementation view level, the extraction algorithm can identify subsets of classes according to the VptM concepts. A subset of a class is a group of related attributes and methods and can be considered as traits [16]. As a consequence, an architectural element

Software System Understanding via Architectural Views Extraction

437

(i.e., a class) can be seen as a set of (potentially and partially) overlapping traits. The same trait can be found in different architectural elements. In the Banking software application example, we use a business domain-based viewpoint and thus, the matching algorithm presented before. This algorithm searches all classes (considered as architectural elements) of the implementation view which contain the VptM’s concepts in their name (i.e., Bank, Account, Credit card, etc.); when found, the classes are put in a group labeled with the corresponding concept and linked to the related architectural element. The classes that do not correspond to any concept of the VptM are grouped as Outside domain. The matching extraction algorithm is also used in software pattern-based viewpoints; in this latter, the viewpoint model is a Software Design Pattern Model. For instance the MVC pattern model contains Model, View, Controller as concepts of the MVC’s domain with their relationships. In this case, the extraction algorithm groups architectural elements according to MVC’s concepts and their relationships.

4

Architectural Views

Our definition of a view is based on the IEEE standard. An architectural view is a way to present the system using the elements that are relevant to stakeholders concerns [10]. The multiple views of a system allow one to give support to understanding the system to different classes of stakeholders. We propose a simple Architectural Meta Model for representing architectural views: a system architectural view is represented as a set of interconnected architectural elements (Figure 2). An architectural element is mapped to a group

Fig. 2. Architectural Meta Model

438

A. Razavizadeh et al.

of system’s elements (or a group of architectural elements) of the architectural view (of the framework) given as input. The Architectural Meta Model deals also with relationships among architectural elements. When extracting an architectural view, using the framework, the relationships among architectural elements of an architectural view are deduced from relationships among architectural elements of the architectural view given as input to the framework. Thus, the extraction process takes into account both the identification of the architectural elements and their relationships. Cascading Architectural Views: Our recursive approach enables one to use a previously extracted architectural view as an input for a new extraction process with a new (or even the same) architectural viewpoint. Therefore, each extracted architectural element (that is a group of elements of the architectural view given as input) may be also considered as an input of the recursive framework. Applying the framework recursively consists in defining and organizing architectural elements of the generated view according to the viewpoint model and extraction algorithms. As consequence, each architectural element of this generated view may be refined according to a new viewpoint model, and so on. Considering again the Banking software application example, we are cascading extraction processes (i.e., several framework recursions): starting from the source code of the software application, the first extraction process produces the implementation view which serves as the input view for another extraction process; this latter considers a business domain-based viewpoint and generates a business domain-based architectural view. This business domain-based architectural view is itself employed as input of a third extraction process using a MVC pattern viewpoint. This third extraction process identifies MVC viewpoint architectural elements (i.e., Model, View, Controller ) of each architectural element of the business domain-based architectural view (given as input) and generates new architectural views accordingly. For cascading views, one places the different viewpoints in an ordered collection and recursively applies the generate views algorithms (See Figure 3b). As a result of such architectural viewpoints cascade,

a)

b)

Fig. 3. a) Cascading multiple-viewpoint in a multiple-view perspective b) Extraction (recursive) algorithm

Software System Understanding via Architectural Views Extraction

439

we obtain an abstract architectural view for which the architectural elements reveal business domain concepts (second viewpoint used) and are composed of those of Model, View and Controller elements (third viewpoint used).

5

Illustration Example

Let us go back to the Banking software application and illustrate the application of the matching viewpoint extraction algorithm with the business VptM. The Banking software system source code entails 88 classes. The stakeholder begins first by defining a business viewpoint model that contains three concepts: Account, Client, Card. This proposed model is a very abstract and basic model. It reflects a non-expert user’s intuitive system understanding. Starting from the implementation view, using this VptM (architectural concepts and relationships) and the matching extraction algorithm, an architectural view is generated. This view contains thus 3 architectural elements (3 concepts) plus the Outside domain architectural element (Figure 4b). Further investigations can be done focusing on the Outside domain group/architectural element: the classes associated to the group Outside domain can be deeply analyzed for similarities identification. Several classes may share a concept that might correspond to a concept in the domain, which was not formalized (or that has been forgotten) in the viewpoint model. This later can thus be updated. The extracted architectural view is equally updated in order to include the new architectural element. The remaining elements of the Outside domain group generally can be now subject to another extraction process using a given VptM. The extraction process entails,

Fig. 4. a) Bank application view extraction; b) Extraction result with the initial VptM; c) Extraction result after exploration of the Outside domain architectural element

440

A. Razavizadeh et al.

for example, ”software design know-how” that is formalized in another viewpoint model. The new detected concepts presented in Figure 4c are thus extracted from the Outside domain architectural element. The results obtained include the detection of 7 new architectural concepts that are part of the business domain. Considering the number of classes (implementation view ’s elements), detecting 10 concepts is a good sign. We should remark that the detection of concepts which are not parts of domain is a false positive. It entails for example ”software design know-how” that is formalized in another viewpoint model. Figure 4a shows also the links established between the implementation view and the business view. These links facilitate maintaining the consistency between the abstract and the concrete representations of the system.

6

Related Work

This section addresses those works that deal with software architecture reconstruction. Various works are proposed in order to extract architectures of an object-oriented systems. We distinguish these works according to two criteria: the extraction process input and the technique of this process. The inputs used by extraction approaches are various. Most often the source code is used, but some researchers have highlighted the importance of considering alternative sources of information during the architecture extraction such as: developer knowledge [20][12]; bug reports and external documentation [2]; or considering an ontology of the software system’s domain [3]. In our approach we propose to infer a viewpoint as input in order to guide the extraction from the source code of a system. The use of viewpoints to generate views is a key aspect of our approach. The viewpoint is not limited to be developer knowledge, bugs or documentation, thus it can be one or all of them. This viewpoint may be: a software pattern, a business model or even an interesting concept requested by user; therefore it is generic compared with other approaches. The main difference is the separation of two existing concepts of viewpoint definition according to IEEE standard: concerns (as a viewpoint models) and conventions (as an extraction algorithms). This separation increases the generic aspect of our approach. The techniques used to reconstruct architecture of an existing system are various. Approaches like [18] and [21] consider external constraints (represented as queries) to be checked against the reality of source code or recovered architectural elements. [20],[12] and [22] propose an automatic reconstruction technique based on reflexion models, starting with a structural high-level model. In Murphy et al. proposition, users iteratively refine a structural high level view model to gain information about the source code. The technique is based on the definition of a set of mappings between this high level model and the source code. Our technique is a reflexion model; the main difference is that we propose a recursive framework to apply this reflexivity. This recursion leads in define multiple views from any generated (or existing) view. At each recursion a view extracts from another view using a viewpoint.

Software System Understanding via Architectural Views Extraction

7

441

Conclusion

The presented approach for architecture reconstruction allows us to extract information for the stakeholders who are interested in high level architectural views of a software system. We propose a generic and recursive framework that considers various viewpoints (from different sources of information) and generates multiple views of an existing system. The first instantiation of the framework uses a view of the source code as input. This process of instantiation considers horizontal and vertical recursions to extract cascading architectural views. The approach stresses on separating the defined notion of architectural viewpoint into: viewpoint model and viewpoint extraction algorithm. This enables us to propose two classes of viewpoints: matching viewpoints emphasizing the model side (e.g., business-domain based and pattern-based viewpoints) and the discovering viewpoints emphasizing the extraction algorithm side (e.g., activity-based viewpoint, cohesion viewpoint). Each architectural element in an extracted view entails a link towards the group of elements it represents (from the input view). This link is a valuable asset for system maintenance and allows maintaining the consistency among different views of the system during its evolution. The approach presented in this paper can be used at any object-oriented source code granularity level. The straightforward approach uses classes as the first architectural element kind, but any other slicing like method-based and/or package-based can be used. Acknowledgements. This work has been partially funded by the french ANR JC05 42872 COOK Project.

References 1. Clements, P., Bachmann, F., Bass, L., Garlan, D., Ivers, J., Little, R., Nord, R., Stafford, J.: Documenting Software Architectures: Views and Beyond. AddisonWesley Professional, Reading (2002) 2. Cubranic, D., Murphy, G.: Hipikat: Recommending pertinent software development artifacts. In: Proceedings 25th International Conference on Software Engineering (ICSE 2003), pp. 408–418. ACM Press, New York (2003) 3. Deissenboeck, F., Ratiu, D.: A unified meta-model for concept-based reverse engineering. In: Proceedings of the 3rd International Workshop on Metamodels, Schemas, Grammars and Ontologies, ATEM 2006 (2006) 4. Demeyer, S., Ducasse, S., Nierstrasz, O.: Object-Oriented Reengineering Patterns. Square Bracket Associates (2008) 5. Deursen, A., Hofmeister, C., Koschke, R., Moonen, L., Riva, C.: Symphony: Viewdriven software architecture reconstruction. In: Proceedings of the Fourth Working IEEE/IFIP Conference on Software Architecture (WICSA), pp. 122–134 (2004) 6. Ducasse, S., Lanza, M., Tichelaar, S.: Moose: an Extensible Language-Independent Environment for Reengineering Object-Oriented Systems. In: Proceedings of CoSET 22000 (2nd International Symposium on Constructing Software Engineering Tools) (June 2000) 7. Ducasse, S., Pollet, D.: Software architecture reconstruction: A process-oriented taxonomy. IEEE Transactions on Software Engineering (2009)

442

A. Razavizadeh et al.

8. Finnigan, P., Holt, R., Kalas, I., Kerr, S., Kontogiannis, K., Mueller, H., Mylopoulos, J., Perelgut, S., Stanley, M., Wong, K.: The software bookshelf. IBM Systems Journal 36(4), 564–593 (1997) 9. Guo, Y., Atlee, Kazman: A software architecture reconstruction method. In: Working Conference on Software Architecture (WICSA), pp. 15–34 (1999) 10. IEEE Architecture Working Group. IEEE P1471/D5.0 Information Technology — Draft Recommended Practice for Architecural Description (August 1999) 11. Jazayeri, M.: On architectural stability and evolution. In: Blieberger, J., Strohmeier, A. (eds.) Ada-Europe 2002. LNCS, vol. 2361, pp. 13–23. Springer, Heidelberg (2002) 12. Koschke, R., Simon, D.: Hierarchical reflexion models. In: Proceedings of the 10th Working Conference on Reverse Engineering (WCRE 2003), p. 36. IEEE Computer Society, Los Alamitos (2003) 13. Kruchten, P.B.: The 4+1 view model of architecture. IEEE Software 12(6), 42–50 (1995) 14. Lakhotia, A.: Rule-based approach to computing module cohesion. In: Proceedings 15th ICSE, pp. 35–44 (1993) 15. Lehman, M.: Programs, life cycles, and laws of software evolution. Proceedings of the IEEE 68(9), 1060–1076 (1980) 16. Lienhard, A., Ducasse, S., Ar´evalo, G.: Identifying traits with formal concept analysis. In: Proceedings of 20th Conference on Automated Software Engineering (ASE 2005), pp. 66–75. IEEE Computer Society, Los Alamitos (2005) 17. Mancoridis, S., Mitchell, B.S., Chen, Y., Gansner, E.R.: Bunch: A Clustering Tool for the Recovery and Maintenance of Software System Structures. In: Proceedings of ICSM 1999 (International Conference on Software Maintenance), Oxford, England. IEEE Computer Society Press, Los Alamitos (1999) 18. Mens, K., Kellens, A., Pluquet, F., Wuyts, R.: Co-evolving code and design with intensional views — a case study. Journal of Computer Languages, Systems and Structures 32(2), 140–156 (2006) 19. M¨ uller, H.A.: Rigi — A Model for Software System Construction, Integration, and Evaluation based on Module Interface Specifications. PhD thesis, Rice University (1986) 20. Murphy, G., Notkin, D., Sullivan, K.: Software reflexion models: Bridging the gap between source and high-level models. In: Proceedings of SIGSOFT 1995, Third ACM SIGSOFT Symposium on the Foundations of Software Engineering, pp. 18– 28. ACM Press, New York (1995) 21. Pinzger, M., Fischer, M., Gall, H., Jazayeri, M.: Revealer: A lexical pattern matcher for architecture recovery. In: Proceedings of the 9th Working Conference on Reverse Engineering (WCRE 2002), pp. 170–178 (2002) 22. Robillard, M.P., Murphy, G.C.: Concern graphs: finding and describing concerns using structural program dependencies. In: ICSE 2002: Proceedings of the 24th International Conference on Software Engineering, pp. 406–416. ACM Press, New York (2002) 23. Tonella, P., Antoniol, G.: Object oriented design pattern inference. In: Proceedings of ICSM 1999 (International Conference on Software Maintenance), pp. 230–238. IEEE Computer Society Press, Los Alamitos (1999)

MONET 2009 PC Co-chairs’ Message The research areas of mobile technologies, social networking and mobile services applications are receiving wide interest from private and public companies as well as from academic and research institutions. The mobile and networking technologies, the new generation of wireless local area networks and ad hoc networks are devoted to playing an important role in many areas of social activities, predominantly in those areas where having the right data at the right time is a mission-critical issue. Mobile and networking technologies for social applications serve groups of people “on the move,” sharing activities and/or interests; in particular these technologies involve geographically distributed groups who are collaborating on some task in a shared context or independently from their location. By their real nature, mobile technologies can be considered multidisciplinary technologies involving social aspects; indeed, they often involve personal, group and ubiquitous issues, supporting inter-personal connections and involving human–technology interaction in different, and dispersed, contexts. Mobile technologies also play an essential role in personalizing working and interaction contexts, while supporting experimentation and innovation, and the advancement of the field is fundamental for developing social networking. Social networking technologies bring friends, family members, co-workers and other social communities together. These technologies are convergent, emerging from a variety of applications such as search engines and employee evaluation routines, while running on equally diverse platforms from server clusters to wireless phone networks. Social networking and its connection with the use of mobile devices represents one of the most relevant phenomena related to the networking technologies and their emerging problems of use, robustness, vulnerabilities to reliability and performance due to malicious attack. The fourth international workshop on Mobile and Networking Technologies for social applications (MONET 2008) was held in November 2009 in Vilamoura (Portugal). The workshop allowed researchers, experts from academia and industry, and practitioners to discuss new mobile and networking technologies, social networking and mobile applications; this debate has represented a stimulus to identify challenging problems in the social applications of those technologies and to show results and experiences connected with social networking, business applications and, mobile applications and services. This year, after a rigorous review process, eight papers were accepted for inclusion in the conference proceedings. The success of the MONET 2009 workshop would not have been possible without the contribution of the OTM 2009 workshops organizers, PC members and authors of papers, all of whom we would like to sincerely thank. Patrizia Grifoni Fernando Ferri Irina Kondratova Arianna D’Ulizia

R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, p. 443, 2009. © Springer-Verlag Berlin Heidelberg 2009

SocioNet: A Context-Aware Approach for Lowering the Communication Barrier Igor Pernek1 and Karin Anna Hummel2 1

Faculty of Electrical Engineering and Computer Science, University of Maribor, 2000 Maribor, Smetanova 17, Slovenia [email protected] 2 Institute of Distributed and Multimedia Systems, University of Vienna, 1080 Vienna, Lenaugasse 2/8, Austria [email protected]

Abstract. Social networking platforms, such as Facebook and Twitter, foster new social interactions. Following this vision, we introduce SocioNet, a context-aware and rule-based system for mobile devices that finds best matching persons in proximity and therefore establishes contacts. The system architecture is a hybrid central server and P2P architecture supporting matchmaking. As concerns for social platforms arise mainly in terms of usability and privacy, SocioNet proposes (i) the use of existing personal information for matchmaking to avoid tedious filling-in of user profiles and (ii) preservation of privacy by not storing personal data on the SocioNet server if not wanted by the user. We demonstrate the feasibility of SocioNet by a prototypical implementation based on .NET CF and WLAN. To rate user satisfaction, we performed a user survey. First results show, that privacy is still a major cause not to use social networking platforms when physical presence is involved. Keywords: Context-awareness, Personal Information Data, Privacy Preservation, Social Communication Barriers.

1 Introduction Social networks supported by Internet services are experiencing a tremendous popularity all over the world. Building social networks and sharing experiences, like videos and photos, has become very easy, although privacy concerns remain. Huge databases hold private and personal information of various kinds which can be maliciously exploited as well. However, many people rate the benefit of these IT based social networks higher than their threats to privacy. We experience that everyday life becomes more and more supported by networked computing technologies such as everywhere wireless connectivity, mobile smart devices, and sensors to determine orientation, acceleration, and location, e.g., supported by GPS receivers. As a consequence, IT based social networks can also be extended to situations of physical presence and interaction with the physical world. We expect that IT based social networks of the future will combine both virtual and physical social interactions. In this work, we propose SocioNet, which aims at R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 444–453, 2009. © Springer-Verlag Berlin Heidelberg 2009

SocioNet: A Context-Aware Approach for Lowering the Communication Barrier

445

establishing contacts in the physical world by matching a user’s personal data with personal data of others in proximity. In other words, SocioNet fosters physical interactions based on social relationships known in the virtual world, but possibly not known in the physical world. A possible use case is a situation in a big mall, where a person would like to find the best shop for digital cameras, but also a shop that can be trusted, etc. Instead of just proposing all the shops around, SocioNet provides the user with links to persons who might be of help (and are currently willing to interact). If the system provides a good match, a short conversation might help to find out which shop to prefer and the searching person might also get additional hints during this conversation. To provide these features, SocioNet integrates location sensors, like GPS receivers for outdoor positioning, uses personal information already stored on the mobile smart device of the user, and introduces several roles of others to search for (e.g., friend of a friend). By using personal information already stored on the device, such as contacts and calendar entries, SocioNet avoids cumbersome entering of preferences and other personal data. The matchmaking further relies on the availability of wireless networking (ad-hoc and infrastructure WLAN, 3G networks, etc.). Here, SocioNet allows keeping personal data local to increase the level of privacy, but allows also to store it on a central server. The server is in any case used to identify who is participating in SocioNet. Depending on where the data is stored, either a Peer-toPeer (P2P) connection is suggested between the two user devices for exchanging personal information and matchmaking is done at the clients, or the server performs matchmaking. (Note, that the information is encrypted before sending.) The research questions we want to answer are: (i) Can we propose a system that avoids tedious filling-in of user profile data? (ii) What are the performance and privacy tradeoffs between storing SocioNet information on a central server and exchanging information in P2P manner? (iii) How does a user rate the benefits of SocioNet, e.g., is it useful and preserves privacy good enough? In the remainder of the paper, we will address these questions after introducing related work in Section 2. How SocioNet approaches to lower communication barriers is summarized in Section 3 followed by a presentation of the prototypical implementation for PDAs (Personal Digital Assistants) based on .NET CF and WLAN in Section 4. In Section 5, we present performance reflections and the results of a user survey which has been carried out to rate user acceptance.

2 Related Work After the rapid growth of Internet based social network services the same phenomena is happening in the area of mobile computing. Over the last years various mobile social networks have been established and it is to expect more of them to arise as mobile smart devices are spreading equipped with multiple wireless networking facilities (3G, WLAN, Bluetooth, etc.). According to a recent forecast [1], half of the new connections to the Internet in 2009 will be mobile and the mobile device will become the primary Internet connection tool for most people in 2020. Besides the ability to maintain social groups and to connect with a social network’s members, mobile social networking is also often used as a means, which helps the mobile users to hook-up with friends, friends-of-friends, or other people in proximity [8], [15],

446

I. Pernek and K.A. Hummel

[10], [3], [11]. The continuous appearance of new tools for facilitation of face-to-face interaction with the help of electronic personal assistants is reflecting the potential of systems combining physical and virtual world. For example, using the Short Message Service (SMS) often leads to face-to-face communication and PDAs can promote social interaction [14]. Depending on the mobile device’s operating system, like Android, Symbian OS, Windows Mobile, applications are written in J2ME, C++, or based on .NET CF. We have chosen .NET CF for the prototypical implementation of SocioNet. Existing mobile social networks use different system architectures on top of wireless networks, such as WLAN or 3G. While the general architecture of mobile social networks is centralized [6], a lot of them are using P2P architectures [12], [4], [2] to exploit the fact that only the peers nearby should be contacted and no additional infrastructure is needed. Each system architecture paradigm is accompanied with a set of advantages and disadvantages. Although processors of mobile devices are getting faster, they are still not able to perform real-time matchmaking on a larger set of profile data. On the other hand, the central server approach solves the problem of matching large data sets but privacy concerns are raised. Different data provisioning patterns are used to perform matchmaking between the users. While in the past user predefined profiles were used to perform pairing of users with similar interests, nowadays context information is becoming a valuable source of profile information [9]. It is expected that context-awareness will become even more important as trends in mobile computing are converging to smarter approaches. Besides usability, the main factor that makes or breaks a mobile social platform is trust in the system. Different studies have been carried out evaluating the way privacy is handled in existing mobile social applications and mobile social system architectures. In [7], the Bellotti and Sellen’s feedback and control framework [5] is used to analyze existing mobile social applications. The conclusions drawn are, that privacy designs are usually weak, as they are not offering enough control over the user’s personal data and are not providing enough feedback about where the data is stored. SocioNet incorporates the insights and beneficial design principles concluded by related work on social networks by considering performance, privacy, and usability issues at the same time.

3 SocioNet Concept In this section, we will describe design decisions and the concepts included in SocioNet answering the question how to derive profiles for matchmaking. Additionally, we will discuss the system architecture of SocioNet. 3.1 Functions and Features The design of SocioNet aims at making the application unobtrusive, transparent, and simple to use, to make it suitable to a broad range of different users. The prototype installation of SocioNet can be controlled using the mobile device main window, which results in a gently sloped learning curve for inexperienced users. Additionally, we have eliminated the phase of entering long and cumbersome user profile and preference data. Instead of fostering users to enter these data, SocioNet uses personal information already stored on the device, like contact data and calendar entries. The

SocioNet: A Context-Aware Approach for Lowering the Communication Barrier

447

control over the data used in the matchmaking process lies in the hands of the user and can be selected via a profile data control interface. As both the P2P and the central server architecture have advantages and disadvantages, we have decided to combine them into a hybrid system architecture (Fig. 1a) to select between different configurations for storing profile data for matchmaking. In this system architecture approach, the P2P network is an unstructured network and the server is in any case responsible for providing links to clients (names, IP addresses of clients). We have decided not to use any structured P2P network approach (like Distributed Hash Tables) mainly because we may exploit the hybrid architecture and therefore can avoid costly searches in the P2P sphere. Using a central server also for matchmaking leads to decreased privacy, but also better performance in terms of matchmaking execution time and data transfer in particular of large scale profiles (load and delays) necessary prior to matchmaking. The P2P sphere avoids storing private data centrally but requires more resources on the mobile devices since matchmaking is performed by a mobile peer.

Fig. 1. a) Hybrid network architecture and b) Profile data control screen

The central server acts as a tracker of online clients able to perform matching of the data stored on the server (if any). In any configuration, the server’s responsibility is to provide link information to all clients. The server is also ready to store optionally the most frequently used matchmaking data, if allowed by the user’s privacy settings. Fig. 1b shows how the user may select different types of personal data for matchmaking and whether the data should be used only local in the P2P sphere. After a user issues a matching request, data available on the server is matched on the server to avoid additional network traffic. If client data is not available, a list of nearby clients is forwarded to the client device which then pushes the necessary data to the clients residing nearby for matchmaking. Finally, matching results are returned either from the server or the peer client devices – or both – and joined to a final result set, which is presented to the user. Using the approach described, we are able to adapt the

448

I. Pernek and K.A. Hummel

communication style to privacy, performance, and cost considerations. Hence, the user remains not only in control which data to share for matchmaking, but also where the data should be stored. To summarize, all design steps were taken to reach the main goal of the application, i.e., to find the best matching persons in proximity of the user and to promote face-toface interaction in an urban area where wireless networks are available. Matches are based on location and personal information (contact and calendar data) provided by state-of-the-art mobile devices. 3.2 Roles and Rules While the main matchmaking criterion is the proximity of users, SocioNet uses the roles presented in Table 1 to reflect social relationships in the SocioNet community. Different roles further allow the user to pick a person matching his or her personality or current mood. If the user would like to get in contact with a person he or she knows or is partly familiar with, the user can pick a result annotated with the friend or a friend-of-friend tag. If the person would like to socialize with an unknown person who shared interests with the user or even with a total stranger nearby, he or she can easily pick a match tagged with the interests match or a stranger tag and possibly expand his or her social network. Table 1. Description of the SocioNet roles Role Friend Friend-of-friend Interest match Stranger

Description [all persons in proximity] A person with whom the user is acquainted. A person with whom a friend of the user is acquainted. A person with same interests, taking part in the same social activities. A person, who is not a friend, neither a friend-of-friend nor an interest match.

All of the roles used by the SocioNet application are based on simple classification rules as explained in Table 2. With respect to the described classification rules, different roles are not necessarily mutually exclusive, as the friend or a friend-offriend could also have interests in common with the user and therefore lead to an interest match. For determining the roles, different profile sources are used. Table 2. Description of the main SocioNet rules Role Friend

Profile section Contact-book

Friend-of-friend

Contact-book

Interest match

Calendar

Stranger

Contact-book, calendar

Classification rule A person whose telephone number is stored in the user’s contact-book. A person with whom the user is sharing one or more contacts. A person with whom the user is sharing social events in the calendar. A person having nothing in common with the user, but residing nearby.

SocioNet: A Context-Aware Approach for Lowering the Communication Barrier

449

In more detail, optimized matchmaking at the server introduces new complexity to the basic concept. After a match is accepted, the match’s role is determined and the corresponding user-role match counters are increased for the matched persons. If a match counter for a role meets a pre-configurable threshold, profile reorganization is performed. E.g., if a user regularly accepts interest matches the system predicts that it is more likely that the next match accepted will be an interest match. As a consequence, if allowed by the user’s privacy settings, profile data used to recognize interest matches (e.g., calendar data) will be stored on the server to decrease network traffic.

4 Implementation The SocioNet mobile social network prototype is built as a hybrid P2P and central server solution, which allows matchmaking being done on the central server or directly on the mobile client device (here, a peer). While the server is implemented in the .NET Framework 3.5, the PDA client prototype is based on the Pocket PC .NET Compact Framework 3.5 platform and tested on a DELL AXIM X51V. Although WLAN and IP are used in the prototype implementation, the network layer is abstracted and can easily be exchanged by, e.g., GPRS or a 3G network. The system architecture was successfully implemented, meaning that clients can connect to a server and/or other peers directly to perform matchmaking, as well as the role concept. To achieve a higher level of modularity, the server solution is implemented as host application and a library of XML Web services, which could be upgraded or replaced without much effort. Clients contact servers on a specific socket port to invoke a Web service and listen then for notifications of the service. With the use of transparent privacy settings and a rule-based profile storing approach, we expect that a good performance-trust tradeoff will result. Relationships between two contact book or calendar entries are stated by full-text match. We have decided to obfuscate the data with a one-way hash function and transform the text into a form not readable by humans, while still preserving enough information to perform full-text matching. Although original data could be restored with a simple rainbow attack [13], an additional step is needed to abuse the personal data. To optimize matchmaking at the server, rule-based profile storing as described in Section 3.2 is implemented together with profile caching to reduce network traffic. Rather than transmitting locally stored profile data for each matching attempt, profile information is stored in the server’s volatile memory for the time of a session. After the user logs out or is inactive for a pre-configurable amount of time (timeout), his or her profile is removed from the cache.

5 Performance Reflections and User Questionnaire The prototype has been evaluated with respect to performance measurements for comparing the messaging load to the analytically expected load and user acceptance. With respect to performance, the important question was about the costs to expect

450

I. Pernek and K.A. Hummel

when preserving privacy using the P2P sphere for matchmaking in comparison to the central server solution. User acceptance is evaluated by means of a user survey. In this section, we will briefly summarize first results of these investigations. 5.1 Performance Reflections We now evaluate the impact of matchmaking placement by taking a look at the network traffic caused (bytes transferred) of two configurations: Central server only and peer-side. We present here the analytical calculations useful for determining trade-offs between privacy and overall network load L in bytes (additionally, response time could have been investigated experimentally based on the used WLAN IEEE 802.11g). By comparing the analytical numbers with our measurements, we discovered no significant deviations (as expected from a correct implementation of messaging). The experiment carried out was simulating Nu = 100 mobile user devices in proximity, each one holding Cu = 100 contact-book entries; each of size = 32 bytes after obfuscation. Each user requests matchmaking to take place Mfu = 10 times in the simulation period. The peer-side approach, where client profiles are stored in the P2P sphere only, resulted in Cu x size = 3200 bytes transferred (Nu - 1) Nu = 9900 times to the matchmaking mobile device (note, that the whole profile has to be transferred for each request). After Mfu =10 matchmaking requests, resulting number of bytes transferred are calculated as L = Cu x size x (Nu - 1) Nu x Mfu = 316.800.000 bytes. For the central server only system configuration, the size of the initial data transfer of Nu = 100 clients is L = Cu x size x Nu = 320.000 bytes. Additionally, due to changes in the contact book, incremental synchronization with the server will be required causing additional load. As can be seen, the pure P2P solution is reasonable in case small amounts of data have to be exchanged, Nu is small, or frequent updates of personal data occur. With the use of a central server, there is only one initial data transfer and incremental updates (e.g., a new contact is added to the contact-book). Matchmaking is then performed by the server and no additional data transfer is needed. Since our approach allows to store profile data partially on the central server and in the P2P sphere (on the mobile device), the rule-based profile can be used to generate arbitrary hybrid configurations, which allow to store some information of lower privacy protection level (e.g., calendar entries) on the server while leaving others on the mobile device (e.g., contact data). Network load will be reduced while keeping the user in the loop of controlling where his or her profile data is stored. The performance increase depends here linearly on the amount of data kept at the central server. 5.2 Questionnaire Based User Survey After a short demonstration of the features of SocioNet, we conducted a user questionnaire to find out the answers to the following crucial questions with respect to user acceptance of SocioNet in terms of usability and privacy: i.

Do the participants think that SocioNet will open new communication options and which roles do they like to interact with (friends, friends-of-friends, persons sharing interests, strangers)?

SocioNet: A Context-Aware Approach for Lowering the Communication Barrier

ii. iii.

451

Do the participants think that privacy is assured by keeping data local? Do the participants think that their mobile personal information is rich enough to lead to good matches?

We evaluated the answers of 40 participants in the age ranging from 18 to 48 years. The Computer Proficiency (CP) self-estimate of the participants was either high (CP=3), medium (CP=2), or low (CP=1). The average proficiency was calculated as 2.6 and is rather high. Table 3 summarizes the results of the questionnaire. Table 3. Results of the user survey [in %] Classes [# of participants] Opens new communication options Use SocioNet to contact a friend friend-of- friend interest match stranger Privacy feeling in control local storage PI-data sufficient

CP < 3 [15] 73

CP = 3 [25] 76

All [40] 75

53 33 46 13

64 52 68 24

60 45 60 20

20 93 53

56 72 52

43 80 53

We can state some observation based on the results of the questionnaire: − − −

−

−

More than 70% of both computer proficient participants and participants not that familiar with computing technology think that SocioNet opens new communication possibilities. When asked about the type of contacts which should be fostered via SocioNet, it is remarkable that higher proficiency generally comes with a higher likelihood of using SocioNet for establishing (social) contacts. Generally, 60% of the participants would use SocioNet to contact their friends and persons with similar interests, while only 45% would contact friends-offriends, and 20% of the participants would also like to use SocioNet to contact strangers. These first results show that the participants base their contacts on existing close relationships or on existing similar interests. It is remarkable, that only 20% of low and medium proficient participants think they are in control of their privacy, while 56% of the highly proficient participants feel in control. Here, we see a general lack of mental models of where digital personal data is best stored and how unauthorized access can be prevented which may be a cause for this feeling. On the other hand, 93% of low and medium computer proficient participants felt that storing the data not on a central server helps to increase privacy, while participants with high proficiency were more reluctant (72%). Here, computer proficient participants have most likely considered several remaining threats to privacy (like, men-in-the-middle, not trustworthy P2P system, etc.).

452

−

I. Pernek and K.A. Hummel

SocioNet tries to avoid entering of boring user profiles, but many participants think that personal information stored on their mobile devices will not be sufficient to identify persons to contact. Here we see that our alternative approach requires further (positive) evaluations (e.g., a longer field study with real-life personal information data) before users might trust the solution.

Finally, the participants were asked why they would not use SocioNet to contact others. Some participants thought that they do not need technology to contact friends or friends-of-friends. Additionally, missing trust in the system was a major issue.

6 Conclusions In this work, we have introduced SocioNet, a social networking platform dedicated to mobile smart devices to support social interactions among persons in proximity. While addressing performance and trust issues, SocioNet provides pointers to other persons willing to interact and help in particular every-day situations. SocioNet follows the vision that human-to-human interaction allows for better problem solving due to the richness of human social interactions when compared to a solely database based recommender system. To find best matching persons, we introduced an extended role model representing social relationships. Due to privacy issues, we provided a solution where personal information does not have to be stored on a central server but may be exchanged directly between the participating mobile devices. The prototypical implementation showed that this peerto-peer solutions results in significant messaging overhead, which could be reduced by adding rules resulting in partial central storage of personal data. To evaluate the usefulness of SocioNet and the privacy enhancing solutions, we performed a questionnaire. 75% of the 40 participants (computer proficiency high) rated the prototype as capable of establishing new communication options, which was our general aim. SocioNet would be more likely used to establish communication channels with friends and persons of similar interest than with unknown persons (even if they are friends-of-friends). When it comes to privacy, we investigated that the loss of control over private data is felt more intensive by low and medium computer proficient participants. A mental model for digital data and data privacy might help to improve this situation. The questionnaire also pointed out that it is not yet clear to the user whether personal information retrieved from the databases available on mobile smart devices is sufficient to perform good matchmaking. In future work, we plan to address this issue by a wider field study.

References 1. Anderson, J.Q., Rainie, L.: Future of the Internet III, Pew Internet & American Life Project (2008), http://www.pewinternet.org/Reports/2008/ The-Future-of-the-Internet-III.aspx

SocioNet: A Context-Aware Approach for Lowering the Communication Barrier

453

2. Arb, M., Bader, M., Kuhn, M., Wattenhofer, R.: VENETA: Serverless Friend-of-Friend Detection in Mobile Social Networking. In: WIMOB 2008, IEEE International Conference on Wireless and Mobile Computing, pp. 184–189 (2008) 3. Axup, J., Viller, S., Maccoll, I., Cooper, R.: Lo-Fi Matchmaking: A Study of Social Pairing for Backpackers. In: Dourish, P., Friday, A. (eds.) UbiComp 2006. LNCS, vol. 4206, pp. 351–368. Springer, Heidelberg (2006) 4. Belle, S.K., Waldvogel, M.: Major Domus Redux: Privacy in Mobile Social P2P Networks (2008), http://www.ub.uni-konstanz.de/kops/volltexte/2008/5495/ 5. Bellotti, V., Sellen, A.: Design for Privacy in Ubiquitous Computing Environments. In: ECSCW 1993: Third European Conference on Computer-Supported Cooperative Work, pp. 77–92 (1993) 6. Chang, Y.-J., Liu, H.-H., Chou, L.-D., Chen, Y.-W., Shin, H.-Y.: A General Architecture of Mobile Social Network Services. In: ICCIT 2007: International Conference on Convergence Information Technology, pp. 151–156 (2007) 7. Chen, G., Rahman, F.: Analyzing Privacy Designs of Mobile Social Networking Applications. In: EUC 2008: IEEE/IFIP International Conference on Embedded and Ubiquitous Computing, pp. 83–88 (2008) 8. Jambo Networks, http://www.jambo.net/ 9. Joly, A., Maret, P., Daigremont, J.: Context-Awareness, the Missing Block of Social Networking. International Journal of Computer Science and Applications 4(2), 50–65 (2009) 10. Kern, S., Braun, P., Rossak, W.: MobiSoft: An Agent-Based Middleware for SocialMobile Applications. In: On the Move to Meaningful Internet Systems 2006: OTM 2006 Workshops, pp. 984–993 (2006) 11. Konomi, S., Thepvilojanapong, N., Suzuki, R., Pirttikangas, S., Sezaki, K., Tobe, Y.: Askus: Amplifying Mobile Actions. In: Pervasive 2009: Pervasive Computing, pp. 202– 219 (2009) 12. Mani, M., Nguyen, A.-M., Crespi, N.: What’s Up 2.0: P2P Spontaneous Social Networking. In: PERCOM 2009: IEEE International Conference on Pervasive Computing and Communications, pp. 1–2 (2009) 13. Oechslin, P.: Making a Faster Cryptanalytic Time-Memory Trade-Off. In: Boneh, D. (ed.) CRYPTO 2003. LNCS, vol. 2729, pp. 617–630. Springer, Heidelberg (2003) 14. Olson, G.M., Olson, J.S.: Human-Computer Interaction: Psychological Aspects of the Human Use of Computing. Annual Review of Psychology 54(1), 491–516 (2003) 15. Playtxt, http://www.playtxt.net/

Models of Charity Donations and Project Funding in Social Networks* Adam Wojciechowski Poznan University of Technology, Institute of Computing Science ul. Piotrowo 2, 60-965 Poznan, Poland [email protected]

Abstract. One of the key fundaments of building a society is common interest or shared aims of the group members. This research work is a try to analyze web-based services oriented towards money collection for various social and charity projects. The phenomenon of social founding is worth a closer look at because its success strongly depends on the ability to build an ad-hoc or persistent groups of people sharing their believes and willing to support external institutions or individuals. The paper presents a review of money collection sites, various models of donation and money collection process as well as ways how the projects' results are reported to their founders. There is also a proposal of money collection service, where donators are not charged until total declared help overheads required resources to complete the project. The risk of missing real donations for declared payments, after the collection is closed, can be assessed and minimized by building a social network. Keywords: charity, project funding, money collection, social networks.

1 Introduction Reasons why people donate to charity projects and forms of support are subject of various studies [4, 13]. An approach, complementary to scrupulous observations and polls, to discover motivation for charity, used in our research, was studying comments on web portals that appeared under articles related to charity and social help issues. Although such a method could not bring us objective quantitative results, we intended to focus rather on identifying situations, problems and arguments for supporting or not participating in charity actions that people give in an anonymous discussion. We also tried to analyze if the will to help is a function of emotions risen by participation in a sad event (maybe reported on TV or elsewhere), observation how other people contribute or the ability to help is a basic instinct that awakes in us independent from circumstances and people around us. Non Government Organizations (NGOs), main organizers of charity projects developed on country-wide and international scale, open the opportunity to participate in large scale support actions by small donations brought by big crowd of participants. Many social problems seem too large for any one person to make a difference. * This research was partially supported by the grant 91-439/09-BW. R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 454–463, 2009. © Springer-Verlag Berlin Heidelberg 2009

Models of Charity Donations and Project Funding in Social Networks

455

Making a donation gives the donor personal power over a complex issue that is much larger than himself [11]. It appeared that important factors that make people to contribute to projects run by NGOs are small donations (many can afford it) and feeling of being a part (founder) of an important project. Joined contributions of a group focused on solving particular problem is a good example of utilizing so called social capital [8, 12]. It is also worth to notice that good atmosphere (fun, joy, concert) and even day of the week has an influence on number of participants and their will to contribute to projects presented during an event. Martin and Randal in [9] describe an interesting experiment which statistically proved so called ‘Sunday effect’, where donations dropped to a donation-box in City Gallery Wellington, New Zealand were larger and more frequent on Sundays than on other days of the week. Observed donators’ behaviour is a reason why many large-scale charity programs implement money collections during concerts and other outdoor events where participants can observe each other while donating. Charity help and money donations become an important and growing part of world economy. While registered charitable donations, reported in the Giving USA 2007 survey[2], exceeded US$295 billions in year 2006, the totaled sum collected in 2007 grew to US$ 306 billion in 2007[3]. It is worth to notice that majority of giving came from individuals while only 1.3% of donations was contributed from huge actions supported by media. An effective way to reach wide audience at low price is Internet. The interactive media provide tools for delivery textual and audiovisual content while visitors (participants) have the possibility to react instantly. The action performed by visitors to a charity collection sites may give donation via internet money transfer (e.g. Paypal or credit card payment). They may also do some work in distributing information about the charity program by sending a message to their friends. And finally the visitor, who register in charity collection web-site, may be informed about new charity programs when they start. Frequent web-site visitor is also a valuable donator, who may bring some funds to charity program. The money may come from sold advertising space in the web-site. Such an approach is used in a service run by Polish Humanitarian Action (NGO): pajacyk.pl, where a daily return and click of a user brings small donation from sponsor advertised in the site. Reported money donated this way is enough to serve daily ca. 2000 hot meals for children in selected Polish schools. In this research we try to analyze reasons why people decide to help, distinguish the most preferred forms of donations in the Internet space and finally there is a proposal of an approach which assumes that support goes only to those projects which can be fully financed from declared donations. The novelty of the approach is in the fact that declared donations are deducted from accounts only in case when total declared sum is higher or equal to required resources. The projects is validated against legal regulations which, in case of Poland, do not allow (with some exceptions) public/internet basking for money by individuals but such a collection may be run by NGOs, foundations etc. The paper is built of 5 sections. After introduction there is a collection of motivations and arguments for participation and avoiding charity actions found in literature review and on internet forums under articles related to charity issues. Section 3 is a survey of money giving and charity donation websites with discussion

456

A. Wojciechowski

of their main features and business models applied for money collection. In section 4 there is a proposal of a service based on a web-site dedicated to organize money collections for individually described program, project or action coordinated by an NGO or foundation. The work is closed by short conclusions and bibliographical references.

2 Motivation for Charity and Money Donation People decide to donate to charity programs for various reasons which include social, economic and psychological factors [4, 10, 13]. Experimental research show that charitable giving is strongly influenced by contributions from a social group, e.g. people working together [5]. It is a strong argument in discussion whether building a stable or ad-hoc social network may increase the possibility of donation and amount of money given by individuals belonging to the social network [6]. Another reason to build a social network oriented towards charity projects comes from GivingUSA 2002 report [1], where the main reason why people donated was that they were asked to give by someone whom they knew well. A popular technique, used by governments and employers, for increasing individuals’ motivation for participation in charity giving is gift-matching. In this approach it is assumed that each donation provided by an individual donor is doubled or increased in some extent by offering coming from institutional body. Experimental research in this field showed that matching-gift contribution has positive influence on the possibility that an individual decides to donate and the amount of offered support[7]. Help may be addressed in various forms (medical care, assistance, babysitting, teaching, feeding, offering a job). In many cases, the most convenient form of aid, especially in distributed environment, is money donation. However, what is often addressed by organizations dealing with distributing social help, the value of the aid is low if it cannot change the ability of people in poverty to manage their problems themselves after the initial investment. In other words, the main problem to be solved is not how to give someone a fish but how to give her/him a fishing-rod and teach how to catch a fish in the future. In this field, it seems reasonable, that organizations which address their programs to groups of people have more professional experience, and potency to utilize the effort and resources in well coordinated social programs. On the other hand, aid offered by individual donor directly to another person may be used entirely (without institutional overheads) to appease basic and most urgent needs. An interesting map of motivation and arguments – pros and cons money giving and charity aid may be collected while reading discussions appearing on websites under articles touching charity issues. The hottest discussion observed on Internet forums deals with the problem how direct money-gifts are consumed, whether the donation given to a begging person on a street is used according to declared aim of collection. Doubts about the real use of given money resist many people from supporting begging persons. Observation important for us in our research and efforts to build a website dedicated for collecting money for projects coordinated by NGOs is that people want and expect a kind of report how their money were used, whether their

Models of Charity Donations and Project Funding in Social Networks

457

donation had an influence on the final result of the project and finally they want to know and have satisfaction if their contribution ‘made a change’.

3 Money Giving, Lending and Social Aid Served over the Internet Social activity observed in Internet sites which formed web 2.0 movement has also its reflection or a parallel branch on fields where joined efforts of crowds (social networks) and money donations may lead to successful realization of projects. Approaches used to stream joined good will efforts of people include the following forms: • Crowd-sourcing: an approach commonly used while some tasks are outsourced or delegated to employees or volunteers willing to perform some work on good will bases, for free. This approach is used to produce new pieces of open source software, designing an algorithm or performing complex computational tasks on computers offered by volunteers who install special client-software able to download a task, perform the computations and send results to server which interprets and glue partial results into joined solution of entire problem. • Crowd-funding: it is a special form of crowd-sourcing, where a group of people (a social network) collects money for a particular project. Internet facilities are used for spreading information about the project and possibility to join and donate. Crowd-founding is often used to support victims of natural disasters, to help in publishing first CD by a young music team, supporting projects coordinated by NGOs and, finally, supporting individuals in collecting resources on the way to realize dreams and plans. • Person-to-Person/Peer-to-Peer lending: direct loans offered by a single person to another person. The concept of P2P lending assumes sidestepping banks or financial brokers, which typically play the role of an expensive middleman. Savings coming from direct contact of lender and borrower should provide better discount for the lender when compared to bank deposit and cheaper credit for the borrower when compared to a bank loan. P2P lending may also be an alternative for borrowers who, for any reason, cannot get a loan from a bank. Depending on local law regulations, P2P lending services may have several restrictions, e.g. sum of a single transaction may be limited. Because of 1-to-1 character of P2P lending transactions, risk of each transaction is attributed to lender unless the transactions are insured. One of methods used to minimize the risk of capital lose is diversification of peers who borrow money from a single investor. Reliability (or credibility) of peers increases with growing number of returned loans. Some P2P lending services allow users to provide links to their profiles in other social websites like linkedin.com or goldenline.pl (in Poland) to give more information about themselves. • Social lending: a specific form of direct loans, where transactions are realized within a closed group (social network). A person willing to join the social lending network needs to be invited by a member of the community. Business model, where transactions are realized within a group of friends/colleagues, friends of

458

A. Wojciechowski

friends and so on…, may reduce the risk attributed to money lending. Among the most known private lending sites are: prosper.com and zopa.com. • Micro funding: investing money in start-up projects, artists etc. In majority of cases supported firm or person allows investor to participate in success of financed project. It may be formally guaranteed by a contract. In this sense micro founding plays a role similar to stock market, where new shares are sold to support new investments while shareholders expect rise of stock price in the future as well as dividend. • Charity auctions: last but not least in analyzed here forms of social funding are charity auctions, where various goods (artwork, antics, trophies and ordinary products) are offered for sale with condition that money coming from transaction will support a charity. The purpose of the charity is known to all participants and visitors. A factor that increase competition among bidders is public access to information who wins the auction. Sometimes, participation in a charity auction may also be a form of promotion, especially when name or some ID of bidder is known to the public and auction is broadcasted on a TV channel or the information remains for long on a web pages.

Social lending

Group lending Lendingclub.com Finansowo.pl

P2P lending Crowd funding

Prosper.com Monetto.pl

Peer 2 Peer Micro funding

Aid Kiva.org

Chipin.com Fundable.com

Organizations Donorschoose.com Justgiving,com

Investment Myfootballclub.co.uk Sellaband.com

Charity auctions Charityfolks.com Fig. 1. Forms of donation and investment conducted by social networks and individuals over the Internet

Models of Charity Donations and Project Funding in Social Networks

459

4 Internet Basking for Money Based on Good Will Donations Money collection for charity purpose is a process where an important role must be attributed to trust in organization and people who organize donation and control procedures. Trust that donors have in NGOs which organize social help could easily be liquidated if it comes to the daylight that money donated in public collection were subject of a fraud. This may be a reason why organizing country-wide or international money collection (e.g. conducted over the Internet) is restricted by law and in case of Poland it is allowed for NGOs, while individuals may only organize public money collection after approval from Ministry of Interior and Administration. In practice, it is convenient to organize such a project by an NGO, especially if the organization already has experience in similar actions. Charity is not the only purpose of public money collection. As mentioned in section 3, social funding and micro funding may be oriented towards supporting interesting projects run by individuals. However, lessons learned from our research show that in our case it will be easier to pair an NGO and project inventor (money collector and performer) than organize a public money collection by an individual. Thus, in our proposal of organizational and business model of collection site it will be assumed that all money collections will be organized/controlled by an NGO. Individuals willing to run their own projects financed from public donations may get support from NGOs. In proposed solution, unlike in fundable.com, only NGOs will be allowed to start a collection, however in the description of the collection it might be specified who is responsible (e.g. inventor) for particular project and what are expected results. A prototype application based on business model described in this section was developed in a research project run at Poznan University of Technology, Poland, partially described in [14]. 4.1 Conceptual Model of a New Money Basking Site In description of business model the terms ‘money collection’ and ‘money basking’ may be used alternatively to describe the same process. It is decided that donation process should be as simple as dropping some coins to a basket on a street. The difference of proposed system when compared to basking on the street is in fact that support may only go to projects which have chance to be entirely financed in 100% and every donor gets report on how the money were consumed. The operational schema for proposed money collection site is based on several assumptions selected to increase collection effectiveness: • The community (social network) consist of two types of members: project coordinators (NGOs) and donors (individuals, institutions, etc.). If an individual wants to propose his/her own project (e.g. to plant an oak alley along a private field or to repair a bench in a park), he/she goes to a chosen NGO which may become the project coordinator and ‘opens a basket’ for money collection to support this action. • Each money collection (basket) is described by several attributes: inventor and coordinator, aim of the collection in form of a webpage (title, description: text, photos, etc.), sum of money required for realization and money donated by

460

•

•

•

•

•

•

•

A. Wojciechowski

inventor. Two more attributes are: donated money and declared support (more detailed description is given further in this section). We believe that the bigger part of founding or work comes from the inventor, the more likely it is that project gets acceptance from the rest of society, because higher engagement of inventor expresses his will and determination to complete the project. Money basking website is organized in a form of a social network. Anyone can join the community, however it is preferred if new members are invited by already registered ones. When a new member joins the community after an invitation from another member he inherits credibility from the inviting member. A basket (money collection) for a single project may be opened for restricted time only. However, the period while community members can declare their donations for the project should be long – it is proposed that time limit may not exceed 6 months. Value of a single donations (donation declared by a single community member) is restricted. A donation limit boundary is built by selecting a lower number of two values: e.g. EUR 20.00 or a single donation cannot exceed 4% of all money expected from the social network. Numbers given above are just an example of bounds and actual values used in running system will be adjusted for operational convenience. Social network members may declare their support for selected project. To do this, a logged user declares a sum of money he/she is ready to give. Declared money are not required to be transferred instantly (although it is possible). If a member decides to pay instantly, the money transfer is made directly to the NGO coordinating the project with a note for what purpose the money are given. Every donation paid instantly is calculated as 100% sure money given to the project. From project coordinator’s point of view, we may say, it is a preferred form of giving money. However, because of relatively small values of single donations it is assumed that NGO will not return instant donations to donators, even if the project is not realized because of missing resources. In such an event, money lodged to NGO account from instant donations, may be used by the NGO to support their other projects. Whenever a community member declares support to a project, he/she makes a conditional proposal. The user declares: I will give my money to that project if it has chance to be realized (if it is financed in 100%). Declared donation are totaled separately from instant donations. Because it may happen that declared donations will not be paid by the person who promised to pay, declared donations are multiplied by the donor credibility. For example, if a new member, with credibility of 0.75 declares to donate EUR 10.00, the system counts expected benefit from such declaration as EUR 7.50. Member credibility grows with each declaration fulfilled and with every instant donation. In particular case, it may happen that all members, even those with credibility below 1, pay their declarations, when the collection is finished. According to assumed rules, total money collected from such transactions would exceed the sum required to realize the project. In such case overpaid donations would be saved to cover missing declared donations in other baskets. During the entire period while a project basket is open for donation, besides description of project aims there is a visible information what support was already

Models of Charity Donations and Project Funding in Social Networks

461

offered for the project and how much is still missing. Information about declared offerings is adjusted according to credibility factor of donors who declared their support for this project. • When total of inventor contribution, instant donations and credibility adjusted declared donations cover all required sum of money to realize the project, a message is sent to all project stakeholders. Donators, who declared their support get information that project is to be financed in 100% and they are asked to transfer declared money. Such an approach reduces risk associated with partial covering resources required for the project. • After the project is realized, all its stakeholders receive a report with words of thanks and description how their donations were utilized in the project. 4.2 Procedures to Maximize Probability That Declared Donations Will Be Paid Money giving may bring satisfaction for both sides: for those who receive money to realize their dreams and for those who support useful actions. In many cases even a small donation gives a feeling of participation in a project that brings happiness to other people. To preserve the feeling of safe donation and maximize probability that money donated to projects in basking system are not subject of a fraud several procedures are proposed: • Projects are coordinated by NGOs and all donations are lodged to the NGO’s account. Project expenses at the stage of realization are coved by the organization. • Users not willing to pay instantly without guarantee that project will receive support sufficient for full financing, may donate after the collection is closed and declared donations cover the project requirements. • User credibility attribute assigned to registered members of social network is a measure that helps to estimate how much money must be declared in order to obtain sum required for full financing the project. • Whenever a user does not fulfill his declaration, his/her credibility is lowered, as well as it is reduced the credibility of a user who invited this ‘not reliable’ member to the community. Consequently, the user credibility rise, after successfully paid declared donation, as well as it rises the credibility of a member who invited ‘reliable’ member to the community. • Descriptive status of a member (in sense of credibility) and participated collections is publicly visible and may be a sign of pride for users who actively donate various projects. • Project report is sent to all stakeholders after the project is realized. Receiving such summary of how donators’ money helped to finance a useful action is a form of thanks and good invitation to donors to support similar projects in the future. • In proposed model it is assumed that user’s credibility factor and formulas how it is calculated after a declared donation was/was not transferred are adjusted according to dynamic behavior of social network built around the donation system. The aim of adjusting formulas is to guarantee declared money collection at level sufficient to full financing of projects.

462

A. Wojciechowski

4.3 Technological and Social Network Features That May Affect Money Collection Money collection process based on good will basis requires good scalability. This may be achieved by quick and cheap distribution of information about particular collections among people (social network members) who share the same believes and values. When a new collection begins, an information may be sent to the community members who used to support projects coordinated by the same NGO. The information may be delivered via e-mail or sent directly to users’ mobile devices to keep them in touch with the community. Net of connections between community members is created upon their invitations to the community and shared interest which may be deducted from supporting the same collections. An important role in building the good-will-society is invitation. The link between a community member and an invited person is permanent and the invited member behaviour affects inviting member’s credibility. Once the invited member supports a projects (gives money) he increases his own credibility as well as he increases the credibility of the member who invited him to the community. Empty declarations (not paid after the collection ends) will decrease the member’s and inviting person’s credibility.

5 Conclusions Many social activities and charity projects are financed from public money collections. In era of globalization and expanding social networks it is a natural consequence that basking for money is moving from streets to virtual space where it is easier and cheaper to reach crowds of volunteers and build a community willing to donate. In proposed model of money collection, donations may be transferred after a project collects declared support at the level sufficient for full realization. Applied business model assumes that money given in instant donations are not returned to donors in case if the project is not supported in 100%. However, the money coming from instant donations go directly to an NGO coordinating the project and may be used by the NGO to support similar actions in the future or may increase project inventor contribution when the project calls for support in a new collection. Such an approach is different from existing money collection applications. For example in fundable.com donations are not taken from credit card account if the project does not get 100% support, but such a convenient function has one drawback – time for a single collection is limited to 26 days, as Paypal limits pledges to 26 days. Short period for money collection may be not sufficient to form a strong enough group or users willing to support the aim of the collection. A different approach if assumed in website siepomaga.pl, where money collections are not limited in time, and they remain active until they are fully paid by instant donations. Approach assumed in proposed model is a compromise solution. There is a possibility of instant donations as well as it is possible do declare a conditional donation, which will be transferred if the projects gets full support. Because, support declarations can be realized in long term, time for particular money collections has

Models of Charity Donations and Project Funding in Social Networks

463

not to be limited to a very short period. In order to keep the system free from projects which do not get social acceptance and support it is recommended that a single money collection should not last longer than 6 months. Good will character of donations in proposed model is expressed in two step procedure (initial declaration and money transfer performed after project gets full support). Assumed business procedures based on user credibility factor may guarantee that all the money required to realize projects will be covered from public collection conducted in the system.

References [1] American Association of Fundraising Counsel Trust for Philanthropy. Giving USA 2002, American Association of Fundraising Counsel Trust for Philanthropy (2002) [2] American Association of Fundraising Counsel Trust for Philanthropy. Giving USA 2007, American Association of Fundraising Counsel Trust for Philanthropy (2007) [3] American Association of Fundraising Counsel Trust for Philanthropy. Giving USA 2008, American Association of Fundraising Counsel Trust for Philanthropy (2008) [4] Andreoni, J.: Philanthrophy. In: Handbook of Giving, Reciprocity and Altruism. Elsevier/ North-Holland (2004) [5] Carman, K.G.: Social Influences and the Private Provision of Public Goods: Evidence from Charitable Contributions in the Workplace. Stanford Institute for Economic Policy Research, Discussion Paper No. 02-13 (January 2003) [6] Ghosh, A., Mahdian, M.: Charity Auctions on Social Networks. In: Proceedings of the nineteenth annual ACM-SIAM symposium on Discrete algorithms, Society for Industrial and Applied Mathematics, pp. 1019–1028 (2008) [7] Karlan, D., List, J.A.: Does Price Matter in Charitable Giving? Evidence from a LargeScale Natural Field Experiment. American Economic Review 97(5), 1774–1793 (2007) [8] Lin, N.: Social Capital: A Theory of Social Structure and Action. Cambridge University Press, NY (2001) [9] Martin, R., Randal, J.: How Sunday, price, and social norms influence donation behavior. Journal of Socio-Economics (in press) (Corrected Proof, Available online April 5, 2009) [10] Ribar, D., Wilhelm, M.: Altruistic and Joy-of-Giving Motivations in Charitable Behavior. Journal of Political Economy 110(2), 425–457 (2002) [11] Sims, S.: Why Do People Donate to Charitable Causes, http://www.stepbystepfundraising.com/ why-do-people-donate-to-charitable-causes/ (August 15, 2007) [12] Smith, M.S.: Social capital in online communities. In: Proceedings of the 2nd PhD workshop on Information and knowledge management, pp. 17–24. ACM, New York (2001) [13] Vesterlund, L.: Why do people give? 2nd edn. The Nonprofit Sector. Yale Press (2006) [14] Wesolowski, R.: Internet community system for on-line basking for money, master thesis developed at Poznan University of Technology, Poland, under supervision of Wojciechowski A., Poznan (2008)

Mobile Context Provider for Social Networking Andr´e C. Santos1 , Jo˜ ao M.P. Cardoso2, Diogo R. Ferreira1, , and Pedro C. Diniz1 2

1 IST – Technical University of Lisbon, Portugal Faculty of Engineering, University of Porto, Portugal [email protected]

Abstract. The ability to infer user context based on a mobile device together with a set of external sensors opens up the way to new contextaware services and applications. In this paper, we describe a mobile context provider that makes use of sensors available in a smartphone as well as sensors externally connected via bluetooth. We describe the system architecture from sensor data acquisition to feature extraction, context inference and the publication of context information to well-known social networking services such as Twitter and Hi5. In the current prototype, context inference is based on decision trees, but the middleware allows the integration of other inference engines. Experimental results suggest that the proposed solution is a promising approach to provide user context to both local and network-level services.

1

Introduction

The processing capabilities of mobile devices coupled with portable and wearable sensors provide the basis for new context-aware services and applications tailored to the user environment and its daily activities. To enable such kind of services, mobile devices must be able to clearly and accurately identify specific user contexts [1,2]. For this purpose, mobile devices can be augmented with sensors that yield information such as position, lighting or sound, from which specific user contexts can be determined. In this paper we present a prototype system consisting of a smartphone augmented with an array of sensors connected via bluetooth, and we describe the use of this system as a context provider for social networks. The system is an evolution of a previous prototype [3] and it is able to learn a set of given contexts and to identify the user context dynamically at run-time. The new prototype described in this paper is also able to publish context information to social networking services. The success of social networking services such as Facebook, Hi5, LinkedIn and Twitter and their increasing use via mobile devices suggest that there is an interest and potential in providing users with mechanisms to automatically keep up to date with their peers. The paper is organized as follows. We begin with a description of related work in the area of sensing and context inference. Then we present the approach and 

Corresponding author.

R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 464–473, 2009. c Springer-Verlag Berlin Heidelberg 2009 

Mobile Context Provider for Social Networking

465

the implemented system: its sensors, architecture, and operation through data acquisition, preprocessing, feature extraction, and context inference. Finally, we describe how the system publishes user context to well-known social networking services, namely Twitter and Hi5.

2

Related Work

Context identification has been recognized as an enabling technology for proactive applications and context-aware computing [4,5]. Early context-aware applications were predominantly based on user location defined as typical user places (e.g., “at home”, “in a museum”, “in a shopping center”). Projects such as GUIDE [6] and Cyberguide [7] addressed the use of information about location and situation to guide the user when visiting tourist attractions. Recent work has addressed techniques to identify a richer set of contexts or activities. These include simple user activities (e.g., “walking”, “running”, “standing”), environment characteristics (e.g., “cold”, “warm”), or even emotional condition of the user (e.g., “happy”, “sad”, “nervous”). Usually, the identification of contexts is performed in several stages. Processing raw data from sensors may require a wide variety of techniques such as noise reduction, mean and variance calculation, time- and frequency-domain transformations, estimation of time series, and/or sensor fusion. Then context inference itself has been addressed using different techniques such as Kohonen Self-Organizing Maps (KSOMs) [8], k-Nearest Neighbor [9], Neural Networks [10], and Hidden Markov Models (HMMs) [11]. Some approaches also combine several of these techniques, as described in [12]. Regarding the inference of user activities such as “walking” or “running”, there have been a myriad of approaches, ranging from simple processing steps and threshold operations [13,14,2] to the use of neural networks as a clustering algorithm [10]; or even using non-supervised time-series segmentation [15]. As an example, the work presented in [1] infers activities such as “walking”, “running”, “standing”, and “sitting” with a single 3-axis accelerometer. With the increasing popularity of social networking services, context information finds a new role in enabling interaction between members in a community. In [16], for example, the authors present the Meeting Room Assistant application, a hyper-local facilitator where context is used to enrich communication between participants in real-life meetings, in a similar way to what social networking services achieve on the web. In the work presented in this paper, we extract signal features using techniques similar to those described in [2,14]. For context inference we combine signal-processing and machine-learning techniques, using decision trees [17] to fuse features and to identify user activities. All data preprocessing and context inference is performed on the mobile device. The results can be published to a remote server in order to aggregate information from multiple users, thus allowing for more advanced and possibly non-local context inferences. Our work focuses in particular on the publication of context information to well-known social networking services.

466

3

A.C. Santos et al.

System Prototype

The driving goal for this work is the ability to identify user context using a set of sensors connected to a mobile phone. The sensors should be relatively small in order to be embedded in clothes or personal items such as backpacks or purses. Sensors include accelerometers, light, sound, humidity, temperature and GPS sensors, and also virtual sensors to acquire information such as time of day and calendar events, which can be retrieved directly from the mobile device. Figure 1(a) depicts the main components of the system prototype: the mobile device, a sensor-aggregating node, and a set of sensors. The black box contains the batteries (the 1-Euro coin is shown to provide an idea of scale). Figures 1(b) and 1(c) depict experimental setups where the components are embedded in a backpack and on a vest, respectively. The vest prototype is an evolution from the earlier backpack model. These experimental prototypes were used for testing purposes and therefore have deliberately unconcealed sensors in order to better evaluate sensitivity to the environment to ensure that the sensors experience approximately the same conditions as the user.

(a) System components.

(b) Backpack prototype. (c) Vest prototype.

Fig. 1. System components and experimental prototypes

Currently, the system is being used with either the Sony Ericsson W910i mobile phone or the Nokia N95 mobile phone, but it can be easily deployed to other smartphones as well. There is a BlueSentry external sensor node that communicates with the smartphone via bluetooth to provide sensor readings, thus avoiding the need for physical connection between the two. With respect to sensors, the prototype includes sound, temperature, light, and humidity sensors, and a 3-axis accelerometer, all wired to the sensor node. In addition to these, there are three other sensors being used, namely the internal accelerometer of the smartphone, a virtual time sensor to provide the time of day from the system clock, and an additional external node which is a bluetooth GPS receiver. 3.1

System Architecture

The system makes use of supervised learning techniques to determine user context. During a training period, the system collects a sufficient number of

Mobile Context Provider for Social Networking

467

manually classified examples in order to induce a decision tree that will be used for context identification. After this training phase the system operates autonomously and unobtrusively by automatically determining the present context from sensor readings. The overall system architecture is presented in Figure 2.

Fig. 2. System architecture with layer description and communication connections

At the lowest level, sensors gather data from the environment and provide it as raw analog signals to the sensor node, which in turn converts them to digital form and transmits them to the smartphone via bluetooth. The application layer has been developed using the J2ME platform. The mobile phone runs a proprietary operating system which supports J2ME MIDlets. With the help of a Mobile Information Device Profile (MIDP), the application acquires raw sensor data from both the internal sensors and external sensor nodes, namely the BlueSentry aggregating node and the bluetooth GPS sensor. The system operates according to four main stages: a sensor data acquisition stage; a preprocessing and feature extraction stage; a context inference stage; and a publication stage. Sensor data acquired from the available sensors are fed

468

A.C. Santos et al.

to the preprocessing stage, which is responsible for extracting signal features to be used in the upper layers of the system architecture. The inference stage gathers these features and determines the present context according to a set of rules. These rules are available in the form of a decision tree that has been built during the training phase. Finally, the mobile device, upon having recognized a specific context, can provide that information to network-level services. 3.2

Application Layer

Figure 3 provides some screenshots of the application running on the smartphone. It presents a simple user interface, allowing different modes to be chosen from a list of available options (Figure 3(a)). It also includes the possibility of editing existing contexts (Figure 3(b)) and printing the decision tree for debugging purposes. Figure 3(c) presents an example of the initial configuration for the continuous training mode which acquires sensor data during a period of time when a certain context is active. In Figure 3(d) shows the different sensor readings and the identified context, as well as a confidence value calculated as the percentage of total records for the displayed context within a fixed-size buffer window. A suggestive icon, when available, is also presented to the user.

(a)

(b)

(c)

(d)

Fig. 3. The application in selection mode (a), in context-editing mode (b), in learning mode (c) and in operation mode (d)

3.3

Sensor Data Acquisition

Sensor data are acquired at a fixed rate. At regular intervals, the smartphone sends a request to the sensor node in order to retrieve data from the connected sensors. The sensor readings are buffered in the smartphone in order to allow a time-framed window preprocessing stage. It is worth noting that sensors may have different acquisition rates. The difference in sampling frequency may force the acquisition to run at the slowest rate, or at individual rates for each sensor. Currently, the system is using the same acquisition rate for all sensors, except for the internal accelerometer of the smartphone, which is being sampled at twice the rate of other sensors.

Mobile Context Provider for Social Networking

3.4

469

Preprocessing and Feature Extraction

The preprocessing stage prepares the raw sensor data to be converted into a finite set of features or categories. While for some sensors the raw sensor value can be mapped directly to a category, other sensors such as the accelerometer need more elaborate preprocessing. Typically, preprocessing involves a set of techniques such as averaging, filtering or transforming values. Rather than using instant values, the system averages signals over a buffer window in order in order to minimize jitter and to provide a more accurate categorization. Table 1 presents the categories and their corresponding value range for each sensor. Table 1. Categorization of sensor values after acquisition Sensor

Category very silent silent sound moderate loud very loud very dark dark light normal bright very bright indoor GPS outdoor position lying accelerometer standing

Calculation 0% — 20% 20% — 40% 40% — 60% 60% — 80% 80% — 100% 0 lx — 200 lx 200 lx — 400 lx 400 lx — 600 lx 600 lx — 800 lx 800 lx — 1000 lx no signal signal gravity xz-plane gravity y-axis

Sensor

Category Calculation very cold −50◦ — 0◦ cold 0◦ — 15◦ temperature mild 15◦ — 25◦ hot 25◦ — 30◦ very hot 30◦ — 150◦ dawn 0h — 5h morning 6h — 11h time afternoon 12h — 17h night 18h — 23h movement not moving low variance accelerometer moving high variance moving fast variance- and FFT-based low 0% — 30% humidity medium 30% — 70% high 70% — 100%

For the movement accelerometer, which is internal to the smartphone, the system has more complex preprocessing. It computes the variance for each axis within a time-framed window which captures the last 16 samples. The three axis variances are compared to a threshold in order to identify the “moving” and “not moving” categories. When “moving” is detected, the system performs an FFT (Fast Fourier Transform) over the last 32 samples and adds up the amplitude of the harmonics for frequencies within the range from 0.5Hz to 2Hz. If the resulting value is greater than a specific threshold value then a category of “moving fast” is reported. Otherwise, the output will be reported simply as “moving”. 3.5

Context Inference

At any given moment, the collected set of sensor readings will bear some relationship to the current user activity. The purpose of context inference is to discover this relationship so that when similar readings occur the device will recognize the same context. The current prototype uses decision trees for context inference. They are fast to build and process, making them attractive for implementation on mobile devices. From a set of training examples it is possible to induce a decision tree

470

A.C. Santos et al.

in order to classify contexts according to sensor readings. The implementation is based on the ID3 algorithm [18], which uses information entropy to build the smallest tree that can correctly represent all branches. Figure 4 depicts an example of an induced decision tree. The contexts depicted in this decision tree are an example of the type of activities that the system can be trained to recognize. The tree has paths from root to leaf nodes that effectively provide the rules for context identification based on sensor readings. For example, if the user is not moving and the sound level is moderate, then the context is “working”. In this example, the movement accelerometer provides the most distinctive feature, followed by the sound and GPS sensors, and only then by the position accelerometer and the virtual time sensor.

Movement Accelerometer Not Moving Moving Sound Very Loud Silent Position Accelerometer Lying Time Night Sleeping

Dawn

Meeting

Walking

Moderate

Working

Moving Fast

GPS

Indoors

Exercising

Outdoors

Running

Standing Reading

Afternoon Resting

Fig. 4. Example of an induced decision tree depicting several contexts and the sensor readings through which they can be identified

The decision tree shown in Figure 4 can be induced from a set of training examples collected during a training period. One such example is, for instance: {sound = moderate; light = very bright ; temperature = mild ; humidity = medium; pos.acc. = standing; mov.acc. = not moving; time = afternoon; gps = indoors; context = working}. When the user sets a context and a training period as in Figure 3(c), the system collects sensor readings during that period and classifies the readings as training examples for the specified context. The training examples are then used to update the decision tree. At runtime, the context identified via the decision tree is stored in a buffer window which gathers a finite number of records and returns the context that has been recorded more often within that time window. This avoids momentary conditions that would make the context change unexpectedly, and also provides a mechanism for the system to assign a confidence level to the context that has

Mobile Context Provider for Social Networking

471

been inferred. Together with sensor data buffering, this provides another layer to mitigate errors due to faulty sensor readings or due to activities that are detected for only a brief moment within a different context. 3.6

Context Publication

The context can be published, upon user permission, to an external server. This has several advantages. First, it is possible to enable, disable or change the behavior of value-added services that depend on user context. Second, user context can be augmented with information available at the network level, such as traffic conditions or special services available at the user location. Third, the publication and availability of user context at the network level opens up the way to other applications such as social networking, remote monitoring, health assistance, etc. Context publication also provides network services with the ability to gather aggregated data on multiple users in order to study different user profiles.

4

Application to Social Networking

Social networking has become increasingly popular with the rise of web-based communities in which users interact with their peers on a regular basis. Social networking services such as Facebook, Hi5, LinkedIn or Twitter nowadays bring together a large number of users. Most of these services provide public APIs with the means to access, configure and update the user profile, status, etc. This allows external systems to publish content to a user profile. Twitter is a well-known social networking and micro-blogging service on which users can interact using short messages, no longer than 140 characters. We use the above system prototype to publish the current user context to a Twitter account. Periodically, the present context is submitted via HTTP through a Wi-Fi or GPRS/3G connection to the Twitter servers. The publication is accomplished using a REST API. Figure 5(a) presents a screenshot from the Twitter service, showing contexts published automatically by the system. The same approach can also be used with other social networking services such as Hi5. This is one of the most successful web-based social networks with around 60 million users. The service allows users to create an online profile and populate it with information about interests, age and location, along with personal photo albums and music preferences, to be shared with friends. Similar to Twitter, the Hi5 service allows the user to post a status message to the network with information about the current activity the user is doing. Our system automates this task by publishing the user context periodically, so that the user profile is always up-to-date. For this purpose the system uses a Wi-Fi or GPRS/3G connection, whichever is available at the moment, and makes a remote call using the official REST API. Figure 5(b) presents a screenshot from a Hi5 profile page, where the status message is being published automatically by the system. Other possibilities include changing the user photo or changing the online/offline/away/busy state according to the present context, as well as tagging content with the current user context.

472

A.C. Santos et al.

(a) Twitter website.

(b) Hi5 personal user profile.

Fig. 5. User context publication to Twitter and Hi5

5

Conclusion

Being able to gather and publish information about user context can be very useful for social networking, as it enables real-time interaction between peers. In this paper we described a prototype system based on a set of general-purpose, inexpensive sensors connected to a smartphone via a bluetooth-enabled sensor node. The current prototype is implemented in a vest and executes all stages from sensing to context inference in the smartphone. It is now a fully operational context provider that operates in an unobtrusive manner after an initial training period, and that is able to publish the user context to well-known social networking services such as Twitter and Hi5. In ongoing work, we are evaluating the use of other context inference techniques, and we are also investigating the possibility of inferring emotional contexts such as happy, calm, unhappy, and hungry, in order to publish this information to social networks.

References 1. Kawahara, Y., Kurasawa, H., Morikawa, H.: Recognizing user context using mobile handsets with acceleration sensors. In: IEEE Intl. Conf. on Portable Information Devices (PORTABLE 2007), pp. 1–5 (2007) 2. Welbourne, E., Lester, J., LaMarca, A., Borriello, G.: Mobile context inference using low-cost sensors. In: Strang, T., Linnhoff-Popien, C. (eds.) LoCA 2005. LNCS, vol. 3479, pp. 254–263. Springer, Heidelberg (2005) 3. Santos, A.C., Tarrataca, L., Cardoso, J.M.P., Ferreira, D.R., Diniz, P.C., Chainho, P.: Context inference for mobile applications in the UPCASE project. In: Proc. 2nd Intl. Conf. on Mobile Wireless Middleware, Operating Systems, and Applications (MOBILWARE 2009). LNICST, vol. 7, pp. 352–365. Springer, Heidelberg (2009) 4. Coutaz, J., Crowley, J.L., Dobson, S., Garlan, D.: Context is Key. Communications of the ACM 48(3), 49–53 (2005) 5. Hull, R., Neaves, P., Bedford-Roberts, J.: Towards situated computing. In: Proc. of the Intl. Conf. on Wearable Computers (ISWC 1997), pp. 146–153 (1997)

Mobile Context Provider for Social Networking

473

6. Cheverst, K., Davies, N., Mitchell, K., Friday, A.: Experiences of Developing and Deploying a Context-Aware Tourist Guide: The GUIDE Project. In: Proc. 6th Annual Intl. Conf. on Mobile Computing and Networking, pp. 20–31. ACM, New York (2000) 7. Abowd, G., Atkeson, C., Hong, J., Long, S., Kooper, R., Pinkerton, M.: Cyberguide: A Mobile Context-Aware Tour Guide. In: Proc. of the Intl. Conf. on Mobile Computing and Networking (MobiCom 1996), pp. 421–433 (1996) 8. Laerhoven, K.V.: Combining the kohonen self-organizing map and k-means for online classification of sensor data. In: Artificial Neural Networks (ICANN 2001), pp. 464–470 (2001) 9. Laerhoven, K.V., Cakmakci, O.: What shall we teach our pants. In: Proc. Fourth Intl Symp. Wearable Computers, ISWC 2000 (2000) 10. Randall, C., Muller, H.: Context awareness by analyzing accelerometer data. In: Proc. 4th Intl Symp. on Wearable Computers (ISWC 2000), October 2000, pp. 175–176 (2000) 11. Skaff, S., Choset, H., Rizzi, A.: Context identification for efficient multiple-model state estimation. In: Proc. of the IEEE/RSJ Intl. Conf. on Intelligent Robots and Systems (IROS), San Diego, CA, USA, October 2007, pp. 2435–2440 (2007) 12. Krause, A., Smailagic, A., Siewiorek, D.: Context-aware mobile computing: Learning context-dependent personal preferences from a wearable sensor array. IEEE Trans. on Mobile Computing 5(2) (February 2006) 13. Healey, J., Logan, B.: Wearable wellness monitoring using ecg and accelerometer data. In: Proc. of the Ninth IEEE Intl. Symp. on Wearable Computers (ISWC 2005), pp. 220–221. IEEE Computer Society Press, Los Alamitos (2005) 14. Si, H., Kawahara, Y., Kurasawa, H., Morikawa, H., Aoyama, T.: A context-aware collaborative filtering algorithm for real world oriented content delivery service. In: Proc. of ubiPCMM (2005) 15. Himberg, J., Korpiaho, K., Mannila, H., Tikanm¨ aki, J., Toivonen, H.: Time series segmentation for context recognition in mobile devices. In: Proc. of the 2001 IEEE Intl. Conf. on Data Mining (CDM 2001), Washington, DC, pp. 203–210. IEEE Computer Society Press, Los Alamitos (2001) 16. Joly, A., Maret, P., Daigremont, J.: Context-awareness, the missing block of social networking. International Journal of Computer Science and Applications 4(2) (February 2009) 17. Quinlan, J.: Induction of Decision Trees. Machine Learning 1(1), 81–106 (1986) 18. Quinlan, J.: C4.5: Programs for Machine Learning. Morgan Kauffman, San Francisco (1993)

Personalized Services Oriented towards Commercial Establishments David Marin Díaz, Alejandro Rico Zuluaga, and Angela Carrillo-Ramos Pontificia Universidad Javeriana, Computer Science Dept., Bogota, Colombia {jose-marin,rico.e,angela.carrillo}@javeriana.edu.co

Abstract. This paper presents the platform “PlaSerEs”, whose main objective is to provide information about the products y/o services offered by commercial establishments to their clients in a personalized way. This platform is structured in four layers: i) the adaptation layer, composed of four modules: the one of the context, the one of the access device, the one of the user and the one of the wireless connection. The latter is one of the main contributions of this work. ii) The general services layer, iii) the personalized services layer and iv) the application layer. In order to validate and to evaluate how “PlaSerEs” works, we developed a functional prototype for a restaurant. Keywords: Personalization, Mobile Applications, Nomadic Users.

1 Introduction When a nomadic user1 accesses different Information Sources (IS) through his/her Mobile Device (MD), the information, which is displayed, does not take into account his/her needs, his/her characteristics, his/her preferences nor the characteristics of the context of use2 [10][11]. Traditionally, the obtained results correspond to generalized information. Any user, without considering who or where he/she is, upon executing a query, he/she will obtain the same results and, additionally, it would not be optimized the fact that the systems can provide the information without an exhaustive and constant intervention of the user [4]. The act of guaranteeing to a nomadic user the access to several IS through MD [13], and the adaptation of the information as much his/her profile as his/her context of use[14] [9] are two problems actually reason of research which are not solved together [12]. Nomadic users who access several IS can obtain like answers to their different queries a great volume of information that is not always relevant and, sometimes, it is not supported by his/her MD. When a nomadic user wants to request the different services and/or products provided by commercial establishments, these establishments provide them through generalized portfolios and catalogues for any public. The information resulting of 1

Nomadic users are those who constantly change their location. It is important to note that conditions of information access and the request of services/products by nomadic users have changed, for example, the access through MD, the relevance of user’s preferences, contextual characteristics, etc. 2 For this paper, the terms “context of use” and “context” are used like synonym. R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 474–483, 2009. © Springer-Verlag Berlin Heidelberg 2009

Personalized Services Oriented towards Commercial Establishments

475

these queries is provided without considering the needs of each one of their clients. Also, their publicity is done through announcements in massive means of communication or using posters inside the establishments, trying to maintain or to attract to their clients only with good prices and good products without offering more additional services fit to the user's characteristics [6]. Actually, some establishments have done efforts in pleasing to their clients, giving them products and services “custom-made”. According to Jeff Bezos, founder and executive in chief of Amazon.com, such establishment wants to give to the virtual business, the personal touch that the business without technology had. In this way, a completely different and personalized page is presented. This page considers as much the preferences and the previous purchases, as data provided by the client at the moment of registering at the system. Bezos affirms: "If we want to have 20 million customers, then we want to have 20 million' stores'”. Considering the actual situation that we have exposed, we found a very valuable opportunity in the fact of offering to the commercial establishments, certain services that allow to the establishments to provide to their clients adapted information according to their preferences, their MD and their context. The interest of this paper focuses on helping to commercial establishments to the fast and better attention to their clients. Among the awaited characteristics by the clients in order to make indeed the tests in nomadic environments, are: i) clients equipped with MD; these MD must be equipped with some kind of wireless connection. ii) The user’s expectative as far as the quality in service must be high. This paper is organized in the following way: section 2 presents “PlaSerEs”, platform which provides personalized services to clients of commercial establishments, main contribution of this work. Section 3 shows an application of “PlaSerEs” in the real world. We developed a prototype aimed at a restaurant. In section 4, we analyze some related works. In section 5, we conclude and present some perspectives of this work.

2 PlaSerEs PlaSerEs (acronym of Plataforma de Servicios personalizados para Establecimientos Comerciales, Platform of Personalized Services for Commercial Establishments, see Fig. 1) allows to take into account different aspects of the user, his/her access device and his/her context in order to display adapted information when he/she requests certain services to commercial establishments. This section describes in detail each component of this platform. From the need of adaptation present in the actual systems, the concept of a model which has diverse aspects arises, specially, for adaptation oriented to the content, to the presentation and to the connection. This adaptation model takes into account: i) The content, based on a user profile and a context profile, ii) the presentation of the information using a MD profile and iii) the connection of both, the establishment and the MD. In PlaSerEs, the content module is composed of the user profile model and that of the context. The user profile model adapted from work of Carrillo et al. [4] describes the user preferences with regard to four main aspects: i) activity preferences which correspond to the user characteristics with regard to activities executed by user in the

476

D. Marin Díaz, A. Rico Zuluaga, and A. Carrillo-Ramos

system and the way in which he/she executes them. These activities are registered in a historical file which is used in order to determine possible user behaviors. Additionally, the user preferences are considered. These preferences are related to the specific application, for example, culinary preferences if the application is for a restaurant. Finally, it is necessary to specify his/her work in order to determine which information can be relevant. ii) The basic user data such as the name, gender, age, birth place and residence place are used for personalizing the content of the information which will be given as result of each query. Depending for example of the gender, different products or services are offered. iii) Additionally, we consider the result preferences and the display preferences which correspond to that; that the user wants to see displayed on his/her MD, specially, making reference to the display format, the multimedia data which prefers (e.g., images, videos), all this evaluated considering his/her basic data and the characteristics of his/her MD profile. The remainder of information about the way of representation and the MD information is contained in the MD profile. iv) Finally, we have environmental and socio-cultural constraints which limit the abstraction of the user to certain conditions of the context. For example, if he/she is in the cinema, his/her behaviors (and preferences) are different than those he/she would have if he/she were in a soccer stadium with his/her friends. This information is obtained from the context profile explained below in this section. In Fig. 2a, we present the components of the user profile and its relations with other components of the adaptation model.

Fig. 1. Architecture of the platform “PlaSerEs”

The context model proposed by Kirsch-Pinheiro et al. [8] describes five dimensions: i) What?: are the services which can be presented in this place and at this moment. It depends on the information provided by the IS to which user is connected. ii) When?: establishes the temporal constraints that the application has. User can determine in which moment to execute certain activities. iii) Who?: determines to whom belongs to the profile relating it with the user profile and in this way, to determine the characteristics which can influence in the adaptation of the information. The other data of this profile are used for describing the context that the system has at the moment of the query. What day is today?, What time is it?, What is the actual

Personalized Services Oriented towards Commercial Establishments

477

weather?, What is the season? And, What is the kind of establishment where the user is located? Fig. 2b shows the components of the context model and its relations with the other components of the adaptation model of the superior layers of PlaSerEs.

Fig. 2. (a) User profile Model. (b) Context profile Model.

The presentation module has as objective to consider the characteristics for taking into account, in order to display the information on the MD; it is composed of the MD profile model and it is defined using the extensions of CC/PP (acronym of Composite Capabilities/Preferences Profile) presented by Indulska [7]. The great advantage provided by this module is the possibility of knowing when to limit or to expand, according to its case, the quantity of information and the way in which it is given, being useful to the maximum the MD capabilities and, at the same time, do not overload it. Such overload can occur, for example, when users receive very large sized messages. The first that is taken into account is the information which the CC/PP [15] standard provides, divided in three main groups: a) the hardware platform which has information about processing speed, memory, autonomy with regard to the battery duration and to the screen resolution (width and height). b) The software platform has information about the versions of the operating system and the supported formats. And finally, c) the individual applications show information about the applications like browsers with their different versions and manufacturers. After these layers, we can find user data related to his/her MD. That is, the user preferences with regard to: i) the specific metrics defined by user that the MD will try to fulfill such as, not to wait more than X seconds in order to display information, and so would prevent showing it, for example, in video. ii) The spatio-temporal context, when and where the user wants to see displayed the information. The MD can determine, according to the user preferences, if certain information can be displayed. For example, if the user does not want to be interrupted while he/she sleeps and so, if the MD is turns on and no silence mode, in this period, any event will be reported as a sound. On the user layer, we can find the session preferences which are a particularization of any preferences just mentioned but that are only valid for that session. They are used in order to consider exceptions which are not in contradiction

478

D. Marin Díaz, A. Rico Zuluaga, and A. Carrillo-Ramos

with the profile, having for example, a behavior which is not permanent. For example, a person can have like one of his/her permanent preferences that all requested information does not have a delay superior to five seconds for loading; if a Sunday such user wants to watch all the news in video (thus, loading delays more than five seconds), it is possible to display this information on his/her MD and the latter must put this preference as “temporal” one in order to establish his/her preference for the video format. Fig. 3a presents the MD profile module.

Fig. 3. (a) MD profile Model. (b) Connection Wireless Module.

The connection wireless model (see Fig. 3b) has four main modules which accomplish with the function of collecting information that can be considered in order to connect the MD in the best possible way in a determined moment: i) The hardware module takes into account the communication interfaces of the device with which he/she wants to access to the information, and the communication infrastructure of the IS. The communication interfaces correspond to those adapters installed into the MD which allow the connection (e.g., Bluetooth, IrDa, Wi-Fi). The concept of infrastructure corresponds to the set of devices which are present in the environment and which allow the reception of connection and communication requests from the MD (e.g., access points). ii) The software module takes into account the communication protocols and the respective operating systems supported as much by the IS as by the MD in order to validate the interoperability between the different hardware devices (defined in the hardware module). iii) The logical module has a decision tree which is crossed by levels, allows the selection of the more adequate technology considering as reference the characteristics: a) of the application, b) of the users and c) of the data which will be managed in the system. This decision tree does not takes into account own characteristics of the network nor those of the MD because this information is managed by the hardware and software modules. iv) The taxonomic classifier module extracts the characteristics from the hardware, software and logical modules: a) of the network to which MD is connected, b) of the MD, c) of the application, d) of the users and e) of the data, in order to select the best

Personalized Services Oriented towards Commercial Establishments

479

configuration to be used by the application. This classifier notifies which is the best configuration, for example, Bluetooth, Wi-Fi, 3.5G. On the adaptation layer, we find the general services layer which consists in an implementation of services such as: i) Reservation of a turn at the arrival to the establishment, notifying to the client at the moment in which he/she can be attended in order to acquire or to use the different products/services of the establishment. ii) Query of the catalogue of products/services using his/her MD, in the way in which the client could have the needed information displayed without executing an exhaustive information search. iii) To make his/her order according to a catalogue. iv) Shipment of promotions and messages with general information to each user according to his/her profile and his/her interests. Above the general services layer, we can find the personalized services layer. The objective of this layer is to particularize the general services to a specific commercial establishment, adapting to the establishment needs. For example, the general service “Show catalogue” for the specific case of a restaurant, corresponds to “Show menu” in the personalized services layer. In addition, it is necessary to consider the adaptation layer in order to personalize the information to be displayed on the MD. Above the adaptation and general and personalized services layers, we find the layer in which the application or the specific prototype of the commercial establishment executes. In this layer, graphics interfaces are built and the mechanisms of getting user information which will be processed by the remainder of layers. This interface does not do the adaptation process. It is only the input/output interface which provides needed information to the lower layers in order to process the queries. For the study case of this paper, we developed a prototype and its respective tests, oriented to a restaurant.

3 Study Case of a Restaurant As we present in previous sections, PlaSerEs is aimed at helping to the commercial establishments to provide a best information service to their clients. A kind of these establishments is the restaurants which take care of millions of people daily. We consider that the restaurants become a complete case of study that shows how PlaSerEs would work in the real world. Fig. 4 shows for each layer of the architecture, which content could be present and what kind of information or services each module can provide. In order to evaluate the behavior of PlaSerEs, a prototype for a restaurant was developed. This prototype uses the adaptation model of the platform in order to display the information in the most adequate way according to the user characteristics and his/her context. PlaSerEs offers a screen which allows access to the users registered in the system. The new users must register in the system. The registry of new users is done by means of a screen, in which they enter their personal data in order to complete their user profile. The preliminary registry can finish in the previous screen but the prototype allows establishing preferences about the restaurant menu, the ingredients or the maximum value of the bill that user wishes to pay. All of these constraints are included in the preferences screen (see Fig. 5a). When the user is just registered in the system and enters successfully to the system, he/she finds the main menu. This menu contains all the services provided by the prototype. Each one of the services, which can be accessed from this interface, is the

480

D. Marin Díaz, A. Rico Zuluaga, and A. Carrillo-Ramos

Fig. 4. Platform PlaSerEs used for a restaurant

Fig. 5. (a)Screen of entering the preferences in the prototype of a restaurant located in Bogota. (b) Screen of the menu of the prototype.

personalized services of the platform. These services show how the general services are personalized for the specific case of a restaurant. For example, “Show menu” (specialization of the general service “Show catalogue”) is the first service to which the user can access from the main menu. In this screen, we can see the adaptation of the information because it takes into account the preferences that the user entered in the preferences screen (see Fig. 5a). In the interface of “Show menu” (Fig. 5b), we can see the products which are available for the user. These products are ordered, showing at the first places, those whose preference will be higher and eliminating of

Personalized Services Oriented towards Commercial Establishments

481

the list, those of which the user does not like. When a user is going to order a product, an additional screen is displayed. In this screen, detailed information is shown with the ingredients and the price of them. Such information is shown in order so the user can be sure that the product which is going to be ordered will be of his/her taste. At the desired moment, a user can query the value of his/her bill and the products that he/she has consumed until the moment; the screen of bill control considers the budget restriction included by the user in his/her preferences. A message will be displayed when he/she will be very close or he/she just passed in front of this establishment. This service is a specialization of the “bill control”. There is a screen which shows the actual promotions in the establishment and they are shown, ordered according to the user preferences related to the products. The establishment makes the promotions effective, communicating directly to the establishment and applying it to his/her bill. This service is a specialization of “shipment of promotions”. At last, we find the screen which allows to make a reservation of table for the user who has not entered in the establishment and the service allows her/him, in addition, to configure his/her reservation in terms of the number of people who will be on the table and if the user wants to have his/her table in a smokers or non-smokers section. This screen also allows including a cellular phone number to which the user will be informed, (using SMS) that the reserved table is ready. This service is a specialization of “To reserve a turn”. After knowing in a detailed way the PlaSerEs platform, in the following section some related works are described. These works are related to the adaptation of information and ubiquitous computing, aspects considered at developing this platform.

4 Related Works “PlaSerEs” is a platform which relates the concepts of ubiquitous computing and adaptation in order to provide services to the clients of the commercial establishments. Table 1. Related Works with ubiquitous computing and adaptation subjects MyCampus[5] Ubiquitous access Adaptation to content Adaptation to presentation Adaptation to MD Adaptation to context

AMIGO[1]

ASAM[3]

Berhe et al[2]

PlaSerEs

+

+

+

+

+

the

+

+

+

+

+

the

?

?

-

?

+

the

-

-

+

-

+

the

+

+

+

+

+

In the Table 1, we can find a comparison among some works which apply the concepts of adaptation or personalization combined with the basic concepts of the ubiquitous computing. In addition, it is important to highlight the adaptation aspects which are being considered. This table uses the following notation: “+” if the work contemplates this aspect, “–“ if it does not contemplate this aspect “?” if there is not

482

D. Marin Díaz, A. Rico Zuluaga, and A. Carrillo-Ramos

enough information about this aspect. We can conclude that all of these works allow as much the access when user wants, as the adaptation of the content and considering the context. These aspects have been considered as the most important because it is very relevant that a user can connect to and also, the information will be adapted according to his/her location (that is, adaptation of the content). The aspects of adaptation of the presentation and considering the access device have not been widely worked, mainly because each work is limited to a specific MD and they do not allow scalability in this aspect. Nowadays, it is necessary that the applications allow this, because all the users do not have the same MD. Therefore, as much the adaptation to the presentation and as to the device like the adaptation of the content (considering the context), must be aspects equally important to consider for new applications.

5 Conclusions PlaSerEs was developed in order to provide to the commercial establishments, the possibility of offering personalized services to their clients. For making this possible, the internal architecture of this platform takes into account user characteristics and his/her context. The models developed with adaptation purposes are: a) of the user profile b) of the context of use which includes characteristics which affects the interaction between the IS and the user, depending on his/her location; for all people in the same place, this model presents the information in the same way. c) Of the MD profile which describes the device used by the user for connecting; this profile defines the best display of the information which will be given. d) Of the connection wireless profile which allows personalizing the information according to the available connections as much in the establishment where the user is located, as the connections devices that user’s MD has. These models are the main components of the adaptation layer which allows to PlaSerEs to show the information with a personalized content and presentation. This information is given through the invocation of services provided by the commercial establishments. These services are described and defined in the general services layer. The particular implementations (developed for a specific commercial establishment) of these services belongs to the personalized services layer. In order to validate and evaluate the accomplishment of the PlaSerEs objectives, we developed a prototype which provides adapted services to users of a restaurant, taking into account the user profiles, their MD, the available connection wireless and their context of use. This prototype produced successful results in the tests cases. As future work, we want to verify if the list of services defined is enough for all the possible clients of the platform. It is necessary to define if we have to add new general services and to consider the impact produced by these additions in the other components of the architecture. For example, if we want to include the service of paying the bill, we have to include a security component which connects itself to the bank and allows making the payments in a successful way. In addition, the data model must include user banking information so that he/she can pay his/her bill in an automatic way, each time that he/she uses the platform. In conclusion, in order to include the general service of paying the bill into PlaSerEs, it is not necessary to modify any existent modules. It is only necessary to create a security model which allows paying the bills. Additionally, it is necessary to research about the market needs in order to identify general services, not included in PlaSerEs.

Personalized Services Oriented towards Commercial Establishments

483

References [1] Amigo. Ambient intelligence for the networked home environment, http://amigo.gforge.inria.fr/home/index.html(last access: June 2009) [2] Berhe, G., Brunie, L., Pierson, J.M.: Modeling Service-Based Multimedia Content Adaptation in Pervasive Computing. In: 1st Conference on Computing Frontiers (CF 2004), pp. 60–69. ACM Press, New York (2004) [3] Calisti, M., Lozza, T., Greenwood, D.: An Agent-Based Middleware for Adaptive Roaming in Wireless Network. In: Workshop on Agents for Ubiquitous Computing, UbiAgents 2004 (2004), http://www.ift.ulaval.ca/~mellouli/ubiagents04/ (last access: June 2009) [4] Carrillo Ramos, A., Gensel, J., Villanova, M., Martin, H.: PUMAS: a Framework based on Ubiquitous Agents for Accessing Web Information Systems through Mobile Devices. In: 20th Symposium on Applied Computing (SAC 2005), pp. 1003–1008. ACM Press, New York (2005) [5] Dolog, P., Bieliková, M.: Navigation Modelling in Adaptive Hypermedia. In: De Bra, P., Brusilovsky, P., Conejo, R. (eds.) AH 2002. LNCS, vol. 2347, pp. 586–591. Springer, Heidelberg (2002) [6] Hristova, N., O’Hare, G.M.P.: Ad-Me: A Context-Sensitive Advertising System, http://www.prism.ucd.ie/publications/pub2001/HriAdme01ii.pdf (last access: June 2009) [7] Indulska, J., Robinson, R., Rakotonirainy, A., Henricksen, K.: Experiences in Using CC/PP in Context-Aware Systems. In: Chen, M.-S., Chrysanthis, P.K., Sloman, M., Zaslavsky, A. (eds.) MDM 2003. LNCS, vol. 2574, pp. 247–261. Springer, Heidelberg (2003) [8] Kirsch-Pinheiro, M., Gensel, J., Martin, H.: Representing Context for an Adaptative Awareness Mechanism. In: de Vreede, G.-J., Guerrero, L.A., Marín Raventós, G. (eds.) CRIWG 2004. LNCS, vol. 3198, pp. 339–348. Springer, Heidelberg (2004) [9] Lech, T., Wienhofen, L.: AmbieAgents: A Scalable Infrastructure for Mobile and Context-Aware Information Services. In: 4th Int. Conference on Autonomous Agent and Multi-Agent Systems (AAMAS 2005), pp. 625–631. ACM Press, New York (2005) [10] Lowen, T.D., O’Hare, P.T., O’Hare, G.M.: The WAY Ahead: Entity Rendezvous through Mobile Agents. In: 37th Hawaii International Conference on System Sciences, pp. 1–8 (2004), http://csdl2.computer.org/comp/proceedings/hicss/2004/2056/ 09/205690285a.pdf [11] O’Grady, M.J., O’Hare, G.M.P.: Gulliver’s Genie: Agency, Mobility & Adaptivity. Computers & Graphics, Special Issue on Pervasive Computing and Ambient Intelligence - Mobility, Ubiquity and Wearables GetTogether 28(4), 677–689 (2004), http://www.cs.ucd.ie/csprism/publications/genie/ CompandGraph_2004.pdf (last access: June 2009) [12] Pirker, M., Berger, M., Watzke, M.: An approach for FIPA Agent Service Discovery in Mobile Ad Hoc Environnements. In: UbiAgents 2004 (2004), http://www.ift.ulaval.ca/~mellouli/ubiagents04/ (last access: June 2009) [13] Rahwan, T., Rahwan, T., Rahwan, I., Ashri, R.: Agent-Based Support for Mobile Users Using AgentSpeak (L). In: Giorgini, P., Henderson-Sellers, B., Winikoff, M. (eds.) AOIS 2003. LNCS (LNAI), vol. 3030, pp. 45–60. Springer, Heidelberg (2004) [14] Sashima, A., Izumi, N., Kurumatani, K.: CONSORTS: A Multi-agent Architecture for Service Coordination in Ubiquitous Computing. In: Chen, S.-H., Ohuchi, A. (eds.) MAMUS 2003. LNCS (LNAI), vol. 3012, pp. 190–216. Springer, Heidelberg (2004) [15] W3C. Composite Layerbility/Preference Profiles (CC/PP): Structure and Vocabularies 1.0. W3C, http://www.w3.org/TR/CCPP-struct-vocab

CRM System Implementation in a Multinational Enterprise Alok Mishra and Deepti Mishra Department of Computer Engineering Atilim University, Ankara, Turkey [email protected], [email protected]

Abstract. The concept of customer relationship management (CRM) resonates with managers in today’s competitive economy. As more and more organizations realize the significance of becoming customer-centric in today’s competitive era, they embrace CRM as a core business strategy. CRM an integration of information technology and relationship marketing provides the infrastructure that facilitates long-term relationship building with customers at an enterprise-wide level. Successful CRM implementation is a complex, expensive and rarely technical projects. This paper presents the successful implementation of CRM in a multinational organization. This study will facilitate in understanding transition, constraints and implementation of CRM in multinational enterprises. Keywords: Customer Relationship Management, CRM, Implementation.

1 Introduction As the business environment is dramatically changing, companies today face the challenge of increasing competition, expanding markets, and rising customer expectations (Wu, 2008). A good customer relationship is the key to business success. Relationship building and management, or what has been labeled as relationship marketing, is a leading approach to marketing [11]. The use of customer relationship management (CRM) systems is becoming increasingly important to improve customer life time value [27]. So more and more businesses begin to attach great importance to electronic customer relationship management (eCRM), which focuses on customers instead of products or services, that is, considering customer’s needs in all aspects of a business, ensuring customers’ satisfaction. By providing information on customer data, profiles and history they support important areas of a company’s core processes, especially in marketing, sales and service [7]. eCRM is all about optimising profitability and enabled businesses to keep customers under control, as it makes the customer feel they are really a part of the business progress [22]. In spite of the wide use of sales force automation systems in sales [20], a Forrester study [3] observes significant deficits in today’s marketing, sales and service processes. It was found that just 22% of the companies surveyed possess a uniform customer view and only 37% know which customers are looked after by the individual business units [1]. To eliminate weaknesses in customer contact, many companies are R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 484–493, 2009. © Springer-Verlag Berlin Heidelberg 2009

CRM System Implementation in a Multinational Enterprise

485

either planning or in the process of implementing CRM systems. According to Gartner survey [8], 65% of US companies intended to initiate CRM projects in 2002. In Europe, roughly 3% of companies had fully implemented a CRM project in 2001, 17% had initiated more than one local project and 35% were developing concepts for the introduction of CRM [24]. The software CRM market is expected to increase from $7 billion in 2000 to 23 billion in 2005, even though conventional wisdom is that 30 to 50 percent of CRM initiatives fall short of meeting company objectives, while another 20 percent actually damage customer relationships [2]. Different organizations are approaching CRM in different ways. Some view CRM as a technology tool while others view it as an essential part of business. According to Verhoef et al. [26], the success rate of CRM implementation varies between 30% and 70%. According to industry analysts, almost two-thirds of CRM system development projects fail [4]. Another report estimates that between 60 and 90 percent of enterprise resource planning implementations don’t achieve the goals set forth in the project approval phase [19] Hence, key factors of success or failures during CRM implementation have been the subject of active research in recent years (Wu, 2008). The results show that there is no ‘unique’ CRM project and that successful implementations are rarely technical projects [1]. Therefore the objective of this paper is to report successful CRM implementation and lessons learned in a multinational enterprise. CRM is synthesis of many existing principles from relationship marketing [14][21][17] and the broader issue of customer-focused management. CRM systems provide the infrastructure that facilitates long-term relationship building with customers. Some examples of the functionality of CRM systems are sales force automation, data warehousing, data mining, decision support, and reporting tools [16][23]. CRM systems also reduce duplication in data entry and maintenance by providing a centralized firm-database of customer information. This database replaces systems maintained by individual sales people, institutionalizes customer relationships, and prevents the loss of organizational customer knowledge when sales people leave the firm [13]. Centralized customer data are also valuable to firms managing multiple product lines. In many cases customers will overlap across different lines of business, providing an opportunity for increasing revenues through cross-selling. The paper is organized as follows: Section 2 reviews the literature on CRM implementation. In section 3 we have presented the CRM implementation in a multinational organization. Finally section 4 draws conclusions from the case study in terms of its practical relevance and lessons learned.

2 Literature Review The first requirement for the successful implementation of CRM is clarity regarding CRM terminology. From the many approaches available, the distinction between the following three areas has become generally accepted [5]. • •

Operational CRM supports front office processes, e.g. the staff in a call center Analytical CRM builds on operational CRM and establishes information on customer segments, behavior and value using statistical methods.

486

A. Mishra and D. Mishra

•

Collaborative CRM concentrates on customer integration using a coordinated mix of interaction channels (multi-channel management), e.g. online shops, and call centres.

CRM is therefore understood as a customer-oriented management approach where information systems provide information to support operational, analytical and collaborative CRM processes and thus contribute to customer profitability and retention. CRM system is the automation of horizontally integrated business processes involving “front office” customer touch points –sales (contact management, product configuration), marketing (campaign management, telemarketing), and customer service (call center, field service)-via multiple, interconnected delivery channels. Therefore, CRM system implementation is commonly used in functional areas such as customer support and services, sales and marketing. CRM life cycle includes three stages: Integration, Analysis and Action [12]. Second stage called analysis is the most critical to CRM success [12]. CRM analytics enable the effective management of customer relationships (Wu, 2008). Using CRM analytics, organizations are able to analyze customer behaviors, identify customer-buying patterns and discover casual relationships [12]. The final phase, Action, is where the strategic decisions are carried out. Business processes and organizational structures are refined based on the improved customer understanding gained through analysis [29]. This stage closes the CRM loop and allows organizations to cash in on the valuable insights gained through analysis. According to Gefen and Ridings [9], a CRM system consists of multiple modules including: operational CRM, which supports a variety of customer-oriented business processes in marketing, sales and service operations; and analytic CRM which analyzes customer data and transaction patterns to improve customer relationships. Operational and analytic CRM modules provide the major functions of a CRM system. Successful CRM implementation often entails significant organizational transformation due to the complexity of multiple operations involved in managing customer relationships [15]. Implementing a CRM system is only part of the needed change. To adopt the new ways of interacting with customers, firms need to align various organizational aspects with their CRM systems, e.g. business processes, strategies, top management support, and employee training [10]. A typical CRM implementation can be classified into six iterative processes including exploring and analyzing, visioning, building business case, planning and designing solution, implementing and integrating, and realizing value [29]. Resulting from a variety of catastrophic ERP implementation failures, research on ERP systems points to the need to reduce application complexity. The likelihood of success is related to reduced project scope, complexity, and customization of the application. Defining a reasonable (i.e., smaller) system scope by phasing in software functionality over a series of sequential implementation phases is an important means of decreasing complexity. Similarly, reducing or eliminating customization of the specific functionality of CRM application software is critical to lowering risk. It is the business needs that should determine the CRM application functionality – the scope of functions to be implemented [18]. Organizations are finding that implementing

CRM System Implementation in a Multinational Enterprise

487

CRM functionality beginning with quick, clear-cut and profitable ‘hits’ helps to insure the initial success, and thus long- term success of a CRM initiative. Generally, the case study method is a preferred strategy when “how” and “why” questions are being posed, and the researcher has little control over events [28]. The case study method, a qualitative and descriptive research method, looks intensely at an individual or small participants, drawing conclusions only about the participants or group and only in the specific context [28]. The case study method is an ideal methodology when a holistic, in-depth investigation is required [6]. Case studies are often conducted in order to gain a rich understanding of a phenomenon and, in information systems research, the intensive nature, the richness of a case study description and the complexity of the phenomenon are frequently stressed in case study reports [25].

3 Case Study 3.1 Background of the Company Company ABC is a trans-national company with operations in different segments. This company engages in the design, manufacture, and sale of precision motion and fluid controls, and control systems for various applications in markets worldwide. The company has been growing rapidly in all segments. 3.2 IT Setup Company has highly skilled engineers and has grown from being a small to a large company. IT in company has been “home-grown”, i.e. systems were created using available tools to capture processes. Employee empowerment is very high in the company. It also meant that the company’s business units could decide what systems – hardware, software and networks wanted individually. This has led to a plethora of IT systems. The CIO of the company started rationalizing the “basic” infrastructure to Lotus Notes for e-mail and Microsoft Office Suite for office applications. An Enterprise Resource Planning System (ERP) from QAD called MFG/PRO was implemented to take care of manufacturing, financials and logistic transactions of the company. This system was implemented individually in each of the countries. Customization was not allowed without confirmation by a change request committee. Since reporting in MFG/PRO was weak, the company went ahead with a datawarehousing solution called “Cubes” based on Progress database. Data needed for financial and management reporting was extracted on a daily basis from MFG/PRO into the cubes for analysis. The group is now considering moving all the disparate MFG/PRO systems to its data centre in the main office. 3.3 The Search for IT Solution The company has doubled its’ operations over the past five years. The growing number of customers in the various segments calls for a solution in information technology (IT). Company has over 5,000 customers spanning various markets like Power, Plastics, Metal Forming, etc. Due to the large number of customers using

488

A. Mishra and D. Mishra

company’s components in various markets for various applications and lesser profitability, it was decided to bring together senior managers in the company for determining its future strategy for the IT solution. They found that use of IT in CRM would help company in maximizing revenues in a cost-effective manner through various applications to a consolidated database, for example, sales forecasting, decision of marketing strategies, and customer identification. 3.4 Motivation for CRM CRM can be defined as a management process of acquiring customers by understanding their requirements; retaining customers by fulfilling their requirements more than their expectations; and attracting new customers through customer specific strategic marketing approaches. This requires total commitment from the entire organization. CRM uses IT to track all the ways in which a company interacts with its customers; analyses these interactions to maximize the lifetime value of customers while maximizing customer satisfaction. Company has a large customer base, though the value of business from each customer is currently low. CRM would help the company in identifying customers who provide the greatest revenues for every marketing or service dollar spent or customers who cost little to attract. Typically, these ‘good’ customers present 80 to 90 percent of the company’s profits, though they are only 10 to 20 percent of the client base. The motivation for selecting CRM in the company was to increase business value due to the following: •

•

• • •

•

Information about customers is stored in disparate applications as the employee empowerment is very high. These customer related information from these various systems needed to be brought in, analyzed, cleansed and distributed to the various customer touch-points across the enterprise, such that the various stakeholders – marketing, sales and engineering teams see a single version of ‘truth’ about the customer. This single source of customer data can be used for sales, customer service, marketing etc thereby enhancing customer experience and reducing churnrate. Churn-rate measures the number of customers who have stopped using the company’s products. By storing information about past purchases, sales team can make customized selling or personal recommendation to the customer. Also, this helps in up-selling or cross-selling opportunities. Capability to better current sales forecasting, team selling standardizing sales and marketing processes and systems. Support direct-marketing campaigns by capturing prospect and customer data, provides product information, qualified leads for marketing, and scheduling and tracking direct marketing communication. Also, it helps marketing team fine-tune their campaigns by understanding the prospect to customer conversion. To help engineering in understanding market demand for specific product designs and act accordingly.

CRM System Implementation in a Multinational Enterprise

• •

489

Single out profitable customers for preferential treatment, thereby increasing customer loyalty. Easing sales account management through consolidated information.

3.5 ERP Implementation 3.5.1 ERP Selection. Since there were two different ERP systems in the company, but one mail system, it was difficult for the company to choose the right CRM system. In the end, a relatively unknown system called Relavis was selected as the preferred ERP system. Relavis was chosen because it tightly integrated with IBM Lotus Notes, the common infrastructure across the whole enterprise. Relavis is a small company. The product is much economical than a Seibel, SAP or Oracle. The system has modules to cater for eMarketing, eSales and eService. 3.5.2 Scoping. The scope covered sales and marketing processes and followed the ‘service platform’ approach. A service platform integrates multiple applications from multiple business functions (in this case, sales, marketing, engineering), business units or business partner to deliver a seamless experience for the customer, employee, manager or partner. As shown in figure 1, the new system (Relavis) integrated information from Marketing, Sales to provide input to the ERP and Data warehousing applications and finally created analytical reports to make better business decisions e.g. to understand the sales results of specific leads, recommend better selling techniques and target specific leads etc. The new application could track the status of a lead through all stages of the sales and marketing lifecycle. Marketing was working on branding strategies and segmentation. Events were managed by marketing. These events would come up with a huge number of leads for new opportunities and marketing wanted to handover the leads to sales. Sales filtered the leads from marketing and their own sources into opportunities. Opportunities were defined as those having specific sales persons assigned to. These accounts were

Fig. 1. Enterprise’s Overall Process Flow

490

A. Mishra and D. Mishra

carefully evaluated to see if they fit with company’s overall strategy of increasing revenue and profitability by solution selling. The Miller Heiman Process was used to capture relevant information on the opportunity and the blue-sheets of Miller Heiman was closely monitored by VP Sales and top management. The non-strategic product sale was channelled to distributors and agents. Consolidated forecast numbers were reviewed by senior management on a regular basis. Orders that were received were executed. 3.5.3 Design. A “gap analysis” is conducted since CIO wanted a successful “business” implementation of the system vis-à-vis a technical implementation, the sales and marketing process was mapped. The “as-is” process described the cradle-to-grave aspects of the process. The “to-be” process incorporated Relavis, together with other tools like Miller Heiman eforms, Horizon system for forecast, MFG/PRO system for order execution and Datawarehouse Cubes for analysis. Relavis was customized a bit to include “Business Intelligence” – a piece of software extracting account specific information from past sales through the Cubes. 3.5.4 Implementation. Implementation would involve reviewing the resources requirements and availability, both in terms of hardware and software. The company had Lotus Notes skills in the organization. The system was simple. Hence the implementation was done using in-house resources. Training on the product was arranged from Relavis and its partners. The system approach should involve a “big-bang” approach. After all, an audit and review should be undertaken to determine the monetary as well as nonmonetary benefits against costs incurred. The implementation primarily consisted of the major steps as given in table 1 (Please see Appendix). 3.5.5 Impact. The system was packaged software, with very minimal customization. The only additions to the software were the Business Intelligence part and electronic Miller Heiman blue-sheet for strategic opportunities and gold-sheets for Large Accounts. Some key users were involved in the decision-making. The project implementation plan was received well by them. IT department made sure that the project was driven by sales for the eSales module and marketing for the eMarketing module. A steering committee comprising senior managers of each country (called REPCOTE or Relavis Pacific COre TEam) was formed to drive the implementation. IT took the role of being facilitators. With the implementation, sales believe that the whole process needs to be changed. Business Process Maps with the process, key performance indicators (KPIs), responsibilities and systems were drawn up for possible scenarios. After training, in local languages (Japanese in Japan, Korean in Korea, Mandarin in China), the users were comfortable. A pre-cursor course of general Lotus Notes training was offered to make sure that the users are comfortable with functions such as calendaring, to-do lists, etc. An audit of the implementation is planned by the end of the year to find out

CRM System Implementation in a Multinational Enterprise

491

key success factors and lessons learnt from the implementation. Besides facilitation of documentation about effectiveness of the new system, this audit also provides a baseline measure for future reference. It is best if the audit can provide information about monetary and non-monetary benefits. For example, a balanced scorecard (BSC) approach, a framework developed by Kaplan and Norton, can be adopted. The BSC is organized around four different perspectives: financial; customer (user, or internal customers); internal business processes; and innovation, learning and growth. This approach does provide a balance between quantitative and qualitative outcome measures. This project provides company a chance to look for the potentials of virtual office, business process reengineering and knowledge management activities. The potential benefits derived here should not be underestimated.

4 Conclusion Implementation of CRM system was identified as a critical need to align with the overall business strategy of selling solutions, instead of products. The implementation was driven by the business users, with IT playing a facilitating role, thereby making sure that users derive maximum value out of the implementation. After successful implementation, the CRM system may get into an impact mode, which may challenge the business strategy. Various case studies provide different findings which are unique to CRM implementations because of the integrative characteristics of CRM systems. As a future work we would like to compare various CRM implementation in different organizations on selected significant attributes.

References 1. Alt, R., Puschmann, T.: Successful Practices in Customer Relationship Management. In: 37th Hawaii International Conference on System Science, pp. 1–9 (2004) 2. AMR Research. The CRM Application Spending Report, 2002-2004 (2002), http://www.amrresearch.com/Content/ view.asp?pmillid=10494&docid=9398 3. Chatham, B., Orlov, L.M., Howard, E., Worthen, B., Coutts, A.: The Customer Conversation. Forrester Research, Inc., Cambridge (2000) 4. Davids, M.: How to avoid the 10 biggest mistakes in CRM. Journal of Business Strategy, 22–26 (November/December 1999) 5. Fayerman, M.: Customer Relationship Management. In: Serban, A.M., Luan, J. (eds.) New Directions for Institutional Research, Knowledgement: Building a Competitive Advantage in Higher Education, pp. 57–67. John Wiley & Sons, Chichester (2002) 6. Feagin, J., Orum, A., Sjoberg, G. (eds.): A Case for Case Study. University of North Carolina Press, Chapel Hill (1991) 7. Fingar, P., Kumar, H., Sharma, T.: Enterprise E-Commerce: The Software Component Breakthrough for Business-to-Business Commerce. Meghan-Kiffer Press, Tampa (2000) 8. Gartner survey. CRM in 2002: Redesign from the customer perspective. Gartner Group, San Jose, CA (2001/2002)

492

A. Mishra and D. Mishra

9. Gefen, D., Ridings, C.M.: Implementation team responsiveness and user evaluation of customer relationship management: A quasi-experimental design study of social exchange theory. Journal of Management Information Systems 19(1), 47–69 (2002) 10. Goodhue, D.L., Wixom, B.H., Watson, H.J.: Realizing business benefits through CRM: Hitting the right target in the right way. MIS Quarterly Executive 1(2), 79–94 (2002) 11. Grönroos, C.: From Marketing Mix to Relationship Marketing: Towards a Paradigm Shift in Marketing. Management Decision 32(2) (1994) 12. Hahnke, J.: The critical phase of the CRM lifecycle. Without CRM analytics, your customer won’t even know you’re there (2001), http://www.hyperion.com 13. Hendricks, K.B., Singhal, V.R., Stratman, J.K.: The impact of enterprise systems on corporate performance: A study of ERP, SCM, and CRM system implementations. Journal of Operations Management 25, 65–82 (2007) 14. Jancic, Z., Zabkar, V.: Interpersonal vs. personal exchanges in marketing relationships. Journal of Marketing Management 18, 657–671 (2002) 15. Karimi, J., Somers, T.M., Gupta, Y.P.: Impact of information technology management practices on customer service. Journal of Management Information Systems 17(4), 125– 158 (2001) 16. Katz, H.: How to embrace CRM and make it succeed in an organization, SYSPRO white paper, SYSPRO, Costa Mesa, CA (2002) 17. Morgan, R.M., Hunt, S.D.: The commitment-trust theory of relationship marketing. Journal of Marketing 58, 20–38 (1994) 18. Ocker, R.J., Mudambi, S.: Assessing the Readiness of Firms for CRM: A Literature Review and Research Model. In: Proceedings of the 36th Hawaii International Conference on System Sciences (HICCS 2003). IEEE Computer Society, Los Alamitos (2003) 19. Ptak, C.A., Scharagenheim, E.: ERP: Tools, Techniques, and Applications for Integrating the Supply Chain. CRC Press-St. Lucie Press (1999) 20. Reckham, N.: Rethinking the Sales Force: Redefining Selling to Create and Capture Customer Value. McGraw-Hill, New York (1999) 21. Sheth, J.N., Sisodia, R.S., Sharma, R.S.: The antecedents and consequences of customercentric marketing. Journal of the Academy of Marketing Science 28(1), 55–66 (2000) 22. Shoniregun, C.A., Omoegun, A., Brown-West, D., Logvynovskiy, O.: Can eCRM and Trust improve eC customer base? In: Proceedings of the IEEE International Conference on E-Commerce Technology. IEEE Computer Society, Los Alamitos (2004) 23. Suresh, H.: What is customer relationship management (CRM)? Supply Chain Planet? (2004) 24. Thompson, E.: CRM is in its infancy in Europe. Gartner Group, San Jose (2001) 25. Van Der Blonk, H.: Writing case studies in information systems research. Journal of Information Technology 18(1), 45–52 (2003) 26. Verhoef, P.C., Langerak, F.: Eleven misconceptions about customer relationship management. Business Strategy Review 13(4), 70–76 (2002) 27. Winer, R.S.: A Framework for Customer Relationship Management. California Management Review 43(4), 89–104 (2001) 28. Yin, R.K.: Case Study Research: Design and Methods, 3rd edn. Sage Publications, Thousands Oaks (2003) 29. Yu, J.: Customer relationship management in practice: A case study of hi-tech from China. IEEE Computer Society, Los Alamitos (2008)

CRM System Implementation in a Multinational Enterprise

493

Appendix Table 1. Major tasks during implementation and their duration (please double-click on the following project plan. This needs Microsoft Project application) ID

Task Name

1

Infrastructure readiness

Duration 2 days

2

Get Licenses

3

Synch with Lotus Notes team on training

0.1 days

4

Client PCs / Notebooks and network connecti

0.1 days

5 6

Give training sys implementn doc to local IT s Process Mapping

7

Sales process data gathering

8

"To-be" Sales process mapping

9

"To-be" Support process map

10

Data cleanup

11

Send excel formats to countries

12

Identify account-supporting documents to be u

13

Existing - MFG/PRO data

14

Update MFG/PRO customer data with lat

15

Download cust, add, contact, type ... to ex

16

Contact data (non-MFG/PRO sources)

17

Update data to Relavis

18

Upload existing customer activities into Relav

19 20 21

Review business rules Train users

1 day

1 day 5 days 3 days 1 day 1 day 15 days 1 day 1 day 4 days 3 days 1 day 2 days 1 day 5 days 1 day 4 days

Configure user profiles and relationships

0.5 days

22

Install Training Database in all users

0.5 days

23

Miller Heiman eLearning

24

Notes training

25 26

Calendaring, sharing calendars, to-do lis Relavis training

0 days 1 day 1 day 2 days

27

Relavis Product training

1.5 days

28

Business Intelligence

0.1 days

29

Horizon screen-show

0.2 days

An Architecture for Dynamic Trust Monitoring in Mobile Networks Olufunmilola Onolaja, Rami Bahsoon, and Georgios Theodoropoulos School of Computer Science, The University of Birmingham, United Kingdom, B15 2TT {O.O.Onolaja, R.Bahsoon, G.K.Theodoropoulos}@cs.bham.ac.uk

Abstract. Collusion attacks remain a major problem of reputation and trust models, in mobile ad hoc networks. By covering up malicious behaviour of one another from the remaining part of the network, two or more malicious nodes may collaborate to cause damage to or disrupt the network. A number of models exist, which have been proposed to address this issue. Despite these however, the assurance of trusted communication still remains a challenge in these networks. We present a dynamic trust model that detects malicious behaviour at runtime and prevents collusion attacks. Our proposed model employs a novel approach that has the advantage of predicting the future trustworthiness of nodes, based on historical and online behaviour of nodes. This is achieved by an architecture that applies the paradigm of Dynamic Data Driven Application Systems, in solving the problem of collusion attacks in mobile networks.

1

Introduction

In the context of networks, when a node is trusted, it implicitly means that the probability that it will perform an action that is beneficial or at least not detrimental in the network is high enough to consider engaging in some form of cooperation with the node [1]. Reputation on the other hand, is the opinion of an entity about another; it is the trustworthiness of a node. Both trust and reputation have been used synonymously and adapted to mobile networks. Behavioural expectation within a mobile network is motivated from the social perspective, where individuals are expected to behave in certain ways within the society. The behaviour of an individual whether good or bad, will determine how others will interact with the individual. The expected behaviour of nodes is to be cooperative in routing and forwarding of packets to neighbouring nodes. Misbehaviour among nodes is the deviation from the expected behaviour of nodes in a network. A node is said to be misbehaving once it violates the regular routing and forwarding of packets. Several Reputation and Trust based Models (RTMs) for mobile networks have been proposed over the years. These models aim to provide information that allows nodes to distinguish between trustworthy and untrustworthy nodes and R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 494–503, 2009. c Springer-Verlag Berlin Heidelberg 2009 

An Architecture for Dynamic Trust Monitoring in Mobile Networks

495

Fig. 1. Brainwashing (U - untrusted, T - trusted)

encourage nodes to be trustworthy. Participation of malicious nodes in network activity is discouraged by existing RTMs. Malicious nodes are isolated, denied service and punished by some of these models. However, each model addresses some but not all of the problems in mobile networks. Of particular interest is the problem of collusion attacks, where two or more nodes collude to behave maliciously in the network. A scenario of such an attack is brainwashing. Brainwashing; in Fig. 1 describes when colluding and lying nodes surround a node A for example, and the node is tricked into believing false information. When the node moves into a different neighbourhood with trusted and honest nodes, it will not believe them since their information deviates too much from its own. This is a form of collaborative attack because it takes two or more nodes to collude in order to brainwash another. Without countermeasures, the effects of these attacks have been shown to dramatically affect the security and network performance at runtime [2] as evidenced in poor reliability and quality of service, higher overhead and throughput degradation. In order to address the problem of collusion attack, we propose a novel approach that uses the Dynamic Data-Driven Application Systems (DDDAS) paradigm [3,4] in ensuring trusted communications in mobile networks. The concepts of the paradigm are applied in building RTMs. This paper aims to show that DDDAS is a potential paradigm for addressing trust related problems in mobile networks. The remainder of this paper is organised as follows. Sect.2 describes existing research in reputation and trust based models and Sect.3 gives some background on the DDDAS paradigm. Sect.4 and Sect.5 present our contribution and future work respectively. Sect.6 summarises the paper.

2

Related Work

This section summarises the existing work on reputation and trust based models and describes the problems that persist. A COllaborative REputation mechanism to enforce node cooperation in mobile ad-hoc networks (CORE) [5] model was proposed by Michiardi and Molva.

496

O. Onolaja, R. Bahsoon, and G. Theodoropoulos

Reputation in this model is formed and updated with time by direct observations and information provided by other members of the network. Nodes have to contribute continuously to the community to remain trusted or their reputation will be degraded until they are eventually excluded from the network. Only positive information is shared and consequently, CORE prevents the distribution of false information about other entities. Buchegger et al. proposed the Cooperation Of Nodes: Fairness In Dynamic Ad-hoc NeTworks (CONFIDANT) [2] protocol. The protocol aims at detecting and isolating misbehaving nodes, making it unattractive to any node to deny cooperation. In this model, each node maintains a reputation rating and a trust rating about every other node of interest. Only fresh reputation is propagated, with more weight given to current behaviour of a node than the past. This prevents the possibility of a node from obtaining good reputation initially and subsequently misbehaving. Nodes monitor and detect misbehaviour in their neighbourhood by means of an enhanced packet acknowledgment (PACK) mechanism where confirmation of acknowledgment comes indirectly by overhearing the next node forward the packet. [6,7] The Secure and Objective-based Incentive (SORI) scheme aims to encourage packet forwarding, detect and discipline selfishness among network nodes. SORI keeps count of the number of packets requested for forwarding and those actually forwarded by each node. A reputation rating calculated from these counts along with derived confidence and credibility metrics [6,8] is also kept. The propagation of reputation is secured by a one-way hash function, which makes it difficult for a selfish node with a bad reputation to send packets or fake broadcast information, in an attempt to influence its reputation by impersonating a trusted node. Other more recent work on reputation systems are [9] and others like [10,11] focus on Wireless Sensor Networks (WSNs). The systems aim to distinguish between trustworthy and malicious nodes and to exclude the malicious ones from the network. A common problem of the models described above is vulnerability to collusion attacks and vulnerability to false praise or accusations. This is because they use a distributed approach to information gathering about node behaviour. That is, each node keeps a record about the behaviour of other nodes of interest. Hence, recommendations provided by individual nodes in the network are used in deciding the reputation of other nodes. While the use of distributed monitoring by these models offers robustness and scalability, there is no repository that collates reputation values. Also, these reputation values are stored and circulated by each node and may lead to collusions and congestion within the network. These RTMs make use of a component resident on each node called watchdog mechanism. This component monitors its neighbourhood and gathers information based on promiscuous observation. By promiscuous observation we mean, each node overhears the transmission of neighbouring nodes to detect misbehaviour. Once misbehaviour is detected, the source of the concerned path is notified. This detection mechanism has a weakness of failing to detect a misbehaving node in

An Architecture for Dynamic Trust Monitoring in Mobile Networks

497

Fig. 2. Node misbehaviour

case of collusions [12]. A form of collusion attack (similar to Fig. 1) that shows the downside of the watchdog mechanism is depicted in Fig. 2. If node A forwards a packet through B to D. Node C can decide to misbehave and then, collude with B. With the watchdog mechanism, it is possible that B does not report to A when C alters a packet, before forwarding or dropping the packet. Another problem of the existing models is that they lack a high level of dynamism required for such spontaneous networks. They focus mainly on stored Trust Values (TVs) of the nodes with little or no focus on predicting future TVs. We refer to dynamism in terms of the provision of runtime rating by the models and prediction of the future behaviour of each member of the network in order to aid future security-aware decisions in the network. Other problems of these models include: – The small size of nodes limits their computational power and prevents them from carrying out complex analysis. However, in these models, each node has to maintain reputation information about other nodes; – Extra computation in accepting observed reputation information; – The corruption of trust decisions through recommendations made by nodes. These models lack well analysed approaches to determine the bias of each node [9]; – Other security issues such as the modification of data packets by malicious nodes. To address the problem of collusion attacks, a model with the following is required: 1. Provides dynamic runtime rating of each node based on the cooperation of the nodes; 2. Removes the responsibility of monitoring, calculating and storing of reputation away from the nodes and 3. Predicts the future TVs of nodes by combining historical with the online behaviour of each node.

3

Why Dynamic Data Driven Application Systems (DDDAS)?

The dynamic and volatile nature of Mobile Adhoc Networks (MANETs) makes it difficult to differentiate between normal and malicious network operations. This

498

O. Onolaja, R. Bahsoon, and G. Theodoropoulos

therefore, calls for an equally dynamic approach to identifying and isolating misbehaving nodes. The DDDAS paradigm is a novel approach of symbiotic relation between applications or simulations. In this paradigm, applications can accept and respond dynamically to new data injected into an executing application, and in reverse, such application systems have the ability to dynamically control the measurement processes [4]. The application of the concepts of the paradigm in our model provides dynamism in the detection of malicious nodes and prediction of future behaviour of each node. In order to address collusion attacks, this research adopts the concepts of the paradigm namely: dynamic measurement, simulation, feedback and control. The runtime measurements (behaviour of nodes) are simulated to gain a better understanding and a more accurate prediction of the level of trust for each node. The simulation dynamically measures trust levels, and continually incorporates new measurements at runtime. This will enable the simulation to determine and feedback the reputation of each node into the system. The output of the simulation will help control the network in terms of decisions to be made, to maintain a trusted network. Thus, a trusted third party will be required in the network.

4

Architecture for Dynamic Trust Monitoring

This section introduces our proposed model and discusses how the concepts of DDDAS are adapted in our model. Fig. 3 depicts a conceptual architecture of the model. Table 1 compares the existing models with our proposed model using the functions found in the reputation systems as criteria for comparison. The [5] model gives a higher weight to past behaviour. The authors argue that a more recent sporadic misbehaviour should have minimal influence on a node’s reputation that has been built over a long period of time. In the approach of [2,6] however, the current behaviour of a node carries more weight in order to prevent nodes from obtaining a good reputation and subsequently, misbehaving.

Fig. 3. Conceptual architecture

An Architecture for Dynamic Trust Monitoring in Mobile Networks

499

Table 1. Summary table of reputation and trust models METRIC [5] INFORMATION Reputation REPRESENTA- table with TION each entry representing a function

[2] Bayesian approach, where ratings are an estimation of the actual probability of misbehaviour INFORMATION First and First and second GATHERING second hand hand information information from neighbourfrom neigh- ing nodes bouring nodes MONITORING Watchdog PACK, Watchdog

[8] Counters

Proposed model Reputation table with each entry representing a function

First and second First hand inforhand information mation from SNs from neighbouring nodes Watchdog like

Promiscuous monitoring by SNs TRUST Not applicable Adaptive trust Second hand infor- Authentication of mation/Hash chain propagated rating based authentication for propagated rating RESPONSE Isolation Isolation Punishment by Isolation packet dropping REDEMPTION Node remains Periodic reevalu- No redemption Periodic reevaluaisolated ation and reputation tion fading DYNAMISM Ratings are not Periodically Unspecified Runtime ratings constant updated

The later approach will be adopted in our model and runtime dynamic change in rating will be incorporated. In our model, online and historical behaviour are considered in determining the runtime reputation of each node and with a higher weight given to recent behaviour. By comparing the historical behaviour of a mobile node with its online behaviour, misbehaving nodes are detected and excluded. This is because it is assumed that the behaviour of an unauthorised node is different from what is expected. When an untrusted node that violates the expected behaviour is detected through the simulation, adjustments can be made by an administrator or by an automated means. This may result in a response such as the exclusion of the node from the network. Also, the result of simulating historical and online behaviour will be used in predicting the expected behaviour of nodes in the future. Existing reputation based systems lack effective mechanisms for monitoring reputation information, they rely on promiscuous mode of monitoring (an assumption that is not always true in a real mobile ad hoc network); they consequently inherit the watchdog’s detection drawback [13]. In the process of capturing information about nodes, these systems introduce additional problems such as collusion attacks. There is therefore a need for an effective approach to monitoring the behaviour of nodes, as nodes route and forward packets to adjacent

500

O. Onolaja, R. Bahsoon, and G. Theodoropoulos

nodes. We aim to address this need by introducing a monitoring function to the RTM, carried out by Sensor Nodes (SNs). The use of the SNs is similar to anomaly detection technique in Intrusion Detection Systems (IDSs). The network is partitioned into clusters. Each cluster has a head, which is a SN, and has a direct link with each member of the cluster. The cluster head overhears the traffic to and from all members. Instead of each node operating in a promiscuous mode, the cluster head i.e. the SN in this case, is responsible for information gathering. It is assumed that the SNs have a higher capacity in terms of computational power, energy and storage compared to other network nodes. Their function is to monitor nodes in their cluster and are therefore, not susceptible to collusion attacks. On entrance to the network, a cynical approach is taken, where nodes are not trusted. Each node has a neutral rating until they are able to demonstrate their trustworthiness or maliciousness. The subsequent behaviour of each node will determine an upgrade or downgrade of their TV. Nodes only store TVs of other nodes of interest. If a node needs to forward a packet through a next hop for example, the current reputation of the next hop is sourced from the cluster head. For each node that misbehaves and is detected, there is a timeout for reintroduction into the network. This process is referred to as redemption. This gives a chance for nodes that became faulty for example, to access the network again. If however, the node misbehaves again, it will be isolated at a lower threshold. This is achieved by keeping record of nodes’ past behaviour/misbehaviour in the data store shown in Fig. 3. The components of our proposed model are described in the subsections below: 4.1

Simulation

The incorporation of dynamic inputs (online and archived behaviour) in the simulation, helps with analysis and prediction of the reputation of each node. The output of the simulation provides useful information for the administrator to manage the network or with adequate information to generate an automated response. As described previously, the simulation predicts the future behaviour of nodes by considering their historical behaviour and incorporating their behaviour at runtime. 4.2

Controller

Runtime behaviour of nodes is forwarded to the controller from the SNs. Predictions from the simulation system are fed back to the data controller. This component stores the current reputation value of each node, which may be fetched by the SNs as the need may arise. Reputation is stored in a reputation table with each row containing the reputation score of a particular node. In this architecture, it is assumed that the controller is secure from any form of attacks.

An Architecture for Dynamic Trust Monitoring in Mobile Networks

4.3

501

Sensor Nodes

The role of the SNs is to constantly monitor the behaviour of nodes by acting as cluster head for a group of nodes. They operate in a promiscuous node and overhear transmissions to and from the nodes. SNs gather online information instead of the nodes, because if recommendations made by the nodes are considered; it will give room for collusions and false accusations/praise within the system. 4.4

Data Store

Historical behaviour of nodes are stored and fetched by the controller for simulation from the data store. The information representation function is performed by storing the reputation value of each node in a reputation table in this component. It is assumed that nodes have a verifiable identity that is attached to their behaviour. Trusted communication will be ensured by the use of a secure one way hash function (similar to [8] discussed in Sect.2) for information transmitted between the intermediate SNs and the nodes that require information about other nodes they wish to communicate with. In our model, reputation of nodes is not propagated; it is stored on the controller and made available by the intermediary SNs. This is likely to reduce communication overhead considerably. Thus, our proposed approach will 1. Facilitate dynamic changes to ratings of nodes at runtime; 2. Predict the future behaviour of nodes through the simulation of historical data and online behaviour; 3. Detect misbehaving nodes using the simulation system. Ad hoc networks are traditionally known to lack a central entity. Thus, our model will be most applicable in a semi-ad hoc or WSNs because of the presence of the controller. An example is in high-risk domains that require high security in terms of trust, but need to conserve the mobile nature of the network, such as in military applications.

5

Further Work

We discuss our ongoing research in this section. In the near future, we aim to propose an objective approach for calculating reputation values of nodes. The method with which the simulation system will perform analysis and prediction will be determined. Rigorous tests will be carried out through the simulation of the model and analysis of the results in order to ascertain the effectiveness of our model, in achieving a better overall security. Ensuring identity persistence is an area that will be explored. This is to prevent excluded or isolated malicious nodes from gaining entrance again into the network, under another identity. Also, the application of our model to the Dynamic Source Routing protocol and its performance will be considered.

502

O. Onolaja, R. Bahsoon, and G. Theodoropoulos

Fig. 4. Instance architecture

We plan to extend this approach to a real life application of the Femtocell technology [14], especially the security issues that arise from the deployment of Femtocells in terms of trusted communication. This technology, which is very new, employs low power cells as cellular access points to connect to a mobile operator’s network using residential DSL or cable broadband connections. There has recently been a flurry of activities by mobile phone companies to deploy Femtocells. However, the fact that connection is made via the Internet raises serious security concerns as to how Femtocells can be trusted. Fig. 4 gives an instance architecture showing an application of our model.

6

Conclusion

This paper discusses the pending problems of reputation-based models and how the DDDAS approach can fill the gaps. Our model provides a high level of dynamism to reputation systems by updating the trust values of nodes at runtime. This approach is not only useful at the network level but at a higher level. This will allow for making informed decisions with the dynamic runtime ratings and predictions provided by simulation. We can conclude that the use of runtime monitoring, simulation, feedback and control mechanisms can potentially improve the security of reputation systems.

References 1. Gambetta, D.: Can we trust? Trust: Making and breaking cooperative relations. Basil Blackwell, New York (1988) 2. Buchegger, S., Le Boudec, J.: Performance analysis of the confidant protocol (cooperation of nodes: Fairness in dynamic ad-hoc networks). In: Proceedings of the International Symposium on Mobile Ad Hoc Networking and Computing, MobiHoc., pp. 226–236 (2002)

An Architecture for Dynamic Trust Monitoring in Mobile Networks

503

3. Darema, F.: Dynamic data driven applications systems: a new paradigm for application simulations and measurements. In: Bubak, M., van Albada, G.D., Sloot, P.M.A., Dongarra, J. (eds.) ICCS 2004. LNCS, vol. 3038, pp. 662–669. Springer, Heidelberg (2004) 4. Douglas, C.: Dynamic data driven applications systems. In: Bubak, M., van Albada, G.D., Dongarra, J., Sloot, P.M.A. (eds.) ICCS 2008, Part III. LNCS, vol. 5103, pp. 3–4. Springer, Heidelberg (2008) 5. Michiardi, P., Molva, R.: Core: A collaborative reputation mechanism to enforce node cooperation in mobile ad hoc networks. In: Advanced Communications and Multimedia Security, vol. 100, pp. 107–121 (2002) 6. Buchegger, S., Le Boudec, J.: Self-policing mobile ad hoc networks by reputation systems. IEEE Communications Magazine 43(7), 101–107 (2005) 7. Srinivasan, A., Teitelbaum, J., Liang, H., Wu, J., Cardei, M.: Reputation and Trustbased Systems for Ad Hoc and Sensor Networks. In: Algorithms and Protocols for Wireless Ad Hoc and Sensor Networks. Wiley & Sons, Chichester (2006) 8. He, Q., Wu, D., Khosla, P.: Sori: A secure and objective reputation-based incentive scheme for ad-hoc networks. In: Proc. WCNC Wireless Communications and Networking Conference. IEEE Wireless Communications and Networking Conference, vol. 2, pp. 825–830. IEEE, Los Alamitos (2004) 9. Balakrishnan, V., Varadharajan, V., Lucs, P., Tupakula, U.: Trust enhanced secure mobile ad-hoc network routing. In: Advanced Information Networking and Applications Workshops, AINAW 2007, vol. 1, pp. 27–33 (2007) 10. Chen, H., Wu, H., Hu, J., Gao, C.: Event-based trust framework model in wireless sensor networks. In: Proc. International Conference on Networking, Architecture, and Storage, NAS 2008, pp. 359–364 (2008) 11. Ganeriwal, S., Balzano, L.K., Srivastava, M.B.: Reputation-based framework for high integrity sensor networks. ACM Transactions on Sensor Networks 4(3), 15:1– 37 (2008) 12. Marti, S., Giuli, T., Lai, K., Baker, M.: Mitigating routing misbehavior in mobile ad hoc networks. In: Proceedings of the Annual International Conference on Mobile Computing and Networking, MOBICOM, pp. 255–265 (2000) 13. Djenouri, D., Khelladi, L., Badache, A.N.: A survey of security issues in mobile ad hoc and sensor networks. IEEE Communications Surveys & Tutorials 7(4), 2–28 (2005) 14. FemtoForum: Femtocell technology (2007), http://www.femtoforum.org/femto/aboutfemtocells.php 15. Buchegger, S., Tissieres, C., Le Boudec, J.: A test-bed for misbehavior detection in mobile ad-hoc networks - how much can watchdogs really do? In: Proceedings - IEEE Workshop on Mobile Computing Systems and Applications, WMCSA, pp. 102–111 (2004) 16. Hussain, F., Chang, E., Hussain, O.: State of the art review of the existing bayesiannetwork based approaches to trust and reputation computation. In: 2nd International Conference on Internet Monitoring and Protection, pp. 154–158 (2007) 17. Rafsanjani, M., Moveghar, A., Koroupi, F.: Investigating intrusion detection systems in manet and comparing idss for detecting misbehaving nodes. In: Proceedings of world academy of Science, Engineering and Technology, pp. 351–355 (2008)

ME: Multimodal Environment Based on Web Services Architecture Maria Chiara Caschera, Alessia D’Andrea, Arianna D’Ulizia, Fernando Ferri, Patrizia Grifoni, and Tiziana Guzzo Institute of Reaserch on Population and Social Policies (IRPPS), Via Palestro 32 00185, Rome, Italy {mc.caschera, alessia.dandrea, arianna.dulizia, fernando.ferri, patrizia.grifoni, tiziana.guzzo}@irpps.cnr.it

Abstract. Information, documents and knowledge for each person and for public and private organizations are fundamental in each activity, and they may be the products or services they provide or supply. The daily activities and decision-making processes are usually based on many different pieces of information, which could be handled on PDAs and mobile devices in general, or stored on laptop computers using a lot of different forms, such as spreadsheets, e-mail messages, Web information obtained as the result of a Google search or a query, and so on. Simulating and managing services and information in catastrophic events and emergencies does not represent an exception. This paper describes the Web Services architecture of the Multimodal collaborative knowledge oriented Environment (ME), a platform designed to manage data, information and services for catastrophic events such as earthquakes, floods and dangerous natural phenomena. Keywords: Web Service architecture, Multimodal interaction, disaster management.

1 Introduction ICT pervasiveness in daily activities, the wide use of tools such as mobile devices, and the achievement of Web 2.0 technologies is stimulating new perspectives opening new and wider boundaries for Web Services, and defining distributed architectures. In particular, the use of the Web distributed architecture and natural communication process by multimodal interaction improve the people accessibility and fruition of services. Everything becomes a Web Service: information, data, multimodal interaction; all these aspects are managed as an XML flow that implements the interoperability between different resources. This paper presents the Web Services architecture of the Multimodal collaborative knowledge-oriented Environment (ME), a platform devoted to manage data, information and services for catastrophic events, such as earthquakes, floods, and so on. In fact, in a catastrophic situation, information and data collected by the observatories and operation rooms of the civil protection and the land officies, about

R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 504–512, 2009. © Springer-Verlag Berlin Heidelberg 2009

ME: Multimodal Environment Based on Web Services Architecture

505

building designs, building permits, and emergency plans can be necessary for preventing and promptly react to this catastrophic situations. In catastrophic events such as earthquakes, managing data contained in contingency and town plans requires scientific data related to the history of seismic events in the interested area, and geographic data should be involved. These data can be texts, numeric data, visual information, and so on. Contingency plans, for example, usually contain text and images. Speech or videos are generally preferred for tutorial purpose. In this scenario ICT can define a new manner for managing catastrophic events also using virtual social networks potentialities to improve people awareness on problems and solutions about these events and to promote cooperation among experts. Therefore according to the multiform data, information and services features and modalities used for their I/O they usually involve more than one transmission channel. For these reasons the ME software platform takes into account of the different types of information, their sources, the different situations, locations and times. The ME platform is the answer to the need of an interoperable and distributed software application that uses a Web Service architecture. Web Services technology is based upon the principle of distributed systems and its components communicate with each other only by passing messages (generally represented by XML files). A component may be a program execution on a computer or a device, such as a computer, a printer, and so on. The architecture adopted for ME platform is particularly useful in the situation of catastrophic events because its distributed nature permits to work using different devices everywhere and every time with mobile devices as well as computers allowing multimodal input and output management. The remainder of the paper is organised as follows. Section 2 is described the role of mobile Web services in catastrophic events giving some basic notions of Web service architecture and Service Oriented Architecture. In section 3 the architecture of the Multimodal collaborative environment ME is presented. Section 4 gives some examples of application of the ME environment in catastrophic events. Finally section 5 concludes the paper.

2 The Role of Mobile Web Services in Catastrophic Events Effective prevention and assistance coordination for catastrophic events are crucial aspects, as they involve many organizations and people. Indeed, they need to coordinate their organizational efforts to prevent a disaster, reduce the probability of a disaster happening, or reduce the damages of unavoidable disasters. The problem of providing real time information services has been widely discussed in the literature. De Rubeis et al. in their work [1] describe a questionnaire defined at the “Istituto Nazionale di Geofisica e Vulcanologia (INGV) since June 2007” that was addressed by Internet to no specialist people in order to evaluate seismic effects as felt by them. Gilles Mazet-Roux et al. in their work [2] describe QWIDS (Quake Watch Information Distribution System); this system allows a quick and robust data exchange using permanent TCP connections. QWIDS is based on a client-server technology in which the information published by the server is immediately pushed (via CORBA methods), using XML files. Rubbia et al. in [3] describe the experience of using the website for the Colfiorito earthquake of 1997 as a tool for the

506

M.C. Caschera et al.

dissemination of technical and scientific information for public bodies and research centres. The authors underlined how this website “had the merit of diffusing, elaborating and interpretating data in (nearly) real time for an event of great scientific, and also social, relevance, for the world of research and, more in general, for the public of the Internet.” The development of social software, social networks and mobile technologies is opening new fronteers in the production and delivering of information and data when catastrophic events such as earthquakes happen. People can actively participate and can be actively involved in these processes. ICT tools are useful in catastrophic situations, as demonstrated in the experiment carried out and described in [4], where “the difference between the communications based on paper or electronic forms, as well as the impact of numbers and states of victims and numbers of rescuers” are highlighted. In particular, the authors propose an agent-based computer simulation approach for designing rescue collaborative plans. A Service Oriented Architecture that ensures interoperability, supporting a variety of data for health care emergency from disparate systems was proposed in the AID-N project [5], where different tools interact using Web Services. Similarly, the ME architecture proposed in the next section of this paper is a Web Service architecture. Before describing it in section 3, some notions about Service-Oriented Architectures and Web Service architecture are given. Service-Oriented Architectures (SOAs) implemented with Web Services are available at any time, in any place, and on any platform. Web Services indicate a new type of Web applications that cooperate exchanging messages with each other independently from the platform. The Web Services Architecture Working Group (W3C) defines a Web Service as: “a software system designed to support interoperable machine-to-machine interaction over a network. It had an interface described in a machine processable format (specifically WSDL). Other systems interact with the Web Service in a manner prescribed its prescription using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web related standards” [6]. Technologies on which Web Services are based, just mentioned in the definition, are: • • • •

XML, eXtensible Markup Language [7] SOAP, Simple Object Access Protocol [8] WSDL, Web Services Description Language [9] UDDI, Universal Description, Discovery and Integration [10]

The use of these technologies and other standards enables Web Services communication and cooperation by means of the Web. UDDI (Universal Description, Discovery and Integration) is a service of public registry where it is possible to register services that in SOA architectures are contained in the Service Registry. Web Services use UDDI in order to implement the Service Registry, publishing and searching for Web Services. It maintains information on services such as URL and the manner to access. Even UDDI is a Web Service. This allows the implementation of a system using a Service-Oriented Architecture. Figure 1 shows the schema (classification) of the functioning of a system with SOA architecture based on Web Services.

ME: Multimodal Environment Based on Web Services Architecture

507

Fig. 1. Web Services functioning

In particular, the use of a Web Service architecture with mobile devices represents a very interesting opportunity but, at the same time, it can have several drawbacks. First of all the intermittent connectivity to the network needs supplying services when they become available. Secondly, messages need to be adapted to the device and the transmission features. The Web Service message protocol SOAP supports Web Services on limited devices, providing a Web Service engine with run-time call de-serialization. In [11], the JXTA open framework, which enables Web Service sharing in peer-topeer networks is presented. It provides a peer-to-peer protocol that allows smartphones, PDAs, PCs and servers to communicate and collaborate seamlessly in a highly decentralized manner. The SOAP protocol has been adopted in the ME Web Service architecture too.

3 The ME Architecture The architecture of a natural and easy-to-use Web-based system, the ME system, devoted to manage data, information and services for catastrophic events is presented, considering the multimodal interaction as a Web service. The purpose of the service network is providing people with information from different information sources and solving problems arising in different situations. The system allows people to interact multimodally; it is based on an architecture that promotes a collaborative approach for sharing data, information and services during catastrophic events; it can be available at any time, in any place, and on any platform. A Service-Oriented Architecture (SOAs) implemented with a Web Service approach is characterised by these features. Web Services, as described in section2, are software systems designed to support interoperable machine-to-machine interaction over a network using a set of XML-based open standards. Information, data and multimodal interaction too, are all conceived as Web services.

508

M.C. Caschera et al.

The multimodal interface is a Web service, which exchanges multimodal messages (speech, sketch, handwriting, point, context) and sends its request to other Web Service applications (for example Emergency plan application, Social networking application, Operation room application, Plans definition applications, and so on) and receives their response. The aim is to make easier information and services knowledge sharing in crisis scenarios using Web Services. Each thing is a Web Service, the multimodal interaction management, the plan definition, the emergency plan application, the social networking application, and so on. They are seen as asynchronous messages that exchange XML documents across a network. Web Services are also responsible for mapping the XML documents into and out of executable programs, objects, databases, and applications. When a person uses the “Multimodal interaction management services application” it sends its request to another Web Service among the “Emergency plan application”, “Social Networking application” or any other Web service, as shown in Figure 2, and it receives a response by XML files. Inquiry and publishing services are managed by UDDI.

Fig. 2. ME Web Service architecture

Fig. 3. Multimodal interaction management service architecture

ME: Multimodal Environment Based on Web Services Architecture

509

Multimodal interaction is particularly important for managing emergency and catastrophic events, and it is a critical aspect when using mobile devices. It can be considered as a Web Services architecture in a SOA perspective. In particular, according to this general architecture the “Multimodal interaction management services application” (Figure 2) is a Web Services application that manages the multimodal interaction independently from the used device. Multimodal interaction management services application, once interpreted the multimodal input, requires Web Services, which require multimodal output produced according to the required service. Let us suppose John, after an earthquakes needs to know the less dangerous locations where going with his family; for this reason he is inerested in knowing paths that is possible to cover to reach that locations, not interrupted by debris. His house is deeply damaged and all his digital devices, with the exception for his mobile phone, have been destroyed. He can connect himself with other people using social networks and with civil protection services using his mobile phone. He can send his request of information using voice and sketch and he obtains a visual answer returning a map of the area of interest showing the path and locations John can reach with his relatives. When John sends his request, an XML file for each input channel is sent to the “Modality Recognition Service”. The recognized modal input is sent to the “Modality Fusion and Interpretation” service. The multimodal input is therefore interpreted and the request to the “Emergency plan” sends its response to the “Modality Fission” service. This services manage the output , arranging information according to the used mobile devices and the situation in which the user is in. The Web Services architecture that uses SOA approach is particularly useful; in fact, the different Web Services communicate independently from the adopted platform, exchanging messages implies using the HTTP protocol.

4 Application Scenarios This section discusses some application scenario of the ME platform for catastrophic events. The first scenario involves the “Social Networking” Web Service, the second scenario is connected with the “Plan definition application” and the third is about the “Emergency plan simulation”. 4.1 First Scenario John is coming at home by car when he feel the hearthquake that is alarming his city since four months ago. The previous week his colleague Anne has said him of the possibility to have more information and news on risks connected with this phenomenon using RISCOM, a Social Network implemented by experts in different sectors and among them in the earthquake field, which allows both to obtain precautionary information on seismic events (e.g., behaviors to be adopted, plans to be followed) and to receive news during emergency situations such as for example locations of meeting points. John had registered himself as a member of RISCOM. During the way, John decides to connect himself to the RISCOM by using his mobile phone. He with naturalness says by speech "Social Network RISCOM". The

510

M.C. Caschera et al.

Multimodal interaction management services application is immediately activated and it requires the activation of the “Social Networking application” (see Web Service architecture in Figure 2). The mobile phone shows on the touch screen the list of tha available Social Networks. John scrolls the list by moving the finger from up to down. He selects the Social Network RISCOM to visualize all precautionary information on earthquakes. John decides to register the address of the RISCOM on the mobile phone by saying "Register RISCOM”. In the evening John is coming to his home. During the dinner John alerts a strong seismic shock and he decides to rush on the street with his family. All streets are full of scared people who do not know what to do. John tries to know the meeting points activated in his city and connects himself to the RISCOM requiring this service. He takes-out the mobile phone and says "RISCOM". The phone connects automatically to the previously stored address allowing John to instantly access the RISCOM. Once connected to RISCOM John says "Show the map" to visualize the meeting point closest to him. John needs to have a deeper look at the map and says "Zoom please", while he opens his right hand in front of the display. The map shows the meeting point where John can go to receive all the assistance he needs. 4.2 Second Scenario A seismologic Institute has been provided a survey system using a Macro-seismic Questionnaire in order to collect perceptions and observations of people involved by earthquake. By using a satellite localisation system the Institute localizes John that is in an area involved by the seismic event, and sends him an SMS with questionnaire to be fill out. The questionnaire is devoted to analyse the consequences and effects of the seismic event on people and things. John, after some days from the seismic event decides to answer to the questionnaire. He is using his mobile phone because he is camped in a backpacking tent. At the question: “Where were you during the earthquake?” John answers by speech “I was at home”, at the question “What were you doing?” he answers “I was sleeping”. At the question “how many people close with you felt the earthquake?” he answers selecting “3” by using the keyboard. The ME platform enables John to access Web Services by multimodal interaction with his mobile phone improving accessibility everywhere and in different situations, and enables experts and civil protection structures to collect and share information and knowledge such as for example knowledge related with “seismic maps” that are used for the “Plan definition application”. 4.3 Third Scenario Let us suppose to be in the Securtown city. All is planned at Securtown to make happy and safe citizens. Securetown includes a rural area with isolated buildings. The combined use of acoustic alarms. Tricks daily threaten this harmony and for this reason civil protection and a lot of public and private organizations act to prevent and manage risks and emergencies.

ME: Multimodal Environment Based on Web Services Architecture

511

A very relevant activity is the risk prevention simulating the catastrophic event with the involvement of population. On February 20 a simulation of earthquakes with Richter magnitudo of 6.5 has been planned at Securtown. This event interrupts the electricity, gas and water supply. Alarms with a battery are activated to alert population, audio, text and visual messages are sent by mobile devices to provide people with information for coordinating them on what they have to do. That is, the operation room send to the “Multimodal Interaction management” Web Service the XML files with the multimodal messages for people, according to the “Emergency plan simulation” Web Service request. Mr. Smith, head of the operative room, sends a message to alert people on the need to leave buildings and to reach the lose meeting point: the meeting point is showed on a map in order to facilitate its localization. All people perform action according to the simulation plan and reach the meeting area suddenly. While is reaching the meeting point John perceives some voices near a collapsed building. He immediately sends by mobile to the operative room a request of assistance and send an image that can better explain the situation.

5 Conclusion Information, data and more generally each kind of service involved in the daily activities of individuals and organizations can be provided by different sources and by distributed applications. The heterogeneity of sources could imply information presented using different modalities (speech, visual, and so on) and their possible evolution over the time requiring different forms of treatment. Do not except data, information and services supplied in emergency situations or devoted to prevent and manage natural catastrophic events. They can involve information and data characterizing contingency plans, town plans, scientific data related to the seismic events in the interested area, geographic data in different processes. Emergency situation, moreover, can be particularly critical to access services and data using mobile devices, in terms of availability of technological resources such as bandwidth, intermittent connectivity to the network, or physical and or psychophysics people situations. This paper has described the framework (ME) Web Services architecture that permits to access these information and data used in catastrophic events such as earthquakes, floods, and so on, and to access and manage services using multimodal interaction on mobile devices. The importance of using multimodal interaction for managing services and sharing information is a focal point for emergency situations. In fact, using different modalities and/or their combination represents a very effective manner to supply services in critical situations. Some modules of the framework supporting multimodal interaction have been deveopped. As a future work strong activities of developping and evaluating the framework as a whole are planned.

512

M.C. Caschera et al.

References 1. Hauenstein, L., Gao, T., Sze, T.W., Crawford, D., Alm, A., White, D.: Web based macroseismic survey: fast information exchange and elaboration of seismic intensity effects in Italy. In: Proc. of 6th International ISCRAM Conference Conference on Information Systems for Crisis Response and Management (2009) 2. Gilles Mazet-Roux, G., Bossu, R., Carreño, E., Guilbert, J.: EMSC Real Time Earthquake Information Services, Report of the European-Mediterranean Seismological Centre (2009) 3. Rubbia, G., Camassi, R.: Changes and challenges following the 1997 Colfiorito earthquake: the evolution of the use of the Internet for large seismic events. Annals of Geophysics 2(3/51), 539–551 (2008) 4. Bellamine-Ben Saoud, N., Ben Mena, T., Dugdale, J., Pavard, B., Ben Ahmed, M.: Assessing large scaleemergency rescue plans: an agent-based approach. Special Issue on Emergency Management Systems. International Journal of Intelligent Control and Systems 11(4) (December 2006) 5. Hauenstein, L., Gao, T., Sze, T.W., Crawford, D., Alm, A., White, D.: A Cross-Functional Service-Oriented Architecture to Support Real-Time Information Exchange in emergency Medical Response. In: Proc. of Annual International Conference of the IEEE Engineering in Medicine and Biology Society 2006. IEEE Engineering in Medicine and Biology Society (2006) 6. W3C: Web Services Architecture, http://www.w3.org/TR/ws-gloss/ 7. W3C Recommendation official Web Site, http://www.w3.org/XML/ 8. W3C Recommendation official Web Site, http://www.w3.org/TR/soap 9. W3C Recommendation official Web Site, http://www.w3.org/TR/wsdl 10. W3C Recommendation official Web Site, http://www.w3schools.com/WSDL/wsdl_uddi.asp 11. Amoretti, M., Bisi, M., Zanichelli, F., Conte, G.: Enabling Peer-to-Peer Web Service Architectures with JXTA-SOAP. In: IADIS International Conference e-Society 2008, Algarve, Portugal (April 2008)

OnToContent 2009 PC Co-chairs’ Message In recent years the expectations of software technology have increased tremendously. Today software does not support only process automatization but social networking and social analysis too. For example, applications related to the creation of Web communities, or applications that involve the creation of applications incorporating elements of both traditional knowledge management and business process management techniques. In this context the issues related to the quality of data representation acquire a new relevance. The sort of accurate and timely analysis of data needed by major organizations demands that data be formulated in ways that are expressive and manipulable at the same time. In this context the role of good-quality ontology (i.e., good-quality conceptualizations, encoded in portable and extensible format) is more and more relevant. This workshop aims to focus on content issues, such as methodologies and tools concerned with modeling good ontologies, approaches to ontology content evaluation, quality measures, ontology content management (e.g., metadata, libraries, and registration), ontology documentation, etc. Paolo Ceravolo

R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, p. 513, 2009. c Springer-Verlag Berlin Heidelberg 2009 

Towards a Pattern-Driven Topical Ontology Modeling Methodology in Elderly Care Homes Yan Tang1, Peter De Baer1, Gang Zhao1,2, Robert Meersman1, and Kevin Pudney2 1

VUB STARLab 10G731, Vrije Universiteit Brussel Pleinlaan 2, 1050 Elesene Brussels, Belgium 2 The Social Care Institute for Excellence (SCIE) Goldings House 2 Hay's Lane London SE1 2HB {yan.tang,pdebaer,robert.meersman}@vub.ac.be, [email protected], [email protected]

Abstract. This paper presents a pattern-driven ontology modeling methodology, which is used to create topical ontologies in the human resource management (HRM) domain. An ontology topic is used to group concepts from different contexts (or even from different domain ontologies). We use the Organization for Economic Co-operation and Development (OECD) and the National Vocational Qualification (NVQ) as the resource to create the topical ontologies in this paper. The methodology is implemented in a tool called PAD-ON suit. The paper approach is illustrated with a use case from elderly care homes in UK.

1 Introduction and Motivation In the EC Prolix project1, we need to calculate competency gaps between a learning module (such as a learning material or a course), a person’s profile (such as his Curriculum Vitae), and the descriptions of a job in the human resource management (HRM) domain. In this project, a tool called Competency Analyzer is designed and implemented for supporting a simple calculation method, which computes a competency gap based on scores (e.g., by comparing a competence score in a person’s profile with the score of the required competence) and syntactical structures (e.g., by comparing the document tree structure of a person’s profile with the required competence tree structure). We observe that the simple matching algorithm in the competency analyzer is not sufficient to meet user’s needs in a complex setting. We are required to enrich the comparison power of the competency analsyer. As modern ontology engineering technologies provide insights and design/implementation possibilities of semantics 1

This paper is supported by the EC Prolix project. The EC Prolix (FP6-IST-027905, Process-Oriented Learning and Information Exchange, http://www.prolixproject.org/) is project co-funded by the European Commission under the Sixth Framework Program. It is to align learning with business processes in order to enable organisations to faster improve the competencies of their employees according to continuous changes of business requirements.

R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 514–523, 2009. © Springer-Verlag Berlin Heidelberg 2009

Towards a Pattern-Driven Topical Ontology Modeling Methodology

515

and its usage, we need to create ontologies as a knowledge base to enhance the competency analsyer. There exist several competency ontologies, such as [3, 7, 9], served for different purposes. For instance, the competency ontology in [7] is designed for competencydriven e-learning system. Harzallah et al. [9] use a competency ontology to analyze an implicit competency structure behind a Curriculum Vitae. The application purpose is an important2 factor that affects the content and the structure of resultant competency ontologies. In this paper, we will illustrate a pattern-driven topical ontology creation methodology (PAD-ON) for creating topical ontologies used for the competency matching. The paper is organized as follows. Chapter 2 is the paper background, which includes a use case in the field of elderly care homes in UK and the related work. We present PAD-ON in chapter 3. Chapter 4 presents the result of the paper. We conclude, compare our work to others’ and illustrate our future work in chapter 7.

2 Background In this chapter, we will discuss the paper background, which includes three parts. The first part is a use case, with which we use the methodology to create competency ontology. The other parts are the theoretical background of this chapter, which cover the discussions on ontology, the DOGMA approach to ontology engineering, and the related work. 2.1 SCIE Use Case The Social Care Institute for Excellence (SCIE3) was established by Government in 2001 to improve social care services for adults and children in the United Kingdom. SCIE’s core business is to advice old care homes for providing better services to elderly people. There are two kinds of people in SCIE concerning competency issues: 1) workforce, including carers (e.g., doctors and nurses) and administrative personnel (e.g., managers), 2) elderly people (cared objects). In the Prolix setting, we study competency issues only for the former group. The workforce members are responsible to accomplish different tasks, each of which requires a set of skills, knowledge and background. A task can also contain subtasks and a subtask may belong to different tasks. The tasks are accomplished to fulfill the needs of old people. Old people have a set of well beings, such as the emotional well being and intellectual well being. These well beings eventually form different goals of corresponding tasks. A use case from SCIE is as follows. In UK, every elderly care home (for instance, Risby Hall Nursing Home4) is evaluated periodically by Care Quality Commission 2

However, it is not the only factor that affects the content and the structure of a resultant competency ontology. The members of the domain expert community, for instance, are another factor. The discussion is out of the paper scope, we refer to [10] for the details. 3 http://www.scie.org.uk/ 4 Risby Hall Nursing Home is a private care home in Suffolk for the elderly who suffer from Alzheimer's, Dementia (Elderly) and physical disability.

516

Y. Tang et al.

(CQC5), which is responsible for the registration and inspection of social care services in England. Before taking an official evaluation, Risby Hall asks SCIE for a virtual evaluation and consulting its employees (in this case, nurses) on how to improve the unqualified competences. SCIE evaluates Risby Hall based on the Health and Social Care (HSC) competence specification provided by the National Vocational Qualification (NVQ6). Risby Hall provides the profiles of its nurses in terms of competences. Note that the competences specified by NVQ cannot be always mapped to Risby Hall’s competences. The problem scales down into: how we can find the similarities between an NVQ competence and a Risby Hall’s competence. Current competency analyzer can calculate the competence similarities if these two competences point to the same concept, or contains the same sets of concepts. It fails otherwise. We observe that in the SCIE use case, unfortunately, there do not exist two competences (one from NVQ and the other from Risby Hall) that point to one concept (set). Hence, a competency ontology and a semantic matching engine in the domain of elderly care home are required to enhance the competency analyzer. 2.2 Ontology and DOGMA The essential points in the definition of ontology are discussed by Gruber [8] as follows: 1) an ontology defines (specifies) the concepts, relationships, and other distinctions that are relevant for modelling a domain; 2) the specification takes the form of the definitions of representational vocabulary (such as lexons and commitments in DOGMA, see the following paragraphs), which provide meanings for the vocabulary and formal constraints on its coherent use. In Prolix, we can benefit many advantages of using ontologies as below: 1) Ontology can improve the reusability of the logics of applications. The issue of reusability is addressed at both operational/functional level and static inference knowledge base level. Ontology can be architected and abstracted in such a way that different applications can use the same ontology. For instance, not only Risby Hall’s applications but also the tools from other customers from SCIE can use the competency ontology in this paper; 2) Ontology offers an interoperability solution to the applications so that they can communicate with each other in a seamless way. With the competency ontology for elderly care homes, the competence terms provided by Risby Hall can be interpreted in terms of NVQ standardized concepts. 3) Ontology can improve the analytical performance of applications. Modern ontology engineering approach, such as ontology reasoning engines and algorithms, bestows ontology based applications on analysing benefits; 4) Ontology provides a portable, scalable and extensible solution to knowledge base design. An ontology, by default, can be enriched by different organisations from different communities in different application domains. Our particular work is to explore the ontology of workplace individual competences for enriching the analysing power of the matching mechanism in the competency analyzer. In the DOGMA (Developing Ontology-Grounded Methods and Applications, [11, 13,14]) framework, one constructs (or converts) ontologies by the double articulation principle into two layers: 1) the lexon base layer that contains a vocabulary of simple 5 6

http://www.cqc.org.uk/ http://www.direct.gov.uk/en/EducationAndLearning/QualificationsExplained/DG_10039029

Towards a Pattern-Driven Topical Ontology Modeling Methodology

517

facts called lexons, and 2) the commitment layer that formally defines rules and constraints by which an application (or “agent”) may make use of these lexons. A lexon is a quintuple , , , , , where is a context identifier, within which the terms , are defined. The role and co-role refer to the relations that the concepts share with respect to one another. For example, a on , , , , states a fact that “a driver’s license is issued to a driver”, and “a driver has a driver’s license”. The context identifier may refer to a URI where driver’s license and driver are defined. A commitment contains a set of rules in a given syntax, and describes a particular application view of reality, such as the use by the application of the (meta-) lexons in the lexon base. Suppose we apply the uniqueness constraint on the lexon in order to have has the constraint as “one driver’s license is issued to at most one driver”. Ontologies modeled in DOGMA can be further implemented in an ontology language, such as OWL7 and RDF(S)8. 2.3 Related Work Pattern-driven methodologies for creating domain ontologies are used to (semi-) automatically create ontologies by populating concepts in patterns. A related work of this paper is OntoCase [2], which retrieve and select patterns from a set of ontological patterns. The patterns that get high ranks are further used by ontology-based applications, such as search engines. Chenine et al. [4] use context based ontology design architecture in the form of Principle-Subject-Support (PSS) pattern, for creating distributed, heterogeneous and multi-functioned, application ontology. It is applied to create a military domain ontology. Presutti and Gangemi [12] discuss how to extract and describe emerging content ontology design patterns (CP), and how to compose, specialize and expand them for ontology design. They illustrate two CPs and apply them in the music industry domain. Other related work can be found in [1, 6, 13].

3 PAD-ON We create ontologies based on the structure of topical ontology. 3.1 Structure of Topical Ontology Based on the DOGMA framework (section 2.2) and the application rationale of the competency analyzer, we further divide an ontology into five blocks of specifications (Fig. 1). They are the basis, assertions, topics, applications and instances described as below. •

7 8

The specification of Basis identifies the conceptual objects and their typological relationship. In DOGMA, the basis is a lexon set that only contains lexons with “is-a” (or “part-of”, “subtype”, “subclass” etc.) relationships, for

OWL Web Ontology Language: http://www.w3.org/TR/owl-features/ RDF(S) Resource Description Framework (Schema): http://www.w3.org/TR/rdf-schema/

518

Y. Tang et al.

•

•

‫݁݁ݕ‬ǡ ݅‫ܽݏ‬ǡ ݅‫ݏ‬ǡ ‫ ۄ݊݋ݏݎݎ݁݌‬. This kind of lexons can instance, lexon ‫ߛߛۃ‬ǡ ݁݉‫ݕ݋݈݌‬ n be represented graphiically as a hierarchical, acyclic tree. The Assertions assserts how the conceptual objects interact with each othher. It contains the lex xons that have “free” relations or playing “free” roles w with ݊݁‫ݎ‬ǡ ‫݄ܿܽ݁ݐ‬ǡ ݅‫ݕܾݐ݄݃ݑܽݐݏ‬ǡ ܿ‫݋‬ ‫ ۄ݁ݏݎݑ݋‬. This kind each other, e.g., leexon ‫ߛۃ‬ǡ ‫݊݅ܽݎݐ‬ d of lexons can be represented graphically as a non-directed network. The Topics group ps the relationships and assertions into a topical mapp of larger reusable uniits. We consider a topic as a collection of lexons. Althouugh the theoretical basis for topics is different from that of a context, a topic can sometimes play thee role of a context.

Fig. 1. Ontology building blocks

•

•

The Applicationss select, constrain and contextualize topics, relationshhips and assertions to formulate abstracts about business data and processess in view of specific ap pplication semantics. It is a set of ontological commitmeents that contain constrraints and axioms. The Instance lists concrete references or values about conceptual objects,, relationships and assertions. For example, an instance of “skill level” in the lexon ‫ߛۃ‬ǡ ‫݈݈݅݇ݏ‬ǡ ݄ܽ‫ݏݏ‬ǡ ݅‫݂݋ݏ‬ǡ ‫ ۄ݈݁ݒ݈݈݈݁݅݇ݏ‬can be “good”.

Note that a lexon in the bllock of Instance, Applications and Topics needs to be defined in either the block of Basis or the block of Assertions, or both. The principlee of double articulation in DOG GMA (section 2.2) still holds in Fig. 1. One can consiider that Basis, Assertions and Topics T contain lexons. Applications and Instances bear bboth lexons and commitments. In order to create the paatterns for generating the ontologies, we need to study the ontology resource – materiaals used to create the HRM ontology in the field of eldeerly care homes. We need to create such a competency ontology that contains concepts at two shharing levels: one is the crosss-domain level, which can be used as HRM ontology iin a general sense; the other is domain d specific level, which defines “local” concepts in the domain of elderly care hom mes (section 2.1). The former is considered as the vocaabulary or basis for the latter. The T latter has a closer link with a domain. The cross-domain comp petency ontology is created based on the Organization for Economic Co-operation and d Development (OECD) and the National Vocational Q Qualification (NVQ). The domaain specific ontology is modeled and abstracted from Riisby Hall’s input. We will illustrate the pattterns for creating ontologies and describe how to use thhese patterns to create the ontolo ogy in the flowing section.

Towards a Pattern-Driven Topical Ontology Modeling Methodology

519

3.2 Pattern-Driven Topical Ontology Modeling Methodology (PAD-ON) A topical ontology is an ontology organized by topics [15]. This methodology contains five steps: 1) create pattern(s); 2) create ontological basis (subtypes of each element in the patterns); 3) create ontological assertions; 4) group lexons in the ontological basis and the ontological assertions into topics; 5) model ontological commitments for the applications and populate the instances of some concepts.

Fig. 2. Pattern used for HRM ontology

The design pattern is an extension to the design pattern discussed in [15], which consists of five elementary elements: Participant, Action/Process, Object, Attribute and State (Fig. 2). It has its basis in linguistics. We extend this pattern with the OECD key competence framework, the conceptualization of which focuses on the person and his action, the manner and means. It stresses the interaction between individuals at work. We refine Participant into Person. The State of the action is further detailed into the Instrument and Manner. Accordingly, we have a pattern as below. Persons Act or Interact on Objects by Instruments in Manners

In the SCIE domain, the view of competences focuses on the carer and the cared person. A cared person is the beneficiary of the competent HSC service. The Participant/Person in the design pattern is thus refined into Actor. An active participant performs the action, and the Patient, the passive participant that is affected by the action. Accordingly, the elements in the above pattern are specified as below. • Person/Actor: an initiator of an event or performer of an action, it is a Participant or Person • Patient: an affected, advantaged or disadvantaged participant in the action or event. It is a Participant or Person. • Object: an affected or resultant entity in an action, event or process. It has no volition and is inanimate. • Instrument: a means with which an Actor causes an event or performs an action. It pertains to the State of an action, process or event. • Manner: a state or form of an action, process or event. It pertains to the State of an action, process or event.

520

Y. Tang et al.

On step 1, our task is to define the patterns as illustrated above. Note that OECD is not the only source we use to create the patterns. We also use The Individual Performance Quality Ontology (IPQO) to define the patterns. IPQO makes use of NVQs and NVQ levels defined in the National Qualifications Framework. Below is a simple pattern from IPQO. Persons accomplish Tasks of Levels It can be extended by adding the categories from WICO as: Persons accomplish Tasks of Levels by Acting on or Interacting with Objects or Persons with Instruments in Manners On step 2, we define the subtypes of each element in the above pattern. For instance, we specify “nurse” as a subtype of “Person” and “interpreter machine” as a subtype of “Instrument”. On step 3, we create lexons that does not contain hierarchical relationships as roles. For instance, “assemble” is specified as “Interact” for the lexon ,

,

,

,

.

On step 4, we create ontological topics. The topics are considered as freely combined contexts, each of which accumulates lexons that are described at the basis level and assertion level into a set. For instance, , , , , belongs to the topics of “cleaning” and “HSC21”. The topics are defined based on users’ needs. A topic can be a skill, a competence (a set of skills) or a learning course. On step 5, ontological commitments that make use of the lexons created in the previous steps are modeled. Note that these commitment models need to be further implemented and integrated into the real application – DMatch [5].

4 Result The methodology is implemented in a tool called PAD-ON Suite (Fig. 3), which is developed in MS Access 20079. Users are able to create the patterns and specify the elements with concepts defined in the ontological basis and ontological assertions. Table 1. Number of lexons in different topics for SCIE (data is collected on June 6, 2009) Ontological topic name (selected) B1.1 B1.2 B1.3 Nurse routine task SCIE-manager level 1 – basis SCIE-manager level 2 – basis SCIE-manager level 3 – basis SCIE-manager level 4 – basis …

9

Number of lexons 68 79 70 20 32 102 178 237 …

MS Access is a relational database management system from Microsoft. http://office.microsoft.com/access

Towards a Pattern-Driven Topical Ontology Modeling Methodology

521

With PAD-ON suite, we have created in total 1054 lexons, which are used and grouped in different ontological topics (including 161 HSC topics and 72 Risby Hall’s topics). The example topics and their lexon numbers can be found in Table 1.

Fig. 3. PAD-ON Suit (screenshots)

We have also tested the resultant ontology and the topics in DMatch with simple set comparison algorithm. The result of comparing topic pair is recorded in Table 2. We are now using the same ontology for a more generic matching framework, which is still under development. Table 2. Similarites of topic pairs with simple set comparison algorithm Topic pair B1.3, nurse routine task B1.3, B1.1 B1.3, B1.2 B1.1, B1.2 Nurse routine task, B1.1 Nurse routine task, B1.2

Similarity 0 65.7% 52.85% 73.5% 10% 0

5 Conclusion, Discussion and Future Work In this paper, we have discussed the design of a pattern-driven topical ontology modeling methodology (PAD-ON), which is supported by a tool called PAD-ON suit. The resultant ontology is used by the semantic matching engine called DMatch for the competency analyzer, which provides competence gaps in HRM domain. Elderly care homes are the HRM domain of our ontology. As discussed in chapter 2, there exist pattern-driven ontology creation methodologies, such as [1, 2, 4, 6, 12, 13]. Blomqvist’s work [2] focuses on how to discover and rank ontology patterns amongst many. In her problem setting, there already exists a

522

Y. Tang et al.

domain ontology that contains many ontological patterns. Our work is concentrated on how to use a pattern (or several patterns) to generate an ontology. Chenine et al. [4] design a PSS pattern for domain ontologies. The particular pattern provides relationships between general concepts, which are principles, subjects and supports. It adopts the perspectives from the applications and software engineering. It covers the contexts and sub-domains that are related to the ontology usage and designing ontology based applications. Our work is more specialized in describing a domain; hence the resultant ontology can be used for different kinds of applications (although we use it for semantic matching in the project). The resultant ontology of this paper is now used by DMatch, which contains very simple algorithms, such as the set comparison and a matching algorithm supported by terminology data base. In the future, we will design and implement a more generic matching framework, which contains many matching strategies from different perspectives, such as linguistic, relational database modeling and graph theory.

References 1. Aranguren, M.E., Antezana, E., Kuiper, M., Stevens, R.: Ontology Design Patterns for bioontologies: a case study on the Cell Cycle Ontology. BMC Bioinformatics 9(5), S1 (2008) 2. Blomqvist, E.: Pattern ranking for semi-automatic ontology construction. In: Proceedings of the 2008 ACM symposium on Applied computing table of contents, Fortaleza, Ceara, Brazil, pp. 2248–2255 (2008) ISBN:978-1-59593-753-7 3. Bourse, M., Leclère, M., Trichet, F., Harzallah, M.: CommOnCV: [email protected]. In: Proceedings of the Twelfth International World Wide Web Conference, WWW 2003 (poster), Budapest, Hungary, May 20-24 (2003) 4. Chenine, M., Kabilan, V., Lozano, M.G.: A Pattern for Designing Distributed Heterogeneous Ontologies for Facilitating Application Interoperability. In: Proceedings of 3rd Open INTEROP Workshop On Enterprise Modeling and Ontologies for Interoperability (EMOI 2006), collocated with CAiSE 2006(2006) 5. Christiaens, S., Debruyne, C., Delaaf, J., Stam, J., Tang, Y., Zhao, G.: Prolix Deliverable 3.4 – Test bed vision analysis & first version ontologies, ch. 6, DMatch. V3.0, STARLab, Brussels, Belgium (November 7, 2009) 6. Clark, P., Thompson, J., Porter, B.: Knowledge patterns. In: Cohn, A.G., Giunchiglia, F., Selman, B. (eds.) Proceedings of KR 2000: Principles of Knowledge Representation and Reasoning, pp. 591–600. Morgan Kaufmann, San Francisco (2000) 7. Draganidis, F., Chamopoulou, P., Mentzas, G.: An Ontology Based Tool for Competency Management and Learning Paths. In: Proc. of Sixth International Conference on Knowledge Management (I-KNOW 2006), September 6-8 (2006) 8. Gruber, T.R.: Toward Principles for the Design of Ontologies Used for Knowledge Sharing. In: Guarino, N., Poli, R. (eds.) Workshop on Formal Ontology. Formal Ontology in Conceptual Analysis and Knowledge Representation, Padva, Italy. Kluwer Academic Publishers, Dordrecht (1993) 9. Harzallah, M., Berio, G., Vernadat, F.: Analysis and Modeling of Individual Competencies: Toward Better Management of Human Resources. IEEE Transactions on Systems, Man, and Cybernetics, Part A 36(1), 187–207 (2006) 10. Hepp, M., De Leenheer, P., de Moor, A., Sure, Y. (eds.): Ontology Management for the Semantic Web, Semantic Web Services, and Business Applications. Springer, Heidelberg (2008)

Towards a Pattern-Driven Topical Ontology Modeling Methodology

523

11. Meersman, R.: Ontologies and Databases: More than a Fleeting Resemblance. In: d’Atri, A., Missikoff, M. (eds.) Proceedings of OES/SEO 2001 Rome Workshop. Luiss Publications (2001) 12. Presutti, V., Gangemi, A.: Content Ontology Design Patterns as Practical Building Blocks for Web Ontologies. In: Li, Q., Spaccapietra, S., Yu, E., Olivé, A. (eds.) ER 2008. LNCS, vol. 5231, pp. 128–141. Springer, Heidelberg (2008) 13. Rector, A., Rogers, J.: Patterns, properties and minimizing commitment: Reconstruction of the GALEN upper ontology in owl. In: Gangemi, A., Borgo, S. (eds.) Proceedings of the EKAW 2004 Workshop on Core Ontologies in Ontology Engineering (2004) 14. Spyns, P., Meersman, R., Jarrar, M.: Data Modeling versus Ontology Engineering. SIGMOD Record: Special Issue on Semantic Web and Data Management 31(4), 12–17 (2002) 15. Zhao, G., Meersman, R.: Architecting ontology for scalability and versatility. In: Meersman, R., Tari, Z. (eds.) OTM 2005. LNCS, vol. 3761, pp. 1605–1614. Springer, Heidelberg (2005)

A Socio-semantic Approach to Collaborative Domain Conceptualization Carla Pereira1,2, Cristóvão Sousa1,2, and António Lucas Soares1,3 1

Instituto de Engenharia de Sistemas e Computadores do Porto (INESC Porto), Campus da FEUP, Rua Dr. Roberto Frias, 378, 4200 - 465 Porto, Portugal 2 Escola Superior de Tecnologia e Gestão de Felgueiras – Instituto Politécnico do Porto, Rua do Curral, Casa do Curral, Margaride, 4610-156, Felgueiras, Portugal 3 Faculdade de Engenharia da Universidade do Porto, Rua Dr. Roberto Frias, 4200-465, Porto, Portugal [email protected], [email protected], [email protected]

Abstract. Current knowledge about the early phases of ontology construction is insufficient to support methods and techniques for a collaborative construction of a conceptualization. Following an approach inspired in cognitive semantics, the application and extension of the Conceptual Blending Theory (CBT) to the realm of collaborative semantic tools is proposed. A formal framework is presented together with some examples in the collaborative networks context. A collaborative semantic architecture is presented. This architecture supports the two components of the proposed method: collective conceptualization and consensus reaching. Keywords: Conceptualization, social construction of meaning, ontology development, collaborative networks, conceptual blending.

1 Introduction Even though the most used definition of ontology [4] "An ontology is a formal, explicit specification of a shared conceptualization", underlines the collaborative construction of conceptualizations in the scientific context, we agree that: "While different degrees of formalization have been well investigated and are now found in various ontology-based technologies, the notion of a shared conceptualization is neither well-explored, nor wellunderstood, nor well-supported by most ontology engineering tools" [8]. Current knowledge about the early phases of ontology construction is insufficient to support methods and techniques for a collaborative construction of a conceptualization [5]. Nevertheless, the conceptualization phase is of utmost importance for the success of the ontology, as it is in this phase that a socio-semantic agreement is shaped. Our view is that ontology engineering needs a “socio-cognitive turn” in order to generate tools that are really effective in copying the complex, unstructured, and highly situational contexts that characterize a great deal of information and knowledge sharing in business collaboration. As it argued in [1]: “we need to go beyond the approaches that provide a high R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 524–533, 2009. © Springer-Verlag Berlin Heidelberg 2009

A Socio-semantic Approach to Collaborative Domain Conceptualization

525

level of ‘automation of the meaning’; instead, we need to address situations where human beings are highly required to stay in the process, interacting during the whole lifecycle of applications, for cognitive and cooperative reasons”. The research work described in this paper was motivated by the need to support effectively information and knowledge sharing in the context of collaborative networks with short life-cycles. The early phases of setting up information and knowledge management architectures for inter-organizational teams (e.g., large scale international R&D or systems engineering projects) are complex and problematic due, in a great extent, to the actor’s heterogeneous professional and cultural backgrounds. good example of this is the construction industry, where an enormous effort and money has been spent in standard terminologies, vocabularies, thesaurus, ontologies, etc. with results well behind the expected [7]. This line of research is therefore directed towards the application of cognitive semantic results in the creation of artifacts acting as socio-technical devices supporting the view that meaning socially constructed through collaboration and negotiation. The first line of this research work deals with the application and extension of the Conceptual Blending Theory (CBT) [3] to the realm of collaborative semantic tools. The practical application of our approach is to support the co-construction of semantic artifacts by groups of social actors placed in organizational contexts interacting towards a set of common objectives. Simple examples of these artifacts are the creation of a common taxonomy (or ontology) for classifying and retrieving content from an inter-organizational portal, the creation of specific terminological accounts to serve as conceptual references in project tasks, or the specification of ontologies for systems interoperability.

2 The Conceptual Blending Theory Our proposal to support a collaborative process of conceptualization of a given reality (e.g., a domain in the context of a project) is founded on cognitive semantics, specifically on the Conceptual Blending Theory [3]. CBT accounts for the emergence of meanings by adopting the view that meaning construction involves emergent structure, i.e., conceptual integration is more than the sum of its component parts. An integration network is thus a mechanism for modeling how emergent meaning might come about, accounting for the dynamic aspects of meaning construction. CBT representation gives rise to complex networks by linking two (or more) input spaces by means of a generic space. The generic space provides information that is abstract enough to be common to all the input spaces. Elements in the generic space are mapped onto counterparts in each of the input spaces, which motivate the identification of cross-space counterparts in the input spaces. A further space in this model of integration network is the blended space or blend. This is the space that contains new or emergent structure. The blend takes elements from both inputs, but goes further on providing additional structure that distinguishes the blend from either of its inputs. In other words, the blend derives a structure that is contained in neither input (see [2] and [5]).

526

C. Pereira, C. Sousa, and A.L. Soares

3 A Method to Support the Conceptualization Process The several case studies accomplished in the scope of our participation in two European projects, AC+DC1 and H-Know2, allow us to refine and improve our method as well as to propose a tool to support it (case studies described in [6] and [10]). 3.1 Collaborative Network Characterization Departing from the work of Roth [9], we develop a conceptual and formal framework for modeling collaborative networks as epistemic networks. Our view is that an epistemic network as made of three networks: a social network (involving links between individuals), a semantic network (with links between concepts) and a socio-semantic network (which links individuals to concepts). At the end all partners that belong to the network will be linked to concepts in the same way, or rather, to the semantic network that represents the shared conceptualization. In our context, the nodes in a social network represent the set of individuals of the several organizations (partners), that compose the collaborative network, and links represent the relationships between the several individuals. The semantic network is the network of concepts that represents the strategic frame of the collaborative network, where nodes are concepts of the several domains that compose the network and edges are relations between concepts. The final semantic network will be the shared conceptualization presented in the generic space (considering the network model of CBT theory [5]). The socio-semantic network is made of individuals of the several organizations that compose the collaborative network, concepts of the several business domains, and links between them, representing the usage of concepts by individuals within the strategic frame. The final socio-semantic network represents the relationship between all organizations that compose the network and the shared conceptualization. Considering the three networks, we deal with different kinds of links that influence the result of the shared conceptualization process. Considering the social network, we consider two kinds of relations: links between the several organizations that constitute the collaborative network, i.e., between individuals from different organizations; (theses links influence during the negotiation process); and links between pairs of individuals within the organization (theses links influence the input spaces creation. However, at this moment, this relationship will not be addressed by us). Considering the semantic network, we deal with two kinds of relations: links between concepts of different conceptualization proposals (links between input spaces – considered in the step 2 of our method, see next section) and links between concepts within each conceptualization proposal (each input space). Considering the socio-semantic network, we deal with the links between the individuals that compose the network and the concepts that compose the shared conceptualization. 3.2 CBT Based Method Steps. With a set of assumptions already described in [5], the proposed method establishes the following steps (see figure 1). Step 0: Based on the definition of the strategic 1 2

http://www.acdc-project.org/public/ http://dionisio.inescporto.pt:8282/hknow

A Socio-semantic Approach to Collaborative Domain Conceptualization

527

frame a subgroup of participants should create a preliminary proposal that will be shared in the generic space and used as foundation for the step 1. Step 1: each organization has assigned one or more input spaces (only one input space per organization is considered here, for simplicity) and represents its conceptualization proposal through the input space. Considering the definition of “space”, each conceptualization proposal is a concept map with the information and other knowledge sources which allow the correct understanding of the conceptualization proposal. Step 2: a generic conceptualization is generated; the common conceptual structure in the generic space should be broad enough to be accepted by all the team members with minimum negotiation. Step 3: considering the “counterpart” elements, the process of creating the blend space is started using selective projection; based on the input spaces, strategic frame, generic space and documentation available in the input spaces (called background information), the blend is “run” to obtain new conceptualization proposals. Step 4: new conceptual structures proposed in the blend space are object of negotiation; the concepts for which consensus exists are represented in (“copied” to) the generic space; situations that justify “backward projection” to the input spaces and their modification are analyzed (this analysis will be performed by the users, after obtaining consensus) then the emergent blend structure is validated (confirm or eliminate new concepts that raise in the blend). Step 5: if input spaces modification takes place, the method should resume at step 2; however the creation of a new blend space, is not necessary.

Fig. 1. Method to support the collaborative conceptualization process

Step 6: when all participants manifest their agreement with the conceptualization represented in the generic space, the method instance is finished. Whenever an organization introduces a new concept or association in their input space, it becomes a target for negotiation. At this moment the negotiation process is started. The network team evaluates the new entrance, and if necessary “run” the steps 2, 3 and 4 to help their decision. Consensus Building Strategy to Support the Negotiation Process To ensure a successful negotiation process, which lead to a shared conceptualization (accepted by all partners), is also very important to define an approach for obtaining

528

C. Pereira, C. Sousa, and A.L. Soares

consensus. For this goal, there are some good practices that should be applied, but that need to be adjusted for each case. In [10] we present a strategy for building consensus in the context of collaborative networks, aligned with the fact that the process of building consensus is regarded collaborative right from the design, once the process design itself should involve all participants [11]. Our approach to reach a semantic agreement for the collective conceptualization is thus based on consensus building techniques and involves, besides the negotiation itself, a preparation and an evaluation phases (see [10]). For the preparation phase, the creation of the team and the governance model of the collaboration are the main tasks. In the consensus building phase, must be used a combination of the following two approaches to drive the process, “working with a single-text document” and “taking a visioning approach”. The singletext approach involves introducing a working draft of an agreement early in the process for parties to discuss and revise. This approach provides a clear structure for discussions and a focal point to identify areas of agreement and disagreement. A subgroup of participants works to draft a preliminary proposal. This preliminary proposal is considered the best way to focus a consensus building dialogue (performed in the step 0 of the method). Brainstorming will be used to expand and improve the preliminary proposal using the proposals presented in the input spaces of each organization and to encourage creative thinking. The exploration of several proposals should be accomplished using questions of the type “what if” and performing the steps 2, 3 and 4 of the method to support the collaborative conceptualization process. The “taking a visioning approach” intend to focus participants’ attention toward the future in the course of identifying options and seeking agreements. Conduct the process according to the following questions: What do you have?, What do we want? And “How do we get there? These questions allow the semantic team evaluates the strengths and weaknesses of the current conceptualization proposal and to maintain the process more creative. To support the dissemination of information, a content management system and/or wiki system should be used, that allows notifying the participants in the process, to distribute materials to participants during the process, allow the information sharing, keep all stakeholders updated about the group progress and keep a record of all items discussed. A set of documents such as: meeting minutes, agendas, schedules, working documents and background resources, are taken as important to share. If necessary, at this stage, the agenda and procedural rules can be modified. Evaluation and lessons learnt, before closing the process, the final version of the conceptualization should circulate for all participants. At this moment should be organized a workshop to divulge the final result to all partners. The evaluation of strengths and weaknesses of the process will be performed based on experience obtained through our participation in the process and carrying out an online questionnaire to all participants. Responsibilities and roles definition: There are three different roles that the participants can assume (see figure 2): partner (any member of the collaborative network may take this role); reviewer (each organization define a representative who will assume the role of reviewer; the representatives are part of the group responsible for making decisions). When the specificity of the conceptualization increases the need to create different work groups will be evaluated again; and mediator, a person responsible for ensuring the proper participation of all and managing the conceptualization. The consensus building workflow used is presented in figure 3 and described in [10].

A Socio-semantic Approach to Collaborative Domain Conceptualization

529

Fig. 2. Consensus building workflow

Techniques and Tools. During our research work and based on the case studies carried out through an action research approach, some tools and techniques were placed in evidence to support the proposed method. We are now able to summarize those techniques and supporting tools as well as the current architecture which supports our method. From the terminological domain we used the lexical database, IATE3, the inter-institutional terminology database of the European Union and TermExtractor4. IATE allowed us to search for the correct correspondent terms chosen to name a concept, in several languages, according with a specific domain, along the concept maps creation within each input space. TermExtractor, is a text mining tool, used to extract relevant terms in the interest domain, by submitting an archive of domain-related documents in any format. Those documents used were mainly internal project documents, the logistics area of SAP dictionary5, the terms and glossary about supply chain management proposed by [12]. As the knowledge representation technique for joint construction of a conceptual representation is proposed the use of concept maps, supported by CmapTools6 software. The use of concept maps would allow untrained users, that cannot be expected to conform to the constraints of the formal semantics, to concentrate on the task at hand in an unrestricted environment. Our goal is to allow users (all participants in the conceptualization process) could start informally, without having to translate their know-how into any knowledge representation (heavy) formalism [13]. The exploration of CmapTools features, lead us to clarify some sociotechnical assumptions, as well as specify and/or refine new ones in order to achieve an architecture able to support the proposed CBT methodology. CmapTools was essential to support the frame definition and input and blend services were supported by Plone CMS and Semantic Media Wiki (SMW). CmapTools can actually support, partially, the proposed method (frame definition and input spaces), however we are facing an inter-organizational processes with several steps and stages, which asks for a more comprehensive and collaborative environment architecture (see Fig. 3.), calling for several specific services in order to support consensus building and negotiation processes. 3

http://iate.europa.eu/iatediff/SearchByQueryLoad.do?method=load http://lcl2.uniroma1.it/termextractor/ 5 http://help.sap.com/saphelp_46c/helpdata/En/35/2cd77bd7705394e10000009b387c12/ frameset.htm 6 http://CMAP.ihmc.us/conceptmap.html 4

530

C. Pereira, C. Sousa, and A.L. Soares

Fig. 3. Dynamic Collaborative Environment Architecture

Following this, and according to the goals described earlier on this paper, (where it is mentioned the need to disseminate the information, towards to allow the semantic team to evaluates the strengths and weaknesses of the current conceptualization proposal) two modules are to be developed: one supporting the semi-automated construction of the conceptual integration spaces (semBlend) and the other supporting semantic negotiation and consensus reaching (semCons). These make part of a broader platform: SemSys4CCM (Semantic System for Continuous Construction of Meaning). Currently several services are running in order to communicate with CmapServer, and getting the conceptualization proposal developed according with the initial steps of the method. With this feature we are able to have all the input spaces in our knowledge repository. At this point, the functionalities of the semantic media wiki are used to discuss the input spaces and to annotate the concepts within each input space, gathering information to run the blend. Additional features were developed to allow, maintenance, navigation and integration and synchronization with the CmapServer.

4 A Formal Framework Definition 1: Concept map. Let us consider LC as a set of symbols (the concepts) and LR as set of symbols (the relations). A concept map CM is a tuple (LC, LR, LCM), where LCM is a set of literals of the form r ( y , z ) , such that r ∈ LR ; y , z ∈ LC .

CM = {r ( y, z ) : r ∈ LR, y, z ∈ LC}

(1)

Definition 2: Space. A conceptual space, E, is a tuple (CM, LK), where CM is a concept map and LK is a set of links to information and knowledge sources. Definition 3: Context Frame. Given a collaborative network, N, the context frame (FN) can be defined as a tuple (DN, ON), where DN are the set of business domains of the organizations that compose the network, ON are the set of goals of the network (common organization’s goals together with specific goals for the network). Definition 4: Conceptualization proposal (input space). Let us consider T ⊆ S × D binding S to D. We introduce the operation “^” such that for any element s ∈ S , s^ is the set of elements of DN which are T − related to s. T

A Socio-semantic Approach to Collaborative Domain Conceptualization

531

expresses any kind of relationship between an organization s and business domain d. In our case, this relationship represents the fact that d is one of the business domains of s.

s ^ = {d ∈ D | sTd } .

(2)

β ⊆ d × FN binding d to FN. We introduce the operation “*” such that for any element c, k ∈ d : d ⊂ D , x * is the set of elements of d which are β − related to FN. β expresses the fact that a subset of LC or a subset of LK d to be part of Let us consider

FN. c represents a concept and k represents a information source of the domain d.

{ } = {k ∈ d | kβ F }

( x*)c = c ∈ d | cβ FN ( x*)k

(3)

N

When we start the creation of a conceptualization proposal, we use the information and knowledge of each domain and organize them in a space. Being, the input space of an organization s1, a tuple ( LC1 ' , LK1 ' LR ' , LCM ' ) = (CM 1 , LK1 ) , where

LC1 ' is the set of concept , ( x*) c ,of the business domains of s1 related to FN , LK 1 ' k is the set of information sources , ( x*) , of the business domains of s1 related to FN. A first version of the shared conceptualization available for discussion (presented in the blend space), G ' , created with focus on the several partners proposals can be formalized as follow. The concepts for which consensus exist are copied for the generic space. G ' is created using the mapping operation, ϕ , that find a set of mappings between two concepts presented in different proposals (in different input spaces) and the projection operation η . For lack of space, the several operations will not be described with detail here. The final shared conceptualization, G, is a tuple ( LCG , LRG , LK G , LCM G ) where LCG and LRG are composed by elements (concepts or relations, respectively) from the mapping operation, blend creation (the elements of

b Δ ) and elements proposed during the negotiation process by the participants.

Definition 5: Negotiation and decision-making space (Blend space). The blend space (B) results from the application of the composition, completion and elaboration processes to the input spaces. It is a tuple ( LC B , LRB , LCM B ) , where LC B and LRB results from the projection and completion operations. A projection operation determines, for each element of a concept map in the input spaces, what will be its correspondent in the blend space. The input for the projection operation is the result of the mapping function application. The completion operation provides new elements, not visible in the input spaces but that are part of FN , with base in some filters applied to the information sources available in the several spaces. That is, this space provides a new proposal of shared conceptualization for negotiation. For us, a blend is defined by the projection ( η ) and completion ( δ ) operations. In an initial iteration, we consider the results of the projection operation as the first version of the shared

532

C. Pereira, C. Sousa, and A.L. Soares

conceptualization ( G ' ). During the negotiation process the participants can “run the blend”, which corresponds to the completion operation. Considering a proposed blend space, B, the several organizations negotiate the proposal for the shared conceptualization. Like this, let us consider θ ⊆ LC B × S binding LC B to S. We introduce de operation

" Δ" such that for any element s ∈ S , b Δ is the set of elements of LC B

θ − related to every element of S. In our case, the θ

relationship represents the exis-

tence of consensus between all organizations S about a

c ∈ LC B .

b Δ = {c ∈ LC B | ∀s ∈ S , cθs} .

(4)

During the negotiation process can be proposed others concepts for besides the ones that constitute the input spaces and blend space. Of these proposals, the concepts for which consensus exists are also presented in the generic space.

5 Conclusions The approach described in this paper proposes a shift in the process of creation of semantic artifacts from a “semantic artifact engineering” perspective to a “actorartifact co-evolution” one. Socio-semantics is the scientific umbrella to this approach, which is also inspired in cognitive semantics and networking social theories. A set of detailed case studies is under way, whereas action research was adopted as the privileged way to generate knowledge in socio-technical settings. The results already achieved through case studies allowed us to design the architecture of a collaborative environment architecture that will support all steps of the method. Future work involves the refinement of the architecture. Further developments are needed to meet the requirements for a semi-automated conceptual integration. This will require the development of semantic artifacts over the content management layer, extending a wiki to a semantic level and providing a set of services which, in conjunction with CmapTools, will offer a suitable environment to support the negotiation and the Blend space.

References 1. Cahier, J.-P., Zaher, L.’H., Leboeuf, J.-P., Guittard, C.: Experimentation of a socially constructed “Topic Map” by the OSS community. In: Proceedings of the IJCAI 2005 workshop on KMOM, Edimbourg (2005) 2. Evans, V., Green, M.: Cognitive Linguistics: an introduction. Edinburgh University Press (2006) 3. Fauconnier, G., Turner, M.: Conceptual Integration Networks. Published in Cognitive Science 22(2), 133–187 (1998) 4. Gruber, T.R.: A Translation Approach to Portable Ontology Specifications. Knowledge Acquisition 5(2), 199–221 (1993) 5. Pereira, C., Soares, A.: Ontology development in collaborative networks as a process of social construction of meaning. In: Meersman, R., Tari, Z., Herrero, P. (eds.) OTM-WS 2008. LNCS, vol. 5333, pp. 605–614. Springer, Heidelberg (2008)

A Socio-semantic Approach to Collaborative Domain Conceptualization

533

6. Pereira, C., Sousa, C., Soares, A.: A socio-semantic approach to the conceptualisation of domains, processes and tasks in large projects. In: 11th International Conference on Enterprise Information Systems, May 2009, pp. 6–10 (2009) 7. Silva, M., Soares, A., Simões, D.: Selecting and Structuring Semantic Resources to Support SME’S Knowledge Communities. In: INCOM 2006, 12th IFAC Symposium on Information Control Problems in Manufacturing, St. Etienne, France (2006) 8. Staab, S.: On understanding the collaborative construction of conceptualisations. In: International and Interdisciplinary Conference Processing Text-Technological Resources at the Center for Interdisciplinary Research (ZiF - Zentrum für interdisziplinäre Forschung). Bielefeld University, March 13-15 (2008) 9. Roth, C.: Co-evolution in Epistemic Networks Reconstructing Social Complex Systems. Structure and Dynamics: eJournal of Anthropological and Related Sciences 1(3) (2006) 10. Pereira, C., Sousa, C., Soares, A.: Short-term semantic consensus: towards agile ontology specification for collaborative networks. In: 10th IFIP Working Conference on VIRTUAL ENTERPRISES (PRO-VE 2009), Thessaloniki, Greece, October 7-9 (2009) 11. Susskind, L., Mckearnan, S., Thomas-Larmer, J.: The Consensus Building Handbook: A comprehensive Guide to Reaching Agreement. The Consensus Building Institute. Sage Publications, Thousand Oaks (1999) 12. Vitasek, K.: Supply Chain Management, Terms and Glossary (2008) 13. Eskridge, T., Hayes, P., Hoffman, R., Warren, M.: Formalizing the informal: a confluence of concept mapping and the semantic web. Concept Maps: Theory, Methodology, Technology. In: Cañas, A.J., Novak, J.D. (eds.) Proc. of the Second Int. Conference on Concept Mapping, Costa Rica (2006) 14. Pereira, F.: Creativity and Artificial Intelligence: A conceptual Blending Approach. Applications of Cognitive Linguistics. Mouton de Gruyter, Berlin (2007)

Termontography and DOGMA for Knowledge Engineering within PROLIX Peter De Baer1, Robert Meersman1, and Rita Temmerman2 2

1 STARLab, Vrije Universiteit Brussel, Pleinlaan 2, 1050 Brussels, Belgium Centre for Terminology and Communication, Erasmushogeschool Brussel, Pleinlaan 5, 1050 Brussels, Belgium {pdebaer,meersman}@vub.ac.be, [email protected]

Abstract. In this article, we describe our ongoing research to combine two approaches, i.e. Termontography and DOGMA, for knowledge engineering. Both approaches have in common that they mainly rely on natural language to describe meaning. Termontography is a special form of terminography that results in an ontologically structured terminological resource. DOGMA is an abbreviation of Developing Ontology Guided Mediation for Agents. The DOGMA approach results in a scalable and modular ontology that can easily be (re)used for different domains and applications. Both Termontography and DOGMA have already been used separately during several research projects. In this article we explain how both approaches are being combined within the PROLIX project, and what the advantages of this combination are. The goal of PROLIX is to develop an open, integrated reference architecture for process-oriented learning and information exchange. Keywords: Knowledge engineering, ontology engineering, terminography.

1 Introduction In today's knowledge driven world, effective access to and use of information is a key enabler for progress. Modern technologies not only are themselves knowledge intensive technologies, but also produce large quantities of new information that must be processed and aggregated. These technologies require knowledge capture, which involves the extraction of useful knowledge from vast and diverse sources of information as well as its acquisition directly from users. Driven by the demands for knowledge-based applications, the constructed knowledge resources should best be structured in such a way that various applications may use the information. In order to build such resources, VUB STARLab combines two approaches for knowledge engineering, i.e. Termontography and DOGMA, as part of the European integrated project PROLIX1. In this article we will first introduce both approaches for knowledge acquisition and representation. Afterwards, we will describe the combination of both approaches within the PROLIX project and explain some of the advantages. 1

http://www.prolixproject.org/

R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 534–543, 2009. © Springer-Verlag Berlin Heidelberg 2009

Termontography and DOGMA for Knowledge Engineering within PROLIX

535

2 Termontography Termontography is based on the insights of sociocognitive terminology management [17], which in addition to linguistic information, takes cultural and cognitive perspectives into account during terminology description. Based on these insights an innovative methodology for sociocognitive terminography was developed. The goal of the methodology is to build comprehensive lexical resources that may help to overcome certain communication problems. The methodology therefore starts with a problem analysis of each communication problem, in order to find the requirements of a possible solution in the form of an ontologically structured terminological resource. An example of such communication problem may occur in specialized communication. To build a multilingual terminological resource, the methodology analyses terms as they appear and are used in multilingual (specialized) natural language, using techniques of corpus linguistics, terminography, and ontology engineering. Extracted terms from a specialized text corpus are described and linked to concepts, resulting in a terminological ontology. Techniques for ontology engineering are applied to structure the terminological information according to the different perspectives of interest for the end user. This formal knowledge representation, using an ontology, should also facilitate the application of the resulting resources in various software tools like an electronic dictionary, a translation memory system, or a knowledge management system. Two examples of resources that were built using the methodology are: an ontologically structured lexical resource that helps to bridge communication gaps between welfare professionals in the European Union [4], and an ontologicallystructured multilingual (EN, FR, NL) terminological resource of competences and occupations [3]. 2.1 Termontography Methodology The Termontography methodology consists of a cyclic process divided into six phases. During the first knowledge analysis phase (1), the communication problem is analyzed. The analysis results in a specification requirements document for the terminological resource and a categorization framework [5]. Such categorization framework may best be considered as a terminological domain ontology that contains the key concepts and relations for the domain. Using the key concepts a specialized text corpus is compiled during the information gathering phase (2). The gathered texts are then analyzed and relevant terminology is extracted and linked to the categorization framework. This we call the search phase (3). During the refinement phase (4) the terminological resource will be further developed. Verification (5) guarantees the correctness of the resource according to the accepted understanding of the domain. Validation (6) guarantees that the resource corresponds to the specification requirements document. Note: The methodology follows the typical ontology development life cycle [14]; however, the specification, conceptualization, formalization, and implementation phase all use the categorization framework [5] to capture the terminological and ontological information.

536

P. De Baer, R. Meersman, and R. Temmerman

2.2 Termontography Software Currently, the Termontography methodology is supported by the following software tools: the didactic CatTerm wizard teaches student-translators to use the methodology to acquire bilingual domain knowledge, the Termontography Workbench (see Fig. 1) is used to manage a specialized corpus and the ontologically structured terminology base, and the Categorization Framework Editor [3] that is used to manage a terminological ontology in the form of a categorization framework. All these software applications make use of the Categorization Framework API [2] to manage the underlying information store.

Fig. 1. The Termontography Workbench is used to manage a text corpus, extract terminology, and build a terminological ontology

3 DOGMA DOGMA is a research initiative of VUB STARLab where various theories, methods, and tools for ontology engineering and ontology driven application design are studied and developed. A DOGMA inspired ontology is based on the classical modeltheoretic perspective [15] and decomposes an ontology into a lexon base and into a layer of ontological commitments [11, 12]. This is called the principle of double articulation [16]. A lexon base holds simple, commonly agreed upon, context-specific facts that are part of the conceptualization of a particular domain. These facts are called lexons. A

Termontography and DOGMA for Knowledge Engineering within PROLIX

537

lexon is formally defined as a 5-tuple . A lexon may be read as: within the context identified by the context-id, the implied head concept may play this role for the tail concept, and conversely the tail concept may play this co-role for the head concept. The modality “may” indicates plausibility since lexons are assumed to be defined independent of subsequent applications (and therefore also may come in many shapes and formulations for the same “fact”). For example the lexon states that within the context of human resource management, programming skills (may be) part of the qualification for a Bachelor in Computer Science, and conversely that this degree (may be) providing the competence ‘programming skills’. Both (context, head) and (context, tail)-pairs are axiomatically assumed to identify a unique concept. Any specific (application-dependent) interpretation rules are moved to a separate layer of ontological commitments. The commitment layer mediates between the ontology base and its applications. Each ontological commitment defines a partial semantic account of an intended conceptualization [9]. It consists of a finite set of axioms that specify which lexons of the ontology base are used and how they should be annotated in and used by the committing application. Experience shows that it is much harder to reach an agreement on such application specific constraints than on the generic plausible domain facts [10]. E.g. a rule stating that each employee has a single function may hold in one organization, but could be too strong for another application. As DOGMA intends to be a generic approach to ontology engineering it is not restricted to a specific ontology language (e.g. RDF [13] or OWL [20]). Once the elicitation process is finished, and the ontology formalized, the DOGMA tools can output the information to the target language. Conversely, existing ontologies may be converted from specific representation languages into DOGMA, so that they may be maintained and updated using the DOGMA Studio tools [1, 18]. The DOGMA principles derive in part from an early database design methodology called Natural Language Information Analysis Method [7] and uses natural language based techniques and terminology in order to elicit concepts from domain experts. The latter therefore do not have to tackle formal language issues, or learn to think in a new paradigm. Due to the strict separation between lexon base (i.e. lexical representation of concepts and their relationships) and commitments (i.e. adding application-specific interpretation rules) a DOGMA ontology achieves a more convenient balance between use and reuse. For example, a well accepted fact that an employee holds a position within an organization, could be reused in many applications. An application specific commitment that an employee holds just one position could, however, be too strict for most organizations. Usage complexity concerns also become separated similar to the way databases implement data independence [11]. 3.1 DOGMA Software Currently, the DOGMA approach is supported by the following software tools2: the DOGMA Studio suite and the DOGMA-MESS web platform. 2

We limit our discussion to the research prototypes; commercial versions of the Studio suite are available from the STARLab spin-off company Collibra (www.collibra.com).

538

P. De Baer, R. Meersman, and R. Temmerman

The DOGMA Studio suite contains both a Server and a Workbench. The DOGMA Server is an ontology library system that features context-driven disambiguation of lexical labels. It provides a framework for managing multiple context dependency types and operators. The DOGMA Workbench is based on the plug-in architecture of the Eclipse IDE. Plug-ins exist for ontology viewing and querying, and editing modules support the different ontology engineering activities. DOGMA-MESS (Meaning Evolution Support System) is a web-based platform that supports interorganizational ontology engineering [6]. The main focus in DOGMA-MESS is how to capture relevant interorganizational commonalities and differences in meaning. It provides a community grounded methodology to address the issues of relevance and efficiency. In DOGMA-MESS, there are three user roles: (1) Knowledge Engineer, (2) Core Domain Expert, and (3) Domain Expert. The task of the Knowledge Engineer is to assist the (Core) Domain Experts in their tasks. The major chunk of knowledge is captured by the Domain Experts themselves. The Core Domain Expert builds high-level templates in the so-called Upper Common Ontology. The Domain Experts specialize these templates to reflect the perspective of their organization in their Organizational Ontologies. The Domain Experts are shielded from complexity issues by assigning specific tasks in the elicitation process (e.g. to specialize a ‘Subtask’ template for ‘Baking’). In every version of the process, common semantics are captured in the Lower Common Ontology whilst organizational differences are kept in the Organizational Ontologies. Information in the Lower Common Ontology is distilled from both the Upper Common Ontology and the Organizational Ontologies using meaning negotiation between (Core) Domain Experts. The Lower Common Ontology is then used as input for future versions in the process.

4 Termontography and DOGMA DOGMA and Termontography have already been applied separately during the research projects FFPoirot (http://www.ffpoirot.org/) and PoCeHRMOM (http://starlab.vub.ac. be/website/PoCehrMOM). Currently, we use a combination of both approaches for the PROLIX project. The objective of PROLIX is to align learning with business processes in order to enable organizations to faster improve the competencies of their employees according to continuous changes of business requirements. To reach this goal, PROLIX develops an open, integrated reference architecture for process-oriented learning and information exchange. Third party vendors may integrate specific solutions into the overall approach by introducing or replacing modular components and/or services. One of the tasks of STARLab in the project was to develop ontologies based on the existing competence frameworks used by the test bed partners, e.g. British Telecom (BT), the Social Care Institute for Excellence (SCIE), Klett Lernen und Wissen GmbH, and the Baden-Württembergische Genossenschaftsverband. To develop the ontologies we made use of the existing competence materials of the test bed partners. For example, SCIE provided us with documents describing the competence standards, e.g. ‘Health and Social Care’ (HSC) and ‘Leadership and Management for Care Services’ (LMC), they use within their organization. To build the SCIE competence ontology based on these standards we made use of the Termontography Workbench (see Fig. 1) to build the text corpus, extract the terminology, and

Termontography and DOGMA for Knowledge Engineering within PROLIX

539

build the terminological ontology. A first advantage of this approach is that, during the development of the ontology, the link with the source texts is preserved. Since the source texts help to document the derived ontology, the collaborating knowledge engineers, who may not be domain experts themselves, are better able to understand the concepts and concept relations. Another advantage is that the Termontography Workbench allows publishing the ontology in HTML3. The HTML format makes it easy to discuss the ontology with domain experts and users. Each competence also has a unique URL which may be used to specify the competence. For example, a job candidate might specify his competences (e.g. in a portfolio) by referring to the corresponding competence URLs. This enables HRM managers to better understand the competences by analyzing the HTML competence information. A third advantage is that (multilingual) terminological information can easily be added during the conceptualization process. Adding (multilingual) terminological information helps, both knowledge engineers and end users, to better understand the ontology. Terminological documentation is considered important in many ontology engineering methodologies, e.g. ENTERPRISE [19] and METHONTOLOGY [8]. Another task of STARLab within PROLIX was the development of a data matching service and the evaluation of different ontology-based data matching algorithms. Using the DOGMA Studio tools, knowledge engineers could, in collaboration with domain experts from the test beds, develop a domain ontology for competency matching. This domain ontology consists of the concepts: competence, competence level, competency, context, function, person, qualification, qualification level, and task. • •

• • • • •

3 4

A competence is a generic competence that may be reused within different organizations. A competence level indicates the proficiency level of a person for competences. Examples are the reference levels in the Common European Framework of Reference for Languages4. Each competence level has a minimum and maximum value between 0 and 1 to enable interorganizational comparison. If an organization uses four competence levels A, B, C, and D, competence level A might, for example, have the minimum value 0 and the maximum value 0.25, i.e. 1 / 4. A competency is a specific competence that includes a certain competence level and optionally a context. A context is a category that may help to contextualize competences. For example the context BT would indicate that the competence should be interpreted within the context of that organization. A function is an organization specific occupational title. A person represents an employee within an organization or a job candidate. A qualification is a training certificate issued by an organization that certifies a set of competencies for a person. The qualification may correspond to a set of training materials, a set of begin competencies, and a set of end competencies.

SCIE competence ontology: http://starlab.vub.ac.be/prolix/SCIE/competences/index.htm Common European Framework of Reference for Languages: http://tinyurl.com/2k7zko

540

P. De Baer, R. Meersman, and R. Temmerman

•

•

A qualification level is a level that indicates the difficulty level of a qualification. Examples are the European Qualification Levels5. Each qualification level has a minimum and maximum value between 0 and 1 to enable interorganizational comparison. A task is an organization specific task that requires certain competencies.

To test different matching strategies, application ontologies with instance information linked to terminological resources and the domain ontology were needed. To manage these ontological and terminological resources the Context Ontology Editor (COE) (see Fig. 2) was developed. The COE uses the Categorization Framework API (CF API) [2] and the DOGMA ontology format to bridge between both ontology formats. Although the CF API makes a distinction between abstract contexts and concrete objects, both types share the same super type ‘meaning’. Therefore it is possible to handle both contexts - for the domain ontology - and objects - for the application ontology - in a similar way. Since the ‘meaning’ type may be linked to (multilingual) terminology, the data matching algorithms have access to both the ontological and the terminological information via the CF API. This makes it easier to implement data matching algorithms compared to using different types of resources. The Categorization Framework does not make use of description logics. However, the matching algorithms may commit to specific contexts, objects, object relations, and object properties in the resource. Therefore, semantically rich reasoning is possible. For

Fig. 2. The Context Ontology Editor is used to manage both the domain (Context taxonomy) and application ontology (Object hierarchy), and to link contexts and objects to terminology

5

European Qualification Levels: http://tinyurl.com/lfrq6u

Termontography and DOGMA for Knowledge Engineering within PROLIX

541

example, the relationship ‘has required competency’ may be used to list the required competencies for a certain task. The reason why we prefer not to make use of description logics is that we want ontologies that are easy to build, reuse, and understand. Therefore, we prefer to use natural language to describe the intended meaning. We also believe that the consistency of the ontologies may be guaranteed by the commitments in the ontology software tools (or the CF API) without imposing formal restrictions on the ontology itself. Ultimately, the responsibility for the correct use and implementation of an ontology will always be in the hands of the application developers and the ontology engineers who use and construct the ontology. Not all the competency information, provided by the test beds, was available in text format. For example, BT provided samples on competences, competence levels, functions, tasks, and qualifications in MS Excel format. To import such existing structured information, the Categorization Framework XML (CF XML) [2] format could be used. CF XML is a simple XML format to import and export a Categorization Framework via the CF API. The advantage of the format is that objects are identified by the combination of both the context head term and the object head term. This allows the automatic merging of two Categorization Frameworks and the modular management of the resources. Simple scripts may be used to convert structured information into CF XML.

5 Conclusion Our experience in combining Termontography and DOGMA for knowledge engineering shows that both approaches complement each other well. Termontography is useful to develop terminological ontologies starting from structured and unstructured textual material. This allows ontology engineers to make use of the wisdom contained in existing resources, for example standards, while developing ontologies. The approach is also useful to document existing ontologies with (multilingual) terminological information. DOGMA is especially suited to develop more formal ontologies by allowing domain experts to create and update the ontology using a combination of top-down and bottom-up techniques. Both approaches allow for the modular development of the information resources. CF XML may be used to import / export parts of the terminology base, and lexons and ontological commitments may be imported / exported within DOGMA Studio. Acknowledgments. The research described in this paper was sponsored in part by the EU IP 027905 Prolix project.

References 1. Coessens, B., Christiaens, S., Verlinden, R.: Ontology guided data integration for computational prioritization of disease genes. In: Meersman, R., Zahir, T., Herrero, P., et al. (eds.) On the Move to Meaningful Internet Systems 2006: OTM 2006 Workshops (KSinBIT 2006). Springer, Heidelberg (2006)

542

P. De Baer, R. Meersman, and R. Temmerman

2. De Baer, P., Kerremans, K., Temmerman, R.: Constructing Ontology-underpinned Terminological Resources. A Categorisation Framework API. In: Proceedings of the 8th International Conference on Terminology and Knowledge Engineering, Copenhagen (2008) 3. De Baer, P., Kerremans, K., Temmerman, R.: A Categorisation Framework Editor for Constructing Ontologically underpinned Terminological Resources. In: Proceedings of the 6th international conference on Language Resources and Evaluation, Marrakech (2008) 4. De Baer, P., Kerremans, K., Temmerman, R.: Bridging Communication Gaps between Legal Experts in Multilingual Europe: Discussion of a Tool for Exploring Terminological and Legal Knowledge Resources. In: Corino, E., Marello, C., Onesti, C. (eds.) Proceedings of the XII Euralex International Congress, Turin, Italy, September 6-9, pp. 813–818 (2006) 5. De Baer, P., Kerremans, K., Temmerman, R.: Facilitating Ontology (Re)use by Means of a Categorization Framework. In: Meersman, R., et al. (eds.) On the Move to Meaningful Internet Systems 2006. Proceedings of the AWeSOMe workshop, Montpellier, France, October 2006, pp. 126–135 (2006) 6. de Moor, A., De Leenheer, P., Meersman, R.: DOGMA-MESS: A meaning evolution support system for interorganizational ontology engineering. In: Schärfe, H., Hitzler, P., Øhrstrøm, P. (eds.) ICCS 2006. LNCS (LNAI), vol. 4068, pp. 189–202. Springer, Heidelberg (2006) 7. De Troyer, O., Meersman, R., Verlinden, P.: RIDL* on the CRIS Case: a Workbench for NIAM. In: Olle, T.W., Verrijn-Stuart, A.A., Bhabuta, L. (eds.) Computerized Assistance during the Information Systems Life Cyle, pp. 375–459. Elsevier Science Publishers B.V., Amsterdam (1988) 8. Fernández, M., Gómez-Pérez, A., Juristo, N.: METHONTOLOGY: from ontological art towards ontological engineering. In: Proceedings of AAAI 1997 spring symposium series, workshop on ontological engineering, Stanford, CA, pp. 33–40 (1997) 9. Guarino, N., Giaretta, P.: Ontologies and knowledge bases: Towards a terminological clarification. In: Mars, N. (ed.) Towards Very Large Knowledge Bases: Knowledge Building and Knowledge Sharing, pp. 25–32. IOS Press, Amsterdam (1995) 10. Meersman, R.: Semantic web and ontologies: Playtime or business at the last frontier in computing? In: NSF-EU Workshop on Database and Information Systems Research for Semantic Web and Enterprises, pp. 61–67 (2002) 11. Meersman, R.: Ontologies and databases: More than a fleeting resemblance. In: d’Atri, A., Missikoff, M. (eds.) OES/SEO 2001 Rome Workshop. Luiss Publications (2001) 12. Meersman, R.: The use of lexicons and other computer-linguistic tools in semantics, design and cooperation of database systems. In: Zhang, Y., Rusinkiewicz, M., Kambayashi, Y. (eds.) Proceedings of the Conference on Cooperative Database Systems (CODAS 1999), pp. 1–14. Springer, Heidelberg (1999) 13. Miller, E., Manola, F.: RDF primer. W3C recommendation, W3C (2004), http://www.w3.org/TR/2004/REC-rdf-primer-20040210/ 14. Pinto, H.S., Martins, J.P.: Ontologies: How can They be Built? Knowledge and Information Systems (6), 441–464 (2004) 15. Reiter, R.: Towards a logical reconstruction of relational database theory. In: Brodie, M., Mylopoulos, J., Schmidt, J. (eds.) On Conceptual Modelling, pp. 191–233 (1984) 16. Spyns, P., Meersman, R., Jarrar, M.: Data modelling versus ontology engineering. SIGMOD Record 31(4), 12–17 (2002) 17. Temmerman, R.: Towards New Ways of Terminology Description. The sociocognitive approach. John Benjamins, Amsterdam (2000)

Termontography and DOGMA for Knowledge Engineering within PROLIX

543

18. Trog, D., Vereecken, J., Christiaens, S., De Leenheer, P., Meersman, R.: T-lex: A rolebased ontology engineering tool. In: Meersman, R., Tari, Z., Herrero, P., et al. (eds.) OTM 2006 Workshops. LNCS, vol. 4278, pp. 1191–1200. Springer, Heidelberg (2006) 19. Uschold, M., King, M.: Towards a methodology for building ontologies. In: Proceedings of IJCAI 1995’s workshop on basic ontological issues in knowledge sharing, Montreal, Canada (1995) 20. van Harmelen, F., McGuinness, D.L.: OWL web ontology language overview, W3C recommendation, W3C (2004), http://www.w3.org/TR/2004/REC-owl-features-20040210/

A Pattern-Based Framework of Change Operators for Ontology Evolution Muhammad Javed, Yalemisew M. Abgaz, and Claus Pahl Centre for Next Generation Localization (CNGL), School of Computing, Dublin City University, Dublin 9, Ireland {mjaved,yabgaz,cpahl}@computing.dcu.ie

Abstract. Change operators are the building blocks of ontology evolution. Different layers of change operators have been suggested. In this paper, we present a novel approach to deal with ontology evolution, in particular, change representation as a pattern-based layered operator framework. As a result of an empirical study, we identify four different levels of change operators based on the granularity, domain-specificity and abstraction of changes. The first two layers are based on generic structural change operators, whereas the next two layers are domainspecific change patterns. These layers of change patterns capture the real changes in the selected domains. We discuss identification and integration of the different layers. Keywords: Ontology evolution, change operators, pattern-based change.

1

Introduction

The dynamic nature of knowledge in every domain requires ontologies to change over time. The reason for change in knowledge can be the change in the domain, the specification, the conceptualization or any combination of them [1]. Some of the changes are about the introduction of new concepts, removal of outdated concepts and change in the structures and the meanings of concepts. A change in an ontology may originate from a domain knowledge expert, a user of the ontology or a change in the application area [2]. Ontology evolution is defined in different ways [3,4,5]. A comprehensive definition is given as “the timely adaptation of an ontology to changed business requirements, to trends in ontology instances and patterns of usage of the ontology based application, as well as the consistent management/propagation of these changes to dependent elements” [3]. Based on the different perspectives of the researchers, there are different solutions provided to handle ontology evolution [3,6,7,8]. Different phases of ontology evolution have been identified [3]. Basic changes in the evolving ontology can be captured using operators. However, the identified change operators focus on generic and structural changes lacking domain-specificity and abstraction. Moreover, these solutions lack adequate support for different levels of granularity at different levels of abstraction. Some central features of our proposed evolution framework that go beyond the current focus on compositionality of change are: R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 544–553, 2009. c Springer-Verlag Berlin Heidelberg 2009 

A Pattern-Based Framework of Change Operators for Ontology Evolution

545

– To make changes in ontologies effective, change needs to be operationalised. The operation can be atomic, composite or complex [1,9,10]. This indicates that the effectiveness of a change is significantly dependent on the granularity, how the change operators are combined and the extent of their effect in the ontology. The impact of the change operators can affect the consistency of the ontology. Thus, a coherent treatment of the change operators and their effect on the consistency at each level of granularity becomes vital. – The changes at a higher level of granularity, which are frequent in a domain, can be represented as domain-specific patterns – which are often neglected by the lower-level compositional change operators addressed in the literature. Thus, the categorization of operators at a domain-specific level enables us to support high-level abstraction. This abstraction enables us to map the domain-specific levels to abstract levels and facilitate the smooth linking of domain ontologies with upper ontologies like SUMO [11]. We present an approach to deal with ontology evolution through a framework of compositional operators and change patterns, based on the empirical evaluation of changes in a couple of different ontologies. We focus on domain-specific perspective-linking structural changes in domain ontologies. We identified four levels of change operators and patterns based on the granularity of changes, the effect the change operators have on the ontology, domain-specificity, i.e., the extent to which the operators are specific to a certain domain and become domain-specific patterns of change, and the degree of abstraction. The paper is structured as follows: We discuss our empirical study in Section 2. Framework of change operators and patterns is presented in Section 3. A short evaluation is given in Section 4. Related work is discussed in Section 5 and we end with some conclusions.

2

Empirical Study of Evolution of Domain Ontologies

While layered change operators have been suggested, we studied the evolution of ontologies empirically in order to investigate the relationships between generic and domain-specific changes and to determine common patterns of change. 2.1

Domain Selection and Ontology Development

Since our focus is to study, identify and classify the changes that occur in ontologies, a careful selection of the domain is of great importance. As case studies, the domains University Administration and Database Systems were taken into consideration. The former is selected because it represents an organisation involving people, organisational units and processes. The latter is a technical domain that can be looked at from different perspectives – for instance being covered in a course or a textbook on the subject. The database textbook ontology was derived from the taxonomy arising from the table of content and the index. The technical database domain ontology was developed by domain experts. The university ontology was developed by us.

546

2.2

M. Javed, Y.M. Abgaz, and C. Pahl

Empirical Change and Evolution Analysis

We approached the problem as an empirical study and conceptualization of the two domain areas. The database ontology is constructed by observing the domain area and the patterns are identified by observing the practical changes in the domain. These changes are identified by comparing text books, course outlines, lecture notes and changes in technologies. These practical changes are the changes that we observed following database experts, academics and practitioners, which allowed us to approach the problem from an empirical point of view. Domain experts in both areas have contributed to the study [12]. The abstraction of the changes into a higher level in the hierarchy is done by conceptualization of the results of the empirical study. In the case of the university ontology, we considered Dublin City University (DCU) as our case study and we conceptualized most of the activities and the processes in DCU for the construction of the ontology. Following a similar approach to the database ontology, we investigated abstraction at higher levels during conceptualization. 2.3

Analysis of the Empirical Results

We outline some results here, before discussing details that will lead to the change operator framework in the next section. Database Ontology. We observed that the changes in the database system can be identified by taking different perspectives into account. In teaching, the course content changes almost every year introducing new concepts, theories and languages. In publishing, new database books in the area appear every couple of years resulting in addition of new chapters, merging or removal of existing chapters and changing of the structure of the topics within and among chapters. In industry, new technologies and languages are emerging. These changes result both in structural and instance level change. For example, in the perspective of teaching databases, an academic may introduce a new technology and make it a precondition for learning some of the chapters. Furthermore, he may merge two chapters into one. These factors make evolution predictable to some extent. University Ontology. The objective of this ontology is to assist administering the proper execution of the day-to-day activities of a university. We observed that a University ontology changes frequently at instance level due to joining or leaving of Faculty, Student or Staff, introduction of new Courses etc., but less frequently and more irregularly at concept level.

3

A Framework of Change Operators and Patterns

Changes have to be identified and represented in a suitable format to resolve ontological changes [13]. The explicit representation of change allows us to analyse and understand a change request. Changes that occur in the ontology are

A Pattern-Based Framework of Change Operators for Ontology Evolution

547

Fig. 1. Different Levels of Change Operators

tracked and identified. Based on our observation of common changes in all versions of the ontologies, we studied the patterns they have in common, resulting in a framework of change operators (Fig. 1): – – – –

level level level level

one: elementary changes which are atomic tasks. two: aggregated changes to represent composite, complex tasks. three: domain specific change patterns. four: abstraction of the domain specific change patterns.

The operators in level one and level two reflect generic structural changes; however the change patterns in level three and level four need to be customized (Fig. 2). We observed that ontology changes are driven by certain types of common, often frequent changes in the application domain. Therefore, capturing these in the form of common and regularly occurring change patterns creates domain-specific abstractions. A number of basic change patterns may be provided so that users may adapt and generate their own change patterns to meet their own domain demand. This makes the ontology evolution faster and easier. The dots at each level (Fig. 2) depicts that change operators are extensible. 3.1

Generic Structural Levels

Level One Change Operators – Element Changes. These change operators are the elementary operations used to perform a single task by an ontology management tool. These operators add, modify or remove a single entity in the ontology. A single operator performs a single task that can add single concept, a single property or delete a single concept, etc. We can identify these simple operations based on the constituent components of the ontology. We can create a new concept “DDL” as a subconcept of “Database”: – create a concept DDL using CreateConcept(DDL) – make DDL a subconcept of Database using Subconcept(DDL, Database) Level Two Change Operators – Element Context Changes. Many evolution tasks cannot be done by a single atomic operation. A set of related operations is required. These change operators are identified by grouping atomic

548

M. Javed, Y.M. Abgaz, and C. Pahl

Fig. 2. Architecture of layered change operators

operations to perform a composite task. For example, to delete a single concept “faculty” in the university ontology, removing the concept from the concept hierarchy is not sufficient. Before we remove the concept, we have to remove it from the domain and the range of properties like “hasPublication” or “supervises” that are linked to it. In addition, we need to either remove its subconcepts or link them to the parent concept. Depending on this context of an element, we use different operators from level one resulting in a standardised change pattern. The second level operations affect the structure of the ontology. If an instructor wants to add a single chapter to his course outline, the operator “Integrate Concept Context” that operates on a single targeted concept can be used: – create concept SQL using CreateConcept(SQL) – make SQL subconcept of Database using Subconcept(SQL, Database) If he wants to merge two or more chapters for an abridged course outline, which involves two or more concepts, the operation requires operators higher than integrate concept context and the corresponding operations, for instance Merge (DDL, DML, Database): – Integrate Concept Context by creating concept Database using CreateConcept(Database) – Integrate Property Context by creating property isBasedOn using Create Property(isBasedOn)

A Pattern-Based Framework of Change Operators for Ontology Evolution

549

– Integrate Domain/Range Context by adding domain Database to isBasedOn using AddDomain(isBasedOn,Database) and adding range Relational Algebra to isBasedOn using AddRange(isBasedOn,Relational Algebra) – Remove Concept Context by deleting concept DML using DeleteConcept (DML) and deleting concept DDL using DeleteConcept(DDL) 3.2

Domain-Specific Level

Level Three Change Operators – Domain-specific. This domain-specific perspective links the structural changes to the aspects represented in domain ontologies. In order to execute a single domain-specific change, operations at level two are used. In addition, this level is constructed on the perspectives we identified in the construction stage of the ontology. The change patterns are based on the viewpoints and activities of the users. Two users may have different perspectives to view the ontology which results in the use of a different combination of operations from level two. As the perspectives are different, the number of operations or the sequence of operations might differ. This difference results in patterns of change based on the perspectives of the ontology engineers. Database Ontology. In the Database domain, the different perspectives we mentioned define their own patterns. From the teaching perspective, “manage chapter” has a pattern of calls such as create concept “chapter X” for a specific topic, create properties such as “isRequiredBy”, “isAlternateTo” and “isBasedOn” to sequence topics in a course. From the perspectives of authors, a pattern to create concept “chapter X” and MoveConceptUp “chapter X” is often used. A technology domain expert only needs to include the technology as a new concept and calls to create a concept “new technology”. Level three operators enable us to treat domain-specific operations separately and allow an ontology engineer to define his own change patterns once, which can be executed many times. For example an instructor wants to manage the contents of his database course. He has different ways of managing the chapters by adding new chapters, altering the prerequisites, merging or splitting the chapters or a combination of one or more of the above. Some of the operations that occur frequently are listed in Table 1. An instructor who wants to adapt a course outline every time he delivers courses can identify patterns of changes that enable him to manage the course outline. From the list in Table 1, options 1, 3, 9 can be chosen whenever a new chapter is added and others are left out. He can determine a pattern of managing chapters by adding a new chapter. When a chapter needs to be deleted, options 5 and 10 can be chosen and when chapters need to be split, then 6, 9, 10 would suit. Specific to the domain and the requirements of the ontology user, with out going to the details of the first and the second levels, he can choose his own patterns and execute change based on the patterns defined before. University Ontology. In case of the University Administration domain, level three may contain change patterns such as “manage faculty”, “open new department” or “close department”. If one user needs to register a new category of

550

M. Javed, Y.M. Abgaz, and C. Pahl Table 1. List of Operations for Course Management

1. 2. 3. 4.

Add new chapters (concepts) Move sub sections to chapters Add sections Move chapters to sub chapters

5. 6. 7. 8.

Delete chapters Split chapters Copy chapters Merge chapters

9. Set prerequisite 10. Remove prerequisite

Table 2. List of Operations for Employee Management 1. Add employee 3. Copy employee

2. Add fields of employee 4. Add properties (like Manages, Supervises etc.)

faculty using the manage faculty change pattern, say a Lecturer, then he creates a concept “Lecturer”, creates a property “hasPublication”, “supervise” etc. from level two – see Fig. 2. Another ontology engineer may create a new concept “Lecturer” without including the “supervise” property. Note, that this is a structual change at concept level. For employees with no management position, the ontology engineer can choose a pattern containing 1, 2 and execute that every time there is a new employee. However, if he has managers with a management function then he can choose 1, 2, 4 and if the employee is assigned in two or more sections he can choose 1, 2, 3 and execute this pattern whenever there is a new employee that fits any of these conditions. These changes can be aggregated together and patterns of change can be identified. These specific patterns of change are often domain-specific and can be reused at instance level for the addition of new lecturer or manager employees. However, these variation are similar within a domain. A generic employee change pattern with common operations emerges. 3.3

Abstract Level

Level Four Change Operators – Generic Categorisation. These are constructed based on the abstraction of the concepts in level three. The main objective of introducing this level is to provide a facility that allows us to map domain-specific ontologies to available upper level ontologies (i.e. categorising domain concepts in terms of abstract ones) and that helps to generalise and transfer patterns to other domains. For example the University Administration ontology can be mapped and linked to any other organization that has a similar conceptual structure. In the university domain, one can identify concepts such as students, faculties and employees; a production company may have employees, customers, owners or shareholders. Level four provides an abstraction to represent all these concepts using a general concept “Person”. In a similar fashion, the University system has research groups, departments, and committees; whereas a company may have research groups, departments and board of directors. We can abstract them as “Structures”. Furthermore, we have admission, examination,

A Pattern-Based Framework of Change Operators for Ontology Evolution

551

teaching, auditing in a university system and production, auditing and recruitments in an organization. We can abstract them to “Processes”. In the Database Systems ontology we can identify Relational Algebra, Relational Calculus or SQL concepts, whereas an ontology for Java Programming may have concepts such as Control Statements, Class or Thread. Level four provides an abstraction to represent all these concepts using a general concept such as “Theory”. The benefit is the reuse of domain-specific patterns and their re-purposing for other, related domains, i.e. the transfer between domains. Level four provides a common ground to link the ontology with existing higher-level ontologies such as the Suggested Upper Merged Ontology (SUMO) or MIddle Level Ontology (MILO) that provide the bridge between domains. It provides change patterns that can be applied to any subject domain ontology that is composed of a similar conceptual structure. Level four is constructed on top of level three and level two. Fig. 2 represents the architecture of how the four levels are integrated and interconnected to each other. This can actually be seen as part of the evaluation, where genericity and transferability are important criteria. Level Four is actually a framework aspect that guides transfer of patterns to other domains (rather than being of specific importance for the user of a concrete application ontology).

4

Evaluation

The change operator and pattern framework introduced here has been empirically developed. In our evaluation, we specifically considered validity, adequacy and transferability as criteria. Validity. The evaluation of the work relating to the validity of the operators in representing real-world problems faced by users and ontology engineers. In this regard, the change operators and patterns we found are based on changes actually carried out by users and ontology engineers and observed by us in both the university administration and database systems ontologies. Though it is not expected to be exhaustive, we found that a significant portion of ontology change and evolution is represented in our framework. Adequacy. The adequacy of the solution to be useful and suitable to the users and ontology engineer. For this purpose, we identified different levels of abstractions for those who focus on the generic as well as the domain-specific changes. The patterns are appropriate to provide domain-specific level change support for users. The lower-level operators are useful to ontology engineers to suitably define their own change operators. Domain experts can use the patterns and alter them to meet their requirements by varying the sequentialisation of the content elements. In such cases change patterns are at the right level of abstraction and consequently more usable for the domain experts. It faciliates a structured evolution process easy and reduces effort in terms of time consumption.

552

M. Javed, Y.M. Abgaz, and C. Pahl

Transferability. The four levels of change operators are evaluated against their transferability and applicability to other domain ontologies. Transferability is a measure of the usefulness of the framework. We looked at the transferability or the applicability of our change operator framework for instance between different academic, but also between universities as academic organisations and industrial organisation. Basic change pattern are generally transferable and applicable with little customization of the operators to other domain ontologies – a process facilitated by the categorisation of level 3 within level 4.

5

Related Work

We give a brief summary of current practice in the area of ontology evolution, specifically change representation. The author in [9] discusses the complexity of the change management process and presents a six phase ontology evolution process. She discusses the representation of generic changes and categorized them into elementary, composite and complex. In contrast to our work, they do not include aspects such as granularity, domain-specificity and abstraction. In [1], the authors provide a set of possible ontology change operations based on the effect with respect to the protection of the instance-data availability. Their work focuses more to instances than the structural or domain specific operations. In [10], the impact of ontology change to the validity of the instance availability is discussed and changes are subdivided into two categories, i.e. structural and semantic changes. Though their work addresses semantic changes, our work takes the semantic changes further and proposes domain-specific change patterns for semantic changes. In [6], the authors present a declarative approach to represent the semantics of changes, considered as a reconfiguration-design problem. Their work is focused on the realization of the changes, whereas our work is focused on identifying domain-specific change patterns.

6

Conclusion

We discussed our approach for ontology evolution as a pattern-based compositional framework. The approach focuses on four levels of change operators and patterns which are based on granularity, domain-specificity and abstraction. While ontology engineers typically deal with generic changes at level one and level two, other users can focus on domain-specific changes at level three. Using level four, a link to the existing high-level ontologies like SUMO and MILO can be created. Our framework benefits in different ways. First, it enables us to deal with structural and semantic changes at two separate levels without loosing their interdependence. Second, it enables us to define a set of domain-specific changes. Third, domain-specific changes can be shared among other ontologies that have similar conceptualizations and specifications. It facilitates the linking of an ontology with other high-level ontologies.

A Pattern-Based Framework of Change Operators for Ontology Evolution

553

The empirical study indicates that the solution is valid and adequate to efficiently handle ontology evolution. Currently we are focusing on the formalization of change patterns and the impact of the changes on the consistency of the ontology. The implementation of the approach as an operator and pattern calculus, which includes tools and techniques, and the investigation of pattern customisation and transformation to other domains is our future work.

Acknowledgment This work is supported by the Science Foundation Ireland through its CNGL CSET grant.

References 1. Noy, N.F., Klein, M.: Ontology evolution: Not the same as schema evolution. Knowledge and Information Systems 6(4), 328–440 (2004) 2. Liang, Y., Alani, H., Shadbolt, N.: Ontology change management in prot´eg´e. In: Proceedings AKT DTA Colloquium, Milton Keynes, UK (2005) 3. Stojanovic, L., Maedche, A., Motik, B., Stojanovic, N.: User-driven ontology evolution management. LNCS, vol. 6(4), pp. 285–300. Springer, Heidelberg (2002) 4. Haase, P., Sure, Y.: User-driven ontology evolution management. State-of-the-Art on Ontology Evolution. EU IST Project SEKT Deliverable D3 1.1.b (2004) 5. Flouris, G., Plexousakis, D., Antoniou, G.: A classification of ontology change. Poster Proceedings of the 3rd Italian Semantic Web Workshop, Semantic Web Applications and Perspectives, SWAP 2006 (2006) 6. Stojanovic, L., Maedche, A., Stojanovic, N., Studer, R.: Ontology evolution as reconfiguration-design problem solving. In: Proceedings of the 2nd international conference on Knowledge capture (2003) 7. Zablith, F.: Dynamic ontology evolution. In: International Semantic Web Conference (ISWC) Doctoral Consortium, Karlsruhe, Germany (2008) 8. Plessers, P., De Troyer, O., Casteleyn, S.: Understanding ontology evolution: A change detection approach. Web Semantics: Science, Services and Agents on the World Wide Web 5(1), 39–49 (2007) 9. Stojanovic, L.: Methods and tools for ontology evolution. PhD thesis, University of Karlsruhe (2004) 10. Qin, L., Atluri, V.: Evaluating the validity of data instances against ontology evolution over the semantic web. Information and Software Technology 51(1), 83–97 (2009) 11. Top level Ontologies, http://www.ontologyportal.org 12. Boyce, S., Pahl, C.: The development of subject domain ontologies for educational technology systems. Journal of Educational Technology and Society (ETS) 10(3), 275–288 (2007) 13. Oliver, D.E., Shahar, Y., Shortliffe, E.H., Musen, M.A.: Representation of change in controlled medical terminologies. Artificial Intelligence in Medicine 15(1), 53–76 (1999)

A Simulation Model Articulation of the REA Ontology Wim Laurier and Geert Poels Department of Management Information and Operational Management, Faculty of Economic and Business Administration, Ghent University, Tweekerkenstraat 2, 9000 Ghent, Belgium {wim.laurier,geert.poels}@ugent.be

Abstract. This paper demonstrates how the REA enterprise ontology can be used to construct simulation models for business processes, value chains and collaboration spaces in supply chains. These models support various high-level and operational management simulation applications, e.g. the analysis of enterprise sustainability and day-to-day planning. First, the basic constructs of the REA ontology and the ExSpect modelling language for simulation are introduced. Second, collaboration space, value chain and business process models and their conceptual dependencies are shown, using the ExSpect language. Third, an exhibit demonstrates the use of value chain models in predicting the financial performance of an enterprise. Keywords: Resource-Event-Agent ontology, supply chain, enterprise, accounting model, simulation.

1 Introduction This paper demonstrates how an enterprise ontology can be useful in building various kinds of business simulation models. Such simulation models predict the behaviour of newly designed business systems before they are implemented. In technological fields, simulation models are useful when the cost of error associated with R&D is high. For instance, when a new plane type is designed, its behaviour is simulated before the actual plane is constructed as building a plane is expensive and time consuming and operating a potentially flawed experimental plane might imply loss of lives. Also in business, simulation models are useful for predicting the effects of business changes and redesign actions. For instance, enterprises that suffer liquidity constraints in an environment where external funding is scarce (e.g. unsteady banks and capital markets) may also encounter high costs of error since redesigns that worsen liquidity constraints may immediately imply the end of an enterprise’s existence. The enterprise ontology we look at is the Resource-Event-Agent (REA) ontology [1-5], which originates in a semantic accounting data model that was designed for a shared data environment in which accountants and non-accountants maintain information about the same economic phenomena [6]. Apart from accounting systems design, the REA ontology is applied in accounting education, model-driven systems design, supply-chain collaboration and knowledge representation [7]. The accounting background of the REA ontology allows simulation model builders to inject an economic rationale into their simulation models, and in particular to integrate models showing financial flows with the more traditional models showing logistic R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 554–563, 2009. © Springer-Verlag Berlin Heidelberg 2009

A Simulation Model Articulation of the REA Ontology

555

flows and workflows [8]. So far, this integration of financial and logistic flows was only offered by the e3-value ontology [9] at a very high abstraction level. The explicit connection between logistic processes and financial processes increases the configurability and reusability of the simulation models. For instance, a business process simulation model for determining process capacity, cycle time and process time can easily be reconfigured for estimating the value of and cost of capital for the ‘work in progress’ that will appear as an asset on the balance sheet. Another advantage of REA ontology-based simulation models is that the combined effects of redesigning individual business processes and workflows can be simulated in enterprise or supply chain level models, which may help to identify synergies and interferences between the redesign actions taken on different processes or workflows. The idea of using the REA ontology for simulation purposes comes from Church and Smith [10], who consider it the best-of-class supply chain and business process ontology for constructing business simulation models. Church and Smith merely explore the idea of ontology-based simulation models by using REA for modelling continuous flows in an enterprise using System Dynamics1. The simulation of continuous flows solely supports high-level management applications (e.g. long-term capacity planning). We provide further evidence of the REA ontology’s simulation modelling power by means of REA ontology-based models for discrete event simulation. which supports various kinds of operational management applications (e.g. dayto-day planning). This type of simulation is based on the identification of individual cases for which a lifecycle can be developed based upon case characteristics and on the use of decision algorithms for specific process stages (e.g. if a loan is rated above average it will be approved and granted). For the articulation of the discrete event simulation models, the ExSpect2 simulation tool will be used. Section 2 presents the constructs of the REA ontology and the simulation language of the ExSpect tool. Section 3 shows how discrete event business simulation models for enterprises that engage in supply chains, including models for business processes, value chains and collaboration spaces, are constructed using the REA ontology. Section 4 then compares four alternative value chain designs, on their financial performance (e.g. turnover, total liabilities). Section 5 ends the paper with conclusions and ideas for further research.

2 Overview of the REA Ontology and the ExSpect Simulation Language 2.1 The ExSpect Simulation Language The ExSpect simulation language is a visual modelling language that is based on highlevel (i.e. hierarchical, timed and coloured) Petri-nets. Petri-nets model processes by means of tokens, places and transitions. The distribution of the tokens over the places in a Petri-net represents the state of the process. The transitions specify a strict precedence relation between the places a token can occupy during the execution of a process. Hence, transitions model events that change the state of the process. Coloured 1 2

http://www.systemdynamics.org/ http://www.exspect.com/

556

W. Laurier and G. Poels

Petri-nets allow tokens to have attributes describing them, which means that the state of a process is also determined by the values that the attributes of the tokens take. Hierarchical Petri-nets allow decomposition structures such that a Petri-net can be refined by other Petri-nets [11]. In classic Petri-nets, all transitions represent atomic events, while in hierarchical Petri-nets transitions can represent complex events (i.e. events composed of other events). Finally, timed Petri-nets allow transitions to have a duration, which makes them useful for representing non-instantaneous events. In coloured Petri-nets, the attributes of a token can be used to give a stable identity to the individual that is represented by the token. In workflow modelling, such an individual with a stable identity is called a case [8] (e.g. a document that needs to be processed). When these identity bearing tokens reside in a place, they represent a lifecycle phase of such a case. Consequently, transitions define strict precedence relations between the lifecycle phases of a case or model a precedence relation between different cases. 2.2 The REA Ontology A remarkable conceptual dichotomy in REA is the difference between economic phenomena and business phenomena. The former create or represent economic value (e.g. the acceptance of a sales order), while the latter are considered worth monitoring and controlling although they do not directly create or represent economic value (e.g. the registration of an accepted sales order). For the injection of economic rationale into business simulation models, this distinction between value bearing phenomena (i.e. economic) and value supporting phenomena (i.e. business) is primordial as it discriminates the economic rationale driven business logic from the operational implementation of the business logic. The economy/business dichotomy in the REA ontology relates closely to Porter’s [12] discrimination of primary activities, which construct a scarce and valuable product, and support activities, which allow primary activities to take place. Primary activities directly contribute to the creation of economic value and are represented in the REA ontology as Economic Events. Support activities facilitate and enable this value creation and are represented in the REA ontology as Business Events. Resources in the REA ontology are defined as goods, services or rights that have utility and are under the control of a legal or natural person. Economic resources can be distinguished from business resources because the former are inevitably scarce, which motivates their economic value [3, 6]. Business resources support business activities without being scarce (e.g. information can be replicated/duplicated at very low cost). Events are occurrences in time that relate subsequent process states to each other. Economic events are discriminated from business events as the former involve gaining (i.e. increment) or losing (i.e. decrement) control over economic resources, in contrast to the latter [3, 6]. Agents are natural persons that act on behalf of economic units (e.g. enterprises). Economic agents are accountable for, participate in or initiate economic events, whereas business agents are accountable for, participate in or initiate business events. Units determine the scope of the context in which economic activities take place. Economic units represent financially self-sustaining entities, while business units characterize non-self-supporting structures that are usually embedded in economic units. Table 1 lists some examples for each basic REA construct presented here.

A Simulation Model Articulation of the REA Ontology

557

Table 1. Examples of basic REA Concepts

Resource Event

Agent Unit

Economic e.g. goods, infrastructure, services, machines, rights e.g. payment, purchase, consumption, production, sale e.g. cashier, production line operator, salesperson e.g. enterprise, organisation

Business e.g. documents, manuals, schedules, signals e.g. scheduling a production run, sending an invoice e.g. accounting clerk, production planner e.g. department, team

3 Economic Rationale Models In this section, it is shown how the economic rationale that is expressed in the REA ontology, can be represented in collaboration space, value chain and business process simulation models. Collaboration space models encompass the supply chain view on economic phenomena and focus on (physical) resource flows between economic units. Such models are especially useful for representing and simulating logistic, service and money flows between supply chain partners. Value chain [4, 5] models represent supply chain partners as extended open systems [13] that sustain their continuity by enforcing economic reciprocity. This kind of simulation model can be used for assessing the financial characteristics (e.g. assets, liabilities, turnover) of individual supply chain partners. Business process models show the actual underlying processes. These models allow analysing operational process characteristics (e.g. bottlenecks, cycle time, capacity). The collaboration space model in fig. 1 shows the interactions between three supply chain partners, which we refer to as the enterprise (i.e. the supply chain partner that is the focal point of the simulation model), the supplier of the enterprise and the customer of the enterprise. This collaboration space model shows both business (i.e. offer, order and invoice) and economic (i.e. product and money) resources that are transferred between these partners. The underlying business processes, which can be modelled by decomposing the Petri-net, specify how an offer is generated and transformed into an order; how this order triggers a product transfer and the creation of an invoice and how this invoice triggers a money transfer. Since the economic units (i.e. Supplier, Enterprise, Customer) in the model are modelled as complex transitions (i.e. yellow boxes) that cover more complex underlying processes, each of the resource transfers (e.g. ProductSupp) in the collaboration space is allowed to occur individually, unless the underlying business process specifies otherwise.

Fig. 1. Collaboration space model for an enterprise with one supplier and one customer

558

W. Laurier and G. Poels

Next to business processes, also value chains, which introduce the economic rationale for participating in a supply chain, determine the behaviour of economic units (e.g. illiquidity may force an economic unit to halt its business processes). Fig. 2 shows a value chain model for the enterprise that was the focal point in the collaboration space model of fig. 1. This value chain model presents a generic and extensible template for enterprises participating in supply chains. This value chain model consists of four cycles [4, 5]. The acquisition cycle, which is shown at the left-hand side of fig. 2, models the interface with suppliers via a complex transition (called Acquisition_Cycle), representing a duality between the Product_Inflow transition and the Money_Outflow transition. This duality reflects an axiom of the REA ontology that states that “All events effecting an outflow must be eventually paired in duality relationships with events effecting an inflow and vice-versa”[2]. This means that economic rationale requires adequate compensation for the economic resources that leave an economic unit (i.e. the supplier’s products must be paid for by the enterprise) and dictates the existence of requiting economic events for economic events that create claims and liabilities. Analogously, the revenue cycle, which is represented as the complex transition Revenue_Cycle at the right-hand side of fig. 2, shows the balance between the value of goods sold and the revenues that remunerate them. Similarly, the conversion cycle, which is represented as the complex transition Conversion_Cycle at the upper side of fig. 2, models the business unit in which the value creating transformation processes take place. Finally, the financing cycle, which is represented as the complex transition Finance_Cycle at lower side of fig. 2, models the business unit in which the process of approving payments and controlling budgets takes place. The template in fig. 2 can be extended by adding more acquisition, conversion, revenue financing cycles and transfers (e.g. the payroll cycle [5] that exchanges labour and money (i.e. wages) between the enterprise and its employees). Next to the value chain (i.e. an aggregate of acquisition, conversion, revenue and financing cycles), which shows that the balance between incoming and outgoing money and product flows is essential for the sustainability of an economic unit’s economic activities, the value chain model in fig. 2 is equipped with transfer events that represent the parts of an exchange process that an economic unit is accountable for. Fig. 2 assumes that the enterprise is accountable for both transfers that relate to its revenue cycle (i.e. product outflow and money inflow). The complete transfer economic event is modelled by connecting the decrement side of a transfer event under control of one economic unit (e.g. the TransferProduct transition between the OutflowProductO place and the ProductCust place on the right-hand side of fig. 2) to its increment side, which is under the control of a subsequent economic unit (and which would be shown, e.g. as the TransferProduct transition between the ProductSupp place and the InputProduct place, in the value chain model of that economic unit). Together, both transfer events form an economic event template [14], which starts with an economic resource decrement (i.e. outflow) and ends with an economic resource increment (i.e. inflow), that allows integrating the value chain models of different supply chain partner into one simulation model that can subsequently be shown in a reduced form (i.e. going one level up in the Petri-net decomposition hierarchy) as a collaboration space model.

A Simulation Model Articulation of the REA Ontology

559

Fig. 2. Value chain model for the enterprise in the collaboration space model of Fig. 1

Fig. 3 depicts a simple business process which is part of the ‘Conversion Cycle’ business unit in fig. 2. It models a transformation economic event, which starts with an economic resource decrement and ends with an economic resource increment, that is triggered by an order (i.e. a business resource) and gives rise to the creation of an invoice (i.e. another business resource). The business events that are part of the economic event can be represented by further decomposing the TransformationProduct transition. Similarly, the business events that are part of the ‘TransferProduct’ and ‘TransferMoney’ economic events in fig. 2 can be represented in business process models that underlie these transfer economic events.

Fig. 3. Business process model for the conversion cycle of the enterprise in the value chain model of Fig. 2

4 Exhibit: Alternative Value Chain Designs This section applies the templates presented in the preceding section, to evaluate four alternative theoretical business designs, on their financial performance (e.g. turnover,

560

W. Laurier and G. Poels

debt, value of work in progress). The initial value chain model (i.e. Design 0) ), which is modelled after fig. 7 and contained in a collaborations space model as shown in fig. 6, has an acquisition cycle in which the supplier finances its sales to the enterprise for a 30 day period (i.e. term of payment), a conversion cycle that takes 50 days, a revenue cycle that offers a 30 day payment term to the customer, a product transfer that takes 3 days, a money transfer that takes 2 days and a financing cycle that takes 5 days. The first redesign (i.e. Design 1) , which was implemented by duplicating ‘Design 0’ and changing the transformation business process model (see fig. 8) that underlies its conversion cycle, halves the duration of the conversion cycle (i.e. 50 to 25 days). The second redesign (i.e. Design 2) reduces the term of payment that is offered to the customer with 25 days (i.e. 30 to 5 days) and the third redesign shows the effect of a supplier that reduces the term of payment (i.e. 30 to 5 days) for the enterprise. The latter two redesigns are implemented by changing the characteristics of the invoicing process that is partially modelled as a decomposition of the conversion cycle of the creditor and the financing cycle of the debtor. To abstract from influences other than value chain design, all underlying business processes have a standard deviation of 0 days for their duration (i.e. service time). The elimination of business process service time volatility prevents the redesign effect from being masked by the aggregate volatility of all service times in the value chain. The simulation models for the alternative designs also abstract from price volatility, debt default and profit margins. Eliminating price volatility prevents the financial values (e.g. liabilities, turnover) in the models from being distorted by price fluctuations. Debt default would increase the need for external funding, as default implies that customers do not provide the required financial means to compensate the assets that were transferred to them. Finally, profit margins reduce the need for external funding as they imply that the customers provide more financial means to the enterprise then required for replacing the assets that were transferred to these customers. As a result of these abstractions, the remaining variables in the simulation models are the value chain design and the inter-arrival time between the product deliveries in the supply driven value chain (i.e. assuming product supply is the trigger for all other economic events in the value chain model). Table 2 shows simulation results that originate in a set of 10 simulation runs with 300+ cases each created by a token generator that varies the inter-arrival time randomly and assigns a value of 1, representing €€ 1 000 000, to each individual token. The original design (i.e. Design 0) has a value chain cycle time3 of 90 days (i.e. 50+3+30+2+5). The liabilities equal the value of all assets in the value chain (i.e. work in progress, accounts receivable and cash) for which no requiting money outflow has occurred. The need for external funding (i.e. NEF) then represents the liabilities that is not financed by supply chain partners (mostly the supplier, through terms of payment) and for which other funding (e.g. equity, bank loans) needs to be found. Turnover then aggregates the value of all tokens that flow through the value chain during one simulated year (i.e. 360 days). The receivables aggregate the value of all tokens that are occupied by the revenue cycle (during 30 days), work in progress (i.e. WIP) aggregates the value of all tokens that are occupied by the conversion cycle 3

The time between the acquisition of a raw material and the moment the money that is generated by these raw materials, after conversion and sale, is available for a subsequent acquisition of raw materials.

A Simulation Model Articulation of the REA Ontology

561

Table 2. Simulation Results for alternative value chain designs (*: in days; **: in €€1 000 000) Design 0 Cycle Time* Liabilities** NEF** Turnover** Receivables** WIP** Cash**

Avg. 90 22,4 15,1 89,5 9,0 12,7 1,7

Design 1 Std. 0 4,5 3,7 / 2,9 3,5 1,2

Avg. 65 16,4 9,0 89,9 9,0 6,6 1,7

Design 2 Std. 0 3,8 2,8 / 2,8 2,4 1,2

Avg. 65 16,9 9,4 92,7 3,0 13,1 1,8

Design 3 Std. 0 3,9 2,9 / 1,6 3,5 1,2

Avg. 90 22,4 21,2 89,5 9,0 12,7 1,7

Std. 0 4,5 4,4 / 2,9 3,5 1,2

(during 50 days) and cash aggregates the value of all tokens in the financing cycle (during 5 days). The first redesign results in a reduction of the value chain cycle time by 25 days. Since the underlying business processes have no variance, the cycle time’s standard deviation is 0. This conversion cycle service time reduction decreases the average value of the liabilities by the same percentage as the value chain cycle time is reduced (i.e. 28%), while the average need for external funding is reduced by 40%. Both these reductions originate in a 50% reduction of the work in progress (i.e. WIP), which represents the value of the assets that are involved in conversion processes. This reduction is the result of a reduced conversion cycle service time and a stable product supply and flow. The second redesign also reduces the value chain cycle time by 25 days and the average liabilities with 28% and the need for external funding with 40% due to a 67% decrease in the value of the accounts receivable, which originates in a shorter term of payment and a stable revenue flow. Finally, redesign 3 shows the effect of a reduced term of payment on an enterprise’s need for external funding, as the need for external funding increases with 40% while the total value of the enterprise’s liabilities remains unchanged. This exhibit motivates business process redesign efforts[15] as it shows that shorter service times in the conversion cycle reduce an enterprise’s liabilities and need for external funding, without burdening its customers with an extra need for external funding which may result in a higher cost of capital or increased illiquidity and insolvency risk. This change in the need for external funding for both the seller and the buyer reveals an interference between the seller’s revenue cycle and the buyer’s acquisition cycle through the shared variable ‘term of payment’. Also aggregate effects of business model changes could be simulated if multiple redesigns are incorporated in a single simulation model run. Through the shared variable ‘term of payment’, also the propagation of liquidity constrains throughout entire collaboration spaces could be simulated (e.g. liquidity constraints for a customer may evoke delayed payments to its supplier, which increases this supplier’s need for external funding, which may lead to delayed payments of this supplier to its own suppliers etc., see e.g. [14]) In a day-to-day planning approach, value chain models as presented here could be used to predict the prolonged term of payment for each individual invoice in the waiting line, based upon a priority algorithm (e.g. first-in-first out, largest debt) and a prediction of the expected incoming money flows, based on the due date of individual claims on customers or predicted sales and terms of payment offered to customers.

562

W. Laurier and G. Poels

5 Conclusions and Future Research This paper showed that the REA enterprise ontology can be used to guide the construction of business simulation models, including models for simulating collaboration spaces between supply chain partners, value chains and business processes. The main advantage of using the REA ontology to construct business simulation models is that the economic rationale expressed by this ontology facilitates the integration of financial flows in simulation models that are traditionally focused on logistics flows of goods and services, information flows and workflows. The resulting models can support assessing the financial consequences of specific business process and supply chain configurations. For example, the effect of a customer that delays its payments or a supplier that shortens or lengthens its term of payment on an enterprise’s cash position can be assessed. The simulation language used for REA ontology-based business simulation models is the one of the ExSpect tool and is based on the high-level Petri-net formalism. The use of hierarchical Petri-nets allows constructing decomposition hierarchies of discrete event simulation models, such that simulation models at different levels of aggregation (i.e. business process, value chain, collaboration space) can easily be integrated. The use of coloured Petri-nets was key to injecting economic rationale into simulation models built using the REA ontology and the ExSpect tool, as these coloured Petri-nets allow the attribution of economic value to tokens representing economic resources. Finally, timed Petri-nets allow for the representation of actual business process characteristics (e.g. service time). Since the simulation exhibit presented in this paper abstracts from many natural business variables (e.g. service time variability) and economic variables (e.g. price fluctuations), we intend to elaborate more realistic business cases that demonstrate the use of discrete event simulation models in conceiving and evaluating (alternative) business designs.

References 1. Geerts, G.L., McCarthy, W.E.: An ontological analysis of the economic primitives of the extended-REA enterprise information architecture. International Journal of Accounting Information Systems 3, 1–16 (2002) 2. Geerts, G.L., McCarthy, W.E.: The Ontological Foundation of REA Enterprise Information Systems. Michigan State University (2004) 3. ISO/IEC: Information technology - Business Operational View Part 4: Business transaction scenario - Accounting and economic ontology. ISO/IEC FDIS 15944-4: 2007(E) (2007) 4. McCarthy, W.E.: The REA Modeling Approach to Teaching Accounting Information Systems. Issues in Accounting Education 18, 427–441 (2003) 5. Dunn, C.L., Cherrington, J.O., Hollander, A.S.: Enterprise information systems: a patternbased approach. McGraw-Hill/Irwin, Boston (2005) 6. McCarthy, W.E.: The REA Accounting Model: A Generalized Framework for Accounting Systems in a Shared Data Environment. Accounting Review 57, 554–578 (1982) 7. Gailly, F., Laurier, W., Poels, G.: Positioning and Formalizing the REA enterprise ontology. Journal of Information Systems 22, 219–248 (2008)

A Simulation Model Articulation of the REA Ontology

563

8. van der Aalst, W.M.P., Hee, K.M.v.: Workflow management: models, methods and systems. MIT Press, Cambridge (2002) 9. Gordijn, J.: Value-based requirements Engineering: Exploring innovative e-commerce ideas. Exact Sciences, Phd. Free University of Amsterdam, Amsterdam, p. 292 (2002) 10. Church, K., Smith, R.: REA Ontology-Based Simulation Models for Enterprise Strategic Planning. Journal of Information Systems 22, 301–329 (2008) 11. Zuberek, W.M., Bluemke, I.: Hierarchies Of Place/transition Refinements In Petri Nets. In: 5th IEEE International Conference on Emerging Technologies and Factory Automation, pp. 355–360. IEEE, Kauai (1997) 12. Porter, M.E., Millar, V.E.: How information gives you competitive advantage. Harvard Business Review 63, 149–160 (1985) 13. Gilman, G.: The manager and the systems concept. Business Horizons 12, 19–28 (1969) 14. Laurier, W., Poels, G.: Simulating Liquidity in Value and Supply Chains. In: Albani, A., Barjis, J., Dietz, J.L.G. (eds.) CIAO!/EOMAS 2009. LNBIP, vol. 34, pp. 40–54. Springer, Heidelberg (2009) 15. Reijers, H.A., Liman Mansar, S.: Best practices in business process redesign: an overview and qualitative evaluation of successful redesign heuristics. Omega 33, 283–306 (2005)

An Ontology for Modeling Complex Inter-relational Organizations Yves Wautelet, Nicolas Neysen, and Manuel Kolp Louvain School of Management, Universite catholique de Louvain, Belgium 1, Place des Doyens, 1348 Louvain-la-Neuve {yves.wautelet,nicolas.neysen,manuel.kolp}@uclouvain.be http://www.uclouvain.be/lsm.html

Abstract. This paper presents an ontology for organizational modeling through multiple complementary aspects. The primary goal of the ontology is to dispose of an adequate set of related concepts for studying complex organizations involved in a lot of relationships at the same time. In this paper, we define complex organizations as networked organizations involved in a market eco-system that are playing several roles simultaneously. In such a context, traditional approaches focus on the macro analytic level of transactions; this is supplemented here with a micro analytic study of the actors’ rationale. At first, the paper overviews enterprise ontologies literature to position our proposal and exposes its contributions and limitations. The ontology is then brought to an advanced level of formalization: a meta-model in the form of a UML class diagram allows to overview the ontology concepts and their relationships which are formally defined. Finally, the paper presents the case study on which the ontology has been validated.

1

Introduction

Organizational modeling has been the subject of tremendous works during the last 15 years. Among these, the models developed in the context of i* (i-star) [1,2] have driven lots of research notably through the ”Tropos” project [3]. Such models are however principally targeted for information systems development. The use of organizational modeling could however be much larger. Managers or business strategists can, on the basis of adequate models, study several aspects of organizations, like the transactions and relationships that take place between these organizations. This would help to answer essential questions as: ”What are the different aspects of our business? What are we responsible for? Who are we dependent of ? What are the goals we pursue? How can we achieve them? What should be watched out? Etc. The aim of this paper is not to define a specific model but rather to develop a genuine ontology for studying complex organizations. We define complex organizations as networked organizations involved in a market eco-system that are playing several roles simultaneously. By generalization, market or enterprise R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 564–573, 2009. c Springer-Verlag Berlin Heidelberg 2009 

An Ontology for Modeling Complex Inter-relational Organizations

565

ontologies model economic actors and their interactions. To achieve such an objective multiple dimensions have been considered (an intentional, operational and environmental) so that the different views and abstraction levels necessary for understanding all the business aspects are covered. With a focus on that purpose, a series of concepts (and their relationships) are defined and formalized. The ontology can be instantiated for studying market relationships as well as to dispose of a knowledge base for strategic and tactic decision taking. This paper firstly overviews related work and points to the contributions and limitations of the developed ontology. The latter is then exposed. An UML class diagram exposes and defines formally the concepts of the ontology, including their mutual linkages. Next, the paper overviews the possible instantiation of the framework concepts to the particular an online market intermediary, eBay.

2

Problem Statement

This section overviews related work which discusses existing models and ontologies and identifies a gap in literature about modeling complex organizations. It also envisages the variables yet uncovered (e.g. environmental ones). The contributions and limitations of the ontology proposal are then exposed. 2.1

Related Work

The crux of our argument is that lots of firms may play several roles at the same time because they are involved in complex market relationships. Most of current modeling frameworks do not allow an integrated view of these specific market relationships. We argue that an integrated view of market relationships within complex (or multi-role) organizations should take into account several analytical dimensions. In this paper, we propose three of them: intentional, operational and environmental. These dimensions are more specifically outlined in Section 3. Moreover, we think that a reliable framework modeling complex organizations should be rather dynamic (considering interactions and dependencies between several actors) than static. This argument is shared by Ku, Wensley and Kao in [4] who provide a framework for analyzing the knowledge management processing of joint ventures in a particular industry. From our point of view, joint ventures are a relevant example of complex market relationships where organizations interact to achieve a common goal. As emphasized by authors: ”when enterprises engage in strategic joint venture projects, communication, knowledge sharing and management issues are inevitable and complex problems” [4]. Nevertheless, since only the cooperative role is tackled, the lack of multi-role analysis seems to be a limit of the study. In [5], an agent-oriented meta-model for enterprise modeling is depicted. The model is described using a class diagram but its instantiation focuses on organizations taken individually rather than on the relation between multiple organizations. Moreover, the framework only proposes descriptions of the concepts without presenting a large example of instance to demonstrate the increase in value of each of the concepts. As an answer to

566

Y. Wautelet, N. Neysen, and M. Kolp

the prior limitations, [6] propose a meta-model for enterprise modeling. In this meta-model, the framework is applied in a multi-plant context (each plant is a different organization). Before modeling organizational relationships, it is necessary to establish an axiomatic set of definitions and inter-related concepts. Indeed, across the literature it is possible to find different definitions or representations for equivalent concepts. For example, the notion of role should be clear-cut before developing an analytical model. In [7], a role is defined as ”a combination of several tasks in an enterprise that are likely to change drastically”. In the current paper however, a combination of several tasks constitutes a goal rather than a role (See Section 3). In object-oriented development methodologies as the Unified Process [8] giving a framework to the Unified Modeling Language, a role is defined as ”the behavior and responsibilities of an individual, or a set of individuals working together as a team, within the context of a software engineering organization” [9], which is oriented for the software engineering field. Even if the knowledge contained in a particular ontology can be used in different applications, for different purposes and by different people [10], we nevertheless want a framework less focused on software application development and relying more on the description and analysis of a multi-organizational environment as stated in the introduction. As reminded by [11], one of the problems of using different representations and terminologies to model the same ”thing”, is the absence of any formal mapping between high-level ontologies. In response to this limitation, conceptual modeling can offer useful and solid tools for actor relationship study. For example, [12] suggest a method of ontology construction where different ontologies are merged within the same subject into a single ontology that unifies all of them. 2.2

Contributions and Limitations

The main contribution of the paper is the market ontology itself as described and formalized in the next section. It covers several aspects of primary importance for the study of organizational modeling in the context of market relationships. Also, the ontology exposes the concepts and their relationships through a meta-model and brings concepts to an advanced level of definition and formalization. So far, the proof of concept remains in the application of the theoretical framework on the eBay case study. The model does, however, not provide metrics to evaluate for example the involvement of an actor into a particular role, the relative importance of a goal (low, medium, critical), the required effort to achieve a task, etc. Exceptions however exists since we evoke in the formal definitions of next section the notions of quality of service (QoS), probability of happening and improvement rate. Metrics definition and evaluation are left for future work.

3

The Ontology

The aim of this section is to expose our market ontology. We propose a class diagram which provides modeling elements relevant for specifying both strategic and

An Ontology for Modeling Complex Inter-relational Organizations Actor

+is played by

0..n

+plays

0..n

type : String

depender

+is owned by

1..n

Role

+induces Responsibility

Actor Role +is induced by 1

567

1..n

1..n

1..n

1

pursues

dependee 0..n 0..n

1..n

dependum

Dependency 0..1

Goal 1

+acts

+is influenced by

Environmental Factor

1..n

1..n

0..1

Operational Goal

Softgoal

dependum +owns

Threat attendance_probability

Opportunity improvement_rate

1..n

1 Asset tangible : Boolean

Ressource strategic : Boolean

+alters

+requires

+is required by

1..n

+is altered by

Task

1..n

Capability dynamic : Boolean

0..n

0..n

Fig. 1. The Market Ontology Class Diagram

operational aspects of the organizational context in which the actors relationship takes place. This class diagram is made of concepts (e.g., “Actor”, “Roles”, “Goals”, etc.), relationships relating concepts (e.g., “Plays”, “Owns”, “Realizes”, etc.), attributes of concepts or relationships (e.g., “Probability of happening”, “Improvement rate”, etc.), and constraints on concepts and relationships (e.g., “An actor achieves a goal if and only if that actor possesses all the ressources required to achieve it”). 3.1

Ontology’s Entities and Relationships

The ontology we develop in this paper is aimed to study complex market relationships between economic actors as for example in the case of market intermediation. Studying such an issue nevertheless requires different complementary aspects, they are categorized here as intentional, operational and environmental dimensions. This section overviews the different ontology’s concepts in the context of the dimensions they belong to. Figure 1 depicts a class diagram representing the concepts of a market ontology (in the form of entities i.e. classes) as well as their relationships (associations and generalizations); the aim of this section is to link each of the concepts and to bring them to further definition. Intentional Dimension. The intentional dimension identifies and formalizes the actors involved in the market relationship, assigns them roles under which the

568

Y. Wautelet, N. Neysen, and M. Kolp

have responsibilities and pursue goals independently of the way to implement them. This dimension answers the question: ”Who is involved and what is he looking for?”. Actors are intentional entities used to model organizations as private or public companies, governmental departments, etc. that are processor for some actions. The Actor owns a Type which documents his basic function on the market (for example intermediary, seller, buyer, etc.). They occupy Roles which are abstract characterizations of expected behaviour of an Actor within some specified context of the market. A defined Actor playing a defined Role is characterized as an Actor Role. The Actor Role has a Responsibility onto the market; indeed by playing a defined Role, the market expects the Actor Role to conform to particular guidelines. The later must be followed due to the professional nature of the Actor Role. An Actor Role pursues some Goals guiding his actions. Goals are sometimes involved in a Dependency relationship i.e. an Actor Role is dependent of an other Actor Role for the realization of the Goal. Goals are divided into two subcategories, Operational Goals (sometimes called hard goals, see [1]) which are functional goals the Actor has to fulfil in the context of a particular Role. Softgoals represent non-functional requirements i.e. global qualities of a software system such as security, flexibility, maintainability, usability, etc. They can hardly be the result of an operational decomposition but are more of the result of an adequately followed analysis and design. Operational Dimension. The operational dimension realizes the operational goals identified by the intentional dimension in terms of tasks. Fulfilling tasks requires resources that can be human, devices, patents, etc. This dimension answers the question: ”How is each goal realized?”. The Operational Goals can be achieved by the execution and satisfying realization of a series of Tasks (possibly in a particular sequence). Tasks execution and successful realization entails a series of tangible and intangible Assets that can be of different nature [13]. Indeed, Assets are divided into Resources and Capabilities. We consider here Resources as all the human and material Assets (employees, machines, software, money, furniture, etc.) that are required to fulfill the Tasks. The Capabilities can be viewed as more intangible Assets, like management skills, organizational processes, knowledge base, etc. that are controlled by the actor and contribute to the realization of the Tasks. Resources and Capabilities are closely interlinked. For instance, [14] argue that actors will exploit their dynamic Capabilities to alter their resource base and maintain their competitive advantage. Environmental Dimension. The environmental dimension represents the factors that are external to the organization but has a variable (positive or negative) influence on the goal realization. This dimension answers the question: ”What must be watched out?”. An Environmental Factor can be an external Threat for the adequate goal’s fulfilment (in terms of adequate achievement) or an opportunity that can potentially contribute to the goal’s achievement (in terms of time, quality of achievement, etc.). A goal achievement is indeed subject to multiple realization ways (alternative Tasks can be used) and paths (another sequence or some tasks can be avoided when some guard conditions are met). Moreover a

An Ontology for Modeling Complex Inter-relational Organizations

569

Probability of happening is associated to each Threat as well as an Improvement rate to each Opportunity. Those features will be useful for the Threats and Opportunities prioritization into strategic planning. The operational solutions and other strategies that the Actor (or Actor Role) can put into practice to deal with the threats or to operationalize an opportunity are not represented here as entities since they are outside the scope of this paper. Further developments onto the ontology could however incorporate them. 3.2

Ontology Formalization

In this section, we will bring the market ontology to further formalization. a a Definition 1. A tuple {(roli , qrol ), . . . , (roli+m , qrol )}, Acta  is called an i i+m actor a, where roli is a role. The actor plays a series of roles to pursue goals at a quality level and cost qrol . Played roles are a vector of quality level and cost with i a values. Act is assumed to contain all additional properties of the actor necessary for its definition, the only relevant for the present discussion is its type (for example intermediary).

Format and content of Acta will depend on the structure of the market on which the framework is applied. For simplicity reasons an actor role is defined here over a single role. However, in practice, an actor mostly plays serveral roles. a a Definition 2. a, roli , qrol  associating a role roli to a quality level qrol achieved i i AR by the actor a is an actor role ai . The actor must be capable of playing the role: a a ∀aAR = a, roli , qrol , (roli , qrol ) ∈ a. i i i

Any actor a that can play m > 1 roles can also be seen as a set of actor roles: AR {aAR i , . . . , ai+m }. It is necessary to have a more precise idea of how tasks and goals are conceptualized. Definition 3. A task tki is tkipre , τi , {(asseti ), . . . , (asseti+m )}, tkipost , where tkipre describes the task precondition, τi is a specification (in some natural or formal language) of how the task must be executed, asseti is a asset (ressource or capability) required to achieve the task and tkipost describes the conditions that must be met when the task can be stated executed. Tasks belong to the set TK. Definition 4. gjι , gjN , gjE , goalState j , goalTransit j  is a goal gj , where gjι provides the details of the functional decopmosition of the goal, (gjN , gjE ) defines a workflow. Nodes represent tasks, and edges transitions between tasks. The two functions label nodes and edges with tasks information: goalState j : gjN −→ TK is a partial function returning the task for a given node in the workflow, while goalTransit j : gjE −→ {tkipre }tki ∈TK ∪ {tkipost }tki ∈TK maps each edge to a condition from the set of all task preconditions (i.e., {tkipre }tki ∈TK ) and postconditions (i.e., {tkipost }tki ∈TK ). The task specified on a node must have the precondition and postcondition corresponding to conditions given, respectively, on its incoming and its outgoing edges.

570

Y. Wautelet, N. Neysen, and M. Kolp

A goal can therefore be understood as a process, composed of a set of tasks ordered over the workflow representing the goal. The functional specification of the goal, i.e., gjι is not of interest here. Achieving a goal requires the specification of expected QoS, in addition to the maximal involvment of ressources, and explicit market responsibilities i.e. the Actor Role has a series of responsibilities to respect. Definition 5. A goal achievement gˆj is gj , gjQoS , gjressources , gjrespo , where: – gj is the goal to achieve. – gjQoS specifies expected qualities and their required level. Its definition follows a QoS ontology. Whatever the specific QoS ontology, expected qualities are likely to be specified as (at least) gjQoS = (p1 , d1 , v1 , u1 ), . . . , (pr , dr , vr , ur ), where: • pk is the name of the QoS parameter (e.g., connection delay, standards compliance, and so on). • dk gives the type of the parameter (e.g., nominal, ordinal, interval, ratio). • vk is the set of desired values of the parameter, or the constraint on the value of the parameter. • uk is the unit of the property value. – gjressources is the maximal level of ressources the actor role pursuing the goal is ready to involve for its fulfillment. – gjrespo is a set of responsibilities that constrain the actions the actor role may take when executing the tasks to achieve the goal. By conceptualizing the goal as suggested in Def.4, the goal is thus mapped onto a workflow W F where each node is a task i.e. a step in goal achievement and an edge in W F corresponds to the execution of a task tkk . Each path from the starting node to the destination node corresponds to a sequence of tasks ensuring the achievement of the goal within the prescribed QoS. The model thus assumes that there are alternative ways for achieving the goal. The workflow is a graphical model of the different ways the goal can be achieved as a sequence of tasks.

4

Ontology Application to Market Intermediation

Besides traditional firms with productive activities, market intermediaries that centralize transactions without transforming goods represent a large portion of the economy. Market intermediaries appear on the market when they increase the net gains from the transactions relative to decentralized trade in which partners negotiate the terms of exchange directly [15]. In economic literature, a market intermediary is defined as an economic agent that helps supply and demand meet, whether by purchasing from suppliers and reselling to buyers or by helping both to

An Ontology for Modeling Complex Inter-relational Organizations

571

meet each other [16,15]. This definition supposes that two kinds of intermediaries exist: the merchant and the matchmaker [17]. Beyond this view restricted to buyers and sellers, one can extend the above definition to all pairs of potential partners sharing a common goal. For example, employment and matrimonial agencies can also be considered as intermediaries on their respective markets [18,19]. Specifically, theory on two-sided matching explores the role played by intermediaries in a centralized matching procedure. During the last 20 years, changes in intermediation processes came up with the Internet and the related information and communication technologies (ICTs). Most of the studies about online market intermediation have emphasized the impacts of ICTs in terms of search facilitation [20], transaction costs reduction [21] and transparency improvement [22]. Among others, [23] established potential impacts of ICTs on the different roles of market intermediaries. Indeed, market intermediaries notably differ from other firms as they may play different roles in order to create value and improve the efficiency of an exchange process. Anticipating the further developments and orientations of online market intermediation involves a good knowledge of what the roles of those organizations are. In the literature, even if one can note a ”lexical richness”1 in writing about the roles of online intermediaries [24,23,25], the scientific community attributes always more than a single role to the market intermediary. As a whole, the concerned scholars seem to agree on four major roles for online market intermediaries: (1) a transactional role consisting in aggregating supply and demand; (2) an informational role consisting in collecting, organizing and evaluating dispersed information; (3) a logistical role consisting in providing the required infrastructure; and finally (4) an assurance role consisting in providing trust and security to the transaction process. This multi-role feature of online market intermediaries makes them a relevant frame for the study. To apply our ontology-based framework to online market intermediation, we have taken the eBay company as an example of a Web-based market intermediary between buyers and sellers. Clearly, the eBay company is not isolated from the rest of the world since a lot of stakeholders represent other actors that take place in eBay’s environment. These stakeholders include the buyers, the sellers, but also PayPal, postal service providers, and the community at large. As an actor, eBay (the ”firm” rather than the platform itself) owns the type of ”market intermediary” that specifies its function on the market. We also assume here that eBay plays the roles (at least one) that have been defined higher. At last, due to a lack of space we cannot go through all of the four roles; The interested reader can refer to [26] for an application to the assurance role (i.e. providing trust and security to the transaction process). Building trust is commonly referred in the literature as the key role of Web-based organizations [27]. A broader application of the ontology is available in [28].

1

A large variety of terms -like roles, functions, activities,- are employed in the literature to describe similar concepts answering the fundamental question ”what do intermediaries do?”.

572

5

Y. Wautelet, N. Neysen, and M. Kolp

Conclusion

This paper has taken steps towards extending the modeling capabilities and abstraction potentials of traditional enterprise ontologies by integrating concepts dealing with the complexities inherent to organizations in a comercial relationship with others. Even though this stream of thought already disposes of plenty of studies notably in organizational modeling through i* [1,2], those approaches mostly focus on information systems development rather than on decision taking support. In this paper, we explicitly consider different dimensions leading to multiple levels of aggregation. We provide the contours of an updated framework that helps integrate the specificities of complex and inter-dependant organizations. The aim is here to put forward a formalized tool enabling management science researchers and practitioners to model complex organizations and their related market relationships. To that aim we have instantiated the model to the study of online market intermediation. Our ontology also extends existing works by including consideration of the fact that organizations pursuing several goals simultaneously largely depend on their environment (i.e. external threats and opportunities always impact the way goals are achieved). That is why we add an environmental dimension to the classic dyadic representation of decisional (or, to use our terms, ”intentional”) and operational dimensions. True to the ontological spirit, we hope to stimulate further research by reorienting enterprise modeling into strategic paths. The goal should be to reach unification in theoretical concepts for giving the scientific community a basis to build upon. Finally, there is the important challenge of crafting empirical research to strengthen the proposed ontology and to make further progress in modeling complex organizations as well as multi-role driven market relationships.

References 1. Yu, E.: Modeling strategic relationships for process reengineering. PhD thesis, University of Toronto, Department of Computer Science, Canada (1995) 2. Yu, E.: Towards modeling and reasoning support for early-phase requirements engineering. In: RE 1997: Proceedings of the 3rd IEEE International Symposium on Requirements Engineering, p. 226 (1997) 3. Castro, J., Kolp, M., Mylopoulos, J.: Towards requirements-driven information systems engineering: the tropos project. Inf. Syst. 27(6), 365–389 (2002) 4. Ku, K.C., Wensley, A., Kao, H.P.: Ontology-based knowledge management for joint venture projects. Expert Systems with Applications 35, 187–197 (2008) 5. Jureta, I., Faulkner, S.: An agent-oriented meta-model for enterprise modelling, pp. 151–161 (2005) 6. Jureta, I., Kolp, M., Faulkner, S., Wautelet, Y.: A goal-oriented framework for business modeling. Working Paper IAG, 05/126 (2005) 7. Chen, T.Y.: Knowledge sharing in virtual enterprises via an ontology-based access control approach 59, 502–519 (1966) 8. IBM. The rational unified process. Rational Software Corporation, Version 2003.06.00.6 (2003)

An Ontology for Modeling Complex Inter-relational Organizations

573

9. Jacobson, I., Booch, G., Rumbaugh, J.: The unified software development process. Addison-Wesley, Reading (1999) 10. Maedche, A., Staab, S.: Ontology learning for the semantic web. IEEE Intelligent Systems 2(16), 72–79 (2001) 11. Malucelli, A., Palzer, D., Oliveira, E.: Ontology-based services to help solving the heterogeneity problem in e-commerce negotiations. Electronic Commerce Research and Applications 5, 29–43 (2006) 12. Blomqvist, E., Ohgren, A.: Constructing an enterprise ontology for an automotive supplier. Engineering Applications of Artificial Intelligence 21, 386–397 (2008) 13. Wright, M., Barney, J., Ketchen, D.J.: The resource-based view of the firm: Ten years after 1991. Journal of Management 27, 625–641 (2001) 14. Eisenhardt, K.M., Martin, J.A.: Dynamic capabilities: What are they? Strategic Management Journal 21(10), 1105–1121 (2000) 15. Spulber, D.F.: Market microstructure and intermediation. The Journal of Economic Perspectives 10(3), 135–152 (1996) 16. Hackett, S.C.: A comparative analysis of merchant and broker intermediation. Journal of Economic Behavior and Organization 18, 299–315 (1992) 17. Yavas, A.: Marketmakers versus matchmakers. Journal of Financial Intermediation 2, 33–58 (1992) 18. McNamara, J., Collins, E.: The job search problem as an employer-candidate game. Journal of Applied Probability (28), 815–827 (1990) 19. Burdett, K., Coles, M.: Marriage and class. Quarterly Journal of Economics 112, 141–168 (1966) 20. Gehrig, T.: Intermediation in search markets. Journal of Economics and Management Strategy 2, 97–120 (1993) 21. Bakos, Y.: Reducing buyer search costs: Implications for electronic marketplaces. Management Science 43(12) (1997) 22. Lucking-Reiley, D., Spulber, D.F.: Business-to-business electronic commerce. Journal of Economic Perspectives 15(1), 55–68 (2001) 23. Brousseau, E.: The governance of transactions by commercial intermediaries: An analysis of the re-engineering of intermediation by electronic commerce. International Journal of the Economics of Business 9(3), 353–374 (2002) 24. Giaglis, G.M., Klein, S., O’Keefe, R.M.: The role of intermediaries in electronic marketplaces: Developing a contingency model. Information Systems Journal 12, 231–246 (2002) 25. Barnes, D., Hinton, M.: Developing a framework to analyse the roles and relationships of online intermediaries. International Journal of Information Management 27, 63–74 (2007) 26. Wautelet, Y., Neysen, N., Kolp, M.: An ontology for modeling complex interrelational organizations: an application to online market intermediation. Working Paper 09/07, Universit´e catholique de Louvain, Louvain School of Management (LSM), Louvain-La-Neuve, Belgium (2009) 27. Ott, R.: Building trust online. PhD thesis (2), 10–12 (2000) 28. Neysen, N.: Online market intermediation: Integrating economic and management approaches. PhD thesis, Universite catholique de Louvain, Louvain School of Management (LSM), Louvain-La-Neuve, Belgium (2009)

Efficient Management of Biomedical Ontology Versions Toralf Kirsten1,2, Michael Hartung1, Anika Groß1, and Erhard Rahm1,3 2

1 Interdisciplinary Centre for Bioinformatics, University of Leipzig Institute for Medical Informatics, Statistics and Epidemiology, University of Leipzig 3 Department of Computer Science, University of Leipzig {gross,hartung,tkirsten}@izbi.uni-leipzig.de, [email protected]

Abstract. Ontologies have become very popular in life sciences and other domains. They mostly undergo continuous changes and new ontology versions are frequently released. However, current analysis studies do not consider the ontology changes reflected in different versions but typically limit themselves to a specific ontology version which may quickly become obsolete. To allow applications easy access to different ontology versions we propose a central and uniform management of the versions of different biomedical ontologies. The proposed database approach takes concept and structural changes of succeeding ontology versions into account thereby supporting different kinds of change analysis. Furthermore, it is very space-efficient by avoiding redundant storage of ontology components which remain unchanged in different versions. We evaluate the storage requirements and query performance of the proposed approach for the Gene Ontology. Keywords: Ontology versioning, integration, management.

1 Introduction Many ontologies have recently been developed and are frequently used in life sciences and other domains. In particular, ontologies are used to annotate resources by semantically describing their properties. For instance, molecular-biological objects are annotated with concepts of the well-known Gene Ontology (GO) [4] to describe their function or to specify the biological processes the objects are involved in. Moreover, personal properties of patients such as diseases can be described by concepts of medical ontologies, e.g., OMIM (http://www.ncbi.nlm.nih.gov/omim) or NCI Thesaurus [12]. Many analysis studies utilize such ontology-based annotations to better understand the real-world impact of certain observations. For instance, GO annotations are used for functional profiling [1] of large gene expression datasets to determine the semantic function of certain sets of heavily expressed genes. Most ontologies especially in life sciences are frequently changed to capture new insights or correct previous specifications [5, 14]. Such evolutionary changes typically include the addition, deletion and modification of concepts, relationships, and attribute values/descriptions. These changes are incorporated in newer ontology versions that R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 574–583, 2009. © Springer-Verlag Berlin Heidelberg 2009

Efficient Management of Biomedical Ontology Versions

575

are released periodically. Current analysis studies do not consider the ontology changes reflected in different versions but typically limit themselves to the most current ontology version which may, however, become obsolete to a larger degree within a short period of time. Providing an easy access to different versions of an ontologies is currently not supported but would be helpful for applications to check the stability of analysis results and decide about the need to re-run earlier analysis studies. There has been comparatively little previous research on efficient ontology versioning for large ontologies [3]. Klein and Fensel [8] proposed requirements for ontology versioning, in particular identification, change tracking and transparent evolution. As one task of ontology versioning some ontology management systems support the detection of differences between ontology versions (DIFF operation). The PROMPTDIFF approach [9] uses heuristics which automatically determine structural differences for OWL-based ontologies. OntoView [7] and OBO-Edit [2] include similar algorithms that produce information at the level of elementary changes, e.g., added and deleted ontology concepts. SemVersion [13] provides structural and semantic versioning of RDF-based ontologies with support for different triple stores. However, these systems do not explicitly utilize the information about changes for an efficient storage of ontology versions especially in case of large ontologies. Compared to previous work our method focuses on the efficient storage and management of many versions of large biomedical ontologies. We utilize the observation that most succeeding versions differ only to a smaller extent to achieve an efficient ontology storage with a minimum of redundancy between different versions. We make the following contributions in the paper: • We propose a scalable and space-efficient approach to integrate and manage many versions of different ontologies in a central repository providing applications a uniform ontology access. We have successfully applied our approach to large biomedical ontologies but it is generic and thus can also be applied for ontologies of other domains. • Our approach includes an ontology versioning model that is the basis for an efficient ontology management. It also allows the identification of changes for concepts, relationships and attributes across different ontology versions. Compared to seeing static ontology versions the versioning model provides a dynamic view in which ontology elements are managed (versioned) according to their life time. • We evaluate the storage efficiency and query performance of our approach on ontology version management utilizing various versions of the popular Gene Ontology. The presented approach is fully operational and has been used in diverse applications. Firstly, the Ontology Evolution Explorer (OnEX, online access under http://www.izbi. de/onex) [6] is built upon the versioning system and provides different kinds of ontology change exploration and analyses. It currently integrates approx. 560 versions of 16 life science ontologies. Secondly, the ontology version system is used to study the impact of ontology evolution on functional profiling results using the FUNC package [11]. The rest of the paper is organized as follows. In Section 2 we introduce our versioning model and corresponding relational repository schema. Section 3 describes a method for assessing changes when a new ontology version will be imported. Results

576

T. Kirsten et al.

of our performance analysis are illustrated in Section 4. We summarize and conclude in Section 5.

2 Versioning Model We assume that an ontology O=(C,R) consists of a set of concepts C={c1,…,cn} and a set of relationships R={r1,…,rm}. Concepts represent the entities of a domain to be modeled and are interconnected with relationships of R. Each relationship is associated with a specific type, such as 'is-a' or 'part-of', describing the semantics of the relationship. Concepts and relationships form together the structure of the ontology which can range from a flat vocabulary over a hierarchical representation to a directed acyclic graph (DAG). Each concept is described by a set of attributes, such as concept ID, name, definition or description. We assume that each concept is uniquely identified by the concept ID; in life sciences this identifying attribute is mostly called accession number. An ontology is usually released by the ontology provider at specific points in time to provide the current state of the ontology as a designated version. An ontology version Ov=(Cv,Rv,t) of the ontology O in version v at timestamp t is defined by a set of concepts Cv ⊆ C and a set of relationships Rv ⊆ R that are valid at the creation time t of Ov. Ontology versions follow a linear version schema, i.e., there is a chain of ontology versions, such that each version vi has at most one predecessor vi-1 and one successor vi+1. To find out the validity of concepts at a specific point in time, we associate with a life time (tstart, tend) with each concept and each relationship. A life time period begins with the date tstart of the ontology version in which the concept or relationship occurred for the first time. It ends with a date tend of the ontology version in which the concept or relationship has been valid for the last time (tstart < tend). Therefore, the set of concepts Cv (set of relationships Rv) of an ontology version Ov released at time t consists of all concepts ci ∈ C (relationship r ∈ R) which satisfy tstart ≤ t ≤ tend. In addition to the versioning of concepts and relationships at the ontology level, our versioning model also supports versioning for attributes at the concept level. At this level, we consider two aspects, a) the non-empty attribute set that is used to describe an ontology concept and b) the associated values per attribute. Associating the specific values of a concept attribute with a life time, i.e., a start and end date, allows selecting the concrete attribute value that is valid at a specific point in time t. The version model has been realized within a generic database repository to store the versions of different ontologies and supporting uniform version access. The relational repository schema for the versioning model is shown in Fig. 1. The schema consists of different entities to consistently represent ontologies (entity Ontologies), ontology versions (entity Ontology Versions), concepts (entity Ontology Concepts) and the ontology structure (entity Ontology Relationships). The latter entity represents the set of relationships; each of them is associated with a relationship type (e.g., is-a, part-of). To flexibly store attribute values for each ontology concept we apply the entity-attribute-value concept (EAV) [10]. In this way, the entity Attributes holds the set of attributes describing the semantics of the associated attribute values (entity Element Attribute Values) of an ontology concept. Hence, new attributes and attribute values can be inserted without changing the repository schema. Each ontology concept, relationship, and attribute

Efficient Management of Biomedical Ontology Versions

577

Fig. 1. Relational repository schema to efficiently manage ontology versions

value is associated with a life time represented by the fields 'date-from' and 'date-to'. Using these time periods, any ontology version can be completely reconstructed by taking the 'version date' attribute (entity Ontology Versions) into account, such that it holds date-from ≤ version date ≤ date-to. Actually, one can determine the snapshot of an ontology for any point in time after the creation date.

3 Data Import and Change Detection Given the frequent release of new versions it is important that new versions be automatically imported into the central version management system (repository). Furthermore, ontology changes compared to the previous version should automatically be detected to adapt the lifetime information of ontology components. The data flow for importing new versions from different ontology sources consists of three subprocesses, namely download and import of raw ontology versions, change detection, and loading changed objects into the repository. Most ontology versions can automatically be integrated depending on the physical source type of an ontology. While some ontology providers store versions within a concurrent version system (e.g., CVS and SVN), other ontology versions can be downloaded from web pages or publicly accessible FTP directories. Downloadwrappers for different physical source types regularly look up and automatically download data whenever a new version of a specified ontology is available. A new ontology version is then temporarily imported into a so-called staging area for further processing. Format-specific importers are used to import ontology versions taking the ontology representation into account. While OWL is the dominant ontology representation in the Semantic Web, many biomedical ontologies are provided in the OBO format or other formats, such as CSV, XML, and relational databases. We combine several format-specific importers with the download-wrappers to avoid ontologyspecific wrapper and import implementations. During the download and import phase the version metadata including the version number and the creation timestamp of an

578

T. Kirsten et al.

ontology version is recognized. This metadata is often encapsulated in file names especially when ontology versions are made available on web pages. In other cases, this metadata are available in specific documentation files or can be retrieved from systems such as CVS. The version metadata is the basis for the change detection phase which derives the dynamic life time information from the static ontology versions. This transformation includes the following steps. Firstly, the predecessor Ovi-1 is identified for the given import ontology version Ovi. Secondly, this version is compared with the import version to determine concepts and relationships which have been added and those that were deleted. This comparison is primarily performed by using the accession numbers (ID attribute) of ontology concepts. Finally, the detected changes are used to update the existing repository content. Newly introduced objects are added to the repository with a life time start equal to the timestamp of the import version. For deleted concepts and relationships the life time end is set to the date where an object was available for the last time which is normally the day before the import version Ovi was released. The life time of added and deleted concept attributes is adapted similarly than for the addition and deletion of concepts/relationships. Changes on attribute values are treated in the following way. The old attribute value stored in the repository is annotated with an end timestamp to indicate the end of its validity period. Furthermore, a new attribute entry is created with the modified value and a life time start equal to the import version. The example in Fig. 2 illustrates repository updates for selected changes between the May and June 2007 versions of the GO Cellular Components ontology. The concept GO:0009572 has been deleted, thus the end timestamps of this concept as well as its attributes and relationships are set to 2007-05. By contrast, the concept GO:0000446 with attributes (name, obsolete status, definition) as well as relationships to GO:0000347 and GO:0008023 were added. As a result the system creates new entries with a start timestamp of 2007-06. Finally, the name of GO:0009356 has changed from ‘p-aminobenzoate synthetase complex’ to ‘aminodeoxychorismate synthase complex’, hence the end timestamp of the corresponding attribute entry is set to 2007-05 and a new entry with start timestamp 2007-06 is inserted. Concepts accession number start GO:0009572 2002-02 GO:0000446 2007-06 ... source GO:0009572 GO:0009572 GO:0000446 GO:0000446

end 2007-05

Relationships target type GO:0044459 is_a GO:0009510 part_of GO:0000347 is_a GO:0008023 is_a

concept GO:0009572 GO:0009572 GO:0000446 start 2006-05 2003-05 2007-06 2007-06

end 2007-05 2007-05

GO:0000446 GO:0000446 GO:0009356 GO:0009356

Attributes attribute value name desmotubule central rod obsolete false nucleoplasmatic name THO complex obsolete false definition The THO complex when ... name p-aminobenzoate synthetase complex name aminodeoxychorismate synthase complex

start end 2002-02 2007-05 2002-02 2007-05 2007-06 2007-06 2007-06 2002-12 2007-05 2007-06

Fig. 2. Extract of the versioning repository for GO cellular components

4 Evaluation In this section we evaluate the storage efficiency and query performance of the presented approach for managing ontology versions. We first introduce different measures

Efficient Management of Biomedical Ontology Versions

579

for the storage and query evaluation. We then describe the evaluation scenario in the life science domain and analyze the evaluation results. 4.1 Evaluation Measures To assess the storage requirements we determine the number of stored ontology elements. We also compare the storage requirements of our proposed versioning repository (approach) with the ones for a fully redundant storage of ontology versions (naïve version management). We use these measures for the number of elements in a particular ontology version: Number of concepts, relationships and attributes available in ontology version Ovi Number of elements available in ontology version Ovi

|C|vi, |R|vi, |A|vi

|E|vi = |C|vi + |R|vi + |A|vi We denote the first version by v1 and the latest considered version by vn. The overall number of elements stored in a repository when integrating n succeeding ontology versions Ov1, …, Ovn of an ontology can be calculated as follows. naive

En

= ∑i =1 E vi n

approach

En

=

∪i =1 Evi n

(1)

Since the naive approach completely stores each version, we need to sum up the elements available in each version to determine the overall number of elements for n versions. In contrast, our approach avoids the redundant storage of unchanged elements but only stores the differences between versions. To estimate the resulting storage need we can consider the number of elements in the union of all versions thereby considering elements only once irrespective of their number of occurrence. Since both approaches store the same number of elements |E|v1 for the initial version, we further calculate |E|nnaive / |E|v1 and |E|napproach / |E|v1 to measure the growth w.r.t. first version v1. To determine the influence of ontology changes on the two versioning approaches we consider additions, deletions and modifications of ontology elements. We denote with add, del and mod the average number of added, deleted and modifies elements, respectively, per version change. Based on the number of elements in the first version |E|v1 we estimate the overall number of stored elements for n versions as follows. naive

En

= n E v1 +

n(n − 1) (add − del) 2

approach

En

= E v1 + (n − 1)(add + mod) (2)

The elements stored using the naive versioning technique are n-times the elements of the first version corrected by the elements added or deleted during evolution. Modifications on elements (e.g., attribute value changes) do not affect the overall number of stored elements for the naïve approach. By contrast, our versioning approach stores all elements of the first version plus only the changes (additions, modifications) occurred during evolution. Deletions of elements do not reduce the overall number since the timestamp-based versioning only sets end timestamps for deleted elements, i.e., these elements remain stored. Since we do not separately store each ontology version, individual versions must be reconstructed utilizing the timestamp information which might be comparatively slow for larger ontologies. Hence we not only evaluate storage requirements but also

580

T. Kirsten et al. Table 1. Typical ontology queries

Q1 Q2 Q3

Retrieve details (attributes, parents, children) of a given concept Retrieve all siblings of a given concept Retrieve all concepts in the sub tree of a given concept

Table 2. Storage requirements for |E|v1=1000, add = 20, del = 5, mod = 10 approach

n 10 20 30

E

usual n

10,675 22,850 36,525

E

approach n

1,270 1,570 1,870

En

usual

En

0.12 0.07 0.05

the query performance of our versioning approach. For this purpose we analyze query execution times of three typical ontology queries (Table 1). We determine the average execution times, tQ, for ten executions per query. We also determine the number of result items returned by Q, rQ, and the average time per result item, tQ/rQ. 4.2 Evaluation Scenarios and Results We first analyze the storage needs of an sample hypothetical ontology and then evaluate our approach on real world data. Table 2 compares the resulting storage requirements for both versioning approaches for a sample ontology of 1,000 elements in the first version and for a different number of versions (n = 10, 20, 30). We further assume average change rates of add=20, del=5 and mod=10 per version. In table shows that the proposed approach has a drastically reduced storage overhead compared to the naive versioning approach. For n versions, our approach requires almost n-times fewer elements than the naive versioning method. Furthermore, our approach performs the better the more versions are included. This is due to the fact that our approach only considers the differences between ontology versions whereas naive versioning redundantly stores ontology elements. For a real evaluation scenario, we use the Biological Process (BP) ontology. The BP ontology is managed by the Gene Ontology source that provides two further ontologies namely the Molecular Function (MF) and Cellular Component (CC) ontology. These ontologies are typically used to semantically describe properties of gene products or proteins, e.g., in which biological processes they are involved. While changes of these ontologies occur on a daily basis, we restrict ourselves to monthly summarizations between January 2004 and June 2009 (62 versions1) in our analysis. The initial version of January 2004 had the smallest number of elements (8,112 concepts, 12,456 relationships, 25,268 attribute values). This number increased by a more than a factor of 3 in the latest version of June 2009 (17,104 concepts, 34,248 relationships, 85,767 attribute values). The following evaluation considers three aspects. We first show a comparison of the storage requirements between our approach and the naive versioning method. We then study the influence of the storage interval (e.g., monthly, quarterly) on our approach. Finally, query performance is analyzed. All analyses for the proposed approach use a MySQL database to store the ontology versions; the overall database size for 62 BP versions is 40 MB. The database runs on a 1

Note that at the time of this study GO did not provide versions for 4 months in this time period.

Efficient Management of Biomedical Ontology Versions 130 120 110 100 90 80 70 60 50 40 30 20 10 0

naive versioning method our approach

180000

581

monthly quarterly half year

160000

# elements

|E|vi / |E|v1

140000 120000 100000 80000

version vi

Fig. 3. Comparison of space efficiency of our approach compared to naïve versioning

Jul-08

Jan-09

Jul-07

Jan-08

Jul-06

Jan-07

Jul-05

Jan-06

Jul-04

Jan-05

40000 Jan-04

Jul-08

Jan-09

Jan-08

Jul-07

Jul-06

Jan-07

Jul-05

Jan-06

Jul-04

Jan-05

Jan-04

60000

version

Fig. 4. Comparison of monthly/ quarterly/ semiannually storage requirements

Linux-based 2x Dual-Core 2 GHz Intel machine with 8 GB physical RAM. The tests were performed with disabled database caching in single-user mode. Fig. 3 illustrates the space efficiency of our approach compared to the naïve versioning method for the considered versioning period (January 2004 - June 2009). The storage requirements (integrated number of elements |E|vi) of both approaches are normalized according to the initial version. For both approaches the integration of the initial version takes the same number of elements (about 45,000). For the naïve versioning method, the storage requirements increase substantially with each version and reach 5.6 million elements after the final version corresponding to a growth factor of 124 compared to the first version. By contrast, our approach finally results in only 170,000 stored elements and a very modest growth factor of 3.8 (which corresponds to the overall increase of ontology elements). Given that the naïve versioning needs a 32-fold amount of storage we estimate that the corresponding database would have a size of approx. 1.3 GB compared to the 40 MB of the optimized scheme. Fig. 4 compares the space requirements for monthly, quarterly and semiannually versioning using our approach. Of course, the space requirements of monthly versioning are in general higher than for quarterly and semiannual versions. However, the difference between the three variants is marginal. For the considered time period until June 2009, monthly storage consumes approx. 170,000 elements compared to about 165,000 and 160,000 elements for quarterly and semiannual versions. The greater accuracy of monthly versions can thus be supported with a minimally increased storage. This underlines the scalability of the proposed versioning approach which is especially valuable when a large number of frequently released ontology versions need to be dealt with. Finally, we study the query performance of our versioning approach for the three query types of Table 1. For this experiment we use 22 ontology versions from Jan. 2004 to Apr. 2009. The queries are applied to the biological process behavior (GO:0007610) that is located on the third level (biological process Æ response to stimulus Æ behavior) of the GO-BP ontology. Fig. 5 depicts that the execution times for Q1, Q2, and Q3 are nearly constant over different ontology versions. It takes on average merely 0.17 ms to retrieve all concept details and the siblings of the selected biological process whereas

T. Kirsten et al.

35

1.6

30

1.4 1.2

Q1 Q2 Q3

1 0.8 0.6 0.4

250 Q1 Q2 Q3

200

25 20

150

15

100

10 50

5

0.2

Fig. 5. Query performance analysis, Q1, Q2, Q3 for GO:0007610

Apr-09

Jul-08

Oct-07

Jan-07

Jul-05

Apr-06

Oct-04

Jul-08

Jan-09

Jul-07

Jan-08

Jul-06

Jan-07

Jul-05

Jan-06

Jul-04

Jan-05

Jan-04

version

0 Jan-04

0

0

result size (Q3)

1.8

result size (Q1,Q2)

time (in ms) per item

582

version

Fig. 6. Number of result items, Q1, Q2, Q3 for GO:0007610

the execution times for querying the complete sub-graph are on average 1.47 ms. This holds despite the increase in the number of stored ontology elements for newer versions. Fig. 6 shows the result sizes of the three queries for the selected biological process which grow for newer versions. The number of concept details (Q1) increases from 20 to 31 between January 2004 and April 2009 (growth factor: 1.55), while the number of concepts in the set of siblings (Q2) and in the sub-graph (Q3) grow by a factors 1.4 and 3, respectively. In summary, our versioning approach is not only very space-efficient but also provides nearly constant execution times of the considered query types.

5 Conclusion and Future Work We propose a scalable and space-efficient approach to manage the versions for large ontologies. Our ontology versioning model maintains a life time for all ontology concepts, relationships and attribute values. This allows the reconstruction of the valid state of an ontology for any point in time while avoiding the redundant storage of unchanged parts in succeeding ontology versions. We applied our approach to biomedical ontologies but it is not limited to this domain. The evaluated of the storage requirements confirmed the high space efficiency of the proposed approach resulting in up to a n-fold reduction for n versions compared the separate storage of ontology versions. The evaluation of query performance over numerous versions also showed excellent results indicating that the space efficiency does not result in a significant penalization of query execution times. In future work we plan to extend our approach to the efficient versioning of mappings, e.g., mappings among ontologies (ontology mappings) and mappings associating ontology concepts with objects to semantically describe their properties (annotation mappings). Moreover, the approach can be applied to other domains, e.g. for an evolution analysis of Wikipedia categories. Acknowledgments. This work is supported by the German Research Foundation, grant RA 497/18-1.

Efficient Management of Biomedical Ontology Versions

583

References 1. Berriz, G.F., et al.: Characterizing gene sets with FuncAssociate. Bioinformatics 19(18), 2502–2504 (2003) 2. Day-Richter, J., et al.: OBO-Edit - an ontology editor for biologists. Bioinformatics 23(16), 2198–2200 (2007) 3. Flouris, G., et al.: Ontology change: Classification and survey. Knowledge Engineering Review 23(2), 117–152 (2008) 4. The Gene Ontology Consortium: The Gene Ontology project in 2008. Nucleic Acids Research 36(Database issue), D440–D441(2008) 5. Hartung, M., Kirsten, T., Rahm, E.: Analyzing the Evolution of Life Science Ontologies and Mappings. In: Bairoch, A., Cohen-Boulakia, S., Froidevaux, C. (eds.) DILS 2008. LNCS (LNBI), vol. 5109, pp. 11–27. Springer, Heidelberg (2008) 6. Hartung, M., et al.: OnEX – Exploring changes in life science ontologies. BMC Bioinformatics 10(1), 250 (2009) 7. Klein, M., et al.: Ontoview: Comparing and versioning ontologies. In: Collected Posters of 1st Intl. Semantic Web Conforence, ISWC (2002) 8. Klein, M., Fensel, D.: Ontology versioning on the Semantic Web. In: Proc. of the International Semantic Web Working Symposium (SWWS), pp. 75–91 (2001) 9. Knublauch, H., Fergerson, R.W., Noy, N.F., Musen, M.A.: The Protégé OWL Plugin: An Open Development Environment for Semantic Web Applications. In: McIlraith, S.A., Plexousakis, D., van Harmelen, F. (eds.) ISWC 2004. LNCS, vol. 3298, pp. 229–243. Springer, Heidelberg (2004) 10. Nadkarni, P.M., et al.: Organization of heterogeneous scientific data using the EAV/CR representation. Journal of American Medical Informatics Association 6(6), 478–493 (1999) 11. Prüfer, K., et al.: FUNC: a package for detecting significant associations between gene sets and ontological annotations. BMC Bioinformatics 8(1), 41 (2007) 12. Sioutos, N., de Coronado, S., Haber, M.W.: NCI Thesaurus: A semantic model integrating cancer-related clinical and molecular information. Journal of Biomedical Informatics (40), 30–43 (2007) 13. Völkel, M., Groza, T.: SemVersion: RDF-based ontology versioning system. In: Proc. of the IADIS Intl. Conference WWW/Internet, ICWI (2006) 14. Journal of Biomedical Informatics, Special Issue on Auditing of Terminologies 42(3), 402–580 (2009)

SemioSem: A Semiotic-Based Similarity Measure Xavier Aim´e1,3 , Fr´ed´eric Furst2 , Pascale Kuntz1 , and Francky Trichet1 1

LINA - Laboratoire d’Informatique de Nantes Atlantique (UMR-CNRS 6241) University of Nantes - Team “Knowledge and Decision” 2 rue de la Houssini`ere BP 92208 - 44322 Nantes Cedex 03, France [email protected], [email protected] 2 MIS - Laboratoire Mod´elisation, Information et Syst`eme University of Amiens UPJV, 33 rue Saint Leu - 80039 Amiens Cedex 01, France [email protected] 3 Soci´et´e TENNAXIA 37 rue de Chˆ ateaudun - 75009 Paris, France [email protected]

Abstract. This paper introduces a new similarity measure called SemioSem. The first originality of this measure, which is defined in the context of a semiotic-based approach, is to consider the three dimensions of the conceptualization underlying a domain ontology: the intension (i.e. the properties used to define the concepts), the extension (i.e. the instances of the concepts) and the expression (i.e. the terms used to denote both the concepts and the instances). Thus, SemioSem aims at aggregating and improving existing extensional-based and intensional-based measures, with an original expressional one. The second originality of this measure is to be context-sensitive, and in particular user-sensitive. Indeed, SemioSem is based on multiple informations sources: (1) a textual corpus, validated by the end-user, which must reflect the domain underlying the ontology which is considered, (2) a set of instances known by the end-user, (3) an ontology enriched with the perception of the end-user on how each property associated to a concept c is important for defining c and (4) the emotional state of the end-user. The importance of each source can be modulated according to the context of use and SemioSem remains valid even if one of the source is missing. This makes our measure more flexible, more robust and more close to the end-user’s judgment than the other similarity measures which are usually only based on one aspect of a conceptualization and never take the end-user’s perceptions and purposes into account. Keywords: Semantic Measure, Semiotics, Personnalization.

1

Introduction

Currently, the notion of similarity has been highlighted in many activities related to Ontology Engineering such as ontology learning, ontology matching or ontology population. In the last few years, a lot of measures for defining concept (dis-)similarity have been proposed. These measures can be classified according R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 584–593, 2009. c Springer-Verlag Berlin Heidelberg 2009 

SemioSem: A Semiotic-Based Similarity Measure

585

to two approaches: (i) extensional-based measures such as [14], [9], [7] or [4] and (ii) intensional-based measures such as [12], [8] or [18]. Most of these measures only focus on one aspect of the conceptualization underlying an ontology, mainly the intension through the structure of the subsumption hierarchy or the extension through the instances of the concepts or the occurences of the concepts in a corpus. Moreover, they are usually sensitive to the structure of the subsumption hierarchy (because of the use of the more specific common subsumer) and, therefore, they are dependent on the modeling choices. Finally, these measures never consider the end-user’s perceptions of the domain which is considered [2]. This paper presents SemioSem, a semiotic-based similarity measure, which aims at dealing with these problems. The first originality of SemioSem is to consider the three dimensions of a conceptualization: the intension (i.e. the properties used to define the concepts), the extension (i.e. the instances of the concepts) and the expression (i.e. the terms used to denote both the concepts and the instances). Using the semiotic approach in Knowledge Engineering is not a very new idea, and the 3 aspects of semiotics in ontology has already been underlined [16]. But we propose a practical application of this approach. Thus, SemioSem aims at aggregating three types of measure. The second originality of SemioSem is to be context-sensitive, and in particular user-sensitive. Indeed, SemioSem exploits multiple informations sources: (1) a textual corpus, validated by the end-user, which must reflect the domain underlying the ontology which is considered, (2) a set of instances known by the end-user, (3) an ontology enriched with the perception of the end-user on how each property associated to a concept c is important for defining c and (4) the emotional state of the end-user. The importance of each source can be modulated according to the context of use and SemioSem remains valid even if one of the source is missing. This makes our measure more flexible, more robust and more close to the end-user’s judgment than the other similarity measures. The rest of this paper is structured as follows. Section 2 describes in detail SemioSem: the basic foundations, the formal definitions, the parameters of the end-user and their interactions. Section 3 presents experimental results and compares our measure with related work in the context of a project dedicated to Legal Intelligence within regulatory documents related to the domain “Hygiene, Safety and Environment” (HSE).

2

SemioSem: A Semiotic-Based Similarity Measure

Building an ontology O of a domain D consists in establishing a consensual synthesis of individual knowledge belonging to a specific endogroup (endogroup is used here to name the people that agree with the conceptualisation formalized in the ontology, and not only those who have built it). For the same domain, several ontologies can be defined for different endogroups. Then, we call Vernacular Domain Ontologies (VDO) this kind of semantical resources1, because they depends on an endogroup G, with a cultural and educationnal background. 1

Vernacular means native.

586

X. Aim´e et al.

Formally speaking, we define a VDO, for a domain D and an endogroup G as follows:   O(D,G) = C, P, I, ≤C , ≤P , dom, codom, σ, L where – C, P and I are the sets of concepts, properties and instances of the concepts ; – ≤C : C × C and ≤P : P × P are partial orders on concept and property hierarchies2 ; – dom : P → C and codom : P → (C ∪Datatypes) associates to each property its domain and ventually its co-domain; – σ : C → P(I) associates to each concept its instances; – L = {LC ∪ LP ∪ LI , termc , termp , termi } is the lexicon of G relatively to the domain D where (1) LC , LP and LI are the sets of terms associated to C, P and I, and (2) the fonctions termc : C → P(LC ), termp : P → P(LP ) and termi : I → P(LI ) associate to the conceptual primitives the terms that name them. An ontology is used in a particular context, which depends on the type of application for which the ontology is used, and the user of the application. This is why E. Rosch considers ontologies as ecological [5]. A VDO can be contextualized, that is adapted to the context and in particular to the user. Each personnalization of the VDO leads to a different Personalised Vernacular Domain Ontologie (PVDO), which respects the formal semantics of the VDO but adds a knowledge layer over the VDO to take into account the particularities of the user. We propose to adapt the VDO to the context by adapting (1) the degrees of truth of the isa links defined between concepts and (2) the degrees of expressivity of the terms used to denote the concepts. We also propose to realize this contextualization and, more precisely, this personnalization, by using additional resources that express some elements of conceptualization specific to the user. Three additional resources are used: (1) a set of instances supposed to be representative of the user conceptualization (for instance, in the case of a business information system, these instances are the customers the user deal with, the products he sells to them, etc), (2) a corpus given by the user and supposed representative of its conceptualization (for instance, this corpus can be the documents written by the user on a blog or a wiki) and (3) weighting of properties of each concept. These weighting express the significance that the user attach to properties in the definition of the concept. These weightings are fixed by the user as follows: for each property p ∈ P, the user ordinates, on a 0 to 1 scale, all the concepts having p, in order to reflect its perception on how p is important for defining c. For instance, for the property has an author, the concept Scientific Article will be put first, secondly the concept Newspaper Article, for which the author is less important, thirdly the concept Technical Manual. SemioSem is a semantics similarity measure defined in the context of an PVDO, and uses as resources the PVDO and the three additional resources 2

c1 ≤C c2 means that the concept c2 is subsuming the concept c1 .

SemioSem: A Semiotic-Based Similarity Measure

587

given above. Moreover, SemioSem is based on the three dimensions introduced by Morris and Peirce in their theory of semiotics [11]: (1) the signified, i.e. the concept defined in intension, (2) the referent, i.e. the concept defined in extension via its instances, and (3) the signifier, i.e. the terms used to denote the concept. Thus, SemioSem corresponds to an aggregation of three components: (1) an intensional component based on the comparison of the properties of the concepts, (2) an extensional component based on the comparison of the instances of the concepts, (3) an expressional component based on the comparison of the terms used to denote the concepts and their instances. Each component of SemioSem is weighted in order to be able to adapt the calculation of the similarities to the way the end-used apprehends the domain which is considered (e.g. giving more importance to the intensional component when the end-user better apprehends the domain via an intensional approach rather than an extensional one). These differences of importance are conditioned by the domain, the cognitive universe of the end-user and the context of use (e.g. ontology-based information retrieval). For instance, in the domain of the animal species, a zoologist will tend to conceptualize them in intension (via the biological properties), whereas the majority of people use more extensional conceptualizations (based on the animals they have met during their life). Formally, the function SemioSem: C × C → [0, 1] is defined as follows: 1

SemioSem(c1 , c2 ) = [α ∗ intens(c1 , c2 ) + β ∗ extens(c1 , c2 ) + γ ∗ express(c1 , c2 )] δ

The following sections present respectively the functions intens (cf. section 2.1), extens (cf. section 2.2), express (cf. section 2.3) and the parameters α, β, γ, δ (cf. section 2.4). 2.1

Intensional Component

From an intensional point of view, our work is inspired by [1] and is based on the representation of the concepts by vectors in the space of the properties. Formally, → to each concept c ∈ C is associated a vector vc = (vc1 , vc2 , ..., vcn ) where n = |P| and vci ∈ [0, 1], ∀i ∈ [1, n]. vci is the weighting fixed by the end-user which precises how the property i is important for defining the concept c (by default, vci is equal to 1). Thus, the set of concepts corresponds to a point cloud defined in a space with |P| dimensions. We calculate a prototype vector of cp , which was originally introduced in [1] as the average of the vectors of the sub-concepts of cp . However [1] only considers the direct sub-concepts of cp , whereas we extend the calculation to all the sub-concepts of cp , from generation 1 to generation n. Indeed, some properties which can only be associated to indirect sub-concepts can however appear in the prototype of the super-concept, in particular if the intensional aspect is important. Thus, the prototype vector pcp is a vector in the space properties, where the importance of the property i is the average of the importances of the properties of all the sub-concepts of cp having i. If for i ∈ P, Si (c) = {cj ≤C c, cj ∈ dom(i)}, then: →

pcp [i] =



→

cj ∈Si (cp )

vcj [i]

|Si (cp )|

588

X. Aim´e et al.

From an intensional point of view, the more the respective prototype vectors of c1 and c2 are close in terms of euclidean distance (i.e. the more their properties are close), the more c1 and c2 are similar. This evaluation is performed by the function intens: C × C → [0, 1], which is formally defined as follows: →

→

intens(c1 , c2 ) = 1 − dist(pc1 , pc2 ) 2.2

Extensional Component

From an extensional point of view, our work is based on the Jaccard’s similarity [6]. Formally, the function extens: C × C → [0, 1] is defined as follows: extens(c1 , c2 ) =

|σ(c1 )∩σ(c2 )| |σ(c1 )|+|σ(c2 )|−(|σ(c1 )∩σ(c2 )|)

This function is defined by the ratio between the number of common instances and the total number of instances minus the number of instances in common. Thus, two concepts are similar when they have a lot of instances in common and few distinct instances. 2.3

Expressional Component

From an expressional point of view, the more the terms used to denote the concepts c1 and c2 are present together in the same documents of the corpus, the more c1 and c2 are similar. This evaluation is carried out by the function express : C × C → [0, 1] which is formally defined as follows:  min(count(t1 ),count(t2 )) count(t1 ,t2 ) express(c1 , c2 ) = ( ∗ ) Nocc Ndoc t1 ,t2

With: – t1 ∈ words(c1 ) and t2 ∈ words(c2 ) where words(c) returns all the terms denoting the concept c or one of its sub-concept (direct or not); – count(ti ) returns the number of occurrences of the term ti in the documents of the corpus; – count(t1 , t2 ) returns the number of documents of the corpus where the term t1 and t2 appear simultaneously; – Ndoc returns the number of documents of the corpus; – Nocc is the sum of the numbers of occurrences of all the terms included in the corpus. 2.4

Parameters of SemioSem

α, β et γ are the (positive or null) weighting coefficients associated to the three components of SemioSem. In a way of standardization, we impose that the components vary between 0 and 1 and that α + β + γ = 1. The values of these three coefficients can be fixed arbitrarily, or evaluated by experiments. We also advocate a method to automatically calculate approximations of these

SemioSem: A Semiotic-Based Similarity Measure

589

values. This method is based on the following principle. We consider that the relationship between α, β and γ characterises the cognitive coordinates of the end-user in the semiotic triangle. To fix the values of α, β and γ, we propose to systematically calculate γ/α and γ/β, and then to deduce alpha from the constraint α+β +γ = 1. γ/α (resp. γ/β) is approximated by the cover rate of the concepts (resp. the instances) within the corpus. This rate is equal to the number of concepts (resp. instances) for which at least one of the terms appears in the corpus divided by the total number of concepts (resp. instances). The factor δ ≥ 0 aims at taking the mental state of the end-user into account. Multiple works have been done in Cognitive Psychology on the relationship beween human emotions and judgments [3]. The conclusion of these works can be summarized as follows: when we are in a negative mental state (e.g. fear or nervous breakdown), we tend to centre us on what appears to be the more important from an emotional point of view. Respectively, in a positive mental state (e.g. love or joy), we are more open in our judgment and we accept more easily the elements which are not yet be considered as so characteristic. According to [10], a negative mental state supports the reduction in the value of representation, and conversely for a positive mental state. In the context of our measure, this phenomemon is modelised as follows. We characterize (1) a negative mental state by a value δ ∈]1, +∞[, (2) a positive mental state by a value δ ∈]0, 1[, and (3) a neutral mental state by a value of 1. Thus, a low value of δ, which characterises a positive mental state, leads to increase the similarity values of concepts which initially would not been considered as so similar. Conversely, a strong value of δ, which characterises a negative mental state, leads to decrease these values.

3

Experimental Results

SemioSem is currently evaluated in the context of a project funded by Tennaxia (http://www.tennaxia.com), an IT Services and Software Engineering company which provides industry-leading software and implementation services dedicated to Legal Intelligence in the areas “ Hygiene, Safety and Environment ” (HSE). In the context of this project, an ontology of the HSE domain has been built3 . This ontology, which is particularly dedicated to dangerous substances, is composed of 3.776 concepts structured in a lattice-based hierarchy (depth=11; width=1300), and 15 properties. The whole ontology is stored in a database in order to ensure weak calculation time. In order to store the ontology in text-files, we have defined an extension of OWL which includes additional markup for to isa links and labels, dedicated to the representation of prototypicality values. In order to evaluate our measure and to compare it with related work, we have focused our study on the hierarchy presented in figure 1: the goal is to compute the similarity between the concept Carbon and the sub-concepts of Halogen; for the expert of Tennaxia, these similarities are evaluated as follows: Fluorine=0.6; Chlorine=0.6; Bromine=0.3; Iodine=0.3; Astatine=0.1. We have 3

Tennaxia company - All Rights Reserved. INPI 13th June 2008 N.322.408 – Scam Vlasquez 16th September 2008 N.2008090075.

590

X. Aim´e et al.

also elaborated a specific corpus of texts composed of 1200 european regulatory documents related to the HSE domain (mainly laws, regulations, decrees and directives). Table 1 presents the similarity values obtained with three intensionalbased measures: Rada, Leacock and Wu. One can note that all the values are equal because these measures only depend on the structure of the hierarchy. Table 1 depicts the similarity values obtained with three extensional-based measures: Lin, Jiang and Resnik. Table 2 presents the similarity values obtained with SemioSem according to 6 contexts defined by the following parameters: (1) A (α = 0.7, β = 0.2, γ = 0.1, δ = 1), (2) B (α = 0.2, β = 0.7, γ = 0.1, δ = 1), (3) C (α = 0.2, β = 0.1, γ = 0.7, δ = 1), (4) D (α = 0.33, β = 0.33, γ = 0.33, δ = 1), (5) E (α = 0.7, β = 0.2, γ = 0.1, δ = 0.1), and (6) F (α = 0.7, β = 0.2, γ = 0.1, δ = 5.0). These experimental results lead to the following remarks: (1) in all the contexts, SemioSem provides the same order of similarities as the other measures. In a context which gives priority to the intensional component (cf. context A), SemioSem is better than the other measures. In the context B which gives priority to the extensional component (resp. the context C which gives priority to the expressional component), SemioSem is close to Jiang’s measure (resp. Lin’s measure). In a context which gives no priority to a specific component (cf. context D), SemioSem is between Lin’s measure and Jiang’s measure; (2) context E and F clearly show the influence of the emotional factor: a positive mental state

Fig. 1. Extract of the hierarchy of concepts of the HSE ontology Table 1. Similarity with Carbon Halogen Fluorine Chlorine Bromine Iodine Astatine

Rada 0,25 0,25 0,25 0,25 0,25

Leacock 0,097 0,097 0,097 0,097 0,097

Wu 0,6 0,6 0,6 0,6 0,6

Lin 0.31 0.28 0.23 0.22 0

Jiang 0.14 0.12 0.09 0.09 0

Resnik 1.43 1.43 1.43 1.43 1.43

Table 2. Similarity with Carbon (SemioSem) Halogen Fluorine Chlorine Bromine Iodine Astatine

A 0.40 0.36 0.29 0.28 0.01

B 0.14 0.12 0.10 0.10

C 0.32 0.29 0.23 0.23

D 0.27 0.25 0.20 0.19

2.10−4 2.10−4 3.10−4

E 0.91 0.90 0.88 0.88 0.63

F 0.025 0.017 0.007 0.006 1.10−8

SemioSem: A Semiotic-Based Similarity Measure

591

(cf. context E) clearly increases the similarities values and a negative mental state (cf. context F) clearly decreases similarities values; and (3) the concept Astatine is not evocated in the corpus, nor represented by instances. Thus, it is not considered as similar by Lin’s and Jiang’s measures. SemioSem finds a similarity value thanks to the intensional component.

4

Conclusion

SemioSem is particularly relevant in a context where the perception (by the end-user) of the domain which is considered (and which is both conceptualized within an ontology and expressed by a corpus and instances) can have a large influence on the evaluation of the similarities between concepts (e.g. ontologybased information retrieval). We advocate that such an user-sensitive context, which de facto includes subjective knowledge (whereas ontologies only includes objective knowledge), must be integrated in a similarity measure since ontologies co-evolve with their communities of use and human interpretation of context in the use. Formally, SemioSem respects the properties of similarity measure reminded in [4]: positiveness4 , reflexivity5 and symmetry6 . But, SemioSem is not a semantic distance since it does not check simultaneously the strictness property7 and the triangular inequality8 . For the extensional component, our first choice was the Amato measure. But one of our goal is to be independent from the modeling structure andthis measure clearly depends on the Most Specific Common Subsumer (MSCS). Moreover, in the case of our experiment, it does not really provide more relevant results. It is why we have adopted the Jaccard measure for its simplicity and its independence from the MSCS but we currently study the use of the Dice measure. For the expressional component, the Latent Semantic Analysis could be adopted but since it is based on the tf-idf approach, it is not really appropriated to our approach: we want to keep the granularity of the corpus in order to give more importance to concepts which perhaps appears less frequently in each document, but in an uniform way in the whole corpus (than concepts which are frequently associated in few documents). Then, as we simply compare the terms used to denote the concepts in the corpus, our approach is clearly limited since it can not deal with expressions such as ”t1 and t2 are opposite”. To deal with this problem, we plan to study more sophisticated computational linguistic methods. Finally, for the intensional component, our approach can be time-consuming (when the end-user decides to weight the properties of the concepts9 ), but it is really innovative to our knowledge and it 4 5 6 7 8 9

∀x, y ∈ C : SemioSem(x, y) ≥ 0. ∀x, y ∈ C : SemioSem(x, y) ≤ SemioSem(x, x). ∀x, y ∈ C : SemioSem(x, y) = SemioSem(y, x). ∀x, y ∈ C : SemioSem(x, y) = 0 ⇒ x = y. ∀x, y, z ∈ C : SemioSem(x, y) + SemioSem(y, z) ≥ SemioSem(x, z). Again, by default, all the weightings are equal to 1 and the function Intens remains valid. In the case of our experiment, the results obtained in this context for the concept Fluorine are: A - 0.59 ; B - 0.19; C - 0.38; D - 0.37; E - 0.95; F - 0.12.

592

X. Aim´e et al.

provides promising results. The parameters alpha, beta, gamma and delta are used to adapt the measure to the context which is related to the end-user perception of the domain according to the intentional, extensional, expressional and emotional dimension. We consider that this is really a new approach and this is why we call our measure SEMIOSEM (Semiotic-based Similarity Measure). Moreover, the aggregation we advocate does not just correspond to a sum: these parameters are used both to modulate the influence of each dimension and/or to adapt the calculus according to the resources with are available. Thus, when no corpus is available, the expressional component can not be used (γ = 0). A similar approach is adopted for the intentional component (an ontology without properties leads to α = 0) and the extensional component (no instances leads to β = 0). The value of delta (emotional state) can be defined according to a questionary or the analysis of datas given by physical sensors such as the speed of the mouse, the webcam-based facial recognition, etc. To sum-up, SemioSem is more flexible (since it can deal with multiple information sources), more robust (since it performs relevant results under unusual conditions as shown by the case Astatine of the experimental results) and more user-centered (since it is based on the domain perception and the emotional state of the end-user) than all the current methods.

References 1. Au Yeung, C.M., Leung, H.F.: Ontology with likeliness and typicality of objects in concepts. In: Embley, D.W., Oliv´e, A., Ram, S. (eds.) ER 2006. LNCS, vol. 4215, pp. 98–111. Springer, Heidelberg (2006) 2. Blanchard, E., Harzallah, M., Kuntz, P.: A generic framework for comparing semantic similarities on a subsumption hierarchy. In: Proceedings of the 18th European Conference on Artificial Intelligence (ECAI 2008), pp. 20–24. IOS Press, Amsterdam (2008) 3. Bluck, S., Li, K.: Predicting memory completeness and accuracy: Emotion and exposure in repeated autobiographical recall. Applied Cognitive Psychology (15), 145–158 (2001) 4. d’Amato, C., Staab, S., Fanizzi, N.: On the influence of description logics ontologies on conceptual similarity. In: Gangemi, A., Euzenat, J. (eds.) EKAW 2008. LNCS (LNAI), vol. 5268, pp. 48–63. Springer, Heidelberg (2008) 5. Gabora, L.M., Rosch, E., Aerts, D.: Toward an ecological theory of concepts. Ecological Psychology 20(1-2), 84–116 (2008) 6. Jaccard, P.: Distribution de la flore alpine dans le bassin des dranses et dans quelques regions voisines. Bulletin de la Societe Vaudoise de Sciences Naturelles 37, 241–272 (1901) (in French) 7. Jiang, J., Conrath, D.: Semantic similarity based on corpus statistics and lexical taxinomy. In: International Conference on Research in Computationnal Linguistics, pp. 19–33 (1997) 8. Leacock, C., Chodorow, M.: Combining local context and Wordnet similarity for word sense identification. In: WordNet: an electronic lexical database, pp. 265–283. MIT Press, Cambridge (1998) 9. Lin, D.: An information-theoric definition of similarity. In: Proceedings of the 15th international conference on Machine Learning, pp. 296–304 (1998)

SemioSem: A Semiotic-Based Similarity Measure

593

10. Mikulincer, M., Kedem, P., Paz, D.: Anxiety and categorization-1, the structure and boundaries of mental categories. Personality and individual differences 11(8), 805–814 (1990) 11. Morris, C.W.: Foundations of the Theory of Signs. Chicago University Press (1938) 12. Rada, R., Mili, H., Bicknell, E., Blettner, M.: Development and application of a metric on semantic nets. IEEE Transaction on Systems, Man and Cybernetics 19(1), 17–30 (1989) 13. Resnik, P.: Semantic similarity in a taxonomy: An information-based measure and its application to problems of ambiguity in natural language. Journal of Artificial Intelligence Research (JAIR) 11, 95–130 (1999) 14. Resnik, P.: Using information content to evaluate semantic similarity in a taxonomy. In: Proceedings of the 14th International Joint Conference on Artificial Intelligence (IJCAI 1995), vol. 1, pp. 448–453 (1995) 15. Sanderson, M., Croft, W.B.: Deriving concept hierarchies from text. In: Proceedings of the 22nd International ACM SIGIR Conference, pp. 206–213 (1999) 16. Sowa, J.: Ontology, metadata, and semiotics. In: Ganter, B., Mineau, G.W. (eds.) ICCS 2000. LNCS, vol. 1867, pp. 55–81. Springer, Heidelberg (2000) 17. Tversky, A.: Features of similarity. Psychological Review 84, 327–352 (1977) 18. Wu, Z., Palmer, M.: Verb semantics and lexical selection. In: Proceedings of the 32nd annual meeting of the Association for Computational Linguistics, pp. 133–138 (1994)

Ontology Evaluation through Usability Measures An Experiment with the SUS Scale in the Legal Domain N´uria Casellas Institute of Law and Technology (IDT-UAB), Universitat Aut`onoma de Barcelona, Bellaterra 08193, Spain [email protected] http://idt.uab.cat

Abstract. Current ontology methodologies offer guidance towards knowledge acquisition, ontology development (design and conceptualization), formalization, evaluation, evolution and maintenance. Nevertheless, these methodologies describe most of expert involvements within ontology validation rather vaguely. The use of tailored usability methods for ontology evaluation could offer the establishment of certain quality measurements and aid the evaluation of modelling decisions, prior ontology implementation. This paper describes the experimental evaluation of a legal ontology, the Ontology of Professional Judicial Knowledge (OPJK), with the SUS questionnaire, a usability evaluation questionnaire tailored to ontology evaluation.

1 Introduction Although there are many approaches to ontology evaluation, very few are directed towards the evaluation of the quality of the conceptual content of the ontology. These evaluations could offer relevant insights, especially, for the development of ontologies based on expert knowledge, or in our research, for ontologies based on legal professional knowledge. “Evaluation of ontologies refers to the correct building of the content of the ontology, that is, ensuring that its definitions (a definition is written in natural language and in a formal language) correctly implement ontology requirements and competency questions or perform correctly in the real world” [1]. Most ontology engineering methodologies include, generally, an evaluation stage, although different proposals regarding its actual performance are offered. In this sense, an evaluation is a recursive process, a cyclic activity; findings during evaluation may require ontology refinement, further knowledge acquisition, and as a consequence, also further conceptualization and validation [2]. Regarding evaluation within ontology methodologies, [3] proposed an ontology evaluation based on the competency questions set for the development of the ontology. [1] proposes a life-cycle evaluation, based on the implementation of the requirements, and the validation of definitions, consistency, completeness and conciseness. User assessment is envisaged as an evaluation activity towards ontology reuse. [2] suggested a technology-focused evaluation (formal language—syntax—and consistency), a userfocused evaluation (requirements specification document, including competency questions), and an ontology-focused evaluation (including verification and validation). R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 594–603, 2009. c Springer-Verlag Berlin Heidelberg 2009 

Ontology Evaluation through Usability Measures

595

Finally, UPON [Unified Process for Ontology Building] and OntoLearn include the participation of domain experts in the validation phase, and in the validation cycle towards ontology learning and extraction (see [4,5], respectively). Moreover, evaluation (validation, verification and assessment) and quality measurement of ontologies are currently an important topic of research, especially towards ontology implementation and ontology assessment or comparison for reuse purposes.1 The organization of the EON and OntoContent workshops series,2 together with new evaluation and measurement proposals, demonstrate the relevance of this activity both for ontology development and comparison for reuse. Evaluation according to philosophical notions such as identity or unity (the OntoClean methodology by [11]), according to schema and instance metrics (OntoQA evaluation by [12]), and the work of [13,14] regarding the design of ontology metrics, are some examples of these proposals. As mentioned above, few of these evaluation techniques or methodologies may evaluate the quality of the conceptual content of ontologies, and although some ontology methodologies involve experts during the validation process, most of these expert involvements are described rather vaguely. In order to explore some solutions to support expert evaluation in expert knowledge ontology engineering, we conducted an experiment to study if the use of adapted usability measures (usability questionnaires) could offer relevant ontology evaluation results. This experiment was carried out during the development process of a legal ontology engineered from professional knowledge of judges in practice: the Ontology of Professional Judicial Knowledge [15,16,17]. Human-centred software design and user validation are highly standardized processes which include participation in and evaluation of the general development of software, systems and products, the analysis of their usability, the documentation provided and the quality of their use. Moreover, usability engineering may take into account the effectiveness, efficiency and satisfaction offered by the use of a product (in a certain context), the user interface development process, and the validation of the activities performed during the development process of a product.3 Therefore, ontology engineering could benefit from the inclusion of several systematic human-centred methods in the ontology development life-cycle, specially towards the construction of domain and core ontologies for specific areas of knowledge, especially those which include the modelling of expert knowledge. Knowledge acquisition for ontology modelling, evaluation of ontologies and the production of documentation would directly benefit from the application of a similar approach. Moreover, the use of these measures could offer grounds for further ontology comparison, for research into 1

2

3

Some authors refer to this step as ontology evaluation, although the main purpose of this assessment is ontology reuse and comparison, rather than the conceptual and quality improvement of a particular ontology [6,7,8]. OntoMetric, for example, is a tool that “allows the users to measure the suitability of the existent ontologies, regarding the requirements of their systems” [9]. See also [10] and the European project SEALS (http://www.seals-project.eu). Visit the 5th International EON [Evaluation of Ontologies and Ontology-based tools] Workshop at http://km.aifb.uni-karlsruhe.de/ws/eon2007, retrieved November 10, 2008, and the 3rd OntoContent workshop at http://mature-ip.eu/en/ontocontent2008, retrieved November 10, 2008. For example, human and user-centred design for life cycle of interactive computer-based systems [18], usability methods [19], and the evaluation of quality in use [20,21].

596

N. Casellas

ontology sharedness measurements, and foster expert participation in the development of ontologies based on professional or expert knowledge. This paper describes this experimental evaluation, based on the adaptation of the System Usability Scale developed by [22] to ontology (sharedness) validation. Section 2, briefly describes the Ontology of Professional Judicial Knowledge (OPJK) of the I URISERVICE application. Section 3 outlines the results obtained from an ad hoc evaluative activity of the Ontology of Professional Judicial Knowledge, and section 4 offers the description of the evaluative experiment with the SUS questionnnaire and the comparison of results. Finally, some conclusions and further work are outlined.

2 Ontology of Professional Judicial Knowledge The purpose of the Ontology of Professional Judicial Knowledge was to semantically enhance the search and retrieval capabilities of I URISERVICE, a web-based application that supports legal decision making during the on-call period of Spanish newly recruited judges. The need for the I URISERVICE system and its initial design was established as a result of a thorough ethnographic survey carried out with the collaboration of the Spanish General Council of the Judiciary (CGPJ). From the findings of this survey, the research team assumed that: – Judges in their first appointment solve several practical problems during their first months of work, mostly during the on-duty period. – This knowledge was acquired mainly by practice. – A repository of possible solutions based on experience towards practical problems could offer valuable support for the newly appointed judges. Such a system could also be useful to the judicial profession itself in order to distribute, maintain, and avoid inconsistencies of this practical knowledge. – As use of the Internet/Intranet was widespread among judges, a web-based FAQ system with a simple natural language interface could be designed. – If a system was to provide efficient support in a reliable manner, the repository of knowledge and its accuracy and validity (answers to questions regarding practical problems of the judicial profession) were critical. – During the on-call period, time and accuracy (semantics rather than on simple keyword matching) were also critical issues. Due to these findings, the I URISERVICE application was designed to provide on-line access to an FAQ (Frequently Asked Questions) system that allowed users (judges) to search for practical (experience) questions in a repository. The overall design of the system is based on the need for effectiveness: the system should be able to locate the best possible matching FAQ question to the user’s input question that tackles the problem. The use of semantic technologies, through the use of ontologies, in the system was aimed at providing more accurate searches than the basic keyword search. Therefore, the OPJK ontology needed to represent the relevant concepts related to the problems that took place during the on-call period: domain specific knowledge. This professional knowledge gathered by experience from the practice during on-call period was acquired in interviews aimed at eliciting the problems (questions) that judges

Ontology Evaluation through Usability Measures

597

faced in their first appointment. From these interviews, a corpus of nearly 800 practical questions was obtained; this corpus constituted the main knowledge source towards OPJK ontology conceptualization. Two versions of OPJK were produced in order to facilitate computation capabilities and to obtain significant technical evaluation results in the future. The main classes and their subclasses of the Ontology of Professional Judicial Knowledge were: Role (e.g. Judicial Role, Procedural Role, Family Role), Act (e.g. Procedural Act, Agent (e.g. Judicial Organization, Penal Institution), Document (e.g. Legislative Document, Judicial Document), and Process (e.g. Appeal Procedure, Hearing). The development process, including knowledge acquisition, conceptualization, and formalization has been described by [23,24].

3 OPJK Evaluation The evaluation of the Ontology of Professional Judicial Knowledge included, then, a purpose-focused evaluation and an ontology-focused evaluation. The evaluation of the purpose was based on the analysis of the specification of requirements and competency questions established in the Ontology Requirements Specification Document against the final OPJK ontology. Nevertheless, in this paper, we focus on the description of the ontology-focused evaluation, which comprehended the verification of the correctness of an ontology, and the validation of the representation offered. [2] refers to them as the evaluation of “building the system right” and “building the right system”, respectively. As the Ontology of Professional Judicial Knowledge models conceptual expert professional legal knowledge, ontology-focused validation activities required the involvement of legal professionals or legal experts to validate the knowledge that the OPJK ontology represents, thus, to validate the shareability of the conceptualization formalized under the established requirements. 3.1 Language Conformity and Consistency Checking The domain knowledge contained in the ontology was first represented in a lightweight manner, and complexity was added with the use of OWL as representation language in the following versions of the Ontology of Professional Judicial Knowledge. The use of the Prot´eg´e knowledge acquisition tool and ontology editor allows consistency checking through the Pellet reasoner, and prevents the incorrect usage of the OWL language in the construction of ontologies [2]. All OPJK versions were found consistent by the Pellet reasoner used by the Prot´eg´e editor. 3.2 Legal Expert’s Validation In order to evaluate the content of the ontology, debriefing sessions were set for different groups of legal experts (professionals and academics) in order to inform them of the purpose of the Ontology of Professional Judicial Knowledge, its requirements, its conceptual particularities, and the process of conceptualization followed, based on the corpus of questions provided by the judges in their first appointment during the

598

N. Casellas

surveys carried out during 2004. At the end of these debriefing sessions, the experts were required to answer an ad hoc questionnaire, designed to evaluate specifically different features of the OPJK ontology and, to provide suggestions for improvement (following Nielsen’s approach [25]). A group of 9 legal experts (academics, professionals and researchers) working at or collaborating with the Faculty of Law of the Universitat Aut`onoma de Barcelona took part in the evaluation. From these legal experts, 7 had 6 or more years of working experience (3 experts had 10 years or more). Regarding the area of expertise, there were experts in substantive law—public and private law—(3), procedural law (2), and in the areas of legal theory, legal sociology or legal history (4). Finally, from the total of participants, 3 were legal professionals (2 lawyers and 1 judge), 3 were legal researchers (Law & Technology), and 3 were legal academics. This questionnaire contained a total of 48 questions regarding several aspects of the OPJK conceptualization: concepts, definitions, instances, and relations. The evaluation of the complete ontology (56 classes, 913 instances, 24 owl:ObjectProperty axioms (10 rdfs:subPropertyOf and 12 owl:inverseOf), 2 owl:equivalentClass axioms, 77 owl:disjointWith axioms, 80 multiple class instantiation constructs, 51 owl:sameAs axioms) was considered a lenghtly and time consuming activity with respect to the limited access to experts’ time. Therefore, the evaluation was designed to include the validation of the complete taxonomical structure (56 classes), and the revision of 14 concept defintions, 49 instance classifications, 9 property relations, 4 multiple class instantiations, and 4 equivalent instance relations.4 The experts were asked to express their opinion regarding their level of agreement with the conceptualization, understood as acceptance of the specific conceptualization decision with regards to the purpose of the ontology), according to a Likert scale, a 1 to 5 scale, where 1 corresponds to “highly disagree” and 5 to highly agree. Finally, the evaluation of the features was carried out on these different levels of the ontology separately, as suggested by [8]. First, legal experts performed an evaluation of each of OPJK main classes and some of the natural language definitions provided for them: Agent, Document, Act, Process, and Role. The experts highly agreed or agreed in 27.78% and in 36.11%, respectively, to the taxonomical conceptualization of classes (A, see table 1 below), which represented a 63.89% of general agreement. Nevertheless some high disagreement (5.56%) was also expressed.5 Then, the experts were asked to evaluate the natural language definitions provided for some of the most characteristic concepts of the OPJK ontology with relation to the judicial setting (judicial organization, procedural role, legal document, legal act, criminal act, procedural act, etc.) Judicial Decision Organization, Procedural Role, Legal Document, Legal Act, Criminal Act and Procedural Act. Also, the definitions provided for Macroprocess, Microprocess and Family Role were included 4

5

The specific contents of the questions were chosen by their modelling complexity, based on a previous validation experience and design discussions during the conceptualization process, and conceptualization difficulties. There was no wide disagreement between the experts regarding a specific class, although the Agent class obtained a “high agree” from 8 out of 9 experts.

Ontology Evaluation through Usability Measures

599

to validate their acceptance. The overall agreement of the experts with the questions included in this first section (class conceptualization—A— and class definitions—B and C—) was of 62.96%, including “high agree” and “agree”(while high disagreement represented a 4.32%). Judicial Organization, Family Role, Microprocess, and Legal Act, were the definitions most disagreed upon. The next section of the evaluation questionnaire included 13 questions related to the classification of instances (D). For example, the experts were asked about their agreement regarding the classification of donation and purchase as instances of Legal Act, or plaintiff, defendant, complainant as instances of Criminal Procedural Role. The overall level of agreement on the classification of instances, taking into account results from both “high agree” and “agree” options, was of the 82.9%. Nevertheless, most experts “disagree” and “highly disagree” with several instantiations (judicial office as Judicial Government Organization, and of town hall and social services as Local Organization). In the following section of the evaluation questionnaire, the experts were required to evaluate several relations established between the conceptualized classes, and to express their degree of agreement with several owl:Object Property and rdfs:subPropertyOf constructs and with a set of multiple class instantiation and owl:sameAs constructs (E and F). A total of 75.82% of general agreement (35.95% “highly agree” and 39.87% “agree”) was obtained. The last set of questions of the evaluation questionnaire comprehended the validation of multiple class instantiation and owl:sameAs constructs. In total, the experts were asked to validate 48 items. Their overall levels of agreement with the general conceptualization offered (class, subclass, instantiation, properties, etc.) was of 72.92% (high agreement 32.41% and agreement 40.51%) in total. Table 1 below includes all the specific results. Finally, during these debriefing sessions the experts made several relevant suggestions, generally related to the taxonomical classifications and concept definitions showing the lowest scores, for the improvement of the OPJK ontology. In general, the taxonomical structure of Process and Act was found rather complex. Also, although the class structure for Organization and Role was considered correct, minor revisions could provide major improvement. Moreover, slight changes in labels and definitions could offer clarity and foster expert understanding and agreement. These suggestions were taken into account towards OPJK refinement (see, for more details, [23]. Table 1. Evaluation results

Levels High agreement Agreement Indifferent Disagreement High disagreement TOTALS

A 27.78% 36.11% 19.44% 11.11% 5.56% 100%

Groups of questions B C D E 35.56% 17.28% 38.46% 34.57% 42.22% 37.04% 44.44% 40.74% 15.56% 14.81% 9.40% 16.05% 6.67% 24.69% 4.27% 7.41% 0.00% 6.17% 3.42% 1.23% 100% 100% 100% 100%

F 37.50% 38.89% 9.72% 11.11% 2.78% 100%

Totals 32.41% 40.51% 13.19% 10.65% 3.24% 100%

600

N. Casellas

Both the debriefing sessions and the questionnaires offered very valuable information regarding the conceptualization of the OPJK ontology and its refinement. Nevertheless, neither the questionnaire and the evaluation results were easily exportable towards the evaluation of other ontologies, nor a systematic approach towards the evaluation of ontologies by experts was supported.

4 Usability Evaluation Experiment Therefore, as mentioned in Section 1, also at the end of the debriefing sessions, the experts were asked to answer a tailored version of the System Usability Scale (SUS) questionnaire, in order to evaluate the understanding and agreement felt by the legal experts regarding the Ontology of Professional Judicial Knowledge as a whole. The System Usability Scale, developed by [22], is a ten-item Likert scale (stating the degree of agreement or disagreement), elaborated initially to evaluate the usability of a system. The SUS score “yields a single number representing a composite measure of the overall usability of the system being studied” [22]. The use of this questionnaire is recommended by the UsabilityNet project website as “it is very robust and has been extensively used and adapted. Of all the public domain questionnaires, this is the most strongly recommended”. Also, in a comparsion between different questionnaires to assess website usability (the SUS was tailored to website evaluation) it was found that “one of the simplest questionnaires studied, [SUS], yielded among the most reliable results across sample sizes” [26]. The scale was, in this experiment, translated into Spanish and tailored to evaluate the understanding and acceptance of the contents of the ontology, regarding its purpose. The original sense of the questions was maintained as far as the tailoring allowed.6 For example, question 3: “I found the system was easy to use” was modifed by “I found the ontology easy to understand” (see Table 2). In this case, this legal expert’s validation plays a similar role to usability inspection for a software product [27]. Once the SUS score had been calculated, the overall results obtained with the SUS questionnaire were of the 69.44%, which suggested a high level of agreement with the general OPJK conceptualization. Furthermore, a comparison between the results obtained in the specific (ad hoc) and comprehensive OPJK questionnaire (72.92%) and the results of the SUS 10-item questionnaire (69.44%) shows a high degree of similarity. This may also suggest that the use of short but well-designed ontology evaluation questionnaire, based on the idea of usability questionnaires for software products, could offer rapid feedback and support towards the establishment of relevant agreement, shareability or quality of content measurements in expert-based ontology evaluation. 6

The original SUS questions are: 1) I think that I would like to use this system frequently, 2) I found the system unnecessarily complex, 3) I thought the system was easy to use, 4) I think that I would need the support of a technical person to be able to use this system, 5) I found the various functions in this system were well integrated, 6) I thought there was too much inconsistency in this system, 7) I would imagine that most people would learn to use this system very quickly, 8) I found the system very cumbersome to use, 9) I felt very confident using the system, and 10) I needed to learn a lot of things before I could get going with this system.

Ontology Evaluation through Usability Measures

601

Table 2. SUS Ontology Evaluation Questionnaire 1 2 3 4 5 1. I think that I could contribute to this ontology 2. I found the ontology unnecessarily complex 3. I find the ontology easy to understand 4. I think that I would need further theoretical support to be able to understand this ontology 5. I found the various concepts in this system were well integrated 6. I thought there was too much inconsistency in this ontology 7. I would imagine that most legal experts would understand this ontology very quickly 8. I found the ontology very cumbersome to understand 9. I am confident I understand the conceptualization of the ontology 10. I needed to ask a lot of questions before I could understand the conceptualization of the ontology

5 Conclusions and Further Work This paper outlines some evaluation activities of the Ontology of Professional Judicial Knowledge. Different purpose and ontological evaluative tasks were carried out, and favourable results were obtained by the analysis of the specification of requirements and competency questions, language conformity, and consistency checking. However, special interest was placed in the performance of a legal expert validation. This expert validation included both a specific validation of OPJK classes, subclass relationships, properties and instances and a more general and experimental validation based on a usability questionnaire, the System Usability Scale in particular. The results of these validations suggested that there was room for improvement regarding class conceptualization which could offer more granularity and foster understanding and shareability amongst experts. More importantly, the total results from both questionnaires showed a high degree of similarity, 72.92% and 69.44%, respectively, which may suggest that the use of a well-designed evaluation questionnaire (or a shareability questionnaire), based on the idea of usability questionnaires for software products, could offer support towards expert-based ontology evaluation and allow rapid (general) content validation. Currently, few ontology methodologies give precise guidelines or recommendations regarding ontology evaluation, especially, regarding the involvement of experts (or professionals) in ontological expert knowledge evaluation. The use of tailored usability methods for ontology evaluation could offer the establishment of certain quality measurements and aid the evaluation of modelling decisions, prior ontology implementation. Thus, as requirement specification, testing and producing end-user documentation are central to enhance the quality and usability of the resulting product, these humancentred steps may enhance the quality and sharedness of the resulting ontology.

602

N. Casellas

This approach will be further tested and evaluated in ongoing legal ontology engineering projects, which require the participation of experts and legal professionals in the knowledge acquisition, conceptualization and evaluation stages.

References 1. G´omez-P´erez, A.: Evaluation of ontologies. International Journal of Intelligent Systems 16(3), 391–409 (2001) 2. Sure, Y.: Methodology, Tools and Case Studies for Ontology Based Knowledge Management. PhD thesis, Fakult¨at f¨ur Wirschaftwissenschaften der Universit¨at Fridericiana zu Karlsruhe (2003) 3. Gr¨uninger, M., Fox, M.: Methodology for the Design and Evaluation of Ontologies. In: Proceedings of Int. Joint Conf. AI 1995, Workshop on Basic Ontological Issues in Knowledge Sharing (1995) 4. Velardi, P., Navigli, R., Cucchiarelli, A., Neri, F.: Evaluation of OntoLearn, a methodology for automatic population of domain ontologies. In: Buitelaar, P., Cimiano, P., Magnini, B. (eds.) Ontology Learning from Text: Methods, Evaluation and Applications. Frontiers in Artificial Intelligence and Applications Series, vol. 123. IOS Press, Amsterdam (2005) 5. Sclano, F., Velardi, P.: Termextractor: a web application to learn the common terminology of interest groups and research communities. In: Proceedings of the 9th Conference on Terminology and Artificial Intelligence (TIA 2007), Sophia Antinopolis (October 2007) 6. G´omez-P´erez, A., Fern´andez-L´opez, M., Corcho, O.: Ontological Engineering. In: With examples from the areas of Knowledge Management, e-Commerce and the Semantic Web. Advanced Information and Knowlege Processing. Springer, London (2003) 7. Hartmann, J., Spyns, P., Gibboin, A., Maynard, D., Cuel, R., Su´arez-Figueroa, M.C., Sure, Y.: D.1.2.3. methods for ontology evaluation. Deliverable IST-2004-507482 KWEB D.1.2.3., EU-IST Network of Excellence (NoE) Knowledge Web Consortium (January 2005) 8. Brank, J., Grobelnik, M., Mladenic, D.: D.1.6.1 ontology evaluation. SEKT IST-2003506826 Deliverable 1.6.1, SEKT, EU-IST Project Jozef Stefan Institute (June 2005) 9. Lozano-Tello, A., G´omez-P´erez, A., Sosa, E.: Selection of ontologies for the semantic web. In: Lovelle, J.M.C., Rodr´ıguez, B.M.G., Aguilar, L.J., Gayo, J.E.L. (eds.) ICWE 2003. LNCS, vol. 2722, pp. 413–416. Springer, Heidelberg (2003) 10. Gangemi, A., Catenaccia, C., Ciaramita, M., Lehmann, J.: Qood grid: A metaontology-based framework for ontology evaluation and selection. In: Vrandeˇci´c, D., del Carmen Su´arezFigueroa, M., Gangemi, A., Sure, Y. (eds.) Proceedings of the 4th International Workshop on Evaluation of Ontologies for the Web (EON 2006) at the 15th International World Wide Web Conference (WWW 2006), Edinburgh, Scotland, May 2006, pp. 8–15 (2006) 11. Guarino, N., Welty, C.: Evaluating ontological decisions with ontoclean. Communications of the ACM 45(2), 61–65 (2002) 12. Tartir, S., Arpinar, I.B., Moore, M., Sheth, A.P., Aleman-Meza, B.: OntoQA: Metric-based ontology quality analysis. In: Proceedings of IEEE Workshop on Knowledge Acquisition from Distributed, Autonomous, Semantically Heterogeneous Data and Knowledge Sources (2005) 13. Vrandeˇci´c, D., Sure, Y.: How to design better ontology metrics. In: Franconi, E., Kifer, M., May, W. (eds.) ESWC 2007. LNCS, vol. 4519, pp. 311–325. Springer, Heidelberg (2007) 14. Vrandeˇci´c, D., Gangemi, A.: Unit tests for ontologies. In: Meersman, R., Tari, Z., Herrero, P. (eds.) OTM 2006 Workshops. LNCS, vol. 4278, pp. 1012–1020. Springer, Heidelberg (2006)

Ontology Evaluation through Usability Measures

603

15. Benjamins, V.R., Casanovas, P., Contreras, J., L´opez-Covo, J.M., Lemus, L.: Iuriservice: An intelligent frequently asked questions system to assist newly appointed judges. In: Benjamins, V.R., Casanovas, P., Breuker, J., Gangemi, A. (eds.) Law and the Semantic Web. LNCS (LNAI), vol. 3369, pp. 201–217. Springer, Heidelberg (2005) 16. Casellas, N., Bl´azquez, M., Kiryakov, A., Casanovas, P., Poblet, M., Benjamins, V.R.: OPJK into PROTON: Legal domain ontology integration into an upper-level ontology. In: Meersman, R., Tari, Z., Herrero, P. (eds.) OTM-WS 2005. LNCS, vol. 3762, pp. 846–855. Springer, Heidelberg (2005) 17. Casellas, N., Casanovas, P., Vallb´e, J.J., Poblet, M., Bl´azquez, M., Contreras, J., L´opez-Cobo, J.M., Benjamins, V.R.: Semantic enhancement for legal information retrieval: Iuriservice performance. In: Proceedings of the Eleventh International Conference on Artificial Intelligence and Law. ICAIL 2007, Stanford Law School, California, June 4-8, pp. 49–57. Association for Computing Machinery (2007) 18. ISO: Human-centred design processes for interactive systems. ISO 13407:1999, International Organization for Standardization (1999) 19. ISO: Ergonomics of human-system interaction – usability methods supporting humancentred design. ISO Standard TR 16982:2002, International Organization for Standardization (2002) 20. ISO/IEC: Ease of operation of everyday products - part 1: Design requirements for context of use and user characteristics. ISO Standard 20282-1:2006, ISO/IEC (2006) 21. ISO/IEC: Software and system engineering - guidelines for the design and preparation of user documentation for application software. ISO Standard 18019:2004, ISO/IEC (2004) 22. Brooke, J.: Sus: A ’quick and dirty’ usability scale. In: Jordan, P.W., Thomas, B., McClelland, I.L., Weerdmeester, B. (eds.) Usability Evaluation In Industry, pp. 189–194. Taylor & Francis, London (1996) 23. Casellas, N.: Modelling Legal Knowledge Through Ontologies. OPJK: the Ontology of Professional Judicial Knowledge. PhD thesis, Faculty of Law, Universitat Aut`onoma de Barcelona, Barcelona (2008) 24. Casanovas, P., Casellas, N., Vallb´e, J.: An ontology-based decision support system for judges. In: Casanovas, P., Breuker, J., Klein, M., Francesconi, E. (eds.) Channelling the legal information flood. Legal ontologies and the Semantic Web. Frontiers in Artificial Intelligence and Applications, vol. 188, pp. 165–176. IOS Press, Amsterdam (2009) 25. Nielsen, J.: How to conduct a heuristic evaluation. Web (2005) (Available at 01-10-2008) 26. Tullis, T.S., Stetson, J.N.: A comparison of questionnaires for assessing website usability. In: UPA 2004: Connecting Communities, Minneapolis, Minnesota, June 7-11 (2004) 27. Nielsen, J.: Usability inspection methods. In: CHI 1994: Conference companion on Human factors in computing systems, pp. 413–414. ACM, New York (1994)

Semantically Enhanced Recommender Systems Manuela Ruiz-Montiel and Jos´e F. Aldana-Montes Departamento de Lenguajes y Ciencias de la Computaci´ on, University of M´ alaga, Espa˜ na {mruizmonti,jfam}@lcc.uma.es

Abstract. Recommender Systems have become a significant area in the context of web personalization, given the large amount of available data. Ontologies can be widely taken advantage of in recommender systems, since they provide a means of classifying and discovering of new information about the items to recommend, about user profiles and even about their context. We have developed a semantically enhanced recommender system based on this kind of ontologies. In this paper we present a description of the proposed system. Keywords: Ontologies, recommender systems, user modelling, personalisation.

1

Introduction

Recommender Systems aim to filter potentially useful items from a vast amount of data. We propose a family of Semantic Recommender Systems that, by means of domain ontologies describing both the users and the items, will enhance traditional approaches. Ontological reasoning allows the discovery of semantic features that play a very important role in the recommendation process, since they are the basic principles underlying the users’ choices. Moreover, the use of ontologies will help us to address some of the typical problems of recommender systems.

2

Semantic Recommender Systems

Traditional Collaborative Filtering algorithms proceed by calculating similarities between users or between items [1]. These similarities are based on the ratings the users have given to the items. In the first case (user based), a user will receive recommendations made up of the items that similar users liked best. In the second case (item based), the recommended items will be those that are similar to the ones that the user loved in the past. This latter approach is known to be more efficient, since the similarities can be calculated offline [2]. This type of recommender system has several problems, like the new user problem, the new item problem and the gray sheep problem [1]. The new user or item problem arise when a new user or item is stored in the system. A new user will not R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 604–609, 2009. c Springer-Verlag Berlin Heidelberg 2009 

Semantically Enhanced Recommender Systems

605

have made any previous evaluations about the items, so it will be difficult to compute his/her similarities with respect to other users; and a new item which has no ratings will have the same problem. The gray sheep problem arises when nobody likes an item, so it will not be recommended, though it is possible that some users may like it. If semantic features are taken into account, then the similarities could be computed according to them. Indeed, the semantic features are the underlying reasons for the items or users to be similar or not. Moreover, the problems that arise when we compute the similarities in a collaborative way, now disappear. On the other hand, Content Based Recommender Systems make recommendations considering the items’ and users’ semantic features[1]. The items recommended to a given user will be those whose features match a computed user profile. These recommender systems are a perfect area in which to include ontologies, since they are based on the semantics. Our approach for developing a new family of recommender systems is based on domain ontologies containing the semantic attributes both for items and users. We use OWL ontologies and a reasoner able to classify the described resources. 2.1

Related Work

Middleton, De Roure and Shadbolt have developed a recommender system based on an ontology which constitutes an is-a hierarchy of paper topics, in order to infer more accurate user profiles according to the categories within the taxonomy [3]. Mobasher, Jin and Zhou have taken advantage of an item ontology, which is part of the schema for a relational database, in order to compute similarity correlations between items [2]. Wang and Kong also use an ontology to calculate the correlations between items, and they use a very similar algorithm to the one we present in this paper; but they do not use the ontology to infer the semantic features, since they explicitly specify them [4]. In [5] and [6], the authors also propose the use of semantic descriptions of items and user profiles. In [7], the authors demonstrate that taking into account the underlying semantics in recommender systems leads to better results. We propose the use of semantically rich ontologies (and not only hierarchies) in order to automatically infer implicit information of the items to recommend and the users looking for items, so we can take advantage of it and make more accurate recommendations. Our ontologies have been made manually, gathering information from the tourism domain. 2.2

Domain Ontologies

We have developed two main ontologies. The first one, called the Item Ontology, describes the items according to several criteria depending on the specific domain. The second one is the User Ontology, which classifies the users according to personal data provided such as gender, age or occupation. This ontology will infer new users’ preferences with respect to their personal data. In our case (tourist services), the preferences will be related to different areas such as price, situation or quality.

606

M. Ruiz-Montiel and J.F. Aldana-Montes

The Item Ontology: An Example. We have developed an ontology in the tourism domain, classifying the items in categories such Inexpensive Service, High Quality Service, and many other more traditional ones such as Restauration Service or Accommodation Service. The hierarchy does not end at this first level, but it still continues refining other aspects of each category. E.g., inside ’Accommodation Service’ we can find classes like Charming Accommodation Service. Each point of interest described in the ontology will be member of a set of categories, which will mould the semantic profile of the item. Let us consider a point of interest described in the Item Ontology. Initially, the item only belongs to the class Tourist Service, but two basic features have been asserted: the item has an average price of 20 euros for the set menu and its speciality is the lobster. The ontology will infer that this point of interest belongs to several categories: Restauration Service, Expensive Service and Savoury Food Service. These categories mould the semantic profile of the item. The User Ontology: An Example. The User Ontology is designed depending on the item domain. Nevertheless, the user ontologies for different item domains will have several features in common, i.e., personal data properties: gender, age, interests, etc. The diference between the ontologies will reside in the preferences inferred. The User Ontology will import the terms defined in the Item Ontology, since the user and the item profiles must be calculated with respect to exactly the same domain. In our tourist example, we have defined some classes describing users and their respective preference assumptions. For example, the users in the Young User category, will prefer Young-oriented tourist services. 2.3

Semantic Filtering Recommendation

In Collaborative Filtering Systems, the recommendation process is based on similarity calculation between users or items. The first approaches were implemented with user-user similarity, computed by correlations [1] over the rating vectors. The principal shortcoming of this philosophy is the fact that these vectors are not static: they change continuously and the similarities cannot be computed offline. The recommendation process is neither efficient nor scalable, since the complexity is exponential with respect to the number of users. On the other hand, approaches based on item-item similarities [8,9] have turned out to be more efficient and scalable. The similarities of items are naturally more static than similarities between users, so their computation can be done offline [2]. A great advantage is the fact that now we can take other sources of information into account, different from the rating vectors, i.e., models for the items that include their semantic features. Recommendation Process. Let us imagine there is a user in the system who has rated several items. Some of the ratings will be positive and others will be negative. If we take into account the positive ones, we can gather a set of wellrated items from which to calculate neighborhoods. Given a well-rated item, its

Semantically Enhanced Recommender Systems

607

neighborhood is the set of the n most similar items in the system. The similarity between two items is calculated as follows:  |SIP (i) SIP (j)| simi,j = max(|SIP (i)| , |SIP (j)|) Where SIP (i) is the Semantic Item Profile of the item i, calculated by means of the Item Ontology -i.e, it is the set of semantic categories the item i belongs to. Note that similarities range from 0 to 1. Once we have computed all the neighborhoods of the well-rated items, we recommend those items in the union of all the neighborhoods that satisfy the next two conditions: the item has not been used by the selected user and the Recommendation Factor is bigger than a certain number, called Recommendation Threshold, which is a measure of how good the recommendation will be for an user. It is calculated as follows: RF (i) = r(f ather) ∗ simi,f ather Where father is the item from which the neighborhood was calculated. If an item belongs to more than one neighborhood, then we take into account the biggest factor of all the possible recommendations. The Recommendation Threshold that we use to filter the items depends on the ratings domain. If the maximum rating is, e.g., 5 points, then we can consider a threshold of 3. This implies that the similaritiy of the recommended item with respect to its father must be bigger than 3/5 in order to be recommended. If the father has a rating of 4 points (out of 5), then the similarity must obviously be greater than 4/5: if the father has a lower rating, then the similarity has to be stronger in order to make the item a good recommendation. Nevertheless, this number may be parametrized depending on the number of recommendations we want to compute. Even if we do not consider any threshold, the items can be ordered according to the Recommendation Factor and we can take the first n items of this list. Using this method we avoid the new item problem, since we do not need the ratings of the recommended items; as well as the gray sheep problem, because we focus on all the posible items in the system, computing their similarities. Nevertheless, the new user problem still remains: if the user has not given any rating, then the neighborhoods cannot be calculated. 2.4

Content Based Semantic Recommendation

Another family of Recommendation Systems are Content Based approaches. They share in common a means for describing both the items and the users, and a technique for comparing the items to the user profile [1]. Obviously, our means for describing both the items and the users will be the domain ontologies described in previous sections. The user profile is a combination of two sources of information: the User Ontology and the record of ratings the user has given to the used items. Through the User Ontology we can extract a semantic profile in a similar way to how we computed the Semantic Item Profile. So this profile is a set of categories the

608

M. Ruiz-Montiel and J.F. Aldana-Montes

user belongs to, given his/her personal data such age, occupation, interest, etc. But we have another very powerful source of information: the ratings the user has given to the items he or she has used. We can aggregate the item profiles of the well-rated items, so we can mould a map of semantic categories, each one of them accompanied by a number indicating its importance. This importance will grow if the category refers to more than one well-rated item, and it will also rise if the well-rated items have better ratings. If we mix this map with the semantic profile extracted from the User Ontology, we can consider the result as an accurate Semantic User Profile (SUP ) of the selected user. The recommendation process. Now we have computed the SUP, we can recommend items to the user. The items will be recommended if they fulfill both following conditions: the item has not been used by the selected user and the Semantic Correspondence between the SIP (Semantic Item Profile) and the SUP is bigger than a certain number, called Recommendation Threshold. The Semantic Correspondence (SC ) is calculated as a ponderate product of the SIP and the SUP. The pseudocode is as follows: SC := 0 for (profileElement in SIP){ if (profileElement belongs to SUP){ SC := SC + importance(profileElement, SUP) } } The Recommendation Threshold is a number that depends on the importance factors that we gave to the different elements of the Semantic User Profile, and also depends on the average numbers of profile elements in the Semantic Item Profiles. If in these profiles there is an average number of I elements, and the importance factors move from 0 to 100, then (I/2)*75 (half the features with a good importance) could be a good threshold in order to recommend an item or not. Nevertheless, this number may be parametrized. Even if we do not consider any threshold, the items can be ordered according to the Semantic Correspondence. Using this method we avoid the new user problem, since we can obtain a simple user profile from his or her personal data. Nevertheless, the more items the user rates, the more accurate the computed profile is. With respect to the new item and gray sheep problems, both are addressed since we focus on all the items of the system, computing their Semantic Correspondence with the Semantic User Profile.

3

Conclusions and Future Work

Semantics and ontologies are a powerful tool for improving the performance of recommender systems, since they allow us to avoid some of the typical problems normally involved in this kind of process. Moreover, when we talk about similarities or correspondence between items or item-user, we are really referring to the

Semantically Enhanced Recommender Systems

609

semantics beneath the users and the items. We have developed two Semantically Enhanced Recommender Systems based on two different ontologies: the Item Ontology and the User Ontology, in order to discover user and item profiles. A Context Ontology could be included in this kind of recommender systems, since contextual information is very powerful in some situations in order to filter the available items. Moreover, an evaluation of these semantic enhanced algorithms with respect to traditional approaches needs to be done, in terms of precision and recall and some other semantic-specific criteria. Acknowledgments. This work was supported by the ICARIA Project Grant (Excellence Project, Innovation, Science and Enterprise Ministry of the regional government of the Junta de Andaluc´ıa), TIN2008-04844 (Spanish Ministry of Education and Science), Proyecto Piloto Formaci´ on y desarrollo de tecnolog´ıa aplicada a la biolog´ıa de sistemas, P07-TIC-02978 (Innovation, Science and Enterprise Ministry of the regional government of the Junta de Andaluc´ıa) and the project Creaci´ on de un soporte tecnol´ ogico para un sistema de informaci´ on tur´ıstica, FFI 055/2008 (Tourism, Sport and Commerce Ministry of the regional government of the Junta de Andaluc´ıa).

References 1. Adomavicius, G., Tuzhilin, A.: Toward the Next Generation of Recommender Systems: A Survey of the State-of-the-Art and Possible Extensions. IEEE Trans. Knowl. Data Eng. 17(6), 734–749 (2005) 2. Mobasher, B., Jin, X., Zhou, Y.: Semantically Enhanced Collaborative Filtering on the Web. In: Berendt, B., Hotho, A., Mladeniˇc, D., van Someren, M., Spiliopoulou, M., Stumme, G. (eds.) EWMF 2003. LNCS (LNAI), vol. 3209, pp. 57–76. Springer, Heidelberg (2004) 3. Middleton, S.E., Shadbolt, N., De Roure, D.: Ontological user profiling in recommender systems. ACM Trans. Inf. Syst. 22(1), 54–88 (2004) 4. Wang, R.-Q., Kong, F.-S.: Semantic-Enhanced Personalized Recommender System. In: International Conference on Machine Learning and Cybernetics, vol. 7, pp. 4069– 4074 (2007) 5. Liu, P., Nie, G., Chen, D.: Exploiting Semantic Descriptions of Products and User Profiles for Recommender Systems. Computational Intelligence and Data Mining, 179–185 (2007) 6. Ziegler, C., Schmidt-Thieme, L., Lausen, G.: Exploiting semantic product descriptions for recommender systems. In: Proc. 2nd ACMSIGIR SemanticWeb and IR WS (2004) 7. Moshfeghi, Y., Agarwal, D., Piwowarski, B., Jose, J.M.: Movie Recommender: Semantically Enriched Unified Relevance Model for Rating Prediction in Collaborative Filtering. In: Boughanem, M., et al. (eds.) ECIR 2009. LNCS, vol. 5478, pp. 54–65. Springer, Heidelberg (2009) 8. Linden, G., Smith, B., York, J.: Industry Report: Amazon.com Recommendations: Item-to-Item Collaborative Filtering. IEEE Distributed Systems Online 4(1) (2003) 9. Deshpande, M., Karypis, G.: Item-based top-n recommendation algorithms. ACM Trans. Inf. Sys. 22(1), 143–177 (2004)

Photo-Based User Interfaces: Picture It, Tag It, Use It Geert Vanderhulst, Kris Luyten, and Karin Coninx Hasselt University – transnationale Universiteit Limburg – IBBT Expertise Centre for Digital Media Wetenschapspark 2, 3590 Diepenbeek, Belgium {geert.vanderhulst,kris.luyten,karin.coninx}@uhasselt.be

Abstract. Pervasive environments can be hard to configure and interact with using handheld computing devices, due to the mismatch between physical and digital worlds. Usually, smart resources in the user’s vicinity are discovered and presented in a menu on the user’s device from where they can be accessed. However, in environments with many embedded resources it becomes hard to identify resources by means of a textual description and to get aware of the tasks they support. As an alternative to menu-driven interfaces, we demonstrate annotated photos as a means for controlling a pervasive environment. We present as part of our approach a tool that enables people to picture their own environment and use photos as building blocks to create an interactive digital view on their surroundings. To demonstrate and evaluate our approach, we engineered a pervasive prototype application that is operated through a photo-based user interface and assembled using ontologies.

1 Introduction Many new embedded computing resources and networked appliances that hit the market try to offer simple access to their functionality by minimizing the set of physical controls. As a consequence, these devices rely on digital user interfaces that migrate to personal devices from where they can be operated and configured by a remote user interface. Such computer interfaces, driven by pervasive services and weaving into the fabric of everyday life, give rise to a pervasive computing environment [8]. Moreover, in the vision of the Internet of Things [1] almost any object becomes part of a computer network which demands for proper ways to control all these objects. Awareness of the environment and its resources is key for efficient interaction. Service discovery frameworks such as UPnP1 and directory services provide methods to discover and use pervasive services, but only return limited information about these services. A more advanced approach integrates computer-enabled resources along with the tasks they support in a meta-user interface [2,6]. This user interface is ‘meta’ because it acts as an interface for accessing other, application-specific user interfaces from a menu. However, when the number of resources that are embedded in a pervasive environment increases, it becomes more difficult for end-users to locate them in a menu and to differentiate between similar resources based on a description. To overcome the complexity of pervasive environments we propose photo-based user interfaces that can 1

http://www.upnp.org/

R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 610–615, 2009. c Springer-Verlag Berlin Heidelberg 2009 

Photo-Based User Interfaces: Picture It, Tag It, Use It

611

be created by end-users themselves. We believe interactive photos are a useful instrument to make immobile and invisible resources such as lights and media services (e.g. represented by speakers on a photo), easily accessible in the digital world. In this paper we present a software framework that enables users to picture an environment and use photos to interact with their surroundings. Our contribution is the conjunction of tool support for photo-based user interfaces and a semantic binding between interface and back-end. First we introduce Photoporama, a tool for annotating photos by tagging the things of interest that appear on a photo. Second, we illustrate, using a prototype application, how ontologies help to glue interactive photos and pervasive services together.

2 Related Work Strategies for annotating photos with semantic information have been widely studied. Various approaches use context-descriptive keywords or visual similarity for annotating photos (semi-)automatically. Guus et al. propose a subject matter ontology to describe the vocabulary and background knowledge of a photo’s subject domain [3]. Instead, we annotate the objects that appear on a photo individually and use ontologies to connect objects with application logic. Facebook2 applies a similar approach to mark people on photos and Flickr3 supports notes that can be attached to regions drawn on a photo. By adopting familiar tagging methods, Photoporama enables non-expert users to create semantically enriched photos that serve as a user interface to steer pervasive applications. The use of photos to discover and interact with pervasive services has been suggested before in [4]. In this work, a ‘u-Photo’ is tagged with eyemarks: physical entities that appear on a photo and that represent a pervasive service. Whereas u-Photo uses visual markers as tags for eyemarkers, Photoporama links objects that appear on a photo with richer semantics using the WordNet lexicon. This allows us to connect objects on a photo with services in the environment: the user can interact with the photo to access, configure and operate related services.

3 A Semantic Photobook We define a photobook as a set of digital images, including camera captured photos as well as fabricated images such as a floorplan. Each photo in a photobook is enriched with information about the objects that appear in the photo and references to other photos. For example, a door on one photo could refer to a photo showing the room behind that door. Hence one can browse through a photobook in a similar way as navigating a web page. We provide the Photoporama toolkit4 to create photobooks and ease the integration of a photo-based user interface in a pervasive application. Annotating a photo involves two steps. First, different objects that are related to the usage of pervasive services are identified in the photobook and assigned a number 2 3 4

http://www.facebook.com/ http://www.flickr.com/ http://research.edm.uhasselt.be/photoporama/

612

G. Vanderhulst, K. Luyten, and K. Coninx

of keywords. For example, the piano in figure 1 is tagged as a piano in the sense of ‘a keyboard instrument’. Photoporama uses the WordNet dictionary to disambiguate between the different senses a word might have. The user selects the word sense she has in mind from a list and attaches it as a tag to the object. The second step consists of marking the objects identified in the first step on a photo. This is achieved by drawing a rectangular area on a photo and linking this area with an object, similar to tagging people in Facebook. Hence different photos can link to the same objects while they differ in e.g. viewing angle, distance to the subject, level of detail, etc. Bringing together different photos and objects in a digital photobook demands for efficient searching strategies. A tag cloud, composed of the various annotations on a photo and weighted by their frequency in the photobook, allows users to quickly navigate to objects and browse through photos. Moreover, the linguistic relations that apply between words such as synonyms and hypernyms – ‘is a’ relationships, e.g. ‘musical instrument’ is a ‘hypernym’ for ‘piano’ – are exploited to search for available objects.

4 Engineering Photo-Based Applications In this section we discuss the process of designing a photo-based user interface for a pervasive application. We have built a prototype application that displays scores for a piece of music on a screen or wall surface. A ‘score service’ takes as input a piece of music and a musical instrument which identifies the type of scores – piano scores differ from e.g. guitar scores. When a score service receives input, it searches for corresponding scores in a shared database and renders them on the local device. The user can then remotely navigate through these scores via a distributed user interface. We designed a photo-based user interface to operate the application and linked it with the pervasive score services by means of an ontology as depicted in figure 1. In our test environment, we deployed two score services, one running on a computer attached to a projector and another one on a notebook connected to a television set. We

Fig. 1. A piano is marked and annotated on a photo. According to WordNet, a piano in the sense of a keyboard instrument is a musical instrument, which is linked with a domain ontology.

Photo-Based User Interfaces: Picture It, Tag It, Use It

(a)

613

(b)

Fig. 2. Interacting with a photo-based user interface running on a UMPC (a) pops up a migrated user interface to steer the projection of scores above a piano in the physical world (b)

used a UMPC with the ReWiRe [7] service platform pre-installed and the Photoporama toolkit to steer services using a photo-based user interface as shown in figure 2. Two musical instruments, a piano and a double bass, were marked on a photo and annotated using WordNet. When a user selects an instrument, the ontologies that describe the pervasive environment are queried and a navigate scores task is found and listed in a menu on the photo. When invoked, one is presented with a user interface that displays the selected instrument type (e.g. piano or bass) and asks for a preferred output device for displaying the scores for a piece of music. This input is then passed to the score service on the selected output device that renders the scores which she can navigate from her UMPC. To enhance navigating scores while playing an instrument, the navigation buttons are rendered ten times their original size so that they can easily be tapped. 4.1 Pervasive Services as Back-End As back-end, we use the ReWiRe framework to create and deploy dynamic pervasive services. The ReWiRe platform runs on the computing devices that give rise to the pervasive environment and employs a centralized runtime environment model which is shared amongst devices. In this environment model, ontologies describe the environment’s topology and instances of these ontologies represent the environment’s current state. An upper ontology defines a number of generic concepts and is merged with domain-specific ontologies at runtime. Figure 1 shows a domain ontology for the score application which is imported into the environment model when a score service is deployed. It shows that a ‘musical instrument’ supports a ‘navigate scores task’ which is presented by a corresponding user interface. Note that tasks – defined as executable user processes using the Web Ontology Language (OWL)5 – are essential to describe the goals the end-user can achieve in the environment while services are functional components a task relies on. 5

http://www.w3.org/2004/OWL/

614

G. Vanderhulst, K. Luyten, and K. Coninx

4.2 Photos as User Interface When used as a user interface, a set of photos replaces the windows, dialogs and other widgets found in traditional form-based user interfaces. The objects marked on a photo become interactive parts which allow to navigate through photos or manipulate the state of objects in the environment, displayed on a photo. To simplify the integration of a photo-based user interface within an application, Photoporama treats photos as user interface widgets with their own interaction events. We used Photoporama to create a meta-user interface on top of the ReWiRe framework. Hence annotated photos become a means to interact with the pervasive environment. When an annotated object on a photo is selected, one is presented with supported tasks in a context-sensitive menu. Selecting a task then results in a user interface being displayed to interact with one or more services related to the selected object. 4.3 Ontologies as Glue In order to link objects on a photo with resources in the pervasive software system, we use ontologies as a binding between the user interface and the application logic. Moreover, WordNet is used to mediate between Photoporama tags and ReWiRe domain ontologies. This is achieved by mapping a word sense on its corresponding OWL individual as discussed in [5] and mapping concepts in a domain ontology on WordNet individuals via OWL’s built-in “equivalentClass” property. In practice, a domain ontology designer must link the OWL classes he creates with WordNet while an end-user simply has to tag her photos to realize these bindings. Hence, by observing an object’s tags, its corresponding resource class(es) in the pervasive system can be semantically resolved along with a list of tasks that are supported by this type of resource. For example, the piano in figure 1 supports a ‘navigate scores task’ because it relates with the ‘musical instrument’ concept defined in the domain ontology. According to WordNet, ‘musical instrument’ is a hypernym of ‘piano’ and thus matches with the ‘musical instrument’ concept defined in the domain ontology which is denoted equivalent with a WordNet ‘musical instrument’ by the ontology designer. In our prototype application tasks are derived based on classes of resources; any musical instrument can be played using scores. However, if multiple instances of a resource exist (i.e. a piano in the living room and a piano in the hall), additional information is required to differentiate between similar resources. This is particularly the case for stateful computer-augmented resources such as the light on the piano: a specific light serves as input for a service that steers the lights in an environment. In this situation, it is useful to tag the piano light with a reference to its representation in the pervasive software framework, e.g. through a URI that differs in namespace from WordNet tags.

5 Discussion We believe a major advantage of our approach is the loose coupling between user interface and pervasive services: a software developer creates services and designs domain ontologies mapped on WordNet, an end-user pictures her own environment the way she likes it and annotates her photos using the Photoporama tool; assembly happens at

Photo-Based User Interfaces: Picture It, Tag It, Use It

615

runtime. Awaiting a more formal evaluation, our first experiments with Photoporama already surfaced a number of enhancements. Currently, the state of the environment (e.g. is a light switched on or are scores projected?) can be observed in the digital world using application-specific user interfaces, but it would be nice if photos directly provide feedback about the real world. This can be achieved by introducing a ‘state layer’ in Photoporama with semi-transparent or animated images connected to resource properties in ReWiRe, such as a yellow glow around a light or musical notes to indicate that scores are being projected. Furthermore, photos can be a useful instrument to help users manually allocate resources for pervasive services by selecting them on a photo. Acknowledgments. Part of the research at EDM is funded by ERDF (European Regional Development Fund), the Flemish Government and the Flemish Interdisciplinary Institute for BroadBand Technology (IBBT).

References 1. ITU Internet Reports 2005. The Internet of Things, http://www.itu.int/osg/spu/publications/internetofthings/ 2. Coutaz, J.: Meta-User Interfaces for Ambient Spaces. In: Coninx, K., Luyten, K., Schneider, K.A. (eds.) TAMODIA 2006. LNCS, vol. 4385, pp. 1–15. Springer, Heidelberg (2007) 3. Schreiber (Guus), A.T., Dubbeldam, B., Wielemaker, J., Wielinga, B.: Ontology-Based Photo Annotation. IEEE Intelligent Systems 16(3), 66–74 (2001) 4. Suzuki, G., Aoki, S., Iwamoto, T., Maruyama, D., Koda, T., Kohtake, N., Takashio, K., Tokuda, H.: u-photo: Interacting with pervasive services using digital still images. In: Gellersen, H.-W., Want, R., Schmidt, A. (eds.) PERVASIVE 2005. LNCS, vol. 3468, pp. 190– 207. Springer, Heidelberg (2005) 5. van Assem, M., Gangemi, A., Schreiber, G.: Conversion of WordNet to a Standard RDF/OWL Representation. In: Proceedings of the 5th International Conference on Language Resources and Evaluation (LREC 2006), Genova, Italy (2006) 6. Vanderhulst, G., Luyten, K., Coninx, K.: Put the User in Control: Ontology-Driven Meta-level Interaction for Pervasive Environments. In: Proceedings of the 1st International Workshop on Ontologies in Interactive Systems (ONTORACT 2008), pp. 51–56. IEEE Computer Society, Los Alamitos (2008) 7. Vanderhulst, G., Luyten, K., Coninx, K.: ReWiRe: Creating Interactive Pervasive Systems that cope with Changing Environments by Rewiring. In: Proceedings of the 4th IET International Conference on Intelligent Environments (IE 2008), pp. 1–8 (2008) 8. Weiser, M.: The Computer for the 21st Century. Scientific American, 94–104 (1991)

Ontology Based Proactive Design and Patterns towards the Adaptability of Knowledge Management Systems Yinglin Wang1 and Zheying Zhang2 1

Department of Computer Science and Engineering, Shanghai Jiao Tong University, 800 Dongchuan Road, Shanghai 200240, China [email protected] 2 Department of Computer Sciences, University of Tampere, FIN-33014, Finland [email protected]

Abstract. Knowledge management in large enterprises is composed of complex processes through which knowledge items are created, collected, evaluated and interconnected before they can be reused later. The challenge is how to cope with the different requirements of knowledge management systems, especially over times. The paper proposes a four level abstraction framework for modeling the commonalities and differences of knowledge management systems to cope with the possible changes in the future. Based on an ontology schema, the metameta model is given via combining the OSM model with task models and the commonalities from variability analysis. Then, the knowledge organization pattern, state diagram and task patterns are analyzed. The requirements and future changes are proactively modeled using patterns or variability models, so that the adaptability can be achieved through configuration by end-users in the deployment and runtime phases. Keywords: knowledge management system, software reuse, ontology.

1 Introduction Knowledge management systems are supposed to help people in the processes of the creation, capture, evaluation, retrieval and reuse of knowledge [1]. Just like Enterprise Information Systems (EIS) dealing with general data, knowledge management systems deal with knowledge items across all functional levels and management hierarchies and provide services coordinating organizational business processes [2]. Due to the increasing size and complexity of organizations and the business processes, meeting high stakeholders’ expectations in a timely and a cost effective manner in an ever-changing and highly open dynamic turbulence environment is an essential goal of all information systems development [3],[4]. However, due to the intrinsic contradiction between the volatile requirements and the rigid software structure, trying to build adaptable systems is a great challenge. To overcome the difficulties, the abstraction strategy and patterns of generalized tasks in the collaborative knowledge management processes should be studied. Aiming at building adaptable system architectures which facilitate runtime configuration of KM systems in accordance with the changing organizational needs R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 616–621, 2009. © Springer-Verlag Berlin Heidelberg 2009

Ontology Based Proactive Design and Patterns

617

and stakeholders’ expectations, in this paper we propose a proactive adaptable knowledge management framework, which is based on ontologies and combines the object system model(OSM) with the task schema model. The task model of lifecycle collaborative knowledge management and the way of combining the unstructured and structured knowledge is discussed.

2 The Methodology In order to achieve the objective, this study spans mainly two phases of KM system development, e.g. the requirements phase and the design phase, and covers four levels of abstraction, as shown in Fig. 1. Definition of the four levels of abstraction follows the architecture of the ISO IRDS (Information Resources Dictionary Standard (ISO 1990)) [5]. • The application level includes application data and program execution. It is a concrete presentation of an application. An example of information at this level would be a MS Word file, or a design case saved in a knowledge management system. • The model level includes any intermediate specifications of the business processes and work flows. An example would be the definition of different file types, process templates, and functions templates that are used in a knowledge management system. • The meta-model level specifies the languages in which specifications on the model level are expressed. The generic task types such as selection, identify can be used to represent the elements in the model level. It may also contain the specification of possible generalizations of the model level. • Finally, the meta-meta-model level specifies how the meta-model level objects and concepts can be described and interlinked. It contains an abstract aggregated conceptualization of the related application domain. In our study, the ontology of EIS presents the concepts and their relations which are aggregations of the elements of the meta-model. Ontology of EIS

Variabilitymeta-model

--- Meta-metamodel level

General architecture

Variability model

Application architecture

Features in applications

Applications

--- Metamodel level

--- Model level

--- Application level

Fig. 1. Four levels of abstraction of system implementation

618

Y. Wang and Z. Zhang

The bi-directional arrows illustrate the instantiation and abstraction relationships between models on the consequent abstraction levels. Horizontal arrows present the possibility to map requirements on to the system architectural design. The mapping occurs on every abstraction level.

3 The Meta-meta-Model of Adaptable KM Systems It is reasonable to expect that 60 to 70 percent of a software application’s functionality is similar to the functionality in other software applications, and that 40 to 60 percent of its code, and 60 percent of its design, is reusable in other applications [6]. KM systems have commonality to represent, record, control and compute the objects (e.g., organizations, people, machines and equipments, facilities, products, events and knowledge, etc.) and their interactive behaviors in each application function. The commonalities between different KM systems could be generalized as a reference framework (Fig. 2) and be reused. To model the commonalities, we combines the previous research results of object system models (OSM), task schema model described in the domain theory [7], and other required elements together. The framework in Fig. 2 can be regarded as the specification of the meta-meta model level of EIS. It specifies and implements the most abstract concepts, relations

goal

state

achieve

implemented by process

contain control

is-a

have

contain organize task

have

use

use

generate

pre-condition

induce

post-condition event

starting ending

interface

algorithms /programs

object have

is-a

is-a

agents is-a

people

have

act-on

participate use

state transform

data

is-a knowledge

is-a machine/equipment

use/create/modify

support ontology schema

Fig. 2. The meta-meta model used for adaptable KM systems

property

Ontology Based Proactive Design and Patterns

619

and functions for every kind of EISs. These abstract elements can be used as a good starting point for reifying the specific domains and applications. As Fig. 2 shows, any operations of enterprises are related to one or several goals. Each goal can be implemented by one or more processes, and each process will contain several tasks which can be organized in certain sequential or concurrent relationships. The preconditions should be met before the execution of each action which is executed by authorized agents. At the same time, the actions will trigger certain events and may change the state of key objects. These concepts and their relations reflect a common pattern of EIS, including KM systems as the specialization. They can be further refined at the meta-model and model levels through specialization. Moreover, other common elements obtained through variability analysis phase can be added to enrich the framework. The ontology schema in Fig. 2 is an infrastructure to describe the concepts and relationships of the domain.

4 Patterns in Collaborative KM Processes A body of formally represented knowledge is based on a conceptualization or ontology: the concepts, and other entities that are assumed to exist in some area of interest and the relationships that hold among them [8]. In fact, every KM system is committed to some ontology and an ontology may be changed in the future. Hence, when the ontology is represented explicitly, the system can be easily adapted if the change of ontology is required in the future. To represent domain ontologies, we should use a most general ontology language, or ontology schema. 4.1 Ontology Schema and Patterns for Knowledge Representation The ontology schema includes five kinds of elements: set of classes (concepts), set of enumeration types, set of relations between concepts, set of relations between instances of concepts, and set of axioms. For details of the ontology schema, please refer to the paper [9]. Different with other ontology language, we introduce static properties in the class (concept) representation. Definition 1: A static property is a property that has the same value for all the objects of the class. A property is normal if it is not static. For instance, in a mechanical design scenario, a class named "bearing for shaft" may contain a static property whose value is a text description like: "A bearing is a device to allow constrained relative motion between two or more parts, typically rotation or linear movement". And it may have a static property whose value is a figure which is used to describe the semantic meaning of each parameter that will be used in the description of the instances. We represent knowledge in a four level of abstractions in Fig. 3. At the meta-meta levels, knowledge is an aggregation of all kinds of knowledge in applications, and as the most abstract type it reflects the intension of knowledge and the relationships with other elements. At the meta-model level, more specific types of knowledge emerges, reflect some constructs of knowledge, such as the domain concepts, rules or formulas, cases, and processes to conduct some tasks. At the model level, the format of each type at the meta-model is given and used directly for the coding of the system.

620

Y. Wang and Z. Zhang

knowledge

domain concepts

rules

table format

if-then format

Specific rules

…

cases

--- Meta-metamodel level processes

free-text format

--- Metamodel level

--- Model level --- Application level

….

Fig. 3. The four level of knowledge organization

The specific rules and their structure, e.g., the parameters (i.e., properties) and the values, are configured at the application level by end-users. For instance, the structure (the parameters) of a rule for an object or related objects (e.g., a kind of mechanical part) can be defined in the table format as a class in the domain ontology, and then it is used to represent the permitted relationships of the parameters through a set of instances. 4.2 Task Patterns of Collaborative Knowledge Management The goal of KM systems can be fulfilled by a series of activation and execution of tasks. In KM systems, tasks can be categorized as types of knowledge collection, knowledge evaluation, knowledge retrieval, knowledge activity statistics, etc. For represent the correctness or useful of knowledge items, several states from personal information to enterprise knowledge are used. The knowledge processing tasks will be organized to evaluate the states of the knowledge items. The states of the knowledge items in the process of knowledge management can be generally classified into two kinds: "personal", or "enterprise". Knowledge items of state "enterprise" can be further classified into states of "quasi-knowledge", "knowledge", "rejected", "obsolete", and "processing". The state "processing" can be classified further into "evaluating", "modifying", "deleting", etc. The state transition diagram of a knowledge item is shown in Fig. 4, which is generalized from different applications and thus can be reused as patterns in building knowledge management systems. Moreover, task patterns can be modeled on the state diagram by specifying the preconditions, post-conditions and action sequences. As the abstraction of knowledge and the tasks, the generalized patterns can be reused to cope with many

start personal

evaluating

modifying obsolete

quasi-knowledge

rejected

knowledge

deleting

Fig. 4. The state diagram of a knowledge item in its lifecycle

Ontology Based Proactive Design and Patterns

621

specific cases that have the same features, while the differences are modeled as variants for configurations by end users.

5 Discussions Through the four level of abstraction proposed for knowledge management systems, some of the commonalities and variability were found and they can be reused for handling changes in the future. For instance, the changes of domain ontology and the processes (such as adding new classes, modifying exist classes, redefining processes for an kind of knowledge) can be done directly by users without any coding if no new functions are required. The meta-meta model provide the infrastructure that is not likely to change. At the meta-model level, some generic tasks, such as identify, select and search an object, are modeled. The generic tasks can be used to construct the compound tasks, such as evaluation of knowledge items, at the model level. Because of the limited space, the task patterns could not be given in detail, which will be disscussed further in our next paper. Acknowledgments. Thank the National High Technology Research and Development Program of China (Grant No. 2009AA04Z106), the Natural Science Funds of China (Grant No. 60773088) and the National Basic Research Program (Grant No. 2003CB317005) for financially supporting this research.

References 1. Birkenshaw, J., Sheehan, T.: Managing the Knowledge Life Cycle. MIT Sloan Management Review 44(1), 75–83 (2002) 2. O’Brien, J.A., Marakas, G.M.: Enterprise Information Systems. McGraw-Hill Education, New York (2007) 3. Liu, Y., Zhang, Z.: Stakeholder-Centered Requirements Elicitation: A View from User Research. In: 7th International Conference on Perspectives in Business Information Research 2008, Gdansk, Porland, pp. 25–26 (2008) 4. Perrone, V., Bolchini, D., Paolini, P.: A Stakeholders Centered Approach for Conceptual Modeling of Communication-Intensive Applications. In: SIGDOC 2005: Proceedings of the 23rd annual international conference on Design of communication, pp. 25–33. ACM, New York (2005) 5. ISO (1990) ISO-IEC 10027. Information Technology – Information Resource Dictionary System (IRDS) –Framework, ISO/IEC International Standard (1990) 6. McClure, C.: Software Reuse: A Standards-Based Guide. IEEE Computer Society, Los Alamitos (2001) 7. Sutcliffe, A.: The Domain Theory: Patterns for Knowledge and Software Reuse. Lawrence Erlbaum Associates Publishers, New Jersey (2002) 8. Genesereth, M.R., Nilsson, N.J.: Logical Foundations of Artificial Intelligence. Morgan Kaufmann, San Mateo (1987) 9. Wang, Y., Guo, J., Hu, T., Wang, J.: An Ontology-Based Framework for Building Adaptable Knowledge Management Systems. In: Zhang, Z., Siekmann, J.H. (eds.) KSEM 2007. LNCS (LNAI), vol. 4798, pp. 655–660. Springer, Heidelberg (2007)

ELDeR: An Ontology for Enabling Living inDependently of Risks Diana Saldaña-Jimenez, Marcela D. Rodríguez, Juan-Pablo García-Vázquez, and Adán-Noé Espinoza School of Engineering, MyDCI, Autonomous University of Baja California, Mexico {dianasj,marcerod,adanposg,jgarcia}@uabc.mx

Abstract. We present a Context-aware Component based on agents that enables developers to build Ambient Intelligence (AmI) Systems for supporting the independent living of elders. This component uses the ELDeR ontology that we propose to model the context information inherent to the elder’s daily activities and that enables agents to infer risks. Our aim is to provide an ontology flexible enough to easily enable developers to change the contextual conditions for inferring risks in order to respond to a different scenario. In this paper, we describe the functionality of the activity-aware component and the ELDeR ontology and illustrate their use by presenting the design of an application. Keywords: Ontologies, Ambient Intelligence, Agents.

1 Introduction For creating AmI systems, it is needed context-aware and intelligent systems that monitor the elders’ activities of daily living (ADLs) and recognize when they face an abnormal situation or risk. We are following the approach of using agents as a tool for designing and implementing AmI systems [1]. We have created a context-aware component that facilitates developers to create AmI systems to infer the elders’ daily activities and the risks associated with them. To reach this end, our component includes the ELDeR ontology which represents the elders’ context generated while they perform their activities of daily living in their homes. Several works have proposed infrastructures for facilitating the development of context-aware systems which use the ontology-based approach for modeling context information. For instance, SOCAM (Service-Oriented Context-Aware Middleware) includes [2] common upper-level ontology for representing general concepts such as: Person, Location, Computational Entity (i.e. Devices such as TV, Fridge) and Activity (i.e. Dinner, TakingShower). Similarly, CoDAMoS provides general ontology-based context models [3] which consist of sets of extensible ontologies to express contextual information about User, Tasks, Services, Environment and Platform. I.L.S.A is an agent-based architecture for creating home-based systems for assisting elders [4]. To our knowledge, I.L.S.A is the only project that proposes an ontology for this domain: the Consolidated Home Ontology in Protégé (CHOP). CHOP is a common R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 622–627, 2009. © Springer-Verlag Berlin Heidelberg 2009

ELDeR: An Ontology for Enabling Living inDependently of Risks

623

vocabulary for I.L.S.A related concepts and their relationships. Additionally, CHOP produces an agent communication interface between I.L.S.A.´s agent-based system components. The ontologies presented in this section, are general models (high-level ontlogies) for representing context information. Creating ontologies for specific domains (lower-level ontologies) is not an easy task since it requires a more profound analysis to abstract the context information that is general for any user living in the specific domain. Our aim is to create the ELDeR (Enabling Living inDependently of Risks) ontology flexible enough to enable developers to easily add and change the contextual conditions for inferring risks of elderly performing their ADLs in their homes. To reach this end, we are creating an agent-based component that enables developers to build AmI systems by encapsulating functionality for consulting and updating the ELDeR ontology to infer risks associated with ADLs. In the following section we present the ELDeR ontology. Section 3 explains the design of our contextaware component. Section 4 presents how this component and its ontology facilitates to implement an application designed for preventing elderly from not adhering to their medication routine. Finally, Section 5 presents our conclusions and future work.

2 ELDeR Ontology The ELDeR Ontology provides a common language for agents that are involved in the context of elder healthcare. To design the ELDeR Ontology we obtained a general understanding of ADLs from medical literature [5]. The design of the ontology presented in figure 1, indicates that activities (ADL) are linked to other activities. For instance, some activities are commonly performed sequentially or in a certain order (although not necessarily all the time); for instance: hand washing, eating and teeth-brushing. An ADL is composed of at least one task or Action. For example, the hand washing ADL is composed of actions such as open the faucet, take the soap, etc. Thus, for carrying out Actions, elderly use Objects of their environment. An ADL tends to be performed at certain Times of the day and with certain Frequency. Persons tend to spend certain period of time (Duration) for executing it. Each Action can be performed at one or many Locations, and at a moment in Time. For example, opening a water faucet may be performed in a bathroom or kitchen at different times during the day. In addition, Actions may have Features which we identified as contextual variables of the elder while performing an Action that may cause a Risk. These features should be specified in Rules that infers risk. For instance the action “open the faucet” is associated with the temperature of the water which is a feature, and the Rule is that if it is 54°C or more there is a Risk of scalding. Thus, as represented in Figure 1, not only Features are specified in the Rules to infer risks but Frequency, Time, Duration, Objects and Location may be included in the Rules. Risks are linked with Notifying Agents that notify of the elder’s situation appropriately as defined by the application programmer. The identity of these agents should also be specified in the ontology. Thus, the contents of this ontology will be provided by the programmer according to the application scenario being implemented.

624

D. Saldaña-Jimenez et al.

Fig. 1. ELDeR Ontology

3 Context-Aware Component The Context-aware Component, illustrated in figure 2, contains agents that provide the characteristics of intelligence and context-awareness required for inferring the elders’ activities and predicting if they are facing a risk. These agents were designed based on the types of agents proposed in the SALSA middleware [1]. SALSA provides a library of classes for implementing and handling the execution model of agents, which consists of perceiving information, reasoning, and acting. Further information regarding SALSA is found in. The Context-aware Component contains agents that provide the following functionality: • Gathering context information. The component contains agents that perceive the time, duration and frequency of carrying out an activity (Time Agent, Duration Agent and Frequency Agent). The Features Agent gathers context information (Features) that developers identify as relevant for inferring risks associated with the elderly activity. Other agents act as proxies to external components, such as information resources, devices or other agents, which capture the elderly context. For instance, the Location-proxy Agent perceives the elder´s location from an external component (i.e. Location-estimation agent); and the Objects-proxy Agent perceives information related the elderly interaction with their environment objects used for the activity. Developers should implement the external components for gathering context information and attach them to the context-aware component by using the SALSA communication protocol.

ELDeR: An Ontology for Enabling Living inDependently of Risks

625

Context-aware Component

Time Agent

Risk Assessment Agent

Duration Agent

Wearable Notification System for Medication Adherence Medication Adherence Notifying-Agent

Frecuency Agent ContextAware Agent

ELDeR Ontology

Locationproxy Agent Objectsproxy Agent

Location Estimation Agent

Notification Display

Features Agent

Interaction Estimation Agent

Medicine Dispenser proxy Agent

Fig. 2. Context-aware Component for inferring risks

• Representing and inferring the elderly contex, The aforementioned agents communicate the gathered context-information to the Context-Aware Agent by using SALSA messages extended for conveying this information. The context perceived by the context-aware agent will be used for updating the ELDeR ontology. When the older adult context changes, the Context-aware Agent notifies it to the Risk Assessment Agent, which will consult the ontology to verify if a risk condition has met. The Risk Assessment Agent informs the elder’s situation to the appropriate Notifying Agent specified by the developer in the ontology. Developers implement a Notifying Agent to take the appropriate measures for the risk such as warning the elder or notifying the elder’s caregivers.

4 AmI System for Supporting Medication Adherence We illustrate the functionality provided by the Context-aware Component by presenting a hypothetical scenario of a system that reminds elders to take their medicines. We elected to study the medicating activity since persons who are over-65 years face frequent problems associated with non-adherence to their medication routine. Different studies, analyzed in [6], have reported noncompliance, nonadherence or medication errors rates in the elderly population that range from 26% to 59%. Non-adherence may aggravate health and lead to hospitalizations. An AmI system may support elders in this ADL by: providing reminders before the time for medicating; making older adults aware that the medicine was not taken; and notifying older adults that the medicine has run out. For implementing the aforementioned system functionality, the following components were created and attached to the Context-aware Component as presented in figure 2. The Wearable Notification System for Medication Adherence is a node representing the wearable device that contains the Medication Adherence Notifying-Agent. This agent receives the

626

D. Saldaña-Jimenez et al.

Fig. 3. Wearable Notification System for Medication Adherence. Elements of the user interface are: a) Medicine name, b) doses, c) icon representing the disease or health problem treated by the medication, d) current time, e) number of pills to take.

Fig. 4. AmI System’s agents interacting to remind an older adult to take his medicine

notification messages to be displayed on the wearable device (see figure 3) by the Notification Display. The Medication Dispenser proxy-Agent is attached to the component to be aware of the medicines and doses taken by the elder as indicated in his medicine prescription. The Interaction-estimation Agent uses sensing technology for perceiving the elder’s interaction with the objects around. The following scenario illustrates the interaction among the Context-aware Component and components of the Wearable Notification System for Medication Adherence as illustrated in figure 4. Pablo enters to the kitchen since he wants to prepare his dinner at 8:00 pm. The Context-aware Agent updates the ontology to specify the elder’s context: Pablo is in the Kitchen and he takes a knife since he plans to prepare his dinner. The Time Agent informs the Risk Assessment Agent that the current Time is 8:00pm, which is the time that Pablo should take his last medicine of the day. The Risk Assessment Agent consults the ELDeR ontology to get the rules and the context of Pablo. Then, the reasoning sub-component of the Risk Assessment Agent uses a Bayesian Network formed from the context information of Pablo to estimate the probability that Pablo

ELDeR: An Ontology for Enabling Living inDependently of Risks

627

forgets to take his medicine given that he is in the kitchen doing other actions related to the cooking activity at the same time he needs to take his medicine. To apply the Bayes Rule we used Conditional Google Probabilities (CGP) [7] to obtain the a-priori conditional probabilities. In this case, the CGP enabled us to estimate that the probability that Pablo takes his medicine given that take a knife is 2%. Thus, by using this CGP and by knowing that at least 26% of the elderly may forget to take their medicines, the Risk Assessment Agent determined that Pablo needs to be reminded to take his medicine. Finally, the Risk Assessment Agent informs of this to the Medication Adherence Notifying Agent by sending a sendNotification() SALSA message. The Medication Adherence Notifying Agent generates the appropriate message to be presented on the wearable device by the Notification Display component. Thus, advance inferring of this risk enables the Wearable Notification System for Medication Adherence to appropriately and opportunistically remind Pablo of taking his medicines without disturbing sending unnecessary reminders.

5 Conclusions and Future Work To facilitate the implementation of Ambient Intelligence (AmI) systems that support the activities of daily living of older adults, we designed an agent-based component for inferring elders’ context and predicting whether they need help to carry out their activities of daily living. For inferring users’ context, we have designed the ELDeR Ontology which is a representational model of the elders’ context information that is captured by pervasive technology. We are designing the ELDeR ontology general enough that it can be used for inferring any risk associated with Activities of Daily Living. We plan to carry out a case study for validating the ontology with older adults and healthcare professionals. And finally, we plan to implement different application scenarios to evaluate the ease of use of the Context-aware Component and the flexibility of the ontology for instantiating it according to the scenario supported.

Acknowledgments This work was supported in part by PROMEP-SEP, and CONACyT.

References 1. Rodriguez, M., Favela, J., Preciado, A., Vizcaino, A.: Agent-based ambient intelligence for healthcare. AI Communications 18(3), 201–216 (2005) 2. Gu, T., Keng Pung, H., Qing Zhang, D.: A service-oriented middleware for building context-aware services. J. of Network and Computer Applications 28, 1–18 (2005) 3. Bochini, C., Curino, C., Quintarelli, E.: A Data-oriented Survey of Context Models. ACM SIGMOD Record 36(4), 19–26 (2007) 4. Zita, H., Karen Kiff, M.: The Independent LifeStyle Assistant (I.L.S.A.): AI Lessons Learned. In: 16th Innovative Applications of AI Conference (AAAI), pp. 852–857 (2004) 5. Moruno, P., Romero, D.M.: Activities of Daily Living, p. 474. Elsevier, Spain (2006) 6. Orwing, D., Brandt, N., Gruber-Baldini, A.L.: Medication Management Assessment for Older Adults in the Community. The Gerontologist, 661–668 (2006) 7. Perkowitz, M., Philipose, M., Fishkin, K., Patterson, D.J.: Mining Models of Human Activities from the Web. In: WWW 2004, pp. 573–582 (2004)

ORM 2009 PC Co-chairs’ Message Following successful workshops held in Cyprus (2005), France (2006), Portugal (2007), and Mexico (2008), this was the fifth in a series of fact-oriented modeling workshops run in conjunction with the OTM conferences. Fact-oriented modeling is a conceptual approach to modeling and querying the semantics of business domains in terms of the underlying facts of interest, where all facts and rules may be verbalized in language readily understandable by users working in those business domains. Unlike entity-relationship (ER) modeling and UML class diagrams, fact-oriented modeling treats all facts as relationships (unary, binary, ternary etc.). How facts are grouped into structures (e.g., attribute-based entity types, classes, relation schemes, XML schemas) is considered a design level, implementation issue irrelevant to capturing the essential business semantics. Avoiding attributes in the base model enhances semantic stability and populatability, and facilitates natural verbalization and thus more productive communication with all stakeholders. For information modeling, fact-oriented graphical notations are typically far more expressive than those provided by other notations. Fact-oriented modeling includes procedures for mapping to attribute-based structures, so it may also be used to front-end those approaches. Though less well known than ER and object-oriented approaches, fact-oriented modeling has been used successfully in industry for over 30 years, and is taught in universities around the world. The fact-oriented modeling approach comprises a family of closely related “dialects,” the most well known being object-role modeling (ORM), cognition-enhanced natural language information analysis method (CogNIAM) and fully-communication-oriented information modeling (FCO-IM). Though adopting a different graphical notation, the object-oriented systems model (OSM) is a close relative, with its attribute-free philosophy. The Semantics of Business Vocabulary and Business Rules (SBVR) proposal adopted by the Object Management Group in 2007 is a recent addition to the family of fact-oriented approaches. Commercial tools supporting the fact-oriented approach include the ORM solution within Microsoft’s Visio for Enterprise Architects, the CogNIAM tool Doctool, the FCO-IM tool CaseTalk, and the Collibra ontology tool suite. The NORMA (Natural ORM Architect) tool for ORM 2 is available as a free, open-source plug-in to Visual Studio; a commercial, professional version of NORMA is also under development. Free ORM tools include InfoModeler, Infagon, ActiveFacts, and ORM-Lite. DogmaStudio is an ORM-based tool for specifying ontologies. General information about fact-orientation may be found at www.ORMFoundation.org. This year we had 22 original proposals for workshop papers. After an extensive review process by a distinguished international Program Committee, with each paper receiving three or more reviews, we accepted the 13 papers that appear in these proceedings. Congratulations to the successful authors! We gratefully acknowledge the generous contribution of time and effort by the Program Committee, and the OTM Organizing Committee, especially Robert Meersman and Tharam Dillon (OTM General Chairs), and Pilar Herrero (OTM Workshops General Chair). November 2009

Terry Halpin Herman Balsters

R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, p. 628, 2009. © Springer-Verlag Berlin Heidelberg 2009

Towards a Common Platform to Support Business Processes, Services and Semantics Baba Piprani MetaGlobal Systems, Canada [email protected]

Abstract. The search for the Holy Grail in achieving interoperability of business processes, services and semantics continues with every new type or search for the Silver Bullet. Most approaches towards interoperability either are focusing narrowly on the simplistic notion using technology supporting a cowboy-style development without much regard to metadata or semantics. At the same time, the distortions on semantics created by many of current modeling paradigms and approaches – including the disharmony created by multiplicity of parallel approaches to standardization – are not helping us resolve the real issues facing knowledge and semantics management. This paper will address some of the issues facing us, like: What have we achieved? Where did we go wrong? What are we doing right? – providing an ipso-facto encapsulated candid snapshot on an approach to harmonizing our approach to interoperability, and propose a common platform to support Business Processes, Services and Semantics. Keywords: Services, SOA, Business process, Semantics, Conceptual Schema, ORM, TR9007.

1 Search for Interoperability Interoperability---meaning, diverse systems and organizations working together---is the much sought after goal, IT shops are always striving and searching for IT Nirvana, in the guise of re-usability, common functional components, Services Oriented Architecture, the now defunct term Grid Computing (or is now re-named Cloud Computing…) , and so on. The term “interoperability” is often used in a technical sense i.e. systems engineering, or, the term is used in a broad sense, taking into account social, political, and organizational factors that impact system to system performance. Syntactic Interoperability is when two or more systems are capable of communicating and exchanging data using some specified data formats or communication protocols, e.g. XML or SQL standards---much like interoperability of rail, which have common parameters like gauge, couplings, brakes, signaling, communications, loading gauge, operating rules etc. Syntactic interoperability is a .pre-requisite to achieving further interoperability. Semantic interoperability is the ability to automatically interpret the information exchanged meaningfully and accurately in order to produce useful results as defined by the end users of participating systems, all the participating sides must defer to a R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 629–638, 2009. © Springer-Verlag Berlin Heidelberg 2009

630

B. Piprani

common information exchange reference model. The content of the information exchange requests are unambiguously defined: what is sent is the same as what is understood. Quoting the ‘Helsinki Principle’ from ISO TR9007 [1]

“

Any meaningful exchange of utterances depends upon the prior existence of an agreed set of semantic and syntactic rules. The recipients of the utterances must use only these rules to interpret the received utterances, if it is to mean the same as that which was meant by the utterer.”

2 Oh What a Tangled Web We Weave….Processes, Services and SOA Introduced in the early years of file based systems to model behavior and to model dynamics of the enterprise, early incarnations of Process Modelling progressed from modeling decompositions of business processes, data flows for the IT crowd, and including work flow. With more than a dozen notations, process models were largely a mixed bag serving multiple clientele---business process flow, IT processes analysis, and IT implementers looking for incorporating re-usability. What was missing, and still is, is the formal bridge into data semantics for the automatable processes. More emphasis is being put on the sequencing and orchestration, making the processes an ad hoc grab bag of Picasso style compositions of complex and elementary processes woven together. Enter “services” as in a services oriented architecture (SOA) with a web based focus to provide a new “processing” focus. The infrastructure crowd already had their infrastructure services, and so did the application folks with their application services. Yet the same term ”service” essentially is being used to “service” multiple definitions. The new business model that had difficulty gaining acceptance with the term grid computing now became Cloud Computing, with new paradigms SaaS (Software as a Service), PaaS (Platform as a Service)…being part of XaaS (Everything as a Service)---based on the concept of providing encapsulated functionality via re-usable software components. With the definition of “service” covering a broad base ranging from Information science e-services, infrastructure services, application or process based services, web based services, and so on---the report card for a success rate for a service is not looking good. Firstly, the real story on re-usability of software components. Though Objected Oriented programming was touted as being the ideal platform for hosting re-usable objects, “real” re-usability was not achieved with much success there [2]. Services” was touted as offering re-usability. Here again, about 1 in 5 services achieved the status of being ‘re-usable’ per se. Was it worth investing heavily in SOA to achieve a 20% re-usability factor? [2] [3] On the flip side, there exist several cases where re-usability has been achieved on some basic categories of services, like common services e.g. looking up the qualifications of organization personnel, notification of email etc.---invoked by cross-functional business units, or data transform or cross reference services etc. Suffice it to say, re-use is not a “build it and they will come” solution (quote from movie “Field of Dreams”).

“

Towards a Common Platform to Support Business Processes, Services and Semantics

631

A major factor in the ‘Service” equation was the lack of a consistent definition semantics, and, that it is essentially addressing the “rail track” interoperability---a syntactic connect via a defined interface, defined protocol, message format etc, but without much emphasis on application semantics. In other words while the IT departments spend a lot of money on software that hums, whirs with flashing lights, more often than not the business user community is not finding its objectives being met with a business emphasis. Another point is that of terminology confusion. Several “consulting firms” are inter-mixing “processes” and “services”. Introduce into the foray the traditional terms like “business function”, “function”, “business activity”, “activity” and “tasks”. So now we have a mélange of terms meaning that some transformation is occurring, sometimes with some business focus, sometimes with a technical interface focus, sometimes with a protocol focus, sometimes with a web focus, with no standardized engineering-style specifications. But what is important to note is that most every definition of a service is focusing only on the interface, negotiation, and basic capability. Related work in the area of service description and registration addresses these key points in various approaches. Take WSDL, the Web Service Description Language, an XML based language for describing Web services and how to access them. WSDL is a W3C (World Wide Web Consortium) Recommendation. WSDL essentially has a set of definitions that describe a web service using the main elements: -

The data types used by the service [uses XML syntax for max neutrality] <message> The messages used by the service [parts, like parameters for a function call] <portType> The operations performed by the service [like a function library or module] The communication protocols used by the service [format and protocol details] Other elements like extension elements and a service element that makes it possible to group together the definitions of several web services in one single WSDL document.

Along comes UDDI, the Universal Description, Discovery, and Integration directory services where businesses can register and search for Web services. UDDI is a platform independent framework for describing services and facilitates the integration of business services through discovery via the Internet. Basically it is a directory of web service interfaces described by WSDL where for example airlines could register their services into a UDDI directory and travel agencies could then search the UDDI directory to determine the airline’s reservation interface, that is, if the travel industry published a UDDI standard for flight rate checking and reservation. And then there is OWL-S (Web Ontology Language for Services), as an ontology of services which users and software can discover, invoke, compose, and monitor Web resources offering particular services and having particular properties. Three main parts are described---the service “profile” for advertising and discovering services, the “process model”, which provides a description of a service’s operation, and the “grounding”, which provides details on how to interoperate with the service

632

B. Piprani

via messages. It is interesting to note that a “process” as referred to in OWL-S (atomic process, composite process) is essentially a specification of the ways a client may interact with a service, and not referring to a program to be executed---as the term is recognized in Process Modelling or IT analysis! It is important to note that the above mentioned paradigms approach the interaction of Services essentially at the “syntactic” level. In an effort to approach services from a semantic viewpoint, WSMO (Web Service Modelling Ontology), also a W3C submission, introduces ontologies along with goals, to interact with Web Services, highlighting the semantic description of Web Services in terms of Capability and Interfaces along with connectors between components with mediation facilities for handling heterogeneities. Ontologies are used as a data model for all resource descriptions and all data interchanged during service usage and as a central enabling technology for the Semantic Web. Web Service Modeling Ontology (WSMO) provides a conceptual framework and a formal language for semantically describing all relevant aspects of Web services in order to facilitate the automation of discovering, combining and invoking electronic services over the Web.[4] The W3C 2005 submission of WSMO also defines a Web Service Modelling Language (WSML) for the semantics and computationally tractable subsets of the formal syntax introduced in WSMO. WSML which provides a formal syntax and semantics for the Web Service Modeling Ontology WSMO. WSML is based on different logical formalisms, namely, Description Logics, First-Order Logic and Logic Programming, which are useful for the modeling of Semantic Web services. While the Web Service Modeling Ontology WSMO proposes a conceptual model for the description of Ontologies, Semantic Web services, Goals, and Mediators, providing the conceptual grounding for Ontology and Web service descriptions, WSML takes the conceptual model of WSMO as a starting point for the specification of a family of Web service description and Ontology specification languages. The Web Service Modeling Language (WSML) aims at providing means to formally describe all the elements defined in WSMO. [5]

3 Semantics in Services…Wherefore Art Thou? So, why is SOA having a high failure rate—like 50% [6] [7], and with empty promises of re-usability? [2] [3] [8]. Or should the question be raised, “Semantics, for what purpose are you there?” (in contrast to the section heading above which really asks ‘for what purpose’ semantics (Juliette asks Romeo… O Romeo, Romeo, wherefore art thou Romeo?, Juliet really means "for what purpose?"). The services in SOA essentially are addressing the syntax part (and the semantics of the mechanics part) of the web services for messages and interfaces, and not really addressing semantics of the business requirement---in particular the semantics of the community of concepts, like say SBVR [9], ORM [10] or NIAM [11] i.e. fact based modeling. But, there is a glimmer of hope with WSMO injecting the much needed business semantics via the use of ontologies, even though the engineering style declaration of semantics, the much needed grammar and transforms appear to be inadequately defined or incomplete

Towards a Common Platform to Support Business Processes, Services and Semantics

633

within the ontology declarations---in contrast with the declarations available in fact based modeling methods. While WSMO purports to address semantics via the ontology connection, it is interesting to note that the WSMO model for capability specification, for example, defines pre-conditions for a service as what a web service expects in order to provide its service, i.e. define conditions over its input. These pre-conditions are essentially, valid business rules that are required to be met for the service to be performed. The question is, what is the guarantee that all design architects can come up with the same required set of business rules? In other words is there a conceptual schema that these rules can be derived from? In the absence of such a formal connection, the inclusion of the rule-set in pre-conditions may not be consistent.

4 --So Long as I Get Somewhere "Would you tell me, please, which way I ought to go from here?" "That depends a good deal on where you want to get to," said the Cat. "I don’t much care where--" said Alice. "Then it doesn’t matter which way you go," said the Cat. "--so long as I get SOMEWHERE," Alice… Alice in Wonderland, by Lewis Carrol

Not being able to “engineer” services through some sort of a standard specification approach in addressing semantics---not the semantics of the service protocols or message, here I mean the semantics of the “business” --- in itself presents high risk in implementing SOA. What then seems to be occurring is that there is a large-scale dependency and trust on the mechanics of services in SOA, meaning: provide the syntax, protocols, messages, and a service is successfully accomplished---along with flashing lights, etc. There is generally a hype-follower set that embraces any new offering that promises service nirvana. An SOA implementation that is merely focused on IT and technology, and that does not cater to the real business need, is essentially a high risk candidate for failure. A carefully thought out metadata semantic connection in SOA---both the semantics of the service and semantics of the business---is one way towards assuring a successful implementation. Take for example, a pre-condition (a set of semantic statements that are required to be true before an operation can be successfully invoked) definition for a Web service for booking tickets from [12] as in Fig. 1. We see here a code snippet for a capability pre-condition for booking tickets or complete trips. Agreed, this defines a specification for the preconditions…but the question is whether the analysis process used is repeatable and, that other architects would also arrive at the same solution? In other words, the code does appear as needing to be hand-crafted for each service using the same set of facts. And, more importantly, if other services have this sort of pre-condition code built in, changes affecting any of the common rule subsets could cause a domino effect in other service pre-conditions. Then the re-usability and ease-of-specification problem has suddenly taken the form of spaghetti code, albeit in a different form---resulting in dramatic failures or inconsistencies across the board.

634

B. Piprani

capability VTAcapability sharedVariables {?item, ?passenger, ?creditCard, ?initialBalance, ?reservationPrice} precondition definedBy exists ?reservationRequest (?reservationRequest[ reservationItem hasValue ?item, passenger hasValue ?passenger, payment hasValue ?creditcard] memberOf tr#reservationRequest and (?item memberOf tr#trip or ?item memberOf tr#ticket) and ?passenger memberOf pr#person and ?creditCard memberOf po#creditCard and (?creditCard[type hasValue po#visa] or ?creditCard[type hasValue po#mastercard]) ) Fig. 1. Service Pre-Condition example

Fig. 2. ORM Conceptual Schema of Trip Reservation

Contrast this approach with metadata defined semantics in an ORM conceptual schema in Fig. 2 for a trip reservation. The semantics as defined in the pre-condition example are defined explicitly in the ORM conceptual schema, centrally, in one place only with no redundant declarations. The schema requires a reservation request must have a reservation item (trip) and one or more passengers on a given date.. A

Towards a Common Platform to Support Business Processes, Services and Semantics

635

confirmed reservation then must fulfill an existing reservation request and must be accompanied by one or more credit card reservation payments each of which must have an amount put on hold with the corresponding credit card. There is a total amount for a confirmed reservation and the sum of the amounts held on each credit card must be greater than or equal to total amount of reservation depending on the credit card company rounding algorithms. This means that the pre-condition (with comparable semantics) as defined previously are generatable from the ORM schema, and not required to be hand-coded--which invariably leads to coding errors or inconsistencies. Many of the current service definitions are essentially hand-coded and fall into the same spaghetti coding trap, thus making re-usability and change management a nightmare. Using ORM schema and its generated declaratives is an example of meta-data driven software in action. So, let’s look at an example of a post-condition [12] as in Fig. 3. postcondition definedBy exists ?reservation(?reservation[ reservationItem hasValue ?item, price hasValue ?reservationPrice, customer hasValue ?passenger, payment hasValue ?creditcard] memberOf tr#reservation and ?reservationPrice memberOf tr#price) Fig. 3. Service Post-condition example

Examine the ORM Schema in Fig. 2. All the statements defined in the postcondition are met by the ORM Conceptual Schema. That means, the entire set of precondition and post-condition statements can be safely eliminated, since these rules have been consistently declared in the ORM schema and guaranteed to consistently come across in any implementation transforms, are universally applicable, and not associated with any particular service. In practice, this entire ORM conceptual schema as shown and transformed to SQL was 100% achievable via ISO SQL[13] schema declarations automatically generated from the ORM schema converted to an ERWin [14] IDEF1X [15] based attribute data model. Another viewpoint of a pre-condition example could be that a Service or a Process needs to be executed before a given service execution occurs. I have seen examples of such pre-conditions being stated….but is not that what Choreography is all about? But, examples abound with such redundant declarations with the very same requirement being stated in a service pre-condition as well as in a choreography model---which again contributes to failures due to inconsistencies and redundancy maintenance issues.

636

B. Piprani

An item of concern is the set of semantic annotation functionalities being introduced for WSDL files via a WSDL defined semantic model, which consists of 4 parts: Input semantics, Output semantics, Precondition, and Effect (after an operation--both successful and unsuccessful). With the individual model semantics being at the service level, there does not appear to be a conceptual schema style definition model where all the rules are to be declared. For example an output semantic from one service that is feeding an input semantic of another service could have different model semantics, since input and output semantics are declared on an individual service. It is inevitable that the more human coding that is introduced, that the code is increasingly prone to embracing failures. No wonder there are so many failures in SOA!

5 Proposed ISO Standard Work in Services for Interoperability There is a Working Draft for an ISO Standard to address a metamodel for Service Registration [16] whose scope is to address semantic interoperability of services through achieving a common understanding between users and services for the integration of heterogeneous services. The proposed Service registration standard hopes to provide a mechanism for registering service semantics. In contrast, UDDI does not consider service semantics and only is concerned with web services. Specifically, the scope of Metamodel Framework for Interoperabilty—Part7 Metamodel for service registration is to: Specify a metamodel for registering services that can enable users to discover appropriate services; Define the functional and nonfunctional description of services; and Promote semantic interoperation between various services. The proposed standard does not specify language specific details nor the composition of services. Fig. 4 depicts a UML diagram of the proposed ISO metamodel for service registration. The ISO model appears to be modeling the WSMO and WSDL alignment specifications, and inherits the same deficiencies as noted.

Fig. 4. Proposed ISO WD Metamodel of Service Registration

Towards a Common Platform to Support Business Processes, Services and Semantics

637

6 Towards a Terminology Based Platform Bridging Processes, Services and Semantics What we have seen is a stampede towards finding the “silver bullet” via services. As we have seen, there is inconsistency in the definition of “services”. The term is used interchangeably to mean: Infrastructure services, also Web services, also Application services, also Process, etc….There is still the ‘Picasso’ style analysis with no engineerable model. Missing, is the semantics connection. In modeling semantics again, there are various incarnations: Entity Relationship (ER) that models entities and relationships, but suffers from lack of clarity and separation from attribute level semantics; Unified Modelling Language (UML) which models classes, associations and attributes, and consists of various sub-models or packages, but brings in implementation artifacts early in the modeling exercise, is essentially geared towards implementation using the Object Oriented paradigm. UML model semantics are slightly more expressive than ER, albeit at the attribute based level; Fact Oriented methods (NIAM, ORM, FOM, CogNIAM…) which have gained firmer ground in addressing semantics, are more conceptual schema oriented, are based on natural language foundation with added formalisms; with OWL and RDF applicability as this effort is in its early stages. Recall the definition of a Conceptual Schema in ISO TR9007:1987 The description of the possible states of affairs of the universe of discourse including the classifications, rules, laws, etc. of the universe of discourse” i.e. the Conceptual Schema covers Static and Dynamic aspects of the Universe of Discourse. Current offerings of SOA, Services, Process Modelling and data modeling overlook this important coupling. ISO TR9007 deals with propositions, i.e. Natural Language sentences in messages from the information system. We seem to have omitted this important fact in our search for semantics based interoperability. There is a need to establish a bridge between the business model (in business-speak language) and, the implemented information systems, i.e. use of terminology for specifying and determining business static rules and business dynamic behavioral rules that drive the data models, process models and service models for an information system. Much background work has already been performed in ISO and other areas, including Fact based modelling methods SBVR as a common platform in the use of terminology as applied to communities. It is within such communities that the discovery of applicable services can be made, and definitely not at the syntactic level. A strong foundation of using established semantic modeling techniques is an absolute must for the survival and flourishing of a services architecture. The knowledge triangle [17] should be used as a fundamental start point for a platform for defining an all-encompassing solution in the area of static and dynamic behavior of an enterprise. We need to position Semantic modeling methods, process modeling and Services architectures to achieve implementations that harmonizes data semantics, process semantics, orchestration semantics and platform independence. This paper is based on the keynote speech given by the author at the Metadata Open Forum in Seoul, Korea, June 2009 [18].

“

638

B. Piprani

References 1. International Organization for Standardization(ISO): ISO Technical Report TR9007: Information processing systems—Concepts and Terminology for Conceptual Schema and the Information Base (1987) 2. McKendrick, J.: Pouring cold water on SOA reuse’ mantra, ZDNet (August 2006), http://blogs.zdnet.com/service-oriented/?p=699 3. Linthicum, D.: Core Value of a SOA is the Ability to Reuse Services? Not a Chance (October 2007), http://www.infoworld.com/archives/ emailPrint.jsp?R=printThis&A=http://weblog.infoworld.com/ realworldsoa/archives/2007/10/core_value_of_a.html 4. Web Service Modelling Ontology (WSMO), http://www.w3.org/Submission/2005/SUBM-WSMO-20050603/, http://www.wsmo.org/TR/d2/v1.4/20070216/ 5. Web Service Modelling Language (WSML), http://www.w3.org/Submission/2005/SUBM-WSML-20050603/ 6. Kenny, F.: Ahh Shucks, SOA Is A Failure (November 12, 2008), http://blogs.gartner.com/frank_kenney/2008/11/12/ ahh-shucks-soa-is-a-failure/ 7. InfoQ, Survey: Only 37% of enterprises achieve positive ROI with SOA, http://www.infoq.com/news/2007/08/SOAROI 8. Lawson, L.: IT BusinessEdge, Savings from Reusing Services Oversold and Overpromised, http://www.itbusinessedge.com/cm/blogs/lawson/savings-fromreusing-services-oversold-and-overpromised/?cs=33689&utm_ source=itbe&utm_medium=email&utm_campaign=MII&nr=MII 9. Semantics of Business Vocabulary and Business Rules (SBVR), http://www.omg.org/cgi-bin/doc?dtc/2006-08-05 10. Halpin, T., Morgan, T.: Information Modeling and Relational Databases, 2nd edn. Morgan Kaufmann Publishers, an imprint of Elsevier (2008) ISBN: 978-0-12-373568-3 11. Nijssen, G.M., Halpin, T.A.: Conceptual Schema and Relational Database Design. Prentice Hall, Victoria (1989) 12. Stollberg, M.: SWS tutorial - Industry Workshop, "Adaptive SOA" Semantic Web ServicesRealisierung der SOA Vision mit semantischen Technologien (February 20, 2007), http://www.wsmo.org/TR/d17/industryTraining/ SWS-tutorial-potsdam-20070220.pdf 13. International Standard ISO IEC 9075:1999. Database Language SQL. International Standards Organization, Geneva (1999) 14. CA ERWin Data Modeller, http://www.ca.com/us/data-modeling.aspx 15. IDEF1X, USFIPS Publication 184 release of IDEF1X by the Computer Systems Laboratory of the National Institute of Standards and Technology (NIST), December 21 (1993) 16. ISO/IEC WD 19763-7, Information Technology – Metamodel Framework for Interoperability (MFI): Metamodel for service registration (Working Draft1, 2008-11-18) 17. Lemmens, I.M.C., Nijssen, M., Nijssen, S.: A NIAM2007 Conceptual Analysis of the ISO and OMG MOF Four Layer Metadata Architectures. In: Meersman, R., Tari, Z., Herrero, P. (eds.) OTM-WS 2007, Part I. LNCS, vol. 4805, pp. 613–623. Springer, Heidelberg (2007) 18. Piprani, B.: Towards a Common Platform to Support Business Processes, Services and Semantics. Keynote speech at Open Forum for Metadata Registries, Seoul, Korea (June 2009), http://metadata-standards.org/metadata-stds/Document-library/ Documents-by-number/WG2-N1251-N1300/ WG2_N1259_BabaPipraniPresentation6.pdf

BPMN as a Communication Language for the Processand Event-Oriented Perspectives in Fact-Oriented Conceptual Models Peter Bollen School of Business and Economics Maastricht University, The Netherlands Tel.: 0031-43-3883715; Fax: 0031-43-3884893 [email protected]

Abstract. In this paper we will show how the OMG specification of BPMN (Business Process Modeling Notation) can be used to model the process- and event-oriented perspectives of an application subject area. We will illustrate how the fact-oriented conceptual models for the information-, process- and event perspectives can be used in a ‘bottom-up’ approach for creating a BPMN model in combination with other approaches, e.g. the use of a textual description. We will use the common doctor’s office example as a running example in this article.

1 Introduction The fact-oriented conceptual modeling approach enables analysts to precisely model the content of the data perspective for an application subject area as a set of fact types and population (transition) constraints and (parts of) the process-oriented perspective, mainly by using derivation rules (ORM [1], NIAM [2], CogNIAM [3]) or different types of state (transition) models [4, 5]. A further treatment of the process- and event perspectives in fact-oriented conceptual modeling, has been given in [5-10]. The development of OMG’s SBVR into a standard for expressing business rules is an achievement for the fact-oriented modeling approach because it clearly embraces the idea that the only fact-encoding construct is the fact type and it clearly rejects any form of attribute as a main fact-encoding construct. However, SBVR mainly covers the business rules in the information perspective, but it has no modeling provisions for modeling the business rules in the process- and behavioural perspectives [11-13]. From this the question arises which modeling language standard can be used in tandem with SBVR to express the business rules in the process- and behavioural pespectives. The business process modeling notation (BPMN) v 1.1. [14] is an OMG standard that defines the modeling elements for creating business process models. BPMN was developed with the primary goal of providing a notation that would be readily understandable by all business users, from business analysts to technical developers that will have to implement the technology [15, p.1] and the need to translate ‘original’ business process models into ‘execution’ models. R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 639–648, 2009. © Springer-Verlag Berlin Heidelberg 2009

640

P. Bollen

In this paper we will illustrate how the Business Process Modeling Notation (BPMN) can be used to express the business rules in the process and behavioural perspectives of an enterprise and therefore, in combination with SBVR will allow business analyst to use the modeling results of the fact-oriented approach, that is characterized by it’s clarity, user-validation mechanisms and expressiveness and express it in OMG’s SBVR and BPMN standards [11]. In section 2 we will introduce the essential BPMN modeling constructs. In section 3 we will summarize the fact-oriented conceptual schema for the PDO case study as was derived in [16]. In section 4 we will illustrate how we can map a complete fact-oriented conceptual schema onto a BPMN model. We will use a popular fact-oriented notation for creating the models in the information perspective: Object-Role Modeling [1] extended with an explicit naming convention for fact types and constraints (as in [17]).

2 OMG’s BPMN Standard for Business Process Models The business process modeling notation (BPMN) v 1.1. [3] is an OMG standard that defines the modeling elements for creating business process models. The core modeling elements are defined on [14, pp. 18-20]. The BPMN basic concepts can be classified into flow objects, connectors and artifacts [15]. The flow objects and the sequence flows are the main modeling constructs that can be used to capture the essence of the models in the process-and behavioural perspectives. These modeling artifacts mainly provide the ‘bridge’ between the processes and the information that is needed to execute the process and the information that is the outcome of such a process execution. In figure 1 we have depicted the graphical representations of the most important BPMN modeling constructs.

Flow Objects Connectors Activity Sequence Flow

Event

Artifacts Data Object

Message Flow Text Annotation

Gateway

Association

Fig. 1. Diagrammatic representation of most important BPMN modeling concepts

3 The Fact-Oriented Conceptual Schema for the PDO Case Study The process- and event-oriented elements of the conceptual schema can now be expressed as BPMN ad-hoc processes. We will apply a combined ‘bottom-up’ and a ‘case description’ perspective for creating BPMN models for different aspects, e.g. ‘business domain’- and ‘implementation’ views on the business processes. We will illustrate this mapping with the ‘bench-mark’ patient and doctor’s office (PDO) case study as is described in [18].

BPMN as a Communication Language

641

3.1 The Information Model of the PDO Case Study The ‘traditional’ ORM conceptual schema for the information perspective for the PDO case study is given in figure 2. In contemporary fact-oriented approaches, the domain ontology plays a dominant role, and is usually captured in some form of ‘list of definitions’ (e.g. see [6, 19, 20]). For the PDO domain ontology we refer to the list of definitions in an earlier contribution to this workshop [16]. C16

R1

Ft10

R2

has a preffered

C1

R1

Person surname

Ft1

R2

C4

C5

has

C6

Ft2

R2

R1 Person

person first name

has /is of

C7 C8 Addresss (address code)

U

R1

R2

C9

has

C10 Place of residence (municipality name)

Ft3

Ft4

R1

Patient (patient number)

C3

C2

R1

Doctor (doctor identification code)

R2

is birth date of

C11

"Time slot"

R1

has

C12

C13

P

Ft8

R2

R1

R1

has a preferred/

R2

Ft7 C17

There exists a generic slot

R1

R2

R1

there is a ... on.. R1 /on..the...

R2

Appointment C21 (appointment number)

has an

C19

C20

Ft13 C22

C24

R2

R1

C27

R1 has recorded

R2

R1

Ft9

is an available time sliot

Ft11

is scheduled at

The maximum patient capacity is

Asistant (assistant code)

C15

X

C23 C18 Ft12

Ft6

R2

There exists a timeslot

"Generic slot"

Maximum patient Maximum capacity patient capacity (integer number) (integer number)

C14

Time (hours:minutes)

Date (date code)

Ft5

R2

Stc1:(Ft14.r1, Ft16.r1) Ft15

C26

C25

( -, -)

X

Ft14

R1 has taken place

Stc1

R1 is cancelled

Ft16 ( a, -)

( -, a)

Stc1

Fig. 2. (Excerpt from) list of definitions and fact type diagram for the PDO example

3.2 The Process Description of the PDO Case Study The derivation and exchange rules in a fact-oriented conceptual schema provide a complete description of the semantics in the process-oriented perspective for a given application subject domain. The derivation rules create ‘new’ fact instances out of ‘old’ fact instances. Exchange rules, basically (de)populate the application’s information base by adding and/or deleting (atomic) fact instances. In this article we will only discuss a small (but significant) number of derivation-, exchange- and event rules from our PDO case study. For a complete overview we refer to [16]. Derivation rule Dr1 derives the total number of patients that are registered in the practice at any point in time.

642

P. Bollen

Dr1: Calculate total number of patients IF EXT (Ft4) is empty THEN total number of patients.R1:=0 ELSE total number of patients.R1:=COUNT(EXT(Ft4)) ENDIF

In exchange rule Ex9 an appointment can be added. Ex9: Add appointment(arg1:date, arg2:time, arg3:doctor,arg4:patient, arg5:assistant) IF [‘arg4’ in EXT(Ft5.R2) AND ‘arg1, arg2, arg3’ in Ft9.R1] THEN CREATENEWAPPOINTNUMBER: [b] [( ADD an instance of Ft13 such that Ft13.R1=‘arg4’ AND Ft13.R2= b) ) AND (ADD an instance of Ft11 such that Ft11.R1= ‘b’ AND Ft11.R2:= ‘ arg1, arg2, arg3’) AND (ADD an instance of Ft15 such that Ft15.R2= ‘b’ AND Ft15.R1:= ‘ arg5’)] ENDIF

We note that in the textual description of the PDO case study, trivial exchange rules are not mentioned explicitly. In our work-out of the case study in [16] we have added these exchange rules, thereby we have made assumptions about the extent in which instances of fact types are allowed to be inserted, updated or removed on their own. 3.3 The Event Description of the PDO Case Study An event rule in a fact-oriented conceptual schema depicts under what conditions the occurrence of an event leads to the execution of one or more derivation- and/or exchange rules. In the PDO example, in event rule ER2, it is exactly stated what happens when an unknown patient wants to make an appointment. ER2: Unknown patient requests for appointment ON E1: Person wants to make a doctor’s appointment (arg1: first name, arg2: surname, arg3: date of birth) IF [Dr2: Determine patient status (arg1= ‘E1.arg1’, arg2= ‘E1.arg2’, arg3= ‘ E1.arg3’) = ‘Patient is not yet known’] DO Ex1: Register patient (arg1: first name, arg2: surname, arg3: date of birth, arg4: address, arg5: place of residence) [Impulse mapper: Ex1.arg1:= ‘E1.arg1’; Ex1.arg2:= ‘E1.arg2’; Ex1.arg3:= ‘E1.arg3’]

4 Mapping Fact-Oriented Conceptual Models to BPMN Models In this section we will provide a mapping from the process- and event perspectives to the BPMN modeling constructs that were described in section 3 of this paper. 4.1 Mapping of the Fact-Oriented Models in the Process-Perspective to BPMN Ad-Hoc Process Standards The first mapping we will provide maps the fact-oriented derivation- and exchange rules onto the ‘ad-hoc’ BPMN process model ‘modules’. The concept of derivation rule can be mapped as an BPMN activity. The fact type(s) that are input(s) to a derivation rule are encoded as (an) input data-object(s) and the fact type(s) that is (are) derived in the derivation rule will be encoded as (an) output data-object(s). These input- and output- data objects are connected to the activit(y)ies by means of (a) ‘directed’ association(s).

BPMN as a Communication Language

643

The Doctor’s office registration Dr1: calculate total number of patients

Ex11: add appointment has taken place

Ft14

Ft16

Ft10

Ft8

time slot for doctor

Ft12

Ft1, Ft2, Ft3, Ft4, Ft5

Dr6: find closest preferred doctor time slot

closest preferred doctor time slot

closest preferred time slot Ex7: add doctor time slot

Ex1: register patient

Ex14: add preferred time slot

Ft4, ft7

Ft6, Ft7, Ft9

time slot availability

current patient status Dr5: find closest preferred time slot

Dr4: check availibility preferred doctor time slot

Ex12: add preferred doctor

Ft4, Ft6, Ft10

Ft1, Ft2, total number of Ft3, Ft4 patients

Ft4

Dr3: check availibility preferred timeslot

Dr2: determine patient status

Ft6, Ft7

Ex10: cancel appointment

Ft11, ft16

Ex9: add apointment

Ft5, ft9 Ft9, Ft11, Ft16

Ft11, Ft13, Ft15

~ Fig. 3. Mapping of fact-oriented derivation- and exchange rules onto BPMN ‘ad-hoc’ process models (only graphical elements)

As a second mapping we will provide the mapping of exchange rules in the process perspective. The collection of exchange rules basically limits the playing field on how instances of a ‘base- or asserted fact type’ [21, p.99] can be added to or removed from the information base. In fact-oriented process- and event models we can consider the ‘fact-creating’ activities as processes that can no longer be decomposed. This means that the mapping onto BPMN models is always on a task level. For a discussion on ‘conceptual-process’ types as ‘fact-creating’ activities we refer to [7, 17, 22, 23]. In figure 3 we will only display the graphical BPMN elements (and therefore leave out the attributes for the activity). As an example of how we can use the process attributes to capture the semantics in the process-oriented perspective we have given the attribute values for the process dr1 in table 1 including the related input sets, output sets and IOrules attributes. The fact types that are used in a condition and/or expression in the derivation rules are contained in the BPMN input set of the activity. The resulting fact type that is connected to the ORM derivation rule will be mapped Table 1. Attribute values for process dr1: calculate total number of patients Attributes Activity type Input set Output set IOrules

Prop/attribute artifactInput artifactOutput

value for dr1 Task: calculate total number of patients Data-object Ft4 Data-object total number of patients IF EXT (Ft4) is empty THEN total number of patients.R1:=0 ELSE total number of patients. R1:=COUNT(EXT(Ft4)) ENDIF

644

P. Bollen

as an output set. The ‘derivation algorithm’ in the ORM derivation rule will be mapped onto the activity’s IOrules attribute. Furthermore we will use the assignment attribute modeling construct to capture the (values of) the fact-oriented process argument and we will set the assign time attribute equal to ‘start’. 4.2 Mapping of the Fact-Oriented Models in the Event-Perspective to the BPMN The third mapping that we will illustrate concerns the mapping of event rules onto the BPMN modeling constructs. In the event rules we will first map the event concept in an event. The impulse mapper construct encodes how a derivation/exchange rule argument is instantiated as a function of (amongst others) the value of the event argument. The impulse mapper will be modeled in BPMN as an assignment connected to the activity that is triggered by the event. In figure 4 and table 2 a transformation is shown for an event rule in which a condition must be satisfied before an event occurrence will lead to the execution of a derivation rule and/or exchange rule. In table 2 we have provided the attributes and values for the BPMN model elements that together represent the fact-oriented event rule 2 from the PDO example. Table 2. Attribute values for event rule 2: unknown patient requests for appointment Event Attribute Event name Event type Condition Attribute Condition expression Activity Attribute Activity type Input set properties

Output set IOrules

Assignments

value E1: Person wants to make doctor’s appointment Start value Dr2: Determine patient status (arg1= ‘E1.arg1’, arg2= ‘E1.arg2’, arg3= ‘E1.arg3’) = ‘Patient is not yet known’ value

data object 1 data object 2 arg1 arg2 arg3 arg4 arg5 data object 1,2,3,4,5

Task: Ex1: register patient Ft12 Total number of patients first name, surname, date of birth, address, place of residence Ft1, Ft2, Ft3, Ft4, Ft5 IF [total number of patients< EXT(Ft12.R1) (where Ft12.R2=’arg6’)] THEN CREATENEWPATIENTNUMBER: [a][ADD an instance of FT1 to the ib where Ft1.R2:= ‘a’ and Ft1.R1:= ‘arg2’ AND ADD an instance of FT2 to the ib where Ft2.R1:= ‘a’ and Ft2.R2:= ‘arg1’ AND ADD an instance of FT3 to the ib where Ft3.R2:= ‘a’ and Ft3.R1:= ‘arg3’ AND ADD an instance of FT4 to the ib where Ft4.R2:= ‘a’ and Ft4.R1:= ‘arg4’ AND ADD an instance of FT5 to the ib where Ft5.R2:= ‘a’ and Ft5.R1:= ‘arg5’] ELSE DISPLAY (‘Maximum patient capacity has been reached’) ENDIF Ex1.arg1:= ‘E1.arg1’; Ex1.arg2:= ‘E1.arg2’; Ex1.arg3:= ‘E1.arg3’

BPMN as a Communication Language

645

5 The BPMN Example of the Combined Process and Event Perspectives of the PDO Case Study In section 4 we have illustrated how the fact-oriented process- and event models can be mapped onto BPMN ‘ad hoc’ process model fragments. A specific ‘process- flow’ that can be implemented in an organizational setting, might, however require, more constraints in terms of process precedence requirements, parallelization, other than the ones that are already enforced, for example by process pre-conditions. In terms of business and cost considerations, one specific activity sequence might be favoured over other ones. This phenomena was illustrated in chapter 15 of Halpin and Morgan [21]. In this ‘sampling methodology’ example it was perfectly illustrated how business considerations, e.g. minimizing total costs, can lead to favour one ‘BusinessProcess Design’ over another one, not-withstanding that the underlying facts and activities are identical. In this section of this paper we will give one preferred ‘Business-Process-Design’ for the complete PDO case study [18] (for a complete description of the derivation-, exchange- and event-rules we refer to [16]), by embedding the activities, sequence flows, events that resulted from section 4 in the textual description of the PDO case study using, a specific set of consistent assumptions to create the ‘specific business process design’. In figure 4 we have used the ad-hoc business process model and event-rules from the fact-oriented conceptual model as ‘building blocks’ for the ‘Business’ BPMN model. We thereby, have added the behaviour of the external actors, by adding ‘external actor’ pools and additional message flows, that were not part of the factoriented process- and event models. If we inspect the BPMN model in figure 5, we can see that there are only three ‘external’ events that we need to distinguish in order to execute an instance of each of the three business processes: person needs an appointment, person wants to cancel an appointment, and person has shown up at the appointment. Furthermore, we have left out all the data-objects and their associations, as they were given in the ‘ad-hoc’ process model along the lines of the ones illustrated in figure 3. By going through the textual description of the PDO case study, we will use the application information grammar, the application process description (which includes the derivation- and exchange rules) and the application event description as a starting point for determining the consistency and completeness of the BPMN description. The model modules that we have created by mapping the fact-oriented models onto an ‘ad-hoc’ BPMN process model, now have to be ‘connected’ in combination with the application’s event description as follows: 1) Combine events under disjunct conditions into one event-gateway. 2) Check that every (relevant) fact-oriented process (from the ‘ad-hoc’) model, appears in at least one business process, in the business process diagram 3) Model activities that performed by the ‘outside’ actors in a separate pool Now the business process diagram can be abstracted to create bird’s eye views for different business user groups.

Person

Doctor’s office

Person

Doctor’s office

person wants to cancel an appointment

Illness of a person

patie nt ?

Determine appoint ment s tat us

no

no

yes

appointment exists ?

yes

provide request ask name, name, appointment s urname, datesurname, date of birth, cancellation of birth, a[ppointment appointment time time

Contact docter’s office

Dr2: Determine patient s tat us

provide ask name, surn ame, date name, surname, date reques t of birth of birth Known ap pointmen t

Contact docter’s office

Ex1 0: Cancel appo int ment

Dr1: Calculat e t otal n umb er o f patient s

Ex7: add doctor time slot

Ex 1: register pati ent

ask address, address, place of place of residence residence

Provide additional information

Maximum capacity reached ?

yes no

no

person has shown up at appointment

Ex14: Add (new) preferred time slot

as k preferred preferred time slo t time slot (and doctor)

Provide (new) pref erre d time slot and pref erred doctor

Person Doctor’s offi ce

Determine appoin tment status

no

yes

yes

Dr6: Find closest doctor prefe rre d time -slot

Ex11: Ad d appoi ntment has taken place

Ex9: Add appoi ntment

no

doctor time slot available ?

Dr 4: Check availability doctor pr efer red time-slot

appointm ent exists ?

Ex12: Add preferred doctor

provide as k name, reques t name, appo intment surname, date cancellation of birth, surname, date of bir th, a[ppointment appointment time time

visit docter’s office

yes

time slot available ?

Dr 3: Che ck availability pr eferred time-slot

no

yes

is there a preferred doctor ?

Pr ovide (new) prefe rre d time slot and pref erre d doctor

646 P. Bollen

Fig. 4. Business Process Diagram

The advantage of mapping the fact-oriented models onto a BPMN process model is that the ‘lowest-level’ or the ‘task-level’ of activities is known. Furthermore all necessary, information processing activities are known, and will have to be covered as some element in a BPMN model. In addition, we will be able to model the ‘process’

BPMN as a Communication Language

647

and ‘event’ arguments with the messages that are sent between organizational objects in different pools. A summary of this BPMN-based business model creation process is given in table 3. Table 3. Business model creation process using fact-orientation and BPMN Stage Stage 1: Create information model Stage 2: Create process description

Input document Data use cases

Stage 3: Create event description

Application information model, Application process description, Textual description of case study Application process description,

Stage 4: Create BPMN ‘ad hoc’ process model. Stage 5: Create application Business process Diagram

Application information model, Textual description of case study

‘ad-hoc’ business process model, Application event description Textual description of case study, Consistent set of assumptions.

Resulting document Application information Model Application process description (including derivation rules and exchange rules) Application event description (event rules) ‘ad-hoc’ process model that includes data-objects (as in figure 3) BPMN model that excludes data objects (as in figure 5)

6 Conclusion In this paper we have demonstrated how BPMN can serve the requirement of modeling the (fact-oriented) features in the process- and event perspectives, as expressed in derivation rules, exchange rules and event rules, and the requirement to enable us to record the formal properties of those perspectives that can be used to implement the functionality in software systems. An important role is played by the ‘data-object’ construct because it contains (instances of) fact types. Another important modeling feature in BPMN that we have applied are the miscellaneous nongraphical attributes that are defined for the core BPMN modeling elements. These non-graphical attributes allow us to capture completely and precisely the remaining formal properties of the conceptual models in the process- and event perspectives of a subject-area. It is recommended to start such an analysis by analyzing ‘data use cases’ [21, p.7], thereby abstracting them into an application information grammar. Subsequently, a fact-oriented process and event description can be generated. In the fourth stage, the fact-oriented conceptual models can guide us in this process by mapping the said models onto an ‘ad-hoc’ BPMN process model. In stage five we can analyze the (description of an) application area to create a a ‘bird’s eye’ BPMN model, in which the associated data-objects are left out, to avoid ‘clutter’ [14, p.93].

References 1. Halpin, T.: Information Modeling and Relational Databases; from conceptual analysis to logical design. Morgan Kaufmann, San Francisco (2001) 2. Verheijen, G., van Bekkum, J.: NIAM: An Information Analysis method. In: IFIP TC-8 CRIS-I conference. North-Holland, Amsterdam (1982)

648

P. Bollen

3. Lemmens, I., Nijssen, M., Nijssen, G.: A NIAM 2007 conceptual analysis of the ISO and OMG MOF four layer metadata architectures. In: Meersman, R., Tari, Z., Herrero, P. (eds.) OTM-WS 2007, Part I. LNCS, vol. 4805, pp. 613–623. Springer, Heidelberg (2007) 4. Morgan, T.: Some features of state machines in ORM. In: Meersman, R., Tari, Z., Herrero, P. (eds.) OTM 2006 Workshops. LNCS, vol. 4278, pp. 1211–1220. Springer, Heidelberg (2006) 5. Balsters, H., et al.: Modeling dynamic rules in ORM. In: Meersman, R., Tari, Z., Herrero, P. (eds.) OTM 2006 Workshops. LNCS, vol. 4278, pp. 1201–1210. Springer, Heidelberg (2006) 6. Nijssen, G.: Kenniskunde 1A. PNA Publishing Heerlen (2001) 7. Bollen, P.: Conceptual process configurations in enterprise knowledge management systems. In: Applied computing 2006. ACM, Dijon (2006) 8. Morgan, T.: Business Process Modeling and ORM. In: ORM 2007 workshop presentation slides (2007) 9. Balsters, H., Halpin, T.: Formal Semantics of Dynamic Rules in ORM. In: Meersman, R., Tari, Z., Herrero, P. (eds.) OTM-WS 2008. LNCS, vol. 5333, pp. 699–708. Springer, Heidelberg (2008) 10. Bollen, P.: Fact-Oriented Business Rule Modeling in the Event Perspective. In: CAISEforum 2007 (2007) 11. zur Muehlen, M., Indulska, M., Kamp, G.: Business Process and Business Rule Modeling: A Representational Analysisin. In: VORTE 2007 Workshop (2007) 12. Bollen, P.: The orchestration of Fact-Orientation and SBVR. In: 14th international conference, EMMSAD 2009, Amsterdam, the Netherlands. Springer, Heidelberg (2009) 13. Bollen, P.: SBVR: a fact oriented OMG standard. In: OTM workshops 2008, Monterry, Mexico. Springer, Heidelberg (2008) 14. OMG, Business process modelling notation (BPMN) OMG available specification v 1.1. 2008, OMG (2008) 15. White, S.A.: Introduction to BPMN. On demand business Volume (2006) 16. Bollen, P.: Fact-oriented modeling in the data-, process- and event perspectives. In: Meersman, R., Tari, Z., Herrero, P. (eds.) OTM-WS 2007, Part I. LNCS, vol. 4805, pp. 591–602. Springer, Heidelberg (2007) 17. Bollen, P.: Fact-Oriented Business Service Modeling. In: 12th international workshop on Exploring Modeling Methods in Systems Analysis and Design (EMSSAD 2007), Trontheim, Norway (2007) 18. Patient and Doctor’s office 1.5, in White, S. (2006) 19. Nijssen, G.: Semantics for Business: a process to specify the most important business rule in SVBR. Business Rules Journal 8(12) (2007) 20. Bollen, P.: Extending the ORM conceptual schema language and design procedure with modeling constructs for capturing the domain ontology. In: Halpin, T., Krogstie, J., Proper, E. (eds.) Innovations in Information Systems Modeling; Methods and best Practices, pp. 53–67. Information Science Reference, Hershey (2009) 21. Halpin, T., Morgan, T.: Information Modeling and Relational Databases; from conceptual analysis to logical design, 2nd edn. Morgan-Kaufman, San-Francisco (2008) 22. Bollen, P.: A process description language and method for organizational processes in Universal Informatics. In: Second NIAM- ISDM working conference, Albuquerque, New Mexico, USA (1994) 23. Bollen, P.: A Conceptual Modeling Language for the Adequate Design of Business Processes. In: BPMDS 2007, Trontheim, Norway (2007)

A Model for Semantic Equivalence Discovery for Harmonizing Master Data Baba Piprani MetaGlobal Systems, Canada [email protected]

Abstract. IT projects often face the challenge of harmonizing metadata and data so as to have a “single” version of the truth. Determining equivalency of multiple data instances against the given type, or set of types, is mandatory in establishing master data legitimacy in a data set that contains multiple incarnations of instances belonging to the same semantic data record . The results of a real-life application define how measuring criteria and equivalence path determination were established via a set of “probes” in conjunction with a score-card approach. There is a need for a suite of supporting models to help determine master data equivalency towards entity resolution---including mapping models, transform models, selection models, match models, an audit and control model, a scorecard model, a rating model. An ORM schema defines the set of supporting models along with their incarnation into an attribute based model as implemented in an RDBMS. Keywords: Entity Resolution, Master Data, Semantic Equivalence, semantic interoperability, data equivalency.

1 Data Redundancy and Integration Issues Data duplication and data integrity are major issues confronting IT applications today. It is not uncommon to come across multiple sets of redundant data on customers and other items of primary focus in an organization. A good average figure that is the norm is that there is about 30 to 60 percent redundant data or duplicated data on clients or customers in a typical organization. The search goes on ….for the ‘single version’ of the truth. Enter Master Data Management, which basically refers to non-transactional data, or reference data. There are basically 2 kinds of reference data---the common reference data like types and categories of data pertaining to the properties or characteristics of data, and the other being ‘master file’ type data like, customers, clients, vendors, products etc…essentially data that the organization uses for tracking through transactions. Both of these types of reference data need to be harmonized and coordinated. Many events occur during the life cycle of an organization that causes data to ride the redundancy paddy wagon. Mergers, acquisitions, or even simple lack of governance controls, poorly defined business processes etc. contribute towards multiple copies of client data, creating exponentially increasing issues of data integration. R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 649–658, 2009. © Springer-Verlag Berlin Heidelberg 2009

650

B. Piprani

This paper addresses a model for the solution steps to be taken that are involved in integrating or harmonizing such data, as implemented in an on-going application shown as a use case.

2 Background of Use Case A critical air traffic situation arose in Canada on September 11, 2001 where hundreds of planes bound to the US over the Atlantic were re-routed to Canada. There was an urgent flurry of activity to determine the most suitable and critical match between airport runaway properties; emergency service facilities; airside airport services; passenger airport facilities etc. and, the incoming aircraft with respect to the aircraft type; aircraft size; number of passengers in each aircraft; fuel conditions in each aircraft etc. This presented a Herculean task for Transport Canada (TC), the regulatory agency responsible for the transportation sector in Canada, to access such data across multiple applications on demand! Needless to say, not all applications were in a condition to be cross-navigated considering the urgent timing of the requirement. There was lack of navigability across the various involved systems for items like Airport locations, aircraft types, cities within Canada, etc. In other words, each application and database has its own native referencing scheme that did not permit establishing of cross-walks at the metadata nor the value based level. Some underlying issues: -

-

Mappings were not always available (no total 1:1). In other words, not all airport locations had ICAO codes or IATA codes, since Canada has CFS (Canadian Flight Supplement) codes for the domestic airports. Inconsistent identification and different terminology for referencing the same concept. Inconsistent identification of the different types of aircraft. rounding errors for latitude/longitude produced multiple airports at exact same location Cities within Canada were inconsistently referenced across multiple databases….and so on.

The Transport Canada - Transport Object Dictionary (TOD) project was born to establish a cross-walk across the various applications so that a virtual access approach is feasible by establishing common mappings across various applications and using these common mappings to automatically access data across applications thus simulating a virtual on-demand data warehouse [1] so as to be able to conduct Business Intelligence analysis scenarios. In order to establish this, one of the first steps was to harmonize data based on selected main concepts---Location, Carrier Organizations, Carrier Individuals, and Aircraft etc.

3 Establishing Semantic Mapping - An ORM Mapping Model (Type Level) One of the first steps in the semantic equivalency exercise is to determine the source and target mappings. As explained in [1], in the absence of one finite or global

A Model for Semantic Equivalence Discovery for Harmonizing Master Data

651

Fig. 1. Mapping to a global identifier

identifier for a defined location, a global identifier was established and the mappings were done from the source to the target global identifier only, see Fig. 1. There are several papers written in the area of semantic interoperability and entity resolution see [10-15] and works by Embley and Ullman. Most of the literature deals with schema mapping and wrappers using semi-automated means to establish mappings. However, in practice, the lack of data quality, the inconsistency of data, the lack of standard formats, typographical misspellings, typo errors, non-standard notations say for organizations, colloquial names, abbreviations, whitespaces etc., cause serious matching problems in de-duplication or merging for entity resolution. More often than not, there is a serious lag or gap of enterprises in adopting the industry accepted practices for coding or naming is not followed, thus creating a plethora of variants within the same business community. The common message that comes across is that this integration step of mapping and merging for entity resolution is not a trivial task and there is much work ahead. Mapping across data attributes needs to be harmonized at 2 levels---the metadata level (or type) and at the value level (instance), beginning with the type level and to progress the implementation to the instance level. The TOD project first developed a metadata cross-walk across multiple applications determining the best fit for the metadata mappings using the accompanying ORM Mapping Model as in Fig. 2. The ORM Mapping Model shows mappings between a source data element in the form of a qualified column being mapped to a target qualified column. The model addresses renaming, conversion, filtering, transformation and introduction of a global identifier. Only a partial model is shown that is relevant to the mappings. Other parts of the model contain the mapping and referencing to the data element as defined in the ISO Metadata Registries standard [2], which is not shown.

Fig. 2. ORM Mapping Model (type level)

652

B. Piprani

As ide from the source-target (from-to) mappings based on a column list that represents one or more qualified columns, the mapping model also uses other mapping sub-models: Boundary Conditions ; CAST descriptor; Mapping Criteria; Transform Criteria; and Filter Criteria. These sub-models contain criteria that are effective for the global set of values at the metadata level and not against operations on an individual row set. Boundary Conditions: denotes range, or value or other integrity constraint on the involved column(s) for mapping purposes to be included in the data mapping, usually denoted and exercised by an SQL CHECK clause or User Defined Function. e.g. The carrier UID in CPF is CHECK (carrierUID BETWEEN 1 AND 999999). Contains the actual CHECK clause to be used that can be automatically included in a dynamic SQL statement. CAST descriptor: Any data type conversions on a global scale (see later section for value based CASTing), usually exercised via an SQL CAST predicate. Contains the actual CAST predicate to be used that can be automatically included in a dynamic SQL statement. Mapping Criteria: Any matching criteria beyond the involved columns that affect the mapping e.g. where type=xx, colour = yy etc. Transform Criteria: Any conversion or transform that includes a change of variables or coordinates in which a function of new variables or coordinates is substituted for each original variable, e.g. old Address Type = 2, becomes new Address Type = Business. Contains the actual User Defined Function or code snippet to be used that can be automatically included in a dynamic SQL statement. Filter Criteria: Any applicable controlling criteria to limit the values of the selected set. Contains the actual User Defined Function or code snippet to be used that can be automatically included in a dynamic SQL statement.

4 Establishing Semantic Mapping - An ORM Mapping Model (Instance Level) The ORM Mapping Model at the type level is useful as the meta driver for any Extract Transform Load utilities and for generating dynamic SQL statements to drive the data transfer or migration based on the established mappings. Taking the ORM Mapping Model to the instance level, the ORM Mapping Model (instance level) shows the exact transforms to be used for a given local row level instance, as seen in Fig. 3. The ORM Mapping Model at the instance level is used to cross-correlate or establish concordance between values from one application system to another. An example would be if the row of data pertaining to Ottawa Airport Location denoted by IATA code YOW has a primary key column in Application A with value 1111, which is mapped to Application B which has a primary key column <primary airport id> with value 2259, the ORM Mapping Model (type level) will

A Model for Semantic Equivalence Discovery for Harmonizing Master Data

653

Fig. 3. ORM Mapping Model (instance level)

contain the mappings between Application A as mapped to Application B <primary airport id>, while the exact values for ‘Application A (1111) as mapped to application B (2259) will be contained in ORM Mapping Model (instance level). The ORM Model (instance level) is used to establish precise cross-walk navigation between applications. Also applicable at this instance level are local row specific mapping criteria and transform criteria. It is important to note some of the background work in the area of semantic mapping that is now being promulgated as an ISO standard (ISO 20943-5 Semantic Metadata Mapping Procedure).

5 ISO Standard Work in Progress for Semantic Metadata Mapping Procedures It is important to note that ISO IEC (WD) 20943-5 Semantic Metadata Mapping Procedure [3] attempts to formulate an orderly approach to setting up procedures for enabling metadata mappings based on the ISO 11179-3 Metadata Registries standard. In brief, the ISO IEC (WD) 20943-5 Semantic Metadata Mapping Procedure defines types of Semantic heterogeneities [4] as: Hierarchical Difference - due to different level of detail, and generalization, specialization, composition, Decomposition; Domain Difference – due to different context and culture, and due to different context and culture; Lexical Difference – in different appearance, including synonyms, abbreviations, acronyms, case sensitivity, language, and variation; Syntactic Difference – due to different arrangement of parts, or ordering, delimiters, missing parts; and, Complicated Differences – due to different policies. The ISO standard work is still in its beginning stages and needs to mature--particularly to take note of previously published work. This ISO Standard is expected to be published as a Technical Report in 2012.

6 Determining Equivalency – Probes In a practical real implementation in the TOD project, a semantic mapping exercise was conducted for “Location”, where a location is defined as “A spatial area

654

B. Piprani

designated for purposes of transportation that is of regulatory interest to Transport Canada” e.g. Airport, Marine port, Rail station, Road Station etc. While it was a relatively simple task to establish metadata mappings for Location, the task of integrating the data at the value level proved to be a challenging task. The objective was to establish value equivalency with each of the participating applications, each of which had their own identification scheme and alias code. A location alias was defined as: “Concordance or cross-reference of stated location with any other organization assigned identifiers or codes for airports, ports, train stations etc. e.g. IATA or ICAO codes for Airports, UN/LOCODE for trade including other organizations like US Federal Aviation Administration FAA etc. While some locations had an IATA code, others had only ICAO codes, and if the locations were strictly local within Canada, they had the Canadian Flight Supplement (CFS) code etc. That means, a major airport say, Montreal, could have an IATA code, ICAO code and CFS code, while a smaller domestic only airport could only have a CFS code. The situation is exacerbated with the practice of the assignment of makeup alias codes by each of these organizations---conducted as an interim measure while a permanent code is in the approval process. Here is a sample model that contributed to determining the harmonization of Location, using a decision tree approach, and, a set of probes that were written to investigate whether the given location was a member of a particular set or not. The “probes” were SQL code snippets in the form of User Defined Functions that would essentially “probe” the membership validity of a given instance in a desired set. See model along with probe scoring as in Fig. 4. As mentioned earlier, not all locations had all aliases or geo coordinates available. The other identifying attributes like city name, address, airport name, postal code etc. were localized non-standard interpretations containing variants, which could not directly be used to establish equivalency. It was easy to establish equivalency on the alias codes and coordinates (again here within a threshold since each of the readings could be off by several decimal points---some coordinates may refer to the airport, some coordinates may refer to the city to which the airport belongs etc).

Fig. 4. Probe Based Model for Determining Location Equivalency

A Model for Semantic Equivalence Discovery for Harmonizing Master Data

655

In the example shown in Fig. 4, it was easy to establish equivalency confirmation using probe LP2 and LP3 provide a result of H+, which means we are able to confirm the equivalency of that location based on the 2 mandatory critical criteria matches ALIAS and COORD (geo-coordinates), while probe LP4 provided a no-match condition with an L rating since only low level matches were available for city, Address and Airport names—meaning there were syntactical variations. To standardize the syntactic variations, each of the columns being compared had their whitespaces, special characters, noise characters removed and the syntactic names compressed for matching. But these would not take care of misspelled or flipped characters e.g. ‘abc’ vs ‘acb’. We assigned a score of 3 for High, 2 for Medium, and 1 for Low, but doubled the number for the definitive attributes of Alias and Geocode matches. Then we added up the individual score from the probes and divided by the total max score of the attributes involved or where they were available to come up with a final score. We found that we could trust the ratings at H- and over, which were put through the automated transfer cycle. Those probe results that produced anything less than Hhad to go through a manual review. We also found many of the M+ ratings acceptable with minor corrections made to syntax string values. A probe orchestration sequence model was established as is shown in the later section. This enabled conditional branches and probe activation based on the results (post conditions) of the previous probe result.

7 An Implementation of the ORM Mapping Models Probes To automate much of the probe processing and Extract Transform and Loading processes, the ORM Mapping models shown earlier were implemented in ISO SQL 9075 Database Language SQL standard implementations or a variant thereof. The attribute based schema is shown in Fig. 5, which is an implementation of the ORM Z844_APPLICATION_CONCEPTZ844__Z842__FK

Z842_APPLICATIONS

APPLICATION_NM: varchar(20) (FK) CONCEPT_NM: varchar(20) (FK)

APPLICATION_NM: varchar(20)

Z844__Z841__FK

Z851_COMMON_MAPPING_CMK COLUMN_LIST_ID: varchar(128) APPLICATION_NM: varchar(20) (FK) (AK1.1) CONCEPT_NM: varchar(20) (FK) (AK1.2) SUB_CONCEPT_NM: varchar(20) (FK) (AK1.3 CASE_NM: varchar(20) (FK) (AK1.4) REMARKS_TXT: text SELECT_QUERY_TXT: varchar(1000) Z851__Z845__FK

Z846__Z842__FK

Z846_DATABASE_APPLICATIONS DATABASE_NAME_NM: varchar(128) (FK) APPLICATION_NM: varchar(20) (FK)

Z845__Z844__FK

Z845_APPLN_CONCEPT_SUB APPLICATION_NM: varchar(20) (FK) CONCEPT_NM: varchar(20) (FK) SUB_CONCEPT_NM: varchar(20) (FK) CASE_NM: varchar(20) (FK)

Z841_CONCEPT CONCEPT_NM: varchar(20)

Z932__Z851__FK Z932__Z930__FK

Z932_COLUMN_LIST

Z845__Z847__FK

COLUMN_LIST_ID: varchar(128) (FK) (AK2.1) ORDINAL_NBR: smallint DATABASE_NAME_NM: varchar(128) (FK) TABLE_NAME_NM: varchar(128) (FK) COLUMN_NAME_NM: varchar(128) (FK) (AK2.2

Z852__Z932__FK

Z931_DATATYPES DATATYPE_TXT: varchar(128) (AK1.1

Z852__Z932__FK

Z846__Z923__FK

SUB_CONCEPT_NM: varchar(20)

Z852_AOD_CMK_MAPPING COLUMN_LIST_ID: varchar(128) (FK) ORDINAL_NBR: smallint (FK) MAP_TO_COLUMN_LIST_ID: varchar(128) (FK) MAP_TO_ORDINAL_NBR: smallint (FK) BOUNDARY_CONSTRAINT_TXT: text CAST_TXT: text MAPPING_CRITERIA_TXT: text TRANSFORM_CRITERIA_TXT: text REMARKS_TXT: text FILTER_CRITERIA_TXT: varchar(500)

DATATYPE_CD: varchar(128)

Z847_SUB_CONCEPT_CASE SUB_CONCEPT_NM: varchar(20) (FK) CASE_NM: varchar(20)

Z930_COLUMNS Z930__Z919__FK

Z930__Z931__FK

COLUMN_NAME_NM: varchar(128) DATABASE_NM: varchar(128) (FK) TABLE_NAME_NM: varchar(128) (FK)

Z853__Z852__FK

Z853_AOD_CMK_VALUE_MAPPING COLUMN_LIST_ID: varchar(128) (FK) ORDINAL_NBR: smallint (FK) COLUMN_VALUE_TXT: varchar(200) MAP_TO_COLUMN_LIST_ID: varchar(128) (FK) MAP_TO_ORDINAL_NBR: smallint (FK) MAP_TO_COLUMN_VALUE_TXT: varchar(200) DATE_START_DTE: datetime

DATATYPE_CD: varchar(128) (FK) DATASIZE_NBR: smallint DATASCALE_NBR: smallint DATAPRECISION_NBR: smallint DEFINITION_TXT: text CONSTRAINT_RULE_TXT: varchar(500) SEARCH_CONDITION_TXT: varchar(1000)

Z923_DATABASES DATABASE_NAME_NM: varchar(128

Z919_TABLES

CONNECT_LINK_TXT: varchar(500)

MAPPING_VALUE_CRITERIA_TXT: text TRANSFORM_VALUE_CRITERIA_TXT: text REMARKS_TXT: text DATE_STOP_DTE: datetime

DATABASE_NAME_NM: varchar(128) (FK TABLE_NAME_NM: varchar(128) GROUP_ID: varchar(4) (FK) HISTORY_CURRENT_TYPE_CD: char(1) SHARED_TABLE_IND: char(1) SUBJECT_AREA_ID: integer (FK) TABLE_TYPE_CD: varchar(20) (FK)

Z843_SUB_CONCEPT

Z919_Z923_FK

Fig. 5. Implementation Model of ORM Mapping Models (CMK)

Z847__Z843__FK

656

B. Piprani

mapping models that has proven itself over many projects through thick and thin over the last 10 years in Oracle and SQL Server DBMSs. Each concept like “Location”, “Carrier”, ‘Aircraft”, “Make-Model” has mappings established from various systems into the TOD, where TOD provides a central cross-reference and bridge to enable navigation across various participating applications via the Centralized mapping model, affectionately termed as the CMK (Common Mapping Key) Model.

8 Audit and Control – for Loading and Probe Tracking Due to the many probe attempts involved, it is necessary to track the complete process of Extraction Transformation and Loading as the main thread, and, as a secondary thread, the tracking of the orchestrations of probe sequences. An implementation model of how such tracking was achieved is shown as in Fig. 6: Z1910_PROBES PROBE_ID

Z1901_SUB_RUNS

DATE_CREATED_DTE PROBE_TYPE_CD PROBE_NM (AK1.1) PROBE_DESCRIPTION_TXT PROBE_LOCATION_TXT REMARKS_TXT

RUN_ID SUBRUN_ID

R/1013

DATE_SUBRUN_START_DTE DATE_SUBRUN_END_DTE PROBE_ID (FK) SUBRUN_TYPE_CD VERSION_NBR (FK) REMARKS_TXT

PROBE_ID (FK) VERSION_NBR

Z1905_RUN_ROWS RUN_ID DATABASE_NAME_NM TABLE_NAME_NM RPR_ROW _ID

Z1902_SUBRUN_TABLES

Z1912_PROBE_CHECKS APPLICATION_NM (FK) CONCEPT_NM (FK) SUB_CONCEPT_NM (FK) CASE_NM (FK) PROBE_ID (FK) VERSION_NBR (FK)

RUN_ID (FK) SUBRUN_ID (FK) DATABASE_SOURCE_NM TABLE_SOURCE_NM DATABASE_TARGET_NM (FK) TABLE_TARGET_NM (FK)

PARENT_RPR_ROW_ID (FK) ROW_TRANSFER_TYPE_CD (FK) DATE_ROW _TRANSFER_OK_DTE REMARKS_TXT

R/1456

PROBE_VERSION_DESCRIPTION_TXT PROBE_SOURCE_SYNTAX_TXT PROBE_SPECIFIC_LOCATION_TXT REMARKS_TXT

Z1904_SUBRUN_ROW_CONDITION

CHECK_SUCCESS_PCT REMARKS_TXT

R/972

R/1011

TR51_ROW_CONDITION ROW_CONDITION_CD

TR52_ROW_TRANSFER_TYPE

ROW_CONDITION_ETXT (AK1.1) ROW_CONDITION_FTXT (AK2.1)

TARGET

ROW _TRANSFER_TYPE_CD

R/980

Z1911_PROBE_VERSION R/1008

RUN_ID (FK) SUBRUN_ID (FK) DATABASE_TARGET_NM (FK) TABLE_TARGET_NM (FK) RPR_ROW_ID ROW _CONDITION_CD (FK) DATE_ROW_CONDITION_DTE REMARKS_TXT

R/977

ROW _TRANSFER_TYPE_ETXT (AK1.1) ROW _TRANSFER_TYPE_FTXT (AK2.1)

Z845_APPLN_CONCEPT_SUB Z1903_SUBRUN_TARGET_TABLES RUN_ID (FK) SUBRUN_ID (FK) DATABASE_TARGET_NM TABLE_TARGET_NM

R/1455

APPLICATION_NM CONCEPT_NM SUB_CONCEPT_NM CASE_NM

R/1015

Fig. 6. Probe Tracking Model (partial)

A “run” is established for the Extraction, Transform and Loading of data being migrated from source to target based on the ORM Mapping Models. This ”run” follows the Audit and Control Schema parameters as established in [5] the Data Quality Firewall architecture for an Advanced Generation Data Warehouse. Within this “run” there could be several probe “sub-runs”. The model in Fig. 6 tracks the results from each probe evaluating the post-conditions and rating whether that row under “probing” is ready for insertion as a new row occurrence of “Location” or is really an already established “location” occurrence. Based on the probe score, the sub-run model would essentially be the decisionmaker for the incoming row that is to be merged or mapped, or even whether to be accepted for integration. In other words, this part of the model essentially provides the intelligence for an SQL ‘MERGE’ or ‘INSERT’ operation that follows. We did come across occasions where we needed to spice up some of the specialized versions of the probes after ‘learning’ from a probe run, and to incorporate this intelligence in the new version. That is why versioning played an important part of the probe sequence.

A Model for Semantic Equivalence Discovery for Harmonizing Master Data

657

9 Use Case of a Successful Implementation in Practice The use case as part of the TOD project is in the process of successfully analyzing data from multiple sources to build a Master data set consisting of “multiple versions” versus the common notion of a “single version”. Why? We felt we could not ignore the local version that is in use in a particular application, and that there was no mandate for that local application to switch to a master data version (single version). Reality dictated that we keep track of each of the local versions, yet establish bridges across the multiple versions in order to establish navigation and access as shown below in Fig. 7. [9]:

Fig. 7. Using TOD to Bridge Across Heterogeneous Applications

The application set essentially houses the metadata mapping intelligence in the TOD master database and the Common Mapping Key database. Wrappers are dynamically generated from the metadata in these databases for loading, or for remote retrievals as needed on demand. Business Intelligence tools are used to pull in and analyze the available data housed in heterogeneous databases at their own sites. In summary, the TOD project at Transport Canada is successfully using Object Role Modelling [6] as their base semantic modeling method, interacting with the user community with natural language sentence constructs, and using ISO TR9007 [7] as the kingpin pivot for all rule declarations---at the same time, meeting the realistic corporate requirements of TC naming standards, attribute grouped data models using ERWin, and SQLServer and Oracle DBMSs based on maximizing essential ISO 9075 Database Language SQL [8] Schema declarative statements.

Acknowledgement I would like to acknowledge and thank the Transport Canada TOD (Transport Object Dictionary) team, staff and users, Michel Villeneuve, Madhu Hundal, Tom Nash, Vasko Miovski, Dave McCutcheon, Rob Henkel, Wayne Shimoon, Jean-Pierre

658

B. Piprani

Sabbagh El Rami, Jean Yves Cadieux, Iain Henderson, and Dave Dawson for their support and advice in establishing the necessary mapping algorithms and developing probes in support of this successful application.

References 1. Piprani, B.: Using ORM in an Ontology Based Approach for a Common Mapping Across Heterogeneous Applications. In: Meersman, R., Tari, Z., Herrero, P. (eds.) OTM-WS 2007, Part I. LNCS, vol. 4805, pp. 647–656. Springer, Heidelberg (2007) 2. International Standard ISO IEC 11179:2003 Metadata Registries, International Standards Organization, Geneva 3. International Standard (WD) ISO IEC 20943-5:Semantic Metadata Mapping Procedure, International Standards Organization, Geneva 4. Semantic Metadata Mapping Procedure and Types of Semantic Heterogeneity, Tae-SulSeo, Korea Institute of Science and Technology Information, 12th Annual Forum for Metadata Registries, Seoul, Republic of Korea, June 18-19 (2009) 5. Meersman, R., Tari, Z., Herrero, P.: Using ORM-based models as a foundation for a data quality firewall in an advanced generation data warehouse. In: Meersman, R., Tari, Z., Herrero, P. (eds.) OTM 2006 Workshops. LNCS, vol. 4278, pp. 1148–1159. Springer, Heidelberg (2006) 6. Nijssen, G.M., Halpin, T.A.: Conceptual Schema and Relational Database Design. Prentice Hall, Victoria (1989) 7. van Griethuysen, J. (ed.): Technical Report on Concepts and Terminology for the Conceptual Schema and the Information Base. ISO Technical Report ISO IEC TR9007:1987. International Standards Organization, Geneva (1987) 8. International Standard ISO IEC 9075:1999. Database Language SQL. International Standards Organization, Geneva (1999) 9. Piprani, B.: Ontology Based Approach to a Common Mapping across Heterogeneous Systems. Presentation at Metadata Open Forum, New York (2007), http://metadataopenforum.org/index.php?id=2,0,0,1,0,0 10. Visser, J.: Finding nontrivial semantic matches between database schemas, Masters Thesis University of Twente Publications, Netherlands (July 2007), http://doc.utwente.nl/64138/ 11. Garcia-Molina, H.: Entity resolution: Overview and challenges. In: Atzeni, P., Chu, W., Lu, H., Zhou, S., Ling, T.-W. (eds.) ER 2004. LNCS, vol. 3288, pp. 1–2. Springer, Heidelberg (2004) 12. Elmagarmid, A.K., Ipeirotis, P.G., Verykios, V.S.: Duplicate Record Detection: A Survey. IEEE Transaction on Knowledge and Data Engineering 19 (January 2007) 13. SERF, Stanford Entity Resolution Framework, http://infolab.stanford.edu/serf/ 14. Xu, L., Embley, D.W.: Using Schema Mapping to Facilitate Data Integration, http://www.deg.byu.edu/papers/integration.ER03.pdf 15. Ram, S., Park, J.: Semantic Conflict Resolution Ontology (SCROL): An Ontology for Detecting and Resolving Data and Schema-Level Semantic Conflicts. IEEE Transactions on Knowledge and Data Engineering 16(2) (February 2004)

An ORM-Driven Implementation Framework for Database Federations Herman Balsters and Bouke Haarsma University of Groningen, The Netherlands [email protected], [email protected]

Abstract. Database federations are employed more and more in situations involving virtual and integrated information on demand, e.g., real-time integration of two databases. Heterogeneity in hardware and software platforms, as well heterogeneity in underlying semantics of participating local databases, makes it a hard challenge to design a consistent and well-performing global database federation. The ORM modeling framework allows not only for precise modeling of a data federation, but also hosts tools for reverse engineering, enabling local databases to recapture their intended meanings on a linguistic basis. We will demonstrate how ORM models together with reverse engineering techniques can be used in combination with actual, industrial-strength implementation platforms to develop semantically consistent and high performance database federations.

1 Introduction Many companies are confronted with a large number of internal and external information systems that somehow have to be managed in a uniform and coherent fashion. Companies, e.g., merge in a legal and commercial sense, but merging their data is deferred, or even not done at all. Furthermore, the number of on-line systems providing data is ever-rising. Many companies are involved in building integrations of their legacy systems in order to obtain a coherent overview of available data. Most integration overviews of data are constructed ad-hoc and manually, often resulting in error-prone and time-consuming practices. A major problem in integrating data is caused by lack of semantics. In order to understand the combined collection of all of the data available in the participating local systems, there has to be consensus on the meaning of the data. Naming conflicts, different formats in data, as well global identification of local data objects, can make life very difficult for the designer of an integrated information system. Ideally, the data sources should be combined automatically into a so-called federation. Such an automatically generated federation should provide the desired real-time overview, outlining the business data needs. Federations exist with a wide range of approaches. A number of papers [2,3,6,10,16,18] have been devoted to offering a conceptual framework for the integration of a collection of heterogeneous data sources into one coherent federation. A major feature common to many of these approaches is the use of the concept of Global as View ([18]). The federation is said to be virtual as the federation constitutes a view on a collection of existing local databases. The resulting R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 659–670, 2009. © Springer-Verlag Berlin Heidelberg 2009

660

H. Balsters and B. Haarsma

federation does not involve altering these collaborating sources; the great advantage of not having to change these local sources is that existing applications on those systems can also be left unchanged. Only after establishing common semantics, can the local data models adequately be transformed into a common global model This is why modeling languages based on fact-orientation, such as ORM([13,15]), FCO-IM([4]), NIAM([14]), and OSM ([9]), are good candidates in this particular modeling environment, because they all provide the linguistic basis providing for close and correct interaction between the nontechnical domain expert and the information modeler. Other popular modeling languages (e.g., ER([7]) and UML([20])) are lesser qualified candidates, especially due to lack of sufficient expressiveness, but also to this lack of providing a proper factual, linguistic basis. ORM, furthermore, is grounded in first-order logic ([1,11]), offering ORM a clear mathematically-based semantics. The ORM language also offers well-equipped tooling facilities ([8,12]); reverse-engineering, in particular, is a very useful facility in re-creating the factual, linguistic basis of legacy databases. This paper deals with offering an implementation framework exploiting ideas taken from [2,3] and used to offer a conceptual design of a database federation. This conceptual design method is used in combination with the IBM Infosphere Federated Server (IBM-IFS, cf. [5]). The IBM-IFS techniques of nicknaming and wrapping ([5]), and the reverse- and forward-engineering techniques of the ORM tools, combined with the methodological framework of [2,3], results in an effective implementation platform for development of semantically consistent and highperformance database federations. This paper is organized as follows. In section 2, we describe our general approach –called the ORM Transform– in combining the ORM design method with IBM-IFS. Section 2 also describes technique employed in IBM-IFS to prepare local data sources for federation. Section 3 discusses reverse engineering. Section 4 offers a description of schema integration in ORM. Section 5 treats generation of view definitions for actually implementing the global federated database. This papers ends with some conclusions and suggestions for future research.

2 The ORM Transform: A Laplace Transform Analogue The Laplace Transform ([19]) is a widely used integral transform to solve difficult differential equations. Solving the differential equation by hand would be difficult, error-prone and even impossible. The Laplace Transform works by taking the differential equation, transforming it to an easy-to-solve linear equation. Solving this linear equation also gives the solution for the differential equation. The same applies for the method described in this paper. Solving the problem of federating data by hand proves to be very difficult and error-prone. Our method takes the sources and transforms them into ORM models. These models can be federated into a single ORM model based a clearly-defined and strict procedure ([2,3]). Finally, by transforming this global federated model back to a relational model, we obtain our desired federation.

An ORM-Driven Implementation Framework for Database Federations

661

ORM Transform The complete framework is built upon six processes, cf. Table 1. The processes are executed in succession, starting with the top, and ending at the bottom. The output of each process is the input for subsequent processes. These processes will be covered in later sections of this paper. Table 1. Processes of the Framework

Process Source Definition

Input Existing databases

Nicknaming Reverse Engineering Schema Integration Relational Model Generation View Generation

Selected tables Nicknames Local ORM schemas Global ORM schema

Output Selection of tables from the existing databases Nicknames Local ORM schemas Global ORM schema Relational model

Nicknames Global ORM schema Relational model

DBMS specific DDL with view definitions and table definitions for external data

A federated database is built upon several collaborating sources. Not all the data in these collaborating sources is used in a federated database. There can be several reasons to not include the data in the database. Not all data, e.g., is relevant to the federation (Needless information), and sometimes we are dealing with duplicates of data could be stored in several sources (Redundant information). We have to filter out the needless and redundant information, cf. Figure 1. The filtering happens on the level of the participating database tables. A decision on which tables to include, is not taken by the federation Fig. 1. designer alone; often consultation of a domain/business expert will be necessary. This process results in a list of tables to be included in the federation. 2.1 Example: Company and Credit Database This example concerns a company with a customer database and an external credit registry status database. The customer database contains information about the company’s customers, such as name and address. The external credit registry status database (from now on referred to as ‘credit database’) is a country-wide maintained

662

H. Balsters and B. Haarsma

Fig. 2. Relational Model for Customer Database

Fig. 3. Relational Model for Credit Database

database containing loans and mortgages from financial providers to end customers. The company desires an overview the loans of their customers and prospects. The credit database can be queried through some SQL dialect. The preferred solution is to obtain a federation of this system with their own customer database. In our example, we assume that we already filtered out needless and redundant data in the local data sources. The legenda for figures 2 and 3, below, is as follows: NAC stands for Name Address City; PK stands for primary key; FK for foreign key (the arrow denotes a foreign key reference). The tables of the chosen sources are only locally accessible. In order to play their part in the federation they have to be globally accessible. This is done through the process of nicknaming. This process includes the definition of Wrappers, Servers and User Mappings, and Nicknames ([5]). Wrappers facilitate the querying of a local source in a SQL dialect native to the federated system. IBM-IFS uses its own DB2 SQL dialect on the global level of the federation, and provides wrappers for ODBC, Oracle, MS SQL, etc. Having identified wrappers, servers and databases, we now have to make our local data globally available. This is done by creating nicknames within our federated system, as aliases for our local tables. Having created these nicknames, the federated system takes care of transport between the local servers and the federated system. Since different databases can have tables with same name, original table names are overridden by a nickname (e.g., by prefixing the name by the (abbreviated) server name). 2.2 Relation of Wrappers to Servers In our example, the customer database is available at hostname customers.local and is implemented in an Oracle database. In the federated server we add the wrapper

An ORM-Driven Implementation Framework for Database Federations

663

‘Oracle’, define a server with the given hostname and the user credentials. The credit database is available at the hostname credit.otherparty.external and is implemented in an MS SQL database. In the federated server, we add the wrapper ‘MS-SQL’, and define a server with the given hostname. We then create local nicknames as follows: • • • • • • •

company_customer, server: company, table: customer company_nac, server: company, table: nac credit_person, server: credit, table: person credit_nacz, server: credit, table: nacz credit_debt, server: credit, table: debt credit_person_debt, server: credit, table: persondebt credit_person_phone_number, server: credit, table: personknownphonenumber

Our federated server now contains 7 virtual tables: • company_customer (id, nac_id, email) • company_nac (id, name, address, city) • credit_person (id, last_known_nacz_id, last_known_phone_number_id) • credit_nacz (id, name, address, city, zip_code, person_id) • credit_debt (id, amount, registered_date, is_paid, organization_name) • credit_person_debt (person_id, debt_id) • credit_person_phone_number (person_id, phone_number)

3 Reverse Engineering In order to integrate the models, we extract the models from the existing databases. We assume that no ORM models of these databases exist, and that we are forced to create these models in retrospect. Recreating the models is done by reverse engineering, as opposed to (forward) engineering where you first design and then build the system. When a database is created, chances are that it was not built according to a conceptual schema, with only the logical schema of the database at one’s disposal. The database evolves during its lifetime; attributes and tables were added, changed or discarded, often leaving us with a rather complex database without formal documentation (semantics). Reverse engineering uses the existing database as its input and generates a conceptual schema providing the desired semantics. This conceptual schema can be optimized both in the sense of semantics as in performance. Forward engineering is then used to re-implement the improved schema. Reverse engineering is implemented in the two major tools supporting ORM ([8,12]). After extracting the schema from the database, the schema is analysed, and

664

H. Balsters and B. Haarsma

the semantics of the schema is reconstructed. As an example, assume that the original databases in our Company was an Oracle database. Reverse engineering could then have resulted in the following ORM model. Such ORM models use the same generic name for the relations involved; i.e., has/is-of. Such generic names can be made less general -and possibly more accurateby discussing with a domain expert how these names could be altered, and become more tailor-made to the situation at hand, hence providing a more accurate semantics.

Fig. 4. ORM Model for Company Database

4 Schema Integration In order to complete the framework and to obtain an integrated system, we need an integrated model. The integrated model results from combining local models; the resulting integrated models have to satisfy certain completeness and consistency requirements in order to reflect correct semantics of the different local schemata on the global integrated level. In constructing such a semnantics, we are faced with the problem of semantic heterogeneity, or differences in meaning attached to shared data. This problem can be split up into four main sub problems: global identification, followed by homonyms/synonyms, data conversion, default values and missing attributes. 4.1 Introduction of Global Identifiers Global identification refers to the case where one single object in reality can be defined by two (or more) local objects. These corresponding object types often partially share a common structure. In interest of our integration, this shared common structure should be integrated into a global object: 1. Introduction of the global object. This global object contains the shared common structure, as found in the local objects. 2. Sub/supertyping is applied to the global (supertype) and local (subtype) objects. 3. The global object is assigned a global identifier. Introducing a new identifier allows local objects to be identified by their local identifier. 4. Introduce a discriminating role value on the global level. Not all global objects are defined by all their subtypes. Therefore a discriminating role is introduced to define all the roles the global object plays. 5. Make the correspondence explicit in the object populations (extra semantics needed, see next paragraph). 6. Show the correspondence between local and global identifiers.

An ORM-Driven Implementation Framework for Database Federations

665

Fig. 5. ORM Design Pattern for a Global Identifier

4.2 External Data How do we know which object in one population corresponds to another object in the other population? Unless the objects share some global identifier, it is impossible to decide on this matter by looking at the data alone. The business/organization will have to provide these data, also called external data, since such data has to be provided from some external source, i.e., outside the specified source databases. Such external data consists of a simple extra base table, called a data-reference table. One of the major functions of a federation is to locate and reason about local objects sharing a global identifier. Local objects sharing a global identifier are objects existing in two (or more) populations which –on the global level- refer to one and the same object. For example, in Table 2, a person, in physical reality, could be both a Customer and Credit person. We note that once we have the extra data-reference table as a base table, depicted by the ternary predicate .. equals .. and .. in figure 5, we can derive, the relations play and uses in figure 5. These derivations are employed to make a sharp distinction between the original, physically stored data (such as the data-reference table, Table 2 above), and data on the level of the federation which is completely virtual (i.e., consists entirely of derived data). We introduce an entity type called ‘DebtCustomer’ indicating the intersection of the populations of Customer and Credit persons. The newly introduced entity type can be thought of as a derived subtype; its existence can be reasoned from the supertype playing roles ‘Customer’, as well as ‘Credit’. Next, as shown in Figure 8, a property can be assigned to the newly introduced entity ‘DebtCustomer’. Table 2. Local objects sharing a global identifier

Global_entity_identifier 1 2 2 3

Source_name Customer Customer Credit Customer

Local_identifier 13 17 31 21

666

H. Balsters and B. Haarsma

Fig. 6. ORM Design Patter for a Shared Global Identifier

We could complete the schema integration by defining the roles that ‘GlobalDebt’ entity participates in, as depicted in Figure 7, below.

Fig. 7. Definition of Federated Debt

4.3 Remaining Problems In [2,3], various techniques have been introduced to deal with problem categories of so-called homonyms/synonyms, data conversions, default values and missing attributes. Conflicts due to homonyms are resolved by mapping two same name occurrences with different semantics to different names in the integrated model. For example, suppose that Customer phone number means home number and Credit phone number means office number. These local names (assumed syntactically equivalent) are to be given different names in the global schema in order to make explicit the difference in semantics. Synonyms are treated analogously, by mapping two different names (with the same semantics) to one common global name. Conflicts due to conversion arise when semantically related types are represented in different units or different granularity. These conflicts are solved by applying a suitable conversion function, creating uniform representation of the data on the global level. We will refrain from offering a general treatment of these techniques, since we have only limited space and aim to focus on our implementation framework. We therefore refer to [2,3] for more information on handling homonyms/synonyms, data conversion, default values and missing attributes in a more general, theoretical framework.

An ORM-Driven Implementation Framework for Database Federations

667

5 Relational Model Generation and Views The final step in the framework is the transformation from the integrated model to the integrated sources. This final step is split into two processes within the framework. The first process is to generate a relational model from the integrated model; the second process is to create views on this relational model. 5.1 Relational Mapping Procedure (RMAP) Forward engineering uses a procedure called the Relational Mapping Procedure (RMAP), transforming ORM models into relational models. This procedure, in our example, results in importing the integrated model in VEA (Visio for Enterprize Architects, [12]), and building the project, resulting in the relational model of Figure 8). Note that both ‘RolePlaying’ and ‘GlobalCustomer equals GlobalRole and LocalIdentifier’ look identical. VEA merged the two derived predicates of the global identifier into a single table called `RolePlaying’. We will implement this table as a view definition later on in the framework.

Fig. 8. Relational Model of Integrated Model

5.2 View Generation The ultimate goal of the framework is applying Global as View, eventually yielding the desired federation. Completing the previous step (cf. figure 8) leaves us with table definitions of the generated relational model. This step is devoted to creating view definitions from these table

668

H. Balsters and B. Haarsma

Fig. 9. View Definitions

definitions. For each table –not being a base table– in our relational schema, we have to create a view definition. In previous steps, we have typically offered derivation rules to translate between local and global semantics. These derivation rules need now to be implemented in view definitions. View creation proceeds as follows: create the integrated view model document, and then copy definitions of the data coming from base tables (com_customer, credit_person, credit_debt, GlobalCustomerDataReference)). Implement subtype view definitions first (Customer, Person), followed by supertypes (GlobalCustomer), additional fact types to these supertypes (RolePlaying), intersection types (DebtCustomer), additional types to intersection types (GlobalDebt), and, finally, generate DDL code. The integrated model, created automatically from our integrated schema, does not contain information pertaining to derivation rules and data sources. The final integrated view model document, therefore, is created separately from this integrated model. Although the result looks similar to the integrated model, it is much more complex, due to the additional derivation rules. The DDL code contains the complete definition of our integrated model in terms of SQL code. The code can be executed on our federated system, and the bulk of our federation is completed. After having followed through the whole procedure as described above, we obtain a final integrated view model (cf. Figure 9). This model differs slightly from the relational model of Figure 8; the difference can be found in the view definitions, displayed in our schema with a slash in front of the table names. From this integrated view model we can –mostly manually- construct the extra desired DDL code.

6 Conclusion The framework presented in this paper offers a procedure to arrive at implementations of consistent and complete federations. The chosen ORM modeling framework

An ORM-Driven Implementation Framework for Database Federations

669

allowed not only for precise modeling of a data federation, but also hosts tool support. We have demonstrated how ORM models, together with reverse engineering techniques, can be used in combination with an actual, industrial-strength implementation platform to develop semantically consistent and high performance database federations.

References 1. Balsters, H., Halpin, T.: Formal Semantics of Dynamic Rules in ORM. In: Meersman, R., Tari, Z., Herrero, P. (eds.) OTM-WS 2008. LNCS, vol. 5333, pp. 699–708. Springer, Heidelberg (2008) 2. Balsters, H., Halpin, T.: Data Integration with ORM. In: Meersman, R., Tari, Z., Herrero, P. (eds.) OTM-WS 2007, Part I. LNCS, vol. 4805, Springer, Heidelberg (2007) 3. Balsters, H., de Brock, E.O.: Integration of Integrity Constraints in Federated Schemata Based on Tight Constraining. In: Meersman, R., Tari, Z. (eds.) OTM 2004. LNCS, vol. 3290, pp. 748–767. Springer, Heidelberg (2004) 4. Bakema, G., Zwart, J., van der Lek, H.: Fully Communication Oriented Information Modelling. Ten Hagen Stam, The Netherlands (2000) 5. Betawadkar-Norwood, A., Lin, E., Ursu, I.: Using data federation technology in IBM WebSphere Information Integrator. IBM developerWorks (June 23, 2005), http://www.ibm.com/developerworks 6. Calì, A., Calvanese, D., De Giacomo, G., Lenzerini, M.: Data integration under integrity constraints. In: Pidduck, A.B., Mylopoulos, J., Woo, C.C., Ozsu, M.T. (eds.) CAiSE 2002. LNCS, vol. 2348, p. 262. Springer, Heidelberg (2002) 7. Chen, P.P.: The entity-relationship model—towards a unified view of data. ACM Transactions on Database Systems 1(1), 9–36 (1976) 8. Curland, M., Halpin, T.: Model Driven Development with NORMA. In: Proc. 40th Int. Conf. on System Sciences (HICSS 40). IEEE Computer Society Press, Los Alamitos (2007) 9. Embley, D.W.: Object Database Development. Addison-Wesley, Reading (1997) 10. Embley, D.W., Xiu, L.: A composite approach to automating direct and indirect schema mappings. Inf. Syst. 31(8), 697–732 (2006) 11. Halpin, T.: A Logical Analysis of Information Systems: static aspects of the data-oriented perspective, doctoral dissertation, University of Queensland (1989), http://www.orm.net/Halpin_PhDthesis.pdf 12. Halpin, T.A., Evans, K., Hallock, P.: Database Modeling with Microsoft® Visio for Enterprise. Morgan Kaufmann, San Francisco (2003) 13. Halpin, T.: ORM 2. In: Meersman, R., Tari, Z., Herrero, P. (eds.) OTM-WS 2005. LNCS, vol. 3762, pp. 676–687. Springer, Heidelberg (2005) 14. Halpin, T.: ORM/NIAM Object-Role Modeling. In: Bernus, K., Mertins, K., Schmidt, G. (eds.) Handbook on Information Systems Architectures, 2nd edn., pp. 81–103. Springer, Heidelberg (2006) 15. Halpin, T., Morgan, T.: Information Modeling and Relational Databases, 2nd edn. Morgan Kaufmann, San Francisco (2008) 16. Lenzerini, M.: Data integration: a theoretical perspective. In: ACM PODS 2002. ACM Press, New York (2002)

670

H. Balsters and B. Haarsma

17. Object Management Group, UML 2.0 Superstructure Specification (2003), http://www.omg.org/uml 18. Ullman, D.: Information Integration Using Logical Views. In: Afrati, F.N., Kolaitis, P.G. (eds.) ICDT 1997. LNCS, vol. 1186, pp. 19–40. Springer, Heidelberg (1996) 19. Wikipedia authors (n.d.), Laplace transform

ORM-Based Semantics of B2B Transactions H. Balsters and F. van Blommestein University of Groningen Faculty of Economics and Business P.O. Box 800 9700 AV Groningen, The Netherlands [email protected], [email protected]

Abstract. After widespread implementation of Enterprise Resource Planning and Personal Information Management, the next wave in the application of ICT is headed towards business to business (B2B) communication. B2B has a number of specific aspects, one of them being negotiation. This aspect has been largely neglected by present implementations of standard EDI- or XMLmessaging and by B2B webservice implementations. In this paper a precise model is given of the negotiation process. The requirements of a potential Buyer and the offer of a potential Seller are matched and, if the negotiation is successful, a contract is concluded. The negotiation process model is represented in ORM, extended with dynamic constraints. Our model may be implemented in the databases of the trading partners and in message- or service definitions.

1 Introduction Most commercial and public organizations nowadays have automated their administrative processes. The implementation of Enterprise Resource Planning systems and Personal Information Management systems is widespread. This use of Information Technology has resulted in a huge increase in productivity during the last decennia. Interaction between companies, however, is still hardly supported by application systems, although there are considerable amounts of (repetitive) administrative activities, which are performed manually at both sides of a commercial relation. It therefore seems reasonable to expect that the use of computer systems in interorganizational processes will also lead to, at least, the same improvements. The computer systems of companies must then be interconnected, and nowadays that is quite possible, with the global and simple means of communication known as the internet. In some industry sectors, Electronic Data Interchange (EDI) or XML messaging are deployed. EDI and XML messaging work perfectly in environments where the data exchange can be highly standardised and where commercial relationships hardly change or do not change at all. Setting up an EDI connection between two computer applications takes considerable effort; EDI and XML messages are exchanged in the framework of rigid business processes. R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 671–681, 2009. © Springer-Verlag Berlin Heidelberg 2009

672

H. Balsters and F. van Blommestein

Many relationships between organisations are not sufficiently stable to justify an EDI connection. Companies are constantly looking for new markets and more suitable suppliers, and are permanently innovating their logistics and work processes. EDI cannot keep pace with these changes, due to rigidness in the technology used; i.e., dynamics and flexibility are not sufficiently supported. In this paper, we take negotiation analysis as our main focus; an important dynamic aspect of Business-to-Business (B2B) transactions. In most B2B (EDI or XML) messaging systems negotiation is not supported in an automated sense. It is assumed that commercial conditions have been agreed on beforehand, using, e.g., paper documents or the telephone. While negotiation is routine in most business relationships, it is not supported by automated B2B-transactions. In this paper it is shown how negotiation, leading to data and service alignment, can be formally modeled. The model can be used to configure B2B systems that support dynamic B2B processes.

2 Related Work In line with standardization efforts of ISO/IEC JTC1-SC32 [http://jtc1sc32.org/] and UN/CEFACT [www.unece.org/cefact/], Hofreiter e.a. [17] propose a methodology for designing B2B processes. The methodology, UMM, is based on UML. UMM starts with the identification of the business domain, after which user requirements are gathered, the process flow is modeled, and followed by data modeling. Although both data structures and process flows are modeled, they are treated separately. In reality, alignment of B2B services, the result of a negotiation process, is interwoven with the alignment of related data, so in negotiation process models, separate treatment of data- and process flow will not lead to desired results. Jayaweera [19] has proposed to add intentions or speech acts to B2B messages. The work described in [19] is partly based on FLBC [21], a language representing B2B messages as first -order predicate logic clauses, enriched with speech acts. Jayaweera [19] combines UMM and speech acts with a B2B ontology (REA), and the negotiation workflow pattern as proposed by Winograd et al. He however does not construct a precise data- or object model for B2B negotiations. Angelov [1] has conducted an extensive survey of research dedicated to electronic contracting. He presents many patterns and languages that are proposed by various researchers. None of them, however, has mapped contracting patterns to a precise data model. The conclusion drawn in [1] is that modeling of the negotiation process is still in the initial stage of development.

3 Use of ORM in B2B Modeling B2B modeling places high demands on the modeling language used. The often complex negotiation process has to abide to often rigid business rules and there is often a strict order involved in the negotiation process before success can be claimed. Business rules include constraints and derivation rules. Static rules apply to each state of the information system that models the business domain, and may be checked by

ORM-Based Semantics of B2B Transactions

673

examining each state individually (e.g. ‘In a Transaction participate exactly one Seller and one Buyer’). Dynamic rules reference at least two states, which may be either successive (e.g. ‘A product may only be delivered after having been ordered’) or separated by some period (e.g. invoices ought to be paid within 30 days of being issued). This entails that a language used to model negotiations in B2B transactions should have high expressiveness in specifying data and constraints, as well as the possibility to model basic process requirements (including dynamic rules). B2B negotiation usually involves business persons that themselves are not versant in technical modeling, but are domain experts in offering the information needed to conclude a successful negotiation. These domain experts are an essential link in the modeling process, by not only offering input information, but also in offering the eventual validation of the negotiation model. In a negotiation, Seller and Buyer parties often first have to create a common ontology before they can actually start the negotiating. This process of creating a common ontology is also called the process of data alignment. Hence, natural language communication plays an important role. Only after establishing common semantics, can Seller and Buyer start to enter a (automated) negotiation process. This is why modeling languages based on factorientation, such as ORM [13,14,16], FCO-IM [8], NIAM [15] and OSM [11] are good candidates in this particular modeling environment, because they all provide the linguistic basis providing for close and correct interaction between the non-technical domain expert and the information modeler. Other popular modeling languages (e.g., ER [9] and UML [23,24]) are lesser qualified candidates, due to lack of sufficient expressiveness, but also to the lack of providing a proper linguistic basis. The ORM language offers, besides excellent tooling facilities, the extra benefit that it can handle dynamic rules, which will prove to be very useful in modeling negotiation in B2B transactions. In the Service Discovery community the process of getting agreement on the end result of negotiation is called service alignment. We have been inspired by the solution in [3,6] and have transformed the UML/OCLbased approach ([28]) used there to an ORM-based solution exploiting dynamic rule facilities. As a result we offer a completely declarative solution for aligning a B2B service (the buying and selling of a product). ORM, furthermore, is grounded in first-order logic, offering a clear mathematically-based semantics ([12]). The ORM tools ([10,13]) also offer a reverseengineering facility, which is very useful in re-creating the linguistic basis of legacy databases often encountered in setting up and eventually implementing an automated negotiation environment. In our ORM-based solution a B2B transaction can eventually be implemented as an advanced database transaction. We want to point out that UML, in particular, has many drawbacks with respect to ORM as a data modeling language and also lacks proper tooling to deal with database design and implemenation. We refer the interested reader to [16] for an in-depth treatment of the relationship between ORM and UML. One could argue that process-based languages (YAWL [26], BPEL [23]) could also be good candidates to model negotiation processes. These languages, however, lack data-modeling facilities, as well as constraint modeling facilities necessary to capture the static and dynamic business rules (pertaining to data, and not only to the

674

H. Balsters and F. van Blommestein

sequence of process steps) prevailing in B2B-transactions. This makes a purely process-oriented language less suitable for the modeling of B2B-transactions.

4 Modeling B2B Processes In a B2B transaction, one typically has the situation that a Buyer wishes some product to be delivered by a Seller. In terms of models, this situation translates into two object types (Buyer and Seller) that participate in a Transaction that will be successful under certain explicit conditions. Initially, i.e., when the transaction starts, Buyer and Seller usually are not in a state of immediate success. Typically, Buyer and Seller enter into a negotiation process that eventually might yield a successful transaction resulting in a contract between Buyer and Seller regarding the delivery of some product and the payment for it. Before this negotiation process can start, however, Buyer and Seller have to be able to communicate with each other; i.e., they have to speak the same language to understand each other’s concepts and rules. This part of the business process is called data alignment. In the case of product delivery, for example, Buyer and Seller negotiate about concepts like “delivery period” and “product price”. These concepts may vary in the context of Buyer and Seller in many aspects, e.g., terminology used to indicate these concepts, or units by which these concepts are measured. We can have, e.g., the following informal rule defining a successful transaction: Seller promises to deliver the product and Buyer promises to pay after delivery of that product, while the Requested Period is within the Offered Period, the Requested Price is higher than the Offered Price, and the Requested Total Quantity is smaller than the Offered Total Quantity; the state of the transaction then changes from Initiated to Negotiation Successful. Before Buyer and Seller can start working on completing a successful transaction, they first have to agree on the meaning of concepts like Period, Price and Quantity. This problem of aligning data is well known in the subject area of data integration, as in design of data warehouses ([18,20]) and data federations ([2,5]). Data alignment in this case deals with modeling of an object type Transaction involving the alignment of data elements from Buyer and Seller. The problem of semantic heterogeneity arises when different meanings are assigned to shared data terms. Matters such as naming conflicts (e.g. homonyms and synonyms), conflicts due to different underlying data types of attributes and/or scaling, and missing attributes all deal with differences in structure and semantics of the different local Buyer and Seller data. By employing techniques such as renaming, conversion functions, default values, and addition of suitable extra attributes one can construct a common data model in which these data inconsistencies are resolved. We refer the interested reader to [2,5] for a detailed treatment of these techniques. Let us now look at an example of a situation dealing with data alignment. We remark that in all subsequent ORM models offered in this paper, we will use the notation as offered in [13]. In the model shown in figure 1, on the Buyer side, there is an object type OffDelivery (of Offered Delivery) which gets its data from an existing proprietary local object type called ProductStock, equipped with data elements Quantity, Period, and KiloPrice. On the Buyer side, we have an object type ReqDelivery (of Requested Delivery) with data

ORM-Based Semantics of B2B Transactions

OffDelivery (.nr)

Product (.nr)

concerns **

concerns **

675

ReqDelivery (.nr) +, >?) correspond respectively to the RolePathPurpose values (StartRole, SameFactType, PostInnerJoin, and PostOuterJoin). An identifier in square brackets follows the lead symbol, and “=” is used inside the square brackets after the identifier to indicate correlation with another identifier, so “>+[ro5=ro3]Entity” indicates that the Entity role is used in the path with identifier ro5 as the right hand role occurrence of an inner join and is remotely correlated with ro3 (correlation is discussed in section 3.2). Subpaths are indicated via indentation with the composition operator. By convention, identifiers use an increasing numbering scheme to simultaneously indicate path order. A basic example is a subtype definition for GrandParent using the fact type Person is a parent of Person. In this case, GrandParent may be defined using a role path as: Starting with: Person >>[ro1]Person is a parent of >[ro2]Person >+[ro3]Person is a parent of Person

By applying the simple rule that the path population requires a non-empty population of all roles before the first outer join (there is no outer join in this case), this three step path provides the equivalent of the FORML representation of the same rule: Each GrandParent is a Person who is a parent of some Person who is a parent of some Person. We chose forward predicate text for clarity, the GrandParent derivation rule may be expressed using the alternate Person is a child of Person reading. The rule using the reverse reading is represented as “>[ro2]Person is a child of >>[ro1]Person, Person is a child of >+[ro3]Person” and the corresponding FORML is the much clumsier “Each GrandParent is a Person where some Person2 is a child of that Person and some Person3 is a child of Person2”. By formalizing the derivation rule as a role path, ORM tool implementations can automatically verbalize the most readable form of the derivation rule for the current state of the model. 3.2 Calculations and Conditions The usefulness of role paths is severely restricted if we are limited to populationbased sets. Clearly, we require the ability to restrict the path population based on conditions applied to candidate path instances, and we need both value-based operations (numeric operators and functions) and bag-based operations (aggregation functions) to support common query scenarios. The first thing we need to do is define what we mean by a function. In the context of this discussion, a function takes zero or more inputs and returns a single value. A function input may be either a single value or a bag. A brief discussion on how we are not modeling functions provides perspective. It is common to think of functions simply as special fact types in an ORM model. These algorithmic fact types take two forms: comparison operators, modeled as binary fact types with a spanning uniqueness constraint; and functions, modeled with a uniqueness constraint spanning the input roles and the remaining role representing the

698

M. Curland, T. Halpin, and K. Stirewalt

calculated output. We chose not to model functions this way because the approach does not properly model bag inputs, it requires special semantics for functions with single-valued inputs, and it requires meta-relationships between the fact type and a function implementation specification like the one we’ve defined. The semantic differences between asserted or derived fact types and algorithmic fact types occur in the areas of population, role player type, and unary fact type interpretations. Unlike normal fact types, algorithmic fact types are implicitly populated only: if a role in a derived fact instance is calculated using 5 * 10 = 50, then there is no requirement for a (5, 10, 50) tuple to be stored or derivable in the model. Algorithmic fact types are also heavily overloaded, with different implementations required for different role player combinations. Overloading issues can be resolved by introducing a Thing object type, but this requires special handling by type compatibility rules, which assume top-level types are disjoint. Finally, a nullary function (with no input) is not the same as an asserted unary fact type. For example, calling the Today nullary function is not the same as recording today’s date and asserting an ‘is today’ unary fact type. Such a fact type needs an external data source to be correctly populated and updated. The Today function, on the other hand, is valid without ongoing maintenance. Given these limitations of algorithmic fact types, we chose an alternate approach for metamodeling calculated values (see Figure 4). This provides for function inputs of either bags or single values, and single-valued outputs. From the metamodel perspective, we treat all comparison operators (=, !=, >, etc.), mathematical operators (+,−,×,÷), simple functions (sine, cosine, etc.), and aggregation functions (sum, avg, min, max, count, count distinct, etc.) in the same way, working under the assumption that these different classes of operations will be verbalized and parsed in their standard infix or functional notations. Apart from support for Boolean results, we ignored data types associated with function inputs and outputs, and assumed that calculated values are implicitly typed. A full discussion on typed function inputs based on the data types of associated role players and other factors is out of scope for this paper. The notion of function scope is used to provide a starting point in the path to relate multiple input roles, or to determine the contents of bag input roles. For a function with multiple single-value inputs, such as the multiply function that calculates the LineItem.subTotal shown later in Figure 5, the scope of a LineItem role relates the price and quantity values for that LineItem and allows a tool to use the ORM uniqueness constraint patterns to test whether, given any LineItem, there is at most one price and value to satisfy the single-value input requirements of the function, or whether multiple derived fact instances are needed to represent the result. For bag functions (count, sum, etc.), the scope determines the number of instances included in the bag. For example, given the model in Figure 3, the request count(RoleSubPath) has multiple interpretations, depending on the path. A scope of a parent RolePath specifies a count of all child subpaths, and a scope of a PrimaryRolePath indicates all RoleSubPath instances recursively contained within in the path. In the first case, multiple count values are calculated for each PrimaryRolePath, whereas a single equal or larger count will be produced for the broader scope. We can also get a global RoleSubPath count with a path starting at RolePath and participating in the supertype instance role that is automatically defined for each subtype link.

A Role Calculus for ORM

699

PathValueNode (.id) calculates PrimaryRolePath

CalculatedValue satisfies /is condition of

PathValueNode

RoleOccurrenceInPath [scope] has context-

provides input for

is boolean

Function (.name)

is calculated with

PathConstant has

ConstantValue

operates on

“FunctionInput” corresponds to

FunctionParameter (.id)

occurs at

has

Position Position (.nr) (.nr) {1..} ParameterType {‘value’, (.name) ‘bag’}

Fig. 4. PathValueNode encompasses raw instance data, calculated data, and constant data. All values can be input to function evaluations, projected as outputs for queries and derived fact types, or used as Boolean conditions to be satisfied by instances in the populated role path.

Fortunately, the role path provides a natural scoping mechanism for function evaluation. The context for a calculation must be a role occurrence on a direct or correlated role path that is directly linked to all role occurrences used as inputs to the function. In a role path, correlated role occurrences correspond to variable names in FORML and other text-based representations. The rules for variable generation are based on the RolePathPurpose values: all StartRole nodes correspond to one variable, each SameFactType node gets its own variable and each Post*Join node gets the same variable as the node before it. The RoleOccurrenceInPath is remotely correlated with RoleOccurrenceInPath fact type is used for explicit correlation across splits in the path. See Figure 7 later for an example using remote correlation to combine naturally disjoint variables.

4 Capturing Business Rules We now consider some examples using role paths to define derived fact types. Functions and fact type derivation require two additional constructs to our textual shorthand: calculated values are represented using FunctionName[calculationId of scopeId](input1, input2,…), and binding of derived roles with Derivation: RolePlayer1=PathValueNodeId predicate text RolePlayer2=PathValueNodeId2. If function scope is omitted, then the initial instance of the root object type is used as the default scope. We demonstrate calculations in derived fact types with Figure 5, stability of a role path over model changes in Figure 6, and a remote correlation case in Figure 7.

700

M. Curland, T. Halpin, and K. Stirewalt

Fig. 5. Sample model with derived fact types containing calculated roles

The first task is to derive LineItem has subtotal- Price. The default scope is sufficient to multiply Quantity and UnitPrice, each of which occurs once for each LineItem. Starting with: LineItem and >>[ro1]LineItem has >[ro2]UnitPrice; (; means end of sub path) >>[ro3]LineItem has >[ro4]Quantity multiply[f1](ro2, ro4) Derivation: LineItem=ro1 has subtotal- Price=f1

The total price calculation needs a scope with a multi-valued path step between the scope and input role occurrence. Multiplicity of start or join role occurrences is determined with the FactType’s uniqueness pattern. Multiplicity within the same FactType is one because ORM facts have single-value role players. The transition from Invoice into ro1 is the only multi-valued step; therefore sum uses the default scope. Starting with: Invoice >[ro2]LineItem is on >>[ro1]Invoice >+[ro3]LineItem has subtotal- >[ro4]Price sum[f1](ro4) Derivation: Invoice=ro1 has total- Price=f1

To demonstrate nested function calls, we also show derivation of the total price without using a subtotal. In this case, the scope of the multiply operation produces a bag of results (one for each LineItem), which are then input to the sum function. Starting with: Invoice >[ro2]LineItem is on >>[ro1]Invoice and >+[ro3]LineItem has >[ro4]UnitPrice; >+[ro5]LineItem has >[ro6]Quantity multiply[f1 of ro2](ro4,ro6) sum[f2](f1) Derivation: Invoice=ro1 has total- Price=f2

The next example (see Figure 6) illustrates the semantic stability of our role-based approach. The initial ORM schema models student results using a ternary fact type, which is used as the basis for a subtype definition (shown in FORML). Later on, the decision is made to allow students to repeat courses and to maintain full history of their results. Using NORMA, a temporal role (r4) is inserted into the ternary and the predicate renamed as shown. Since the roles r1..r3 are unimpacted by this change, the underlying role path for the derivation rule remains the same, and the FORML verbalization is automatically updated.

A Role Calculus for ORM

701

Fig. 6. A starting version of a model with a subtype derivation based on a fact type that is later extended by inserting a role for Date. Although the verbalization of the rule is different, the internal role path form of the subtype derivation rule does not change.

This is a population-based subtype derivation rule that requires an ORMgraduate student to participate in the ternary fact type with both conditions satisfied. Starting with: Student >>[ro1]Student for >[ro2]Course begun on Date got >[ro3]Grade Satisfies: equals[f1](ro2,'ORM') greaterThan[f2](ro3,3)

Figure 7 shows a final example involving remote correlation and multiple uses of the same role in a path. In the role-based formulation, {ro1,ro3,ro5} represent the same employee instance because start roles are implicitly correlated. Similarly, {ro6,ro7,ro9} represent a second employee instance because the join operations also imply correlation. However, by default, ro2/ro8 may be different City instances and ro4/ro10 different Country instances. The explicit remote correlation (ro8=ro2) equates the City instances, and the inequality operator ensures different Country instances. With scope unspecified for the inequality function, the root object type is the default scope, which results in potentially many ro10 values for each ro4. The single-valued input on the inequality function forces a separate evaluation for each occurrence of a supervised Employee.

Fig. 7. A unary fact type derivation using explicit remote correlation. The definition for the unary fact type corresponds to the user-friendly query ‘Who supervises an employee who lives in the same city as the supervisor but was born in a different country from the supervisor’.

702

M. Curland, T. Halpin, and K. Stirewalt Starting with: Employee and >>[ro1]Employee lives in >[ro2]City; >>[ro3]Employee was born in >[ro4]Country; >>[ro5]Employee supervises >[ro6]Employee and >+[ro7]Employee lives in >[ro8=ro2]City; >+[ro9]Employee was born in >[ro10]Country Satisfies: inequality[f1](ro4,ro10) Derivation: Employee=ro1 supervises local foreigner

5 Conclusion Role paths provide a highly stable, low-level representation of navigation through ORM space that can be used as a basis for specifying multiple advanced ORM constructs. This paper discussed role paths as a foundation for both subtype and fact type derivation rules. The metamodel described here is currently being implemented as the basis for formal derivation rules in the NORMA tool. Users will formulate derivation rules via high level graphical and textual views that are automatically transformed into the low level role path structures. Intelligible verbalizations of the rules will be generated on demand using the optimal available predicate text, role names, and other elements in the model. Users will also be able to specify different verbalization preferences such as of, dot, or relational styles [14 p. 98]. The same basic path construct may also be used as the basis for dynamic queries specified against a complete ORM model, join path specification for constraints, and complex rules that have generally been loosely classified as “textual constraints”. Future research will investigate combinations of paths and normal constraints, where one or more paths act to define restricted subsets which are subject to additional standard constraints. Research into verbalization and parsing of textual representations of role paths in various languages will also be conducted, along with approaches for guided entry to assist with designating role paths.

References 1. Balsters, H., Carver, A., Halpin, T., Morgan, T.: Modeling Dynamic Rules in ORM. In: Meersman, R., Tari, Z., Herrero, P. (eds.) OTM 2006 Workshops. LNCS, vol. 4278, pp. 1201–1210. Springer, Heidelberg (2006) 2. Balsters, H., Halpin, T.: Formal Semantics of Dynamic Rules in ORM. In: Meersman, R., Tari, Z., Herrero, P. (eds.) OTM-WS 2008. LNCS, vol. 5333, pp. 699–708. Springer, Heidelberg (2008) 3. Bloesch, A., Halpin, T.: ConQuer: a conceptual query language. In: Thalheim, B. (ed.) ER 1996. LNCS, vol. 1157, pp. 121–133. Springer, Heidelberg (1996) 4. Bloesch, A., Halpin, T.: Conceptual queries using ConQuer-II. In: Embley, D.W. (ed.) ER 1997. LNCS, vol. 1331, pp. 113–126. Springer, Heidelberg (1997) 5. Chen, P.P.: The entity-relationship model—towards a unified view of data. ACM Transactions on Database Systems 1(1), 9–36 (1976)

A Role Calculus for ORM

703

6. Curland, M., Halpin, T.: Model Driven Development with NORMA. In: Proc. 40th Int. Conf. on System Sciences (HICSS 40). IEEE Computer Society Press, Los Alamitos (2007) 7. Halpin, T.: Constraints on Conceptual Join Paths. In: Krogstie, J., Halpin, T., Siau, K. (eds.) Information Modeling Methods and Methodologies, pp. 258–277. Idea Publishing Group, Hershey (2005) 8. Halpin, T.: ORM 2. In: Meersman, R., Tari, Z., Herrero, P. (eds.) OTM-WS 2005. LNCS, vol. 3762, pp. 676–687. Springer, Heidelberg (2005) 9. Halpin, T.: ORM/NIAM Object-Role Modeling. In: Bernus, P., Mertins, K., Schmidt, G. (eds.) Handbook on Information Systems Architectures, 2nd edn., pp. 81–103. Springer, Heidelberg (2006) 10. Halpin, T.: Modality of Business Rules. In: Siau, K. (ed.) Research Issues in Systems Analysis and Design, Databases and Software Development, pp. 206–226. IGI Publishing, Hershey (2007) 11. Halpin, T.: Fact-Oriented Modeling: Past, Present and Future. In: Krogstie, J., Opdahl, A., Brinkkemper, S. (eds.) Conceptual Modelling in Information Systems Engineering, pp. 19–38. Springer, Berlin (2007) 12. Halpin, T.: A Comparison of Data Modeling in UML and ORM’. In: Khosrow-Pour, M. (ed.) Encyclopedia of Information Science and Technology, 2nd edn., Information Science Reference, Hershey PA, USA, vol. II, pp. 613–618. (2008) 13. Halpin, T., Curland, M.: Automated Verbalization for ORM 2. In: Meersman, R., Tari, Z., Herrero, P. (eds.) OTM 2006 Workshops. LNCS, vol. 4278, pp. 1181–1190. Springer, Heidelberg (2006) 14. Halpin, T., Morgan, T.: Information Modeling and Relational Databases, 2nd edn. Morgan Kaufmann, San Francisco (2008) 15. ter Hofstede, A., Proper, H., van der Weide, T.: Formal definition of a conceptual language for the description and manipulation of information models. Information Systems 18(7), 489–523 (1993) 16. Hoppenbrouwers, S.J.B.A., Proper, H.A(E.), van der Weide, T.P.: Fact calculus: Using ORM and lisa-D to reason about domains. In: Meersman, R., Tari, Z., Herrero, P. (eds.) OTM-WS 2005. LNCS, vol. 3762, pp. 720–729. Springer, Heidelberg (2005) 17. Meersman, R.: The RIDL Conceptual Language, Int. Centre for Information Analysis Services, Control Data Belgium, Brussels (1982) 18. Object Management Group, UML 2.0 Superstructure Specification (2003), http://www.omg.org/uml 19. Object Management Group (2005), UML OCL 2.0 Specification, http://www.omg.org/docs/ptc/05-06-06.pdf 20. Object Management Group, Semantics of Business Vocabulary and Business Rules (SBVR) (2008), http://www.omg.org/spec/SBVR/1.0/ 21. van Bommel, P., Hoppenbrouwers, S., Proper, H., van der Weide, T.: Giving Meaning to Enterprise Architecture Principles with ORM and ORC. In: Meersman, R., Tari, Z., Herrero, P. (eds.) OTM 2006 Workshops. LNCS, vol. 4278, pp. 1138–1147. Springer, Heidelberg (2006) 22. Warmer, J., Kleppe, A.: The Object Constraint Language, 2nd edn. Addison-Wesley, Reading (2003) 23. Wintraecken, J.: The NIAM Information Analysis Method: Theory and Practice. Kluwer, Deventer (1990)

Automated Test Input Generation for Software That Consumes ORM Models Matthew J. McGill1 , R.E. Kurt Stirewalt2 , and Laura K. Dillon1 1

Dept. of Computer Science and Engineering, Michigan State University, East Lansing, MI 48223 {mmcgill,ldillon}@cse.msu.edu 2 LogicBlox, Inc. [email protected]

Abstract. Software tools that analyze and generate code from ORM conceptual schemas are highly susceptible to feature interaction bugs. When testing such tools, test suites are needed that cover many combinations of features, including combinations that rarely occur in practice. Manually creating such a test suite is extremely labor-intensive, and the tester may fail to cover feasible feature combinations that are counterintuitive or that rarely occur. This paper describes ATIG, a prototype tool for automatically generating test suites that cover diverse combinations of ORM features. ATIG makes use of combinatorial testing to optimize coverage of select feature combinations within constraints imposed by the need to keep the sizes of test suites manageable. We have applied ATIG to generate test inputs for an industrial strength ORM-toDatalog code generator. Initial results suggest that it is useful for finding feature interaction errors in tools that operate on ORM models.

1

Introduction

Increasingly, tools are being developed to analyze and generate code from conceptual schemas specified in ORM 2.0. Examples include the professional edition of the Natural ORM Architect (NORMA) [1] and a tool we developed called VisualBlox, which analyzes ORM models to generate schemas in DatalogLB [2].1 A key concern in the development of such a tool is the cost-effective design of a test suite that adequately tests the tool. In this context, a test suite is a large corpus of ORM models. This paper reports on a tool, called ATIG,2 that automatically generates ORM test models covering diverse combinations of ORM features to use for testing purposes. Automating generation of ORM test inputs presents several difficulties. For one, it can be difficult to ensure that the generated inputs are valid ORM. For 1

2

The LogicBlox technology uses DatalogLB to program and query databases built atop the LB platform. Details on this language and the platform are beyond the scope of this paper. ATIG stands for Automatic Test Input Generator.

R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 704–713, 2009. c Springer-Verlag Berlin Heidelberg 2009 

Automated Test Input Generation for Software

705

example, a generated model containing a fact type with no internal uniqueness constraint is not a valid ORM model. ATIG makes use of a specification of the ORM abstract syntax and semantics to avoid generating invalid test models.3 A second difficulty for automating generation of ORM input models is producing reasonable-sized test suites whose inputs combine a wide range of ORM features in a variety of different ways. ATIG employs combinatorial testing [5] to achieve this goal. ATIG takes as input a feature specification, which specifies the ORM features that the generated test suite should exercise, and a test specification. A feature specification encodes a subset of the ORM metamodel in a manner that facilitates automated analysis. The tool then processes these inputs to automatically produce a suite of ORM models that exercise the features described in the feature specification in a variety of combinations, using the test specification to drive the generation process. For convenience and due to space limits, we depict feature specifications as ORM metamodels expressed in ORM, even though they are currently written in Alloy.4 ATIG exploits two tools—the Alloy Analyzer, which automates the instantiation of relational logic specifications [4], and jenny [6], which automates the generation of combinatorial test plans. Because Alloy provides a host of logical and relational operators, representing ORM feature specifications in Alloy is straightforward. Jenny populates a candidate test plan while avoiding an explicitly specified set of infeasible configurations. A problem with using jenny for generating test plans is the need to know and explicitly enumerate infeasible configurations. We use Alloy’s ability to find an instance of a specification, indicating a configuration is feasible, to iteratively refine candidate test plans, feeding configurations that Alloy cannot instantiate back to jenny. The process iteratively determines likely infeasible configurations until jenny is able to produce a test plan that can be fully instantiated. While this process may cause some possible feature combinations to be omitted, our experience to date indicates that the test suites it generates cover diverse combinations of ORM features and are effective in finding subtle interaction errors.

2

Background and Related Work

This section provides background on testing techniques and analysis tools used by our tool. In particular, we describe two complimentary testing techniques, category-partition testing (Sec. 2.1) and combinatorial testing (Sec. 2.2), aspects of which ATIG automates. We also provide a brief overview of the Alloy Analyzer (Sec. 2.3) and discuss related work (Sec. 2.4). 3

4

Determining the satisfiability of an arbitrary ORM model is NP-Hard [3]. However, the small-scope hypothesis, which argues that most errors can be found by exhaustively testing inputs within a small scope [4], suggests that the small test inputs generated by ATIG can find subtle interaction errors, and our experience to date supports this hypothesis. When NORMA supports first-class derivation rules, generating the Alloy specifications from feature specifications modeled in ORM will be straightforward.

706

2.1

M.J. McGill, R.E. Kurt Stirewalt, and L.K. Dillon

Category-Partition Method

The category-partition method (CPM) [7] is a general method for generating test inputs for software programs. A tester usually cannot exhaustively test a non-trivial software program, as the size of the program’s input space is often too big for exhaustive testing to be practical. In CPM, the tester instead partitions the input space of a program into equivalence classes and selects at most a single input from each equivalence class for testing. A key property of this partition is that all test inputs from the same equivalence class should be sufficiently similar to be considered “equivalent” for testing purposes. This section briefly elaborate these ideas, eliding details of CPM not salient to our test generation method. Before describing CPM, we need to introduce some terminology. To partition the input space, the tester identifies one or more categories and associated choices based on a specification of the valid program inputs. Intuitively, a category describes “a major property or characteristic” [7] of a program input by associating with each input a value from some category domain. For example, for an array-sorting program, a tester might define an array length category, whose domain is the set of non-negative integers; a has dups category, whose domain is bool, indicating whether the array contains any duplicate entries; and a sort order category, whose domain is {ascend, descend}, as shown in Table 1. In contrast, a choice for a category designates a subset of the category domain that contains values a tester considers equivalent for testing purposes. Choices for the same category are pair-wise disjoint, but they need not be exhaustive. For example, the choices for array length distinguish arrays of length 0 and 1, but identify all other small arrays (i.e., arrays containing from 2 to 10 elements) as equivalent and all very large arrays (i.e., arrays containing more than 10000 elements) as equivalent for testing purposes. Given a category and an associated choice, an input is said to satisfy, or equivalently, to cover, the choice if the value that the category associates with the input belongs to the choice. For instance, an input containing an array of length 5 satisfies (covers) the choice [2–10] for array length. A choice combination is a set of choices for which each choice corresponds to a different category. A choice combination that additionally contains a choice for each category is also called a test frame. Given the three categories and corresponding choices in Table 1, for example, {1, false, ascend} is both a choice combination and a test frame, whereas any proper subset of it is just a choice combination. An input covers a choice combination if it covers each choice in the combination. Of course, categories are not necessary orthogonal. Thus, there Table 1. Example categories and choices for an array-sorting program Category Domain Choices array length Non-negative integers 0, 1, [2–10], >10000 has dups bool true, false sort order {ascend, descend} ascend, descend

Automated Test Input Generation for Software

707

might be no valid input satisfying certain choice combinations. For example, because arrays of length 1 cannot contain duplicates, the choice combination {1, true} is infeasible. In CPM, a tester provides a test specification in the form of definitions for a set of categories and corresponding choices, and a test set is generated from the test specification. Essentially, the set of all feasible test frames is viewed as defining a partition on the valid program inputs, where each equivalence class consists of the inputs satisfying one of the feasible test frames.5 Ideally, therefore, a test set would cover all feasible test frames. In practice, however, it may not be practical to achieve this level of coverage. For one, determining feasibility is difficult (and can be undecidable). Moreover, the number of test frames grows exponentially with the number of categories, and so can simply be too large. Thus, the tester must typically select some subset of test frames to be covered. We refer to a subset of test frames to be covered by a test set as a test plan. A test set is produced from a test plan by instantiating each of its test frames. Instantiation of a test frame involves searching for an input that satisfies all choices in the test frame. For example, to instantiate the test frame {[2–10], false, ascend}, an array of, say, length three might be populated with three arbitrary, but distinct, integer values, in which case the less-than operator for integers should be selected to use in comparing array elements. A key difficulty with instantiation is actually selecting valid inputs that simultaneously satisfy all the choices. Here again, inputs that are subject to complex syntactic and static semantic constraints (e.g., ORM models) compound this difficulty [3]. ATIG uses the Alloy Analyzer to automate instantiation of a test frame. 2.2

Combinatorial Testing

As previously noted, a tester must typically narrow the set of test frames in CPM, both to eliminate infeasible test frames and to obtain a reasonable-sized test plan. We use combinatorial testing [5] for this purpose. Borrowing terminology from combinatorial testing, we say a test set achieves t-way coverage if it covers every feasible choice combination of size t. When t equals the number of categories, combinatorial testing and CPM produce equivalent test sets. But when t is small, t-way coverage can often be achieved using smaller test sets. For example, 2-way coverage of the categories in Table 1 can be achieved by a test set containing just 8 test inputs. As the number of categories increases, the reduction in test set size becomes increasingly significant, because a single test frame can cover more t-way choice combinations. Tools, such as jenny, automate the generation of t-way test plans, provided the tester indicates infeasible choice combinations.6 A key contribution of our 5

6

If the choices for some category domains are non-exhaustive, then there will also be an equivalence class for all inputs that do not satisfy any test frame. We assume the tester does not care about covering these inputs and so ignore this equivalence class. The problem of generating minimal t-way test plans is NP-hard. Using a greedy algorithm, however, jenny quickly generates test plans that are near-minimal on average.

708

M.J. McGill, R.E. Kurt Stirewalt, and L.K. Dillon

work is to use the Alloy Analyzer in conjunction with jenny to automate the selection of a “good” test plan. 2.3

Alloy

Our current ATIG prototype works on a feature specification expressed in Alloy, a modeling language combining first order predicate logic with relational operators [4]. Additionally, it uses the Alloy Analyzer in instantiating a test frame or to classify a test frame as “likely infeasible.” More generally, the Alloy Analyzer generates instances up to some bounded size, or scope, of specifications expressed in Alloy. Instance generation is essentially a search problem and bounding the scope guarantees the search terminates. If an instance is found, then the Alloy specification is satisfiable. The Alloy Analyzer can display an instance graphically. It can also output a textual description of an instance in XML. 2.4

Related Work

Several existing methods for generating test inputs for code generators produce the inputs from a description of the source notation [8,9,10]. Those cited use UML class diagrams as the meta-notation, not ORM. Also, unlike our method, none attempts to systematically test combinations of source notation features. Wang [8] and Brottier [9] use only information expressible in UML class diagrams, whereas Winkelmann et al. [10] augment UML class diagrams with limited OCL constraints to allow more precise source notation descriptions. The extra precision means that fewer invalid test inputs are generated. Neither ORM nor the OCL subset in [10] is strictly more expressive than the other. For example, OCL’s implication operator has no natural representation in ORM, whereas ORM’s transitivity constraints cannot be expressed in this OCL subset [10]. We expect, however, that a version of NORMA will have formal support for derivation rules that are at least as expressive as this OCL subset. Other existing methods [11,12,13] require a formal specification of the code generator’s mapping from source to target in addition to a description of the source notation. Formally specifying a code generator’s behavior can provide many benefits. External constraints and rapidly changing requirements, however, can make formal specification of behavior impractical or impossible. During the development of VisualBlox, for example, user feedback motivated frequent changes to the code generator’s requirements, and the complexities of the target language frustrated attempts at formality. In contrast, the description of the source notation remained fairly stable.

3

ATIG Inputs and Outputs

Figure 1 shows the inputs that ATIG uses and the outputs that it creates, as well as the main processes it performs and the data these processes produce and

Automated Test Input Generation for Software

709

Fig. 1. Overview of ATIG

consume. We describe the inputs and outputs in this section, deferring discussion of the internals of ATIG to Section 4. ATIG takes as input a feature specification, which describes the ORM features of interest, and a test specification, which describes the categories and associated choices that a test set should exercise. Figure 2 illustrates the type of information expressed by a feature specification for a subset of the ORM features supported by VisualBlox. Because we do not have space to describe Alloy in this paper, we show the the feature specification as an ORM metamodel. Encoding this metamodel in Alloy is straightforward. The ORM metamodel represents ORM language elements by entity types a(e.g, EntityType, Role) nd represents potential relationships among language elements by fact types (e.g., EntityType plays Role). Constraints (e.g., simple mandatory constraints, exclusion constraints) capture some of the static semantics. Others are specified as derivation rules (e.g., rule labeled “*” attached to Role is lone). For feasibility checking to be tractable, a feature specification can include only a relatively small subset of features and must encode static semantic constraints with an eye toward keeping the sizes of instances small. These considerations affect what to include in the feature specification and how to encode the static

Fig. 2. A simple ORM metamodel of ORM, for testing VisualBlox

710

M.J. McGill, R.E. Kurt Stirewalt, and L.K. Dillon

semantics. For example, an ORM metamodel would typically have a mandatory many-to-many fact type InternalUC constrains Role. However, encoding the compliment of this fact type—InternalUC excludes Role, a non-mandatory one-to-one fact type—produces smaller instances. A test specification supplied to ATIG comprises a set of cardinality categories and associated choices. A cardinality category describes the number of times a particular ORM language element or language element relationship (described in the feature specification) appears in a test model. The domain of a cardinality category is the set of non-negative integers. By convention, a cardinality category is denoted |element name|, where element name stands for the ORM entity or predicate name from the feature specification (e.g., |EntityType|, |Role is in FactType|). ATIG outputs a set of ORM test models in the format used by NORMA. It can also output these test models as diagrams, which facilitates checking that a test model is valid ORM.

4

ATIG: Test-Set Generation Algorithm

ATIG takes as input a feature specification and a test specification, and generates a test set of ORM models using the iterative process depicted in Figure 1. This process employs jenny to iteratively generate candidate test plans, which achieve t-way coverage of the choices defined in the test specification. In addition to the space of choices, jenny takes as input a set of likely infeasible choice combinations to avoid when generating candidate test plans.7 Initially empty, a set of likely infeasible choice combinations is gradually populated as a byproduct of attempts to instantiate the frames of a candidate test plan, as depicted in Figure 1. ATIG uses the Alloy Analyzer to attempt to instantiate test frames. Based on the success or failure of these attempts, control passes along different arcs in Figure 1. Briefly, suppose F denotes an Alloy specification of a portion of the ORM metamodel and f denotes a test frame comprising a set of choices {c1 , c2 , . . . , ck }. ATIG instantiates f by: 1. translating f into an Alloy predicate P with k conjuncts, each of which encodes some ci ∈ f as a constraint on the cardinality of some signature or relation declared in F ; and then 2. using the Alloy Analyzer to run P (within some finite scope) to generate an instance of F that satisfies all of the choices in f . Step 1 is trivial because we use only cardinality categories and the names of these categories correspond to the names of signatures in F . Step 2 may have one of two outcomes: Either the Alloy Analyzer fails to find an instance within the specified scope, in which case we deem f is a likely infeasible frame, or it finds an instance, which ATIG then translates into an ORM model according 7

Jenny treats each choice as an opaque identifier and thus may generate a host of infeasible choice combinations.

Automated Test Input Generation for Software

711

to the schema of the XML representation used by NORMA. Rather than add a likely infeasible frame to the set of likely infeasible choice combinations, ATIG attempts to find a minimal subset of the frame that cannot be instantiated in the given scope.8 To summarize, ATIG generates a test plan comprising only test frames that are consistent with the feature specification, while attempting to optimize coverage of t-way choice combinations. It identifies likely infeasible choice combinations using an iterative process, incrementally building up a list of combinations for jenny to avoid until jenny produces a test plan that ATIG can instantiate (within some particular scope).

5

Discussion and Future Work

A small study with ATIG suggests the tool can generate moderate-sized test suites capable of exposing unexpected interaction bugs. In this study, we used a feature specification that extends the metamodel in Figure 2 with objectification and with integer and boolean value types. The extended metamodel contains 8 object types and 8 fact types, 2 of which are derived. For a test specification, we introduced a cardinality category for each non-derived fact type in the metamodel, and associated 5 choices—namely, 0, 1, 2, [3,5], and [6–8]—with 3 of the categories and 4 choices—namely, 1, 2, [3,5], [6-8]—with the other 3 categories. We ran ATIG on these feature and test specifications to generate a 2-way test set of ORM models. The test specification produces a total of 8, 000 distinct test frames. ATIG generated a test plan containing just 37 test frames, classifying 51 choice combinations as likely infeasible in the process. It took just under 19 minutes (wall time) on a desktop computer containing an Intel Core 2 Duo 3 ghz processor and 2 gigabytes of RAM. The majority of this time is spent in checking choice combinations for feasibility when a test frame cannot be instantiated within the scope used. The 37 models in the generated test set cover a diverse range of ORM feature combinations and exposed a number of previously unknown errors in the current version of VisualBlox. Figure 3 shows four ORM models from the generated test set. Collectively, the models in Figure 3 cover value types used in combination with every other ORM language element in the feature specification, namely entity types, simple mandatory and internal uniqueness constraints, fact types of different arities, and objectification. By covering many feature combinations not present in our manually produced test set, the generated test set uncovered multiple, previously unknown errors. Specifically, 15 of the 37 test models, each a valid ORM model, exercise ORM features in combinations that caused VisualBlox to produce Datalog code that was not accepted by the DatalogLB compiler. Thus, roughly 40% of the automatically generated test inputs were valid models that the VisualBlox development team had not considered supporting. 8

Providing smaller choice combinations will prevent jenny from using these combinations in any generated test plan, speeding convergence of the iterative process.

712

M.J. McGill, R.E. Kurt Stirewalt, and L.K. Dillon

(a) with unary fact type

(c) with entity types

(b) with mandatory uniqueness constraints

and

(d) with objectification

Fig. 3. ATIG-generated models combining value types with other ORM modeling features

Our preliminary results suggest several areas for future work. First, we plan studies to more formally assess the quality of test sets generated with ATIG. Our first study will include more ORM features in the feature specification, and compare the cost-effectiveness of 2-way, 3-way and higher, and manually constructed test sets. Later studies will evaluate various heuristics used in our current prototype. For example, how does using smaller scopes when instantiating test frames affect the size of the generated test plan, the diversity of the choice combinations covered by this plan, the errors exposed by a test set, and the time to generate test sets? Another question deserving more attention in light of the time spent finding minimal-sized likely-infeasible choice combinations is the cost-effectiveness of this step. Would equally diverse test sets be produced if we collected test frames instead of minimal choice combinations, and how would doing so affect the time for the iterative process to converge? In other future studies, we plan to evaluate whether ATIG can provide similar benefits if used to generate test sets for programs that consume other types of inputs with complex structural constraints (e.g., UML models). To facilitate conducting such studies, we also plan to automate the translation of an ORM metamodel into an Alloy feature specification. Translating the graphical ORM language features to Alloy is straightforward. At present, textual constraints on derivation rules pose the primary obstacle to automating the translation to Alloy because there is no formal textual syntax for constraints in NORMA. We anticipate that a future version of NORMA, however, will support textual derivation rules for derived fact types and textual constraints. Another promising area for future work is adding support to ATIG for parallel invocations of Alloy on separate processors or computers to take advantage of the embarrasingly parallel nature of instantiating test frames and searching for likely infeasible choice combinations.

Automated Test Input Generation for Software

713

References 1. Curland, M., Halpin, T.: Model driven development with NORMA. In: Proc. of the 40th Int’l. Conf. on Sys. Sci (2007) 2. Zook, D., Pasalic, E., Sarna-Starosta, B.: Typed datalog. In: Proc. of the 11th International Symposium on Practical Aspects of Declarative Languages (2009) 3. Smaragdakis, Y., Csallner, C., Subramanian, R.: Scalable automatic test data generation from modeling diagrams. In: Proceedings of the twenty-second IEEE/ACM international conference on Automated software engineering, pp. 4–13. ACM, New York (2007) 4. Jackson, D.: Software Abstractions: Logic, Language, and Analysis. MIT Press, Cambridge (2006) 5. Cohen, D., Dalal, S., Parelius, J., Patton, G., Bellcore, N.: The combinatorial design approach to automatic test generation. IEEE software 13(5), 83–88 (1996) 6. http://burtleburtle.net/bob/math/jenny.html: jenny (June 2006) 7. Ostrand, T.J., Balcer, M.J.: The Category-Partition Method for Specifying and Generating Functional Tests. Communications of the ACM 31(6) (1988) 8. Wang, J., Kim, S., Carrington, D.: Automatic Generation of Test Models for Model Transformations. In: 19th Australian Conference on Software Engineering, 2008. ASWEC 2008, pp. 432–440 (2008) 9. Brottier, E., Fleurey, F., Steel, J., Baudry, B., Le Traon, Y.: Metamodel-based test generation for model transformations: an algorithm and a tool. In: 17th International Symposium on Software Reliability Engineering, 2006. ISSRE 2006, pp. 85–94 (2006) 10. Winkelmann, J., Taentzer, G., Ehrig, K., K¨ uster, J.M.: Translation of restricted ocl constraints into graph constraints for generating meta model instances by graph grammars. Electronic Notes in Theoretical Computer Science 211, 159–170 (2008) 11. Sturmer, I., Conrad, M., Doerr, H., Pepper, P.: Systematic Testing of ModelBased Code Generators. IEEE Transactions on Software Engineering 33(9), 622– 634 (2007) 12. Baldan, P., Konig, B., Sturmer, I.: Generating test cases for code generators by unfolding graph transformation systems. LNCS, pp. 194–209 (2004) 13. Lamari, M.: Towards an automated test generation for the verification of model transformations. In: Proceedings of the 2007 ACM symposium on Applied computing, pp. 998–1005. ACM, New York (2007)

Development of Tooling to Support Fact-Oriented Modeling at ESA Inge Lemmens1, Francesco Sgaramella2, and Serge Valera3 1

PNA Generics, The Netherlands 2 Space Software Italia, Italy 3 European Space Agency, Noordwijk [email protected], [email protected], [email protected]

Abstract. Developing space systems implies complex activities involving many parties who are widely distributed in location and time. Such development therefore requires efficient and effective information exchange during the complete lifecycle of the space system. This can only be achieved by realizing semantic interoperability between all involved parties. Semantic interoperability can be achieved if the applications involved share a set of conceptual definitions. To achieve this goal, the concept of a global conceptual model that has the potential to embrace the complete lifecycle of a space system is analyzed. Realizing the full potential of this approach requires methods and tools not only to support the formal specification of such a conceptual model and their tailoring for producing application specific conceptual models, but also to support the development or adaptation of applications resulting in needs to support the 3-level data model hierarchy and the ability to specify domain-specific conceptual models based on the global conceptual model. This paper describes the tools that are under development to support the above described objectives. Keywords: semantic interoperability, fact-oriented modeling, ORM, ESA, ECSS, global conceptual model.

1 Introduction Developing a space system implies complex activities involving many parties who may be widely-distributed both geographically and in time. Each involved party makes use of information systems for capturing and maintaining the information required for developing and operating the elements of the space system of their responsibility. Due to this distribution, both in time and in space, efficient and effective information exchange has to take place during the complete lifecycle of the space system. Through the years and in absence of standards and common definitions, each party has had the freedom to specify how the required information is structured and used. Due to these historical reasons, sharing information between the involved parties is difficult and potentially even impossible. Moreover, reusing the information provided by one of the involved parties presents a potential threat to the successful sharing of information due to the inherent risk of semantic misinterpretation of the supplied information by another party. R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 714–722, 2009. © Springer-Verlag Berlin Heidelberg 2009

Development of Tooling to Support Fact-Oriented Modeling at ESA

715

Successful sharing of information during the whole lifecycle of the space system implies that the information has to be exchanged between the sharing parties without a mismatch of information or a loss of semantics. This can only be realized if the involved parties share the same semantics and have means to derive their own representation from this shared semantics.

2 Semantic Interoperability Any process within the development of a space system uses and produces data. These processes are supported by many different information systems, each of which has a data repository to provide the persistent data storage. Information exchange can thus be considered as the exchange of data between database applications. Taking into account that it is impossible (and undesirable) to standardize the database applications that are used across space industry and agencies, standardization of the data has to be achieved at the semantic level. In order to achieve semantic interoperability, it is necessary to model the data and express the results in a formal way. It is desirable to use as much as possible a modeling approach that provides repeatability and traceability. The approach promoted by this paper complies with the 3-level hierarchy of data models, namely: 1. A conceptual data model, 2. Logical data models, 3. Physical data models. A conceptual data model specifies the semantics of the data relevant to the domain; it defines the data of significance to the end-users, its characteristics and the associations between the data, the meaning and the rules that apply. A logical data model is developed (derived) from the conceptual data model, expressed using a specific data modeling notation, like the Entity-Relationship notation. A physical model is developed (derived) from a logical data model and is used for e.g. permanently storing the data objects on a computer.

Logical Models

Physical Models Fig. 1. The 3-level hierarchy of data models

716

I. Lemmens, F. Sgaramella, and S. Valera

Taking into account that a conceptual model specifies the semantics of the data relevant to the domain, semantic interoperability can be achieved if the involved database applications implement globally-consistent conceptual definitions. To achieve this objective, developing a “domain-specific” conceptual model (i.e. for a given application) requires considering the overall community, i.e. the system, represented by the global conceptual model. Such a constraint implies the following activities: 1. Identifying, within the existing population of the global conceptual model, those conceptual definitions of local interest, potentially defining additional derivation rules for mapping to and from this local view; 2. Adding to the global conceptual model the missing conceptual definitions in a way that satisfies the potential users of these definitions, i.e. the system, for example by applying standards, by ensuring that the system is involved in the modeling of additional definitions. Such an approach results in modeling a local conceptual model as a subset of the global conceptual model.

Fig. 2. Domain-specific conceptual models as subsets of the global conceptual model

3 One Objective, Two Functions Analyzing above overall objective reveals that a supporting tool has to implement two major functions, namely the function: 1. To support the production of database applications and their related components, and 2. To support the exchange of database products on the basis of the global conceptual model that comprises the globally-consistent conceptual definitions. 3.1 Function 1 – Supporting the Production of Database Applications Database applications are generally applications consisting of several data related components, such as those depicted in figure 3. Realizing function 1 means that the tool should support the development of each of these data related components. This forms the scope of the “Enhanced FOM (Fact-Oriented Modeling) tool”.

Development of Tooling to Support Fact-Oriented Modeling at ESA

717

Fig. 3. A database application and its typical data related components

3.2 Function 2 – Supporting the Exchange of Database Products Exchanging database products implies semantic-adequacy of the interpretation of the data by both suppliers and customers. Realizing function 2 means that the tool should ensure the adequacy of the exchanged data for all of its users. This implies that function 1’s conceptual modeling is compliant with system conditions as depicted in figure 4. This forms the scope of the “Ontology definition FOM tool”.

Fig. 4. Development of applications compliant with system conditions

718

I. Lemmens, F. Sgaramella, and S. Valera

4 The Enhanced FOM Tool: A Global Overview The Enhanced FOM tool is responsible for implementing the requirements stemming from function 1, as depicted in figure 5.

Fig. 5. Overall overview of the Enhanced FOM tool

The three-layer architecture of data models is supported by the Enhanced FOM tool. The conceptual model forms the first, top, layer of this architecture and is the basis for the logical models which can be derived from this conceptual model. Three types of logical models are under analysis, namely the relational model, the hierarchical model and the object-oriented model. Mapping from conceptual to logical, and further on from logical to physical model, is done by means of mapping algorithms. However, because there is not one optimal (for all application domains) mapping from conceptual to logical and physical (of given types), customization for each mapping is provided. The relational model is an abstraction and transformation of the conceptual model, showing the underlying relational structure as supported by relational databases. In other words, the relational model is a set of tables and relations between these tables. The hierarchical model is an abstraction of the conceptual model allowing scoping (based on the existence-dependencies relations) and reusing conceptual definitions in

Development of Tooling to Support Fact-Oriented Modeling at ESA

719

order to produce tree-like structures using parent/child relationships. This hierarchical model is adapted to users’ views on the data and offers means to develop facilities such as man-machine interfaces and hierarchically structured data exchange files. The object-oriented model is an abstraction and transformation of classes and relationships between these classes. Based on the logical models, physical models are derived taking into account the software needs (derived from user needs), and given technologies. Assessing the implications of given logical and physical models implies identifying those conceptual definitions that are required for developing a given solution. This means not only those already covered by fact-oriented modeling but also additional ones. For this purpose, as shown in figure 5, assessing MMI development, XSD and XMI is included taking into account the user needs and environmental constraints (such as security): • The man-machine interface modeling acknowledges the existence of (so-called) “data-model-independent MMI model”, i.e., including software requirements derived from user needs and environmental constraints as well as architecture issues of a given technology. The latter physical models provide “data requirements” as derived from the conceptual and logical models that configure the model-independent specification which is the basis of the data-model-independent MMI model. • Trade-offs are made for the modeling of the data repository according to overall needs and technology characteristics, e.g. however relational SQL is adequate for human interactions, it might not be optimal for “between-software” interactions such as those having hard real-time access needs. • XSD is used for example for exchanging data with external entities, e.g. import/ export.

5 Interaction with Other Methods and Tools Interoperability does not mean having everyone following the same method, using the same tools. Complying itself to the interoperability objective, the Enhanced FOM tool promotes the need for exchanging conceptual models developed using other modeling methods and tools. As shown in figure 6, several information exchange points have been identified for ensuring interoperability of conceptual, logical and physical models. Promoting the use of fact-oriented modeling for specifying conceptual models, baselines a FOM exchange schema that is proposed to the overall fact-oriented modeling community as standard means to exchange fact-oriented models. This exchange schema covers the essential concepts required for developing conceptual definitions according to the fact-oriented philosophy, namely ORM, CogNIAM, FCO-IM, SBVR or any other fact-oriented representation form. It also identifies additional conceptual knowledge needed to allow reusing, compiling and structuring fact-oriented models.

720

I. Lemmens, F. Sgaramella, and S. Valera

Fig. 6. Interaction between the Enhanced FOM tool and other tools

For interacting with other modeling tools, interfacing is proposed at the logical level according with existing or to-be-specified interface control documents (ICDs) that define the exchange format (e.g. XMI for object-oriented models). Finally, the Enhanced FOM tool also supports the mapping with implemented models as instantiated within database management systems.

6 The Ontology Definition FOM Tool: A Global Overview Semantic interoperability requires not just any conceptual model but a conceptual model which is comprehensible to all involved stakeholders (see for early work on this [1], [2]), and which is expressive enough to capture everyone’s need without conditioning the quality of everyone’s solution. Achieving comprehensiveness between all stakeholders is realized by using Object Role Modeling. Achieving expressiveness is realized by extending ORM with structuring, packaging, conditioning conceptual definitions, conditioning assertions and derivations, etc. Realizing the full potential of the global conceptual model requires tooling to support not only the development of the global conceptual model based on ORM, but also supports the 3-level data modeling hierarchy (conceptual, logical, physical) and the ability to specify domain-specific conceptual models based on the global conceptual model.

Development of Tooling to Support Fact-Oriented Modeling at ESA

721

Currently, no fact-oriented modeling tool exists to support such extensive needs. The second overall objective of the research activity, initiated by ESA, is the study and development of a “space system ontology definition tool” based on the ORM methodology which is able to support the conceptual modeling of the overall space system knowledge in a way that baselines the conditions required: • For producing database applications that comply with user needs, e.g. providing adequate structures, adequate interface specifications for maintaining and accessing data, adequate constraint specifications for ensuring data quality, adequate data lifecycle specification for ensuring data availability. • For providing means to share and reuse data between applications, e.g. producing interface specifications for data exchange and transformations. 6.1 Using the Ontology Definition FOM Tool within ESA The ECSS (European Cooperation for Space Standardization) System has been developed as a cooperative effort between the European space agencies and space industries. It comprises a comprehensive set of documents addressing all essential aspects of successful implementations of space programs and projects, covering: • Project management, • Engineering, and • Product assurance. With more than 100 standards, handbooks and technical memoranda, the ECSS system constitutes an “informal” specification of a space system ontology that is used by all actors involved in the overall development and operations of space systems. The Ontology Definition FOM tool is developed with the objective to cover all modeling capabilities required to formally specify the ECSS system and to provide to ESA missions the capability to tailor these standardized definitions for projectspecific and application-specific needs, as depicted in figure 7.

Fig. 7. Applying formal methods and tools for deploying the ECSS System

722

I. Lemmens, F. Sgaramella, and S. Valera

Acknowledgements Developing a tool that fulfils the above requirements is an ambitious task and requires a solid understanding of not only fact-oriented modeling, but also the problem domain and its particularities. Therefore, a consortium of three parties consisting of Space Software Italia, PNA Group and the NORMA team (consisting of Terry Halpin and Matt Curland) is working closely with ESA to realize the goals. Each party in this consortium brings in its own unique knowledge and its own unique view on the challenge at hand. We greatly appreciate the support of all the parties involved.

References 1. Nijssen, G.M.: A Framework for Discussion in ISO/TC97/SC5/WG3 and Comments on 78.04./01 and 78.05/03 (1978) 2. Halpin, T., Morgan, T.: Information Modeling and Relational Databases, 2nd edn. Morgan Kaufmann, San Francisco (2008)

Predicate Reference and Navigation in ORM Terry Halpin LogicBlox, Australia and INTI Education Group, Malaysia [email protected]

Abstract. A conceptual schema of an information system specifies the fact structures of interest as well as related business rules that are either constraints or derivation rules. The sole data structure used in fact-oriented modeling approaches is the fact type, which may be understood as a set of typed predicates. In spite of the central role played by predicates in fact-orientation, several issues need to be resolved before their full potential can be fully realized. This paper identifies a number of these issues relating to predicate reference and navigation, and proposes some solutions. Specific issues addressed include predicate disambiguation and formalization, role navigation, and automated verbalization of predicate paths. While the discussion focuses largely on Object-Role Modeling (ORM), many of the issues discussed are also relevant to other fact-oriented approaches, such as Cognition enhanced Natural Information Analysis Method (CogNIAM) and the Semantics of Business Vocabulary and Business Rules approach (SBVR), as well as attribute-based approaches like Entity Relationship modeling and the Unified Modeling Language.

1 Introduction With the rise of model-driven engineering, information systems are increasingly based on high level information models that can be more easily validated with business users. Such an information model includes a conceptual schema as well as a population (set of instances). A conceptual schema specifies the fact structures of interest as well as applicable business rules. Business rules are constraints or derivation rules that apply to the relevant business domain. Constraints restrict the possible or permitted states or state transitions of fact populations. Derivation rules enable some facts to be derived from others. In fact-oriented approaches, all facts are treated as instances of fact types, which may be existential (e.g. Patient exists) or elementary (e.g. Patient smokes, Patient is allergic to Drug). From a logical perspective, a fact type may be treated as a set of typed predicates. For example, the readings “Person is employed by Company” and “Company employs Person” denote the same fact type, but involve two different predicates that are inverses of one another. In attribute-based approaches such as Entity Relationship modeling (ER) [4] and the class diagramming technique within the Unified Modeling Language (UML) [19], facts may be instances of attributes (e.g. Patient.isSmoker) or relationship types (e.g. Patient is allergic to Drug). Both of these structures may be formalized in terms of logical predicates. R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 723–734, 2009. © Springer-Verlag Berlin Heidelberg 2009

724

T. Halpin

In spite of the central role played by predicates in information modeling, several issues need to be resolved. This paper examines a number of these issues relating to predicate reference and navigation within Object-Role Modeling (ORM), a prime exemplar of the fact-oriented approach based on an extended version of Natural Information Analysis method (NIAM) [24]. An introduction to ORM may be found in [10], a thorough treatment in [15], and a comparison with UML in [13]. Fact-oriented modeling includes other closely related approaches, such as Cognition-enhanced NIAM (CogNIAM) [19], Predicator Set Model (PSM) [16, 17], and Fully-Communication Oriented Information Modeling (FCO-IM) [1]. The Semantics of Business Vocabulary and Business Rules (SBVR) initiative is also fact-based in its use of attribute-free constructs [4, 22]. Recently ORM was extended to second generation ORM (ORM 2) [9], the version used in this paper. An overview of factoriented modeling approaches, including history and research directions, may be found in [12]. Although the following discussion focuses largely on ORM, as supported by the Natural ORM Architect (NORMA) tool [6], many of the issues are relevant to other fact-oriented approaches as well as attribute-based approaches like ER and UML. The rest of this paper is structured as follows. Section 2 discusses predicate disambiguation, including formalization options. Section 3 addresses role navigation, with special reference to n-ary relationships. Section 4 provides an algorithm for automated verbalization of predicate paths, and applies this to join constraint verbalization. Section 5 summarizes the main results and outlines future research directions.

2 Predicate Disambiguation Figure 1(a) depicts three fact types in ORM notation: Person runs Barbershop; Person runs Race; Horse runs Race. Reference schemes for the entity types are omitted for simplicity. Figure 1(b) shows an equivalent UML class diagram. (a)

runs Person

Barbershop

runs

(b)

Person

Barbershop runs 0..1 0..1 runs

Race

Horse runs

0..1 Race

* runs

Horse *

*

(c) http://www.w4.org/concept#runs http://www.orm.net/People/contact#th

http://www.orm.net/People/contact#th

http://www.abc.net/Horse/name#Pharlap

http://www.bus.net/Barbershop/id#55 http://www.u2.org/concept#runs

http://www.u2.org/concept#runs

http://www.abc.net/Race/id#3

http://www.abc.net/Race/id#37

Fig. 1. Multiple “runs” predicates in (a) ORM, (b) UML, and (c) RDF

Predicate Reference and Navigation in ORM

725

Each of the three fact types involves a binary predicate displayed with the same verb phrase “runs”. If we use the term “predicate” for the intended semantics of a verb phrase occurrence, then the “runs” predicate in the fact type Person runs Race may be considered the same predicate as the “runs” predicate in the fact type Horse runs Race while differing from the “runs” predicate in the fact type Person runs Barbershop. However, the correspondence between two of these “runs” occurrences is lost in both ORM and UML, since neither provides a practical mechanism for indicating such a correspondence. Although supertyping could achieve this purpose, this would not always be sensible. For example, we could introduce Animal as a supertype of Person and Horse, and replace the two race fact types with the single fact type Animal runs Race. In practice however, the identification schemes for Person and Horse might differ, and be based on different data types (e.g. numeric or string), leading to awkward solutions such as adding artificial identifiers. Moreover, the constraints on the predicate occurrences might differ (as in this example), thus adding to the complexity of unifying the types. For another example of this problem based on ownership, see [15, pp. 262-263]. The Resource Description Framework (RDF) does provide a practical mechanism for predicate identification. In line with the Semantic Web proposal [2], documents may be enriched with global identifiers and structure, using Uniform Resource Identifier references (URIrefs) and embedded tags, to reveal the semantics of what is to be shared in a way that is accessible to automated agents. Ontology languages such as the Web Ontology Language (OWL) are built on top of RDF [25]. Figure 1(c) shows three RDF statements that instantiate the fact types in the ORM and UML schemas. The predicates depicted as labeled arrows in the bottom two statements are seen to be identical in semantics because they have the same URIref. This raises the following issue. Should modeling approaches such as ORM, ER, and UML be extended to enable predicate occurrences to be “equated” (in the sense of having the same meaning), and if so, how? An answer to this question may well have bearing on procedures for mapping between these approaches and OWL. When I formalized ORM many years ago [7], I used unsorted predicate calculus, and treated predicates in different fact types as distinct, even if they had the same short “display name” (e.g. “runs”, “has”). Display predicate names that appeared in multiple fact types were internally expanded to distinct, full predicate names. This expansion may be done by including relevant object type names or by subscripting. For example, the predicate names in Figure 1 may be unabbreviated to “personRunsBarbershop”, “personRunsRace”, and “horseRunsRace”, or to “runs1”, “runs2” and “runs3”. For this example, the first predicate could have been expanded simply to “runsBarbershop”, but if we later added another fact type such as Company runs Barbershop, at least one of these predicates would need a different full name. This convention allows fact types to be formalized via simple typing constraints. For example, the three fact types in our example may be declared thus: ∀xy(x personRunsBarbershop y → Person x & Barbershop y) ∀xy(x personRunsRace y → Person x & Race y) ∀xy(x horseRunsRace y → Horse x & Race y)

726

T. Halpin

Strictly, a fact type corresponds to a set of one or more typed predicates, so alternate readings (e.g. “Person operates Barbershop”, “Barbershop is run by Person”) may be declared for the same fact type, using equivalence operations to establish the correspondence. While use of predicate subscripts leads to shorter formulae, this has the disadvantage for humans of needing to remember which meaning is intended by the subscript. For example, consider the uniqueness constraint that each person runs at most one barbershop. If we use “runs1” for the predicate, the constraint is formalized by the first formula below. Without remembering which of the “runs” predicates is captured by “runs1”, this is less informative than the longwinded second formula. ∀x ∃0..1y(x runs1 y) ∀x ∃0..1y(x personRunsBarbershop y) More recently, I’ve often used sorted logic to formalize ORM. This leads to more elegant formalizations of constraints, so long as we treat all predicates displayed with the same short name as being the same predicate. For example, the uniqueness constraint now formalizes nicely as: ∀x:Person ∃0..1y:Barbershop(x runs y) Unfortunately, this complicates our predicate declaration via typing constraints, since this now leads to disjunctive typing. For example, the three predicate declarations given earlier are replaced by: ∀xy(x runs y → [(Person x & Barbershop y) ∨ (Person x & Race y) ∨ (Horse x & Race y)]) This has some advantages, because we can now easily formulate queries such as “What runs What?” irrespective of the types involved. This is less modular than the previous approach, because every time a runs predicate is added or deleted the disjunction in the type declaration has to be modified accordingly. Nevertheless, the constraint declarations are stable because the types are always specified. Neither of these two approaches reveals which “runs” occurrences mean the same. If we want to capture this correspondence visually, here is one possible solution. By default, treat predicates with the same “short name” as distinct (they internally expand to full predicate names including the object type names) unless they are explicitly equated by appending the same subscript, or are related by a specialization relationship (see [15, p. 387] for a discussion of association redefinition in UML and ORM). For our example, this leads to the ORM schema of Figure 3. Because such cases are rare in modeling, this seems the least intrusive diagrammatic solution. A URIref could also be assigned (e.g. on a property grid) for any predicate for which this is desired. runs Person

Barbershop

runs1

Race

Horse runs1

Fig. 2. Equating predicate semantics

Predicate Reference and Navigation in ORM

727

The predicate declarations may now be formalized as shown. If a short predicate name occurs in only one fact type, you could instead simply use that (e.g. use “runs” instead of “personRunsBarbershop” in the first formula below) so long as you maintain distinct predicate names if this situation changes. ∀xy(x personRunsBarbershop y → Person x & Barbershop y) ∀xy(x runs1 y → [(Person x & Race y) ∨ (Horse x & Race y)]) Care is required when referencing predicates within rules. Consider Figure 3(a), for example. Here the “is licensed” predicate for Doctor means “is licensed to practise medicine”, while the “is licensed” predicate for Driver means “is licensed to drive an automobile”. A footnoted, deontic rule [11] is specified in FORML for DrivingDoctor. This rule is ambiguous, because there is no formal way to determine which of the “is licensed” predicates is intended. One way to resolve this ambiguity is to require that in such cases the relevant subtyping relationship(s) must be included in the rule, with an understanding that predicates have minimum scope. Suppose the intent of the rule is that driving doctors ought to be licensed to practice medicine. In this case, the FORML rule can be disambiguated by expansion to “Each DrivingDoctor is a Doctor who is licensed”. A second, and probably preferable, way to resolve the ambiguity is to enforce the following metarule: if object types overlap, and their grammatical predicates have different semantics, then their grammatical predicates must have different readings. Grammatical predicates are basically fact types minus the object type role being predicated. For example, runsRace is Person’s grammatical predicate in Person runs Race. For unary fact types only, grammatical predicate names are the short, logical predicate names (e.g. is licensed). For the current example, the schema in Figure 3(a) is then illegal, and the user must rephrase at least one of the “is licensed” predicates to distinguish them. Figure 3(b) renames both predicates, removing the rule ambiguity. (a)

(b)

Person

Doctor

Driver

is licensed

is licensed

Doctor is licensed to practise medicine

DrivingDoctor1 1

It is obligatory that each DrivingDoctor is licensed.

Person

Driver is licensed to drive an automobile

DrivingDoctor1 1

It is obligatory that each DrivingDoctor is licensed to practise medicine.

Fig. 3. An ambiguous rule (a) disambiguated (b)

3 Role Navigation If an object type plays a given role in a predicate, all other roles in that predicate are far roles of that object type. Hence, if an object type plays more than one role in a predicate, then all roles in that predicate are far roles for that object type. ORM

728

T. Halpin

requires far role names (if they exist) to be unique for any object type. If an ORM object type A has only one of its far roles played by an object type B, then by default that far role has B’s name as its role name, with its first letter lowercased. These naming rules for roles are similar to those in UML, except UML requires each role to have a name. Unlike ORM, UML does not require predicates to be named, so role names and class names provide the normal way to navigate around a UML class diagram (e.g. using OCL [21, 23]). ORM allows rules to be formulated in either relational style, using predicate names, or attribute-style, using role names. Navigation via role names is straightforward for binary predicates, since the role name is chosen from the perspective of an instance of an object type for which it is a far role. For example, consider the fact type Company is owned by Company in Figure 4. To find which companies are owned by IBM, we might issue the query in relational style as List each Company that is owned by Company ‘IBM’, or in attribute style as Company ‘IBM’.subsidiary. However, role access is less straightforward with n-ary fact types (n > 2). In normal practice, roles on n-aries are named with respect to the n-ary relationship itself rather than with respect to one of its object types. In Figure 4, for example, consider the ternary fact type Company sold Product to Company. Here, the names of the two company roles are “seller” and “buyer”, and the product role name is by default “product”. These role names are useful for generating column names in a relational table for the sale fact type, but they are not useful for navigating around the schema. For example, an expression such as “company.seller” suggests a company’s seller, which is not at all what the expression means. Suppose that we want to know which products have been sold by IBM. This can be specified in relational style easily enough (e.g. List each Product where Company ‘IBM’ sold that Product to some Company). But this query can’t be formulated in attribute style using role names on the ternary. It’s no use using “company.product” to navigate from Company to the product role in the ternary, because this doesn’t tell us whether a given product was bought by that company or whether it was sold by that company. To resolve this issue, we introduce derived binary fact types projected from the ternary, and add relevant role names to them, as shown in Figure 4. The query may now be formulated in attribute style thus: Company ‘IBM’.productSold. is owned by [subsidiary]

[parent]

Company bought* [productBought]

[buyer] [seller] … sold … to ...

sold* [productSold]

Product *Company bought Product [as productBought] iff some Company2 sold that Product to Company. *Company sold Product [as productSold] iff that Company sold that Product to some Company2.

Fig. 4. Navigation using role names

Predicate Reference and Navigation in ORM

729

4 Predicate Path Verbalization Earlier we saw some basic examples of navigating predicate paths in either relational or attribute-style. Navigating from one predicate to another involves a conceptual join on the connecting object type(s) [8, 15]. To automate verbalization of constraints involving join paths (e.g. join subset constraints), a mechanism is needed to specify the underlying role paths and the joins involved. This section provides patterns for verbalizing role paths for the case of inner joins over roles projected from a role path, and applies the technique to verbalize a join subset constraint. Figure 5 shows an abstract example, where the external uniqueness constraint is applied to the role pair (r1, r10), which is projected from the role path (r1, r2, r3, r4, r9, r10) formed by traversing the predicate sequence R1, R2 and R5 and performing the inner joins r2 = r3 and r4 = r9. This role path is a multijoin path as it involves more than one join. Our role path choice is indicated here by shading the joins, but there are three possible paths between B and C. Instead of traversing the top predicate R2, we could traverse the middle predicate R3 that implicitly underlies the subtype connection, performing the joins r2 = r5 and r6 = r9. R3 has the reading “is”, and like the other predicates, is an instance-level predicate: it relates instances of B to instances of C, and is implied by the type-level metapredicate that relates the type B to the type C. As a third alternative, we could traverse the bottom predicate R4, performing the joins r2 = r7 and r8 = r9. R2 R1 A

r1

r2

r3

r4

r5

r6

B

R5 C

r9

r10

D

R3 r7

r8

R4

Fig. 5. External Uniqueness Constraint over a multijoin path

Currently NORMA does not graphically highlight the relevant joins (as done here using shading). In general, shading is not adequate since a path may traverse the same predicate more than once. A general graphical solution may be provided by numbering the roles used to perform the joins. An alternative is to use a textual language to formulate constraints for such cases, verbalizing the relevant join paths. There are two natural ways to verbalize conceptual inner joins in English, one using “that” (or “who” if the join object type is declared personal) and one using “and”. The first way may be used if we have a predicate reading that ends with the join’s entry role followed by a predicate reading starting at the join’s exit role (i.e. one predicate is directed towards, and one predicate reading is directed away from, the join object type). This is illustrated in Figure 6(a), where the join is left-to-right. The second way may be used if we have a predicate reading that starts at the entry role and another predicate reading that starts at the exit role (i.e. both predicates are directed away from the join object type). This is illustrated in Figure 6(b), where the join is top-to-bottom.

730

T. Halpin

(a)

entry role

(b)

exit role

entry role R1

A R1

R2

A R1 … and R2 …

A

… R1 … A that R2 ...

R2 exit role

Fig. 6. Two verbalization patterns for inner joins

In the abstract example cited earlier, we have predicate readings R1, R2, R3 all in the same direction as the role path. The joins may then be specified using “that”. The underlying role path which forms the context for the role projection may then be verbalized as: A R1 some B that R2 some C that R5 some B. The external uniqueness constraint may then be verbalized as shown below. Front text may be accommodated in the usual way, and if an object type plays additional roles on the join path, add subscripts to distinguish its occurrences. Join Path Context: A R1 some B that R2 some C that R5 some B. In this context, each A, C combination is unique.

Figure 7 shows a model based on an example from [15] in which the external uniqueness constraint used to provide the preferred identifier for City applies to roles projected from a multijoin path. In this case we do not have a linear sequence of predicate readings for the whole path (we would have if we added the reading AreaCode is of City). The join on City is specified using “and” since we have readings from its join roles. The joins on State and Country are specified using “that” since we have continuous readings over that path. This uniqueness constraint may be verbalized thus: Join Path Context: City has AreaCode and is in State that is in Country that has RegionCode. In this context, each AreaCode, RegionCode combination is unique. has

has City Name

StateName

is in City

State is in

has

AreaCode

Country (name) has

has *

RegionCode

* City has RegionCode iff City is in some State that is in some Country that has RegionCode.

Fig. 7. A complex example of constraints over join paths

Predicate Reference and Navigation in ORM

731

The additional information regarding preferred identifier is verbalized as for ordinary cases, as shown below. The three other external uniqueness constraints in the example may be verbalized in the usual way [15]. The unique AreaCode, RegionCode combination provides the preferred identifier for City.

If we replace the reading “City is in State” by the inverse reading “State includes City” as in Figure 8(a). The join path may now be declared starting with State, since it begins two continuous paths. Thus: State includes City that has AreaCode and is in Country that has RegionCode. (a)

(b) City

Country (name)

State includes

is in

has

City

State includes

is in

has

Country (name) has

is of AreaCode

RegionCode

AreaCode

RegionCode

Fig. 8. Join path verbalization depends on predicate direction

But if we also reverse the AreaCode fact type reading, as in Figure 8(b), the City join cannot be verbalized using the two patterns given earlier, since City neither starts nor continues its join predicate readings. To cater for such cases where the join predicate readings end at the entry and exit roles (i.e. both predicates are directed towards the join object type), we introduce the third verbalization pattern shown in Figure 9. If A plays additional roles in the path, add subscripts to distinguish its occurrences. entry role

exit role A

R1

R2 … R1 … A and … R2 … that A

Fig. 9. A third pattern for verbalizing inner joins

Using this third pattern, the join path in Figure 8(b) above may be verbalized as: State includes City and is in Country that has RegionCode and AreaCode is of that City.

or as: AreaCode includes City and State includes that City and is in Country that has RegionCode.

Heuristics may be added to provide a deterministic choice of the verbalization. Note that the second verbalization above relies on a minimum backward scope rule for grammatical predicates to ensure that the subject of “is in Country” is State rather

732

T. Halpin

than AreaCode. If desired, parentheses could be added to explicate the expression for those unfamiliar with this scoping rule, e.g. AreaCode includes City and (State includes that City and is in Country that has RegionCode).

Note that the three patterns discussed cover all possible cases for an inner join over two roles: (a) one predicate enters the join and one leaves; (b) both predicates start at the join; (c) both predicates end at the join. We conclude this section by applying the patterns to verbalize a join subset constraint. In general, a subset constraint is directed from one sequence of roles (the source role sequence) to another compatible sequence of roles (the target role sequence). For a join to be involved in the subset constraint, each role sequence must include at least two roles, and at least one of these role sequences must involve at least one join. We consider the common case, where each constrained role sequence is a role pair played by the same object type pair and projected from the ends of a role path of binary predicates with continuous predicate readings in the same direction. The pattern is shown in Figure 10. The source role pair comprises the roles at the ends of the predicate sequence S1 .. Sm (m ≥ 1), and the target role pair comprises the roles at the ends of the predicate sequence R1 .. Rn (n ≥ 1). The object types are not necessarily distinct. If A or B are identical to each other or to some of the C or D types, distinguish their occurrences by subscripts. If front text exists, insert it before the relevant “some” occurrences and after the relevant “that” occurrences (the latter placement is not ideal but will typically suffice; fortunately front text is likely to be rare for this case). If the constraint is deontic, prepend “It is obligatory that”. R1

R2

Rn ...

C1 A

B

-ve: None provided

...

D1 S1

S2

+ve: If some A R1 some C1 that R2 some … that Rn some B then that A S1 some D1 that S2 some … that Sm that B.

Sm

Fig. 10. A pattern for verbalizing a join subset constraint

Applying this pattern to the simple join subset constraint shown in Figure 11 leads to the following verbalization. Person (.nr) has

is of {‘M’, ‘F’} Gender (.code)

PersonTitle is restricted to

Fig. 11. Example of a join subset constraint

Predicate Reference and Navigation in ORM

733

If some Person has some PersonTitle that is restricted to some Gender then that Person is of that Gender.

5 Conclusion This paper discussed three issues concerning predicate reference and navigation. Although the context for the discussion focused on ORM as supported by NORMA, the issues are relevant to other information modeling approaches. Different options for formalizing and distinguishing predicates were considered. The expanded predicate name option has been implemented as a NORMA extension for generating typed datalog [26]. Empirical research is needed to determine just how useful it would be for modelers to have tool support to indicate when short predicate names are being used with the same underlying semantics. Two different perspectives for role names were distinguished, depending on fact type arity, and a technique using role names on derived binaries was proposed to enable attribute-style rules to cater for n-ary fact types. This technique seems attractive because it does not require any additional ORM constructs to be introduced. A comprehensive specification was provided for automatically verbalizing role paths involving inner joins, together with an example to illustrate use of the patterns for verbalizing join constraints. This specification is part of a much larger specification that has been completed for automated verbalization of all role paths and join constraints (join subset, join exclusion, join equality, join uniqueness etc.). It is anticipated that this will be implemented in the NORMA tool before the end of 2009.

References 1. Bakema, G., Zwart, J., van der Lek, H.: Fully Communication Oriented Information Modelling. Ten Hagen Stam (2000) 2. Berners-Lee, T., Hendler, J., Lassila, O.: The Semantic Web. Scientific American (May 2001) 3. Bloesch, A., Halpin, T.: Conceptual queries using ConQuer-II. In: Embley, D.W. (ed.) ER 1997. LNCS, vol. 1331, pp. 113–126. Springer, Heidelberg (1997) 4. Bollen, P.: SBVR: A fact-oriented OMG standard. In: Meersman, R., Tari, Z., Herrero, P. (eds.) OTM-WS 2008. LNCS, vol. 5333, pp. 718–727. Springer, Heidelberg (2008) 5. Chen, P.P.: The entity-relationship model—towards a unified view of data. ACM Transactions on Database Systems 1(1), 9–36 (1976) 6. Curland, M., Halpin, T.: ‘Model Driven Development with NORMA. In: Proc. 40th Int. Conf. on System Sciences (HICSS-40). IEEE Computer Society, Los Alamitos (2007) 7. Halpin, T.: A Logical Analysis of Information Systems: static aspects of the data-oriented perspective, doctoral dissertation, University of Queensland (1989), Online as an 18 MB file at http://www.orm.net/Halpin_PhDthesis.pdf 8. Halpin, T.: Constraints on Conceptual Join Paths. In: Krogstie, J., Halpin, T., Siau, K. (eds.) Information Modeling Methods and Methodologies, pp. 258–277. Idea Publishing Group, Hershey (2005) 9. Halpin, T.: ORM 2. In: Meersman, R., Tari, Z., Herrero, P. (eds.) OTM-WS 2005. LNCS, vol. 3762, pp. 676–687. Springer, Heidelberg (2005)

734

T. Halpin

10. Halpin, T.: ORM/NIAM Object-Role Modeling. In: Bernus, P., Mertins, K., Schmidt, G. (eds.) Handbook on Information Systems Architectures, 2nd edn., pp. 81–103. Springer, Heidelberg (2006) 11. Halpin, T.: Modality of Business Rules. In: Siau, K. (ed.) Research Issues in Systems Analysis and Design, Databases and Software Development, pp. 206–226. IGI Publishing, Hershey (2007) 12. Halpin, T.: Fact-Oriented Modeling: Past, Present and Future. In: Krogstie, J., Opdahl, A., Brinkkemper, S. (eds.) Conceptual Modelling in Information Systems Engineering, pp. 19–38. Springer, Berlin (2007) 13. Halpin, T.: A Comparison of Data Modeling in UML and ORM. In: Khosrow-Pour, M. (ed.) Encyclopedia of Information Science and Technology, 2nd edn., Information Science Reference, Hershey PA, US, vol. II, pp. 613–618 (2008) 14. Halpin, T., Curland, M.: Automated Verbalization for ORM 2. In: Meersman, R., Tari, Z., Herrero, P. (eds.) OTM 2006 Workshops. LNCS, vol. 4278, pp. 1181–1190. Springer, Heidelberg (2006) 15. Halpin, T., Morgan, T.: Information Modeling and Relational Databases, 2nd edn. Morgan Kaufmann, San Francisco (2008) 16. ter Hofstede, A., Proper, H., van der Weide, T.: Formal definition of a conceptual language for the description and manipulation of information models. Information Systems 18(7), 489–523 (1993) 17. Hoppenbrouwers, S.J.B.A., Proper, H.A(E.), van der Weide, T.P.: Fact Calculus: Using ORM and Lisa-D to Reason about Domains. In: Meersman, R., Tari, Z., Herrero, P. (eds.) OTM-WS 2005. LNCS, vol. 3762, pp. 720–729. Springer, Heidelberg (2005) 18. Meersman, R.: The RIDL Conceptual Language, Int. Centre for Information Analysis Services, Control Data Belgium, Brussels (1982) 19. Nijssen, M., Lemmens, I.M.C.: Verbalization for Business rules and Two Flavors of Verbalization for Fact Examples. In: Meersman, R., Tari, Z., Herrero, P. (eds.) OTM-WS 2008. LNCS, vol. 5333, pp. 760–769. Springer, Heidelberg (2008) 20. Object Management Group, UML 2.0 Superstructure Specificatio (2003), http://www.omg.org/uml 21. Object Management Group, UML OCL 2.0 Specification (2005), http://www.omg.org/docs/ptc/05-06-06.pdf 22. Object Management Group, Semantics of Business Vocabulary and Business Rules, SBVR (2008), http://www.omg.org/spec/SBVR/1.0/ 23. Warmer, J., Kleppe, A.: The Object Constraint Language, 2nd edn. Addison-Wesley, Reading (2003) 24. Wintraecken, J.: The NIAM Information Analysis Method: Theory and Practice. Kluwer, Deventer (1990) 25. World Wide Web Consortium, OWL 2 Web Ontology Language, W3C Working Draft (2009), http://www.w3.org/TR/2009/WD-owl2-overview-20090611/ 26. Zook, D., Pasalic, E., Sarna-Starosta, B.: Typed Datalog. In: Gill, A., Swift, T. (eds.) PADL 2009. LNCS, vol. 5418, pp. 168–182. Springer, Heidelberg (2009)

Positionalism of Relations and Its Consequences for Fact-Oriented Modelling C. Maria Keet Faculty of Computer Science, Free University of Bozen-Bolzano, Italy [email protected]

Abstract. Natural language-based conceptual modelling as well as the use of diagrams have been essential components of fact-oriented modelling from its inception. However, transforming natural language to its corresponding object-role modelling diagram, and vv., is not trivial. This is due to the more fundamental problem of the different underlying ontological commitments concerning positionalism of the fact types. The natural language-based approach adheres to the standard view whereas the diagram-based approach has a positionalist commitment, which is, from an ontological perspective, incompatible with the former. This hinders seamless transition between the two approaches and affects interoperability with other conceptual modelling languages. One can adopt either the limited standard view or the positionalist commitment with fact types that may not be easily verbalisable but which facilitates data integration and reusability of conceptual models with ontological foundations.

1

Introduction

Different methodologies and practices to design a fact-oriented or object-role model exist, which commence with a natural language sentence, sample data, or with icons at the type-level in the diagrammatic language. A common aspect of them is the ‘one fact(type) at a time’ approach, which follows naturally from the pseudo-natural language starting point, but it is a conscious choice in the diagrammatic interface because with the latter one also could start with drawing several objects and relate them one by one or draw n-ary relationships and then link object types to roles of the relationships. Unlike the (pseudo-)natural language approach, the diagrammatic interface does emphasise the existence and explicit use of roles as components of the relationships. For instance, a fact such as John loves Mary does not deal with roles, such as the Lover role that John plays and the Beloved role that Mary plays. Does this constitute a fundamental, ontological, difference or is it a byproduct of the different interfaces available in the modelling tools and a modeller’s habits and personal preferences? And what if it does constitute a difference? Should a modeller care at all? In this paper we investigate this problem by availing of recent results from philosophy, and the notion of positionalism of relations in particular, with which we isolate and analyse the different ontological commitments underlying the natural language and diagram-based approaches of fact-oriented modelling (FOM). R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 735–744, 2009. c Springer-Verlag Berlin Heidelberg 2009 

736

C. Maria Keet

It is precisely due to the different ontological commitments that there are different formal characterisations for the ‘basic elements’ of the language. In addition, the different parallel commitments affect approaches and practices to conceptual data modelling methodologies, the possibilities for extensions, such as stereotyping relationships, and has consequences for other usage of FOM models, such as data integration, which can be better addressed with the role-based, positionalist, approach than the natural langauge approach. The remainder of the paper is structured as follows. Section 2 presents a synthesis of the ontological aspects of relations, which we apply to FOM and analyse its practical consequences in section 3. We conclude in section 4.

2

Positionalism

The ontological status of relations receives much attention in philosophy recently. Early ideas were put forward by Williamson [1] and have been elaborated on and structured in [2,3,4,5]. Here we synthesise the main arguments that will be directly relevant for assessing ORM and adjust terminology and the narrative to conceptual data modelling. We introduce the three different ontological commitments about relations and relationships, which are, in Fine’s [2] terminology, the standard view, the positionalist, and the anti-positionalist commitment. This forms the theoretical basis for analysing the consequences for ORM in the next section. Let us start with the standard view, which relies on linguistics and the English language in particular. With the fact John loves Mary, one could be led to assume that loves is the name of the relation and John and M ary are the objects participating in the relation. Switching the objects, Mary loves John, is clearly a different thing and it is not guaranteed to have the same truth value as the former fact; changing the verb from active to passive voice does, i.e., Mary is loved by John. In the standard view, we seem to have two relations, loves and its inverse is loved by. This faces several problems. First, generally, for names a and b, a loves b holds iff what a denotes (in the reality we aim to represent) loves what b denotes. Names normally denote non-linguistic items, because normally the truth conditions of sentences involving names are not sensitive to the existence of linguistic items: John loves Mary is not about language but about John loving Mary, so John and Mary are non-linguistic. Compare this to the fact ‘cabeza’ translates into ‘head’, which is about the language. [1]. Then, that John loves Mary and Mary is being loved by John refer to only one state of affairs between John and Mary—so why should we want, let alone feel the need, to have two relations to describe it? A first step toward resolving this, is to designate the two aforementioned facts to be relational expressions and not to let the verb used in the fact automatically also denote the name of the relation, so that we can have many relational expressions standing in for the single relation that captures the state of affairs between John and Mary. In analogy, we can have many relational expressions for one relationship at the type level. A second issue is that the relational expression comes in a specific order where changing the order does not mean the same when we consider verbs

Positionalism of Relations and Its Consequences for Fact-Oriented Modelling

737

that indicate an asymmetric relation (asymmetry of a relationship R being ∀x(R(x, y) → ¬R(y, x))), such as loves as relation for the verb loves. Availing of another language illustrates this better. Consider John kills the dragon. In Latin, we can convey the same with Johannus anguigenam caedit and with anguigenam caedit Johannus that both refer to the same state of affairs, but Johannum anguigena caedit (the dragon kills John) is a different story alltogether. With Latin and other languages such as German and Irish, we implicitly have a linguistic version of argument places thanks to the explicit use of the nominative and the accusative that are linguistically clearly indicated with -us and -am, and therefore the order of the words matters little (in fact, the order of the argument places is not relevant for the relation itself). English, on the other hand, does not have such declensions that change the terms as a means to disambiguate the meaning of a relational expression, so when we change the word order of a fact truthful to its meaning, then either the verb has to be modified or another verb has to be used. But could we have that in reality and descriptions of reality in English language inverses for seemingly asymmetrical relations necessarily exist, but not in other languages even when they represent the same state of affairs? There are relational expressions that are certainly asymmetric, but this does not imply that the relation and fact(type) it verbalises is asymmetric. Nothing prevents us from using a binary relation killing and to identify the argument places as killer and deceased—i.e, two “argument positions” [2] to have “distinguishability of the slots” [5], or, loosely, a place for the nominative and a place for the accusative—, assign John to killer and the dragon to deceased and order the three elements in any arrangement we like. More generally, we then have as ingredients (i) an n-ary relationship R with A1 , . . . , Am participating object types (m ≤ n), (ii) n argument places π1 , . . . , πn , and (iii) n assignments α1 , . . . , αn that link each object o1 , . . . , on (each object instantiating an Ai ) to an argument place (α  → π × o). Given a, for instance, ternary relationship at the intensional level, R, argument places π1 , π2 , and π3 of that relationship, and instances r ∈ R, o1 ∈ A1 , o2 ∈ A2 , and o3 ∈ A3 , then any of ∀x, y, z(R(x, y, z) → A1 (x)∧A2 (y)∧A3 (z))—in shorthand R(A1 , A2 , A3 )—and its permutations R(A2 , A1 , A3 ) and A2 A3 RA1 where each one has its corresponding argument places—i.e., R[π1 , π2 , π3 ], R[π2 , π1 , π3 ], and [π2 π3 ]R[π1 ]—they all denote the same state of affairs under the same assignment o1 to π1 , o2 to π2 , and o3 to π3 for the extension of the relation. Thus, r(o1 , o2 , o3 ), r(o2 , o1 , o3 ), and o2 o3 ro1 are different representations of the same state of affairs where objects o1 , o2 , and o3 are related to each other by means of relation r. One can visualise this positionalist ontological commitment as shown in Fig. 1-A. We simply have a relation(ship) and several distinguishable ‘holes’ and we put each object in its suitable hole. It may well be the case that not all of the permutations have a nicely readable relational expression in English, but that does not invalidate the permutation and/or even the whole relation. The positionalist commitment solves the standard view’s problems with seemingly asymmetrical relations because there is just one relation for a state of affairs, not two or more as the standard view suggests. According to [1,2,5], there

738

C. Maria Keet

are no asymmetrical relations, because a relationship R and its inverse R− , or their instances, say, r and r , are identical, i.e., the same thing. However, also the positionalist commitment may not be perceived to be ideal. From an ontological viewpoint, the positionalist solution to the ontological nature of relations requires identifiable argument positions to be part of the fundamental furniture of the universe. Practically, it requires something to finger-point to, i.e, to reify the argument places, and use it in the signature of the formal language, which is not as clean and simple as without such elements. In addition, there is a problem with symmetric relations and relationships, such as adjacent to: when we have the two argument positions, πa and πb , of a symmetric binary relation r and assign o1 to position πa and o2 to πb in state s, we can do a reverse assignment of o1 to position πb and o2 to πa in state s , but then o1 and o2 do not occupy the same positions as they did in s, so s and s must be different, which should not be the case. The solution proposed by Fine [2] is the anti-positionalist ontological commitment. There are no argument positions, but just a relation and objects that somehow yield states by “combining” into “a single complex”, like a magnet attracts iron things or pins one sticks into a pincushion; this is depicted in Fig. 1-B. This approach eliminates the need for admitting existence of argument positions—hence, avoids the argument position assignment step that is problematic for the positionalist’s symmetric relation. Verbalising such a relation is, ontologically, of no concern; put differently: one can use as many phrases as one sees fit in as many natural languages as desired, or none.

Fig. 1. A: Graphical depiction of the postionalist ontological commitment with relationship R as ellipse and its three argument places as ‘holes’ with shapes square, star, and roundtangle; B: Graphical depiction of the anti-postionalist commitment with a binary relation as shaded pincushion and two participating objects as pins stuck into the cushion in arbitrary places yielding a state

3

Assessing Fact-Oriented Modelling

With the principal aspects of positionalism in place, we can commence examining conceptual modelling and its languages, and FOM in particular. Before doing so, it is worthwhile to recollect that ORM and ORM2 are, roughly, more expressive than UML Class diagrams and EER. Considering their respective ontological commitment, a UML Class diagram with “association ends” [6] has a positionalist commitment and the EER diagram notation adheres to an anti-positionalist commitment. ORM, LISA-D, NIAM, FCO-IM, and FOM superficially refer to

Positionalism of Relations and Its Consequences for Fact-Oriented Modelling

739

the same kind of thing. However, some use facts and fact types as the basic unit of information whereas object-role modelling uses as basic elements object(types) and roles, i.e., is more fine-grained. NIAM and FCO-IM have their basis in analysis of natural language text and expect those facts and fact types to be expressed as relational expressions; hence, we arrive at the standard view for the natural language-based FOM. Compare this with the diagrammatic objectsand-roles approach, where we have a positionalist commitment for ORM and LISA-D diagrams. To illustrate this and the theory of the previous section, let us consider a practical example in NORMA. The positionalist ternary relationship of Fig. 1-A can be drawn in NORMA as shown in Fig. 2-A, where we have named the ORM roles corresponding to the shapes of the argument places. But how do we name the ternary relationship? As a first step, we could try to make a sentence out of it, e.g., ... located between ... and ... (shown in Fig. 2-B), so that whatever is assigned to the roles [square], [star], and [roundtangle] fills the ellipses, in that order. Two sample fact types are included in Fig. 2-C, so that we now have the relational expression at the type level Sea located between Island and Mainland and another rendering with the roles in a different order in the relational expression Island is separated from Mainland by Sea; i.e., in both cases, an object o ∈ Sea will be assigned to the role [square], an o ∈ Island to the role [star], and o ∈ M ainland to [roundtangle]. While the fact types look different and are verbalised differently, they represent the same state on how the UK, the North Sea and ContinentalEurope relate to each other, and likewise for Jamaica, the Caribbean Sea, and South America. From an RDBMS viewpoint, if we have this data in a GIS database, then the order of the columns—how the data is stored—likely will be different for the two different fact types, but they will produce the same maps because swapping the columns does not change the meaning of the relation that is stored as a table in the database. Generalising this relationship, we have a straightforward topological relation, “betweenness”, with three participating roles, being a [separator], a [player1], and another [player2], and we might as well use a verbalisation “[separator] separates [player1] from [player2]”. If we would have used the relational expression in each sample fact type to name the relationship, i.e., using the standard view ontological commitment, we would have generated four relationships, whereas there really is just one. In principle, with the diagram-based positionalist approach, one can rearrange the roles of the single relationship (here: betweenness) and add as many readings as one likes. This is not possible with a verbalisation-only approach and interface. Moreover, that easily can generate duplicate fact types in larger conceptual data models1 . We analyse this in more detail in the next two sections, with an emphasis on FOM’s formal foundations, modelling methodologies, and consequences in ‘peripheral’ tools and usage.

1

To mitigate this problem, one could add a script in a CASE tool that checks if there is already a fact type with exactly the same participating object types and to warn the modeller that the new fact type might be represented in the model already.

740

C. Maria Keet

Fig. 2. Positionalist examples in ORM. A: an ORM diagram rendering of Fig. 1-A; B: a reading added and a possible generalization of it; C: sample fact types and populations.

3.1

FOM’s Basic Elements

The different commitments can be observed in the formalizations of FOM. The first formalisation of ORM/NIAM by Halpin [7] does not include a specific kind of element for the roles: the diagrams do have roles, but the formalisation uses relationships only. That is, without loss of generality, a binary fact type is formalised with one axiom“∀xy(xRy → Ax&By)”. Halpin notes that “[w]e regard our ordered predicate notation and the unordered role notation as different only in their focus... In both approaches we see a linguistic structure in which objects play various roles with respect to the verb or relationship” ([7] p4-3), which, in the light of recent developments in Ontology, is not merely a different focus, but they reflect different ontological commitments. Ter Hofstede and coauthors introduce a reification with predicators in PSM by introducing a finite set P of predicators in its signature, which are roles in ORM and are called connectors in LISA-D [8]. In a follow-up paper [9], the authors still reify the argument places and put in the signature of the language a finite set R of roles, a function Roles : F  → R+ that “provide[s] a partition of roles over the relationship types”, relationship types, and several auxiliary functions. They make explicit a distinction between the surface reading and the “deep semantics” that is formalised by taking an unambiguous positionalist stance. This commitment is also taken by [10], given that all and only those languages in the DLR family of Description Logic languages are positionalist thanks to the explicit “DL role elements” that correspond to ORM roles. That is, as one of the concept constructors in the DLRifd language we have [$i]R where i denotes a component of the relationship R; e.g., a typed relation loving between two classes C and D is represented as loving  [lover]C  [beloved]D. Note that if one were to use, say, OWL-DL as a formal foundation for ORM, then one does not have an equivalent for ORM roles. Jarrar and Meersman [11] use “lexons” in their ORM-as-ontology-language where “[a] lexon is a binary relationship between context-specific linguistic terms, or in other words, a lexical rendering of a binary conceptual relation.”, denoted

Positionalism of Relations and Its Consequences for Fact-Oriented Modelling

741

with < γ : T1 , r, r , T2 >, and have it that “r and r are lexicalizations of the pair roles of a binary conceptual relationship R; the role r is the inverse of the role r”. The first order logic axiomatization, however, does not comprise relationships at all, but only roles, and equivalence of the two participating roles is asserted in a way such that the roles are treated as binary relations (“∀x.y r(x, y) ↔ r (y, x)”). This duality of roles being treated as relationships at the same time does not aid disambiguation of what the ontological nature of relations and argument places are, although the overall direction in [11] is based on the standard view. Considering an implementation that has interfaces for both the verbalisation and the diagrams, the ORM CASE tool NORMA [12], then one can observe in the XML serialization of ORM diagrams with their mandatory verbalisations that behind that dashboard, it uses roles explicitly. The XML schema has elements such as where each fact type has one or more and one or more and corresponding . Thus, from a formal language perspective, it has the positionalist’s flexibility (although the naming of the relationship is based on the verbalisation of the fact type). Thus, in the light of positionalism and the different commitments taken with FOM approaches, it is not surprising that there is no unanimous agreement on what the basic elements of ‘the’ FOM language are. From a logic perspective, there has been a tendency to move toward the positionalist commitment by giving argument places a proper place in the formalisation. 3.2

Conceptual Analysis Methodologies

Aside from the formal semantics of the languages, the modeller’s and domain expert’s experience and perception that, or if, one can express in a language what one deems necessary for the application domain, is ultimately most important for success of usage of FOM. That some people may prefer pseudo-natural language sentences over diagrams, or vice versa, may have to do with the skills and talents of the person, the to-be-modelled informal source material, or with an unstated ontological commitment. There is a long-standing debate about representing reality versus modelling our understanding of it in natural language. With the standard view, none of the former can go in a conceptual model until one can use its terms in a relational expression. Then, in a conceptual analysis methodology based on the standard view only, in principle, the conceptual analysis stage halts until further notice. To the positionalist or anti-positionalist, this would merely mean adding the relationship but just not giving it a specific reading (relational expression) and continue with the conceptual analysis; if, or when, a verbalisation is found and agreed upon, it simply can be added. This same approach can be used in the positionalist setting when some of the domain experts want to argue about the ‘best’ terms for the relational expression: one either lets them discuss and the modeller can continue in the meantime, or the modeller lets them each have their preferred verbalisation linked to one and the same relationship. In addition, a consequence of the positionalist FOM diagram is that one should not use the asymmetric ring constraint, because a relationship is never asymmetric even though its natural language readings and the standard

742

C. Maria Keet

view commitment may give that (false) impression. And, if one were to be an ontological purist, one cannot represent symmetric relations in FOM diagrams, which is only faithfully represented with an anti-positionalist commitment. A separate topic, which receives comparatively little attention in FOM, is that of reuse of (parts of) conceptual data models. In this context, we mean both the reuse of fragments across conceptual data models and the reuse of relationships within one conceptual model. The latter has its counterpart in UML class diagrams as stereotyped associations, whereas within FOM the reuse of different types of part-whole relationships has been proposed [13]. Forcing this into the standard view means imposing the use of precisely those names for the verbalisation, but this could create artificial debates: when a domain expert insists that something must be made of something else and does not like constituted of, there really is no debate about the meaning of the relation but only about the terms used. Using the positionalist commitment, there is no such problem and, moreover, simplifies use and reuse of ontologically well-founded relationships in conceptual models, which, in turn, improve the quality of conceptual data models. Concerning reuse of fragments across conceptual models, there are currently no easy to use ways in extant FOM CASE tools to deal with conceptual model design patterns, e.g., a company pattern that has several fact types about companies (that have a name, address, status, and so forth). With a methodology based entirely on the standard view, the chances are less that there are actually any design patterns due to the plethora of possible verbalisations that are used for the names of the relationships. The chances are obviously better with the positionalist and anti-positionalist commitments, where such reused fragments can be dressed up with preferred fact type readings afterward anyway. Taking this beyond design patterns and specific relationships, the prospects will be better also for conceptual model-based data integration, including the linking of FOM diagrams with ontologies, because the real relationships will be analysed by the modellers and domain experts during the modelling stage, and not later on attempted to be reconstructed by, often, other people who reuse legacy material. If one adheres strictly to the two commitments, then FOM tools that support both text-based and diagram-based approaches are ontologically incompatible. Obviously, one can add fact type readings in the diagram to limit the possible orderings of the roles in the relationship, and to somehow force the positionalist stance with the diagram into the straightjacket of the standard view. Or demand as many readings as the domain expert can think of in the standard view-based textual interface, or to add a template sentence to be filled-in, such as “the role played by X is called ...” to introduce some notion of the positionalist stance. However, no matter which one is added to the tool, we are hopping on two legs in the overall framework of FOM. One can represent more, and more precisely, the universe of discourse when one takes the positionalist view compared to the standard view. Put differently: the standard view puts constraints on the use of the positionalist way of dealing with relations and forces the order of the roles into those sequence(s) that can be verbalised even though other permutations are logically and ontologically valid. On the other hand, the positionalist comes

Positionalism of Relations and Its Consequences for Fact-Oriented Modelling

743

with extra representational baggage in the formalization compared to a formalisation only for the standard view, but the formalisation is hidden to the modeller and can be dealt with easily computationally anyway. Moreover, a positionalist representation of the universe of discourse can deal fully with the standard view, but not vice versa. In the same line of thinking, one could argue to also leave behind the positionalist commitment and go for the anti-positionalist one, but the positionalist one has distinct advantages in the representation of role-constraints such as role exclusion, role subset, and multi-role frequencies. For the latter argument, however, it is important to appreciate the difference between what is, according to philosophers, the ontological nature of a relation versus what is a more convenient way of representing relationships and their constraints in a modelling language and the subsequent engineering use of role names to generate software code or a physical database schema. 3.3

Consequences on Other Usage of Conceptual Models

FOM is not necessarily used in isolation. Transformations to other conceptual modelling languages with respect to positionalism is straightforward with the positionalist object-role modelling and UML class diagrams, but results in a subset of possible EER diagrams. If one were to take the standard view for FOM, then transformations result in a subset of possible conceptual models for both UML and EER. When representing an EER diagram in ORM, an issue may arise in ORM to actually verbalise the relation, because putting the relation in a nearnatural language sentence is neither part of EER’s modelling methodology nor of its modelling tools. Enforcing a standard view representation nevertheless might mean either splitting the relation so that the new fact types are verbalizable (be that conceptually justifiable or not) or not representing it at all. A similar problem arises with reverse engineering a physical database schema. A more challenging problem is realizing the idea of going from natural language texts, such as public administration documents, to an ORM diagram. There can be many relational expressions for a single relation or relationship, therefore, in principle, one will not have a 1:1 correspondence between the text and the conceptual model. At best, text mining a natural language document yields a set of verbs that are candidates for relations and relationships. Further, both the positionalist and anti-positionalist commitments make dealing with multilingual documents and conceptual models easier, because these approaches also take the position that there is a difference between the linguistic relational expression and the relation itself, alike [8,9,10] make a clear distinction between “surface semantics” versus “deep semantics” and in ([14] p36) between “fact type expression” and “elementary fact type”. That is, there is one natural language-indepentent relationship and many verbalisations in many natural languages. This does not solve multilingual template-based verbalisations of ORM diagrams fully [15], but reduces the problem by enabling to identify better the natural language-independent, reusable, information versus the (near-)natural language sentences the different stakeholders may prefer.

744

4

C. Maria Keet

Conclusions

The underlying ontological commitments concerning the positionalism of relation(ship)s in FOM differ, being the standard view and positionalist commitments. While the verbalisations are certainly of the former type and the diagrammatic interface of the latter, this is not always consistently used as such for extant formalisations of and tools for FOM. Such incompatibilities affect transparency, hamper transition between the two approaches, and influence the modelling methodologies, and model use and reuse. Arguments for and against the two commitments have been discussed, which then leave the options either to adopt the limited standard view only and remove the flexibility of arbitrary role positions in FOM diagrams, or to accept fact types that may not be verbalisable. The latter has the advantages that it facilitates data integration, conceptual model interoperability, reusability of FOM models, and model quality enhancements through use of ontologically-well founded relationships.

References 1. 2. 3. 4. 5. 6. 7. 8.

9.

10.

11.

12. 13.

14. 15.

Williamson, T.: Converse relations. Philosophical Review 94(2), 249–262 (1985) Fine, K.: Neutral relations. Philosophical Review 109(1), 1–33 (2000) van Inwagen, P.: Names for relations. Philosophical perspectives 20(1), 453–477 (2006) Leo, J.: Modeling relations. Journal of Philosophical Logic 37, 353–385 (2008) Cross, C.B.: Armstrong and the problem of converse relations. Erkenntnis 56, 215– 227 (2002) Object Management Group: Superstructure specification. Standard 2.1.2, Object Management Group (2007), http://www.omg.org/spec/UML/2.1.2/ Halpin, T.: A logical analysis of information systems: static aspects of the dataoriented perspective. PhD thesis, University of Queensland, Australia (1989) ter Hofstede, A., Proper, H., van der Weide, T.: Formal definition of a conceptual language for the description and manipulation of information models. Information Systems 18(7), 489–523 (1993) ter Hofstede, A.H.M., Proper, H.A.: How to formalize it? formalization principles for information systems development methods. Information and Software Technology 40(10), 519–540 (1998) Keet, C.M.: Mapping the Object-Role Modeling language ORM2 into Description Logic language DLRif d . KRDB Research Centre Technical Report KRDB07-2, Free University of Bozen-Bolzano, Italy (2007) arXiv:cs.LO/0702089v1 Jarrar, M., Meersman, R.: Ontology Engineering - The DOGMA Approach. In: Dillon, T.S., Chang, E., Meersman, R., Sycara, K. (eds.) Advances in Web Semantics I. LNCS, vol. 4891, pp. 7–34. Springer, Heidelberg (2008) Curland, M., Halpin, T.: Model driven development with NORMA. In: Proc. of HICSS-40, p. 286a. IEEE Computer Society Press, Los Alamitos (2007) Keet, C.M.: Part-whole relations in object-role models. In: Meersman, R., Tari, Z., Herrero, P. (eds.) OTM 2006 Workshops. LNCS, vol. 4278, pp. 1116–1127. Springer, Heidelberg (2006) Bakema, G., Zwart, J.P., van der Lek, H.: Volledig Communicatiegeori¨enteerde Informatiemodellering FCO-IM. Academic Service (2005) Jarrar, M., Keet, C.M., Dongilli, P.: Multilingual verbalization of ORM conceptual models and axiomatized ontologies. Starlab technical report, Vrije Universiteit Brussel, Belgium (2006)

Fact-Orientation Applied to Develop a Flexible Employment Benefits System Maurice Nijssen, Inge Lemmens, and Ralph Mak PNA Group, P.O. Box 408, 6400 AK Heerlen, The Netherlands {maurice.nijssen,inge.lemmens,ralph.mak}@pna-group.nl

Abstract. This paper describes FlexBenefits, a commercial software system designed to support flexible employment benefits, and shows how the use of fact-based modeling aided in the development of this system. Flexible employment conditions are labor conditions which can be traded off against each other. They give employees the opportunity to tailor their working conditions to their personal situation. Flexible employment conditions have to comply with four different levels of legislation presently; governmental laws, collective labor agreements, the company policies and the personnel group policies, each of which change constantly in the course of time. Keywords: Fact Oriented Modeling, Fact Based Modeling, Case Study, Compliance Modeling, Business Rules, Natural Language, NIAM2007, CogNIAM, Doctool, OMG, SBVR, BPMN.

1 Introduction More and more employers offer their employees the possibility to organize their own employment conditions. They represent a trend towards more individual employment agreements, in response to a more demanding and individualized society. Flexible employment conditions are labor conditions which can be traded off against each other. They give employees the opportunity to tailor their working conditions to their personal situation. Flexible employment conditions have a hierarchy of applicable rules; they have to obey governmental laws, collective labor agreements, company policies and personnel group policies, each of which change regularly in the course of time. Therefore, automating flexible employment conditions requires a flexible system. Using fact-based modeling and its associated principles, a successful flexible benefits system called FlexBenefits was developed for ADP Netherlands.

2 Case Study 2.1 About ADP the Netherlands, Project Initiator of FlexBenefits ADP Inc is a New York Stock Exchange (NYSE) listed company with a history of more than 55 years, and in 2008 enjoyed approximately US$ 9 billion in revenues. It R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 745–756, 2009. © Springer-Verlag Berlin Heidelberg 2009

746

M. Nijssen, I. Lemmens, and R. Mak

has 45.000 employees and 545.000 organizations as customer. ADP has a presence in over 130 countries worldwide. The business focus of ADP is to provide payroll, benefits and HR products and services to organizations (employers). ADP has a triple A credit rating and has recently started offering treasury services to its customers. ADP Netherlands (ADP for short) has 550 employees and is a fully owned subsidiary of ADP Inc. ADP is the initiator of the FlexBenefits project. ADP Netherlands has existed for over 40 years, and in 2008 enjoyed approximately €€ 80 million revenues in 2008. ADP has about 8.000 organizations as customer. In 2008, ADP Netherlands handled the payroll services (and associated payroll slips) for approximately 1,2 million employees monthly, who were employees of these 8.000 organizations. PNA Group has a 15 year history of close working relationship with ADP, and is responsible for co-developing cutting-edge products for ADP, aimed at large scale use as explained above. Starting 2004, ADP and PNA have entered into a strategic partnership, thereby explaining the PNA involvement in building and maintaining some of ADP’s mainstream and flagship products. The product mix of ADP to support the fields of payroll, benefits and HR, consists of in-house developed products under the control of ADP, as well as acquired and customized third-party software solutions (based on SAP, for example). Development of the native ADP products occurs for a small part within a European setting (together with other European ADP companies, under auspices of the ADP European head office in Paris). However, the largest share of work occurs in-house, together with development partners, such as PNA. Of the 550 ADP employees in the Netherlands, approximately 100 are involved directly or indirectly with product development. There are approximately 20 business analysts, the rest of the numbers consisting of programmers, testers, documentation makers and project managers. Development occurs within several technical environments such as Delphi, Smalltalk, assembler, Java and .net, resulting in target environments such as mainframe, Windows and internet/browser based. 2.2 The Domain of Employee Benefits: What Does It Entail? First of all, let’s define what Employee Benefits are. Employee benefits are all benefits which an employer offers to its employee (“targets”) in return for certain commodities or assets which are of the employee (“sources”) [6]. Sources can be seen as assets (or potential assets) over which the employee has control. Examples of accumulated and available sources include salary, the amount of labor hours, vacation days and others. Potential assets include the ability to work longer hours/overtime. Targets are offered by the employer and can be seen as benefits which the employee can save for, by exchanging them with sources. Examples of targets include additional vacation days, child care facilities, a company bicycle, free beverages and others.

Fact-Orientation Applied to Develop a Flexible Employment Benefits System

747

2.3 Applicable Law and Compliance Issues There are four levels of applicable legislation involved when determining a flexible benefits exchange model: 1.

2.

3. 4.

governmental laws; these dictate minimum wage levels, minimum amount of holidays per fulltime employment, allowable tax-deductible benefits (such as a company PC, bike etc), tax-free savings possibilities and sabbatical possibilities. collective labor agreements; these usually focus on the calculation methods for hourly wages, overtime and weekend pay compensation, possible combinations of exchange (for example, if one is saving for a company car then they cannot also save for a company bike). company-wide policies; a company can add its own exchange possibilities, as long as these comply with all the previous (higher) levels of legislation personnel group policies; for example, a company may decide that the personnel group “board members” may use their bonus towards a golf set.

Depending on the legislation involved, a personalized arena for exchanging sources against targets is created. 2.4 Rules Applied to the Exchange of Sources and Targets There are prerequisites and restrictions coupled to the use of sources and targets for an individual employee. A prerequisite stipulates that a certain source or target can appear as a usable item in the source / target exchange arena. For example, a prerequisite may state that, to be able to save for the target named “Free beverages for 55+ employees”, an employee needs to be 55 years of age or older. Another example is that to be able to use “Overtime” as a source, an employee must have worked at least 200 hours overtime in the calendar year, otherwise the source cannot be exchanged for a target. So essentially prerequisites determine whether an item can be entered into the exchange arena, otherwise known as the exchange benefits ‘playing field’. A restriction stipulates that an allowed source or target, and the exchange thereof, is bound by certain restrictions (or rules). For example, if one is allowed to save for a company bicycle as a target, then the total amount of money to be saved for that bicycle must be between €€ 500 and €€ 1000. Referring to the example of the source

748

M. Nijssen, I. Lemmens, and R. Mak

“Overtime”, a restriction may also state that overtime hours must be exchanged in certain increments, e.g. “Overtime” may be exchanged in multiples of 8 hours. Sometimes, prerequisites apply across multiple employees / to a personnel group or company. After every employee has indicated a choice, only then can be determined whether the source or target can and will be offered. An example of this is a group restriction coupled to the target “Child care”, which may stipulate that child care will be offered and arranged for by the employer if and only if at least 30 people commit to have at least 1 of their children use this target facility. Apart from these previous intricacies, consider that certain targets span over multiple calendar years. In the Netherlands, it was at one stage possible to have a taxfree company PC if this saving was spread over three years in equal amounts. Adding all this, it becomes obvious that the legally correct administration of all individual employee “playing fields” and associated choices in an efficient and understandable manner, is an absolute necessity to have employers offer employment benefits to its employees in a cost-effective manner. As ADP has thousands of customers, a traditional IT approach with reprogramming due to a change in the “playing field” was not an economical option. 2.5 The Commercial Value of Offering Employee Benefits Why is there a demand for flexible employee benefits by society? The answer is twofold. [6] In times of economic growth, and a shortage of employees, it allows the employer to offer employees an attractive and interesting package of benefits (which can constitute both primary and secondary labor conditions). Hereby, employers can differentiate themselves with regards to other employers in their fight for the favors of the employee. In times of economic decline, it allows employers to either offer employees a. b.

more (perceived) value to the employee at equal employer costs, or equal employee (perceived) value at lower employer costs.

This is largely achieved due to the way that sources are valued and exchanged when traded, namely often at gross (pre-tax) level instead of nett level (post-tax). Other ways that advantages can be gained by the employee occur if the employer decides to promote certain targeted benefits by adding a multiplication factor, if an employee trades certain assets in return. For example, if a production company is operating at full capacity during regular working hours, but has orders requiring 110% capacity, they may offer their employees that for every hour of overtime worked, they gain 1,5 hours towards holidays. The result hereof is that production is ramped up within the existing facilities and the company avoids investment in additional production facilities. The employee gains a better ‘return’ on this overtime because he gets 1,5 times his hours back in holidays, and the employer gains a higher production quota and sales. Both parties benefit. To illustrate the financial/tax aspect involved, lets say an employee has gained the right to a €€ 1000 bonus (source) from his employer. Normally, if this bonus was processed regularly via payroll and taxed at the 52% income tariff (the top income

Fact-Orientation Applied to Develop a Flexible Employment Benefits System

749

tariff in the Netherlands), this would result in a net payout of €€ 480 to the employee. With this money, he could (for example) privately go and buy a €€ 480 bicycle. Assuming a valid and accepted employee benefits system which contains the mentioned sources and targets, the employee could also use the €€ 1000 bonus as a source, and use it towards the “Company bicycle” target. The company would effectively spend the bonus of €€ 1000 on a bicycle on behalf of the employee, and give the bicycle to the employee. The employee thus gains the spoils of a €€ 1000 bike, instead of a €€ 480 bike, yet in both cases the ‘cost’ to the employee is the same €€ 1000 company bonus. Additionally, by working with large numbers, employers usually obtain better prices on targets. For example, the bicycle, which the company paid €€ 1000 for, may normally have a €€ 1100 retail price. So as a result of a flexible benefits arrangement, the effective value for the employee of his €€ 1000 bonus towards a bicycle has increased from €€ 480 in a regular payroll processing and taxing situation, to €€ 1100 in his flexible benefits package. Flexible employee benefits fit into the trend of modern society towards individual arrangements with regards to employee benefits, because it allows each employee to make and record his own choices from within the allowed ‘playing field’ for his personnel group. Apart from the plain desire or usefulness in offering flexible benefits, many collective labor agreements already stipulate that individual employees have a right to participate in a flexible employment benefits system. Because each employee can usually trade one or more sources against one or more targets, whereby the amount of money and/or time traded in each combination can usually be determined by the employee, this already requires quite an extensive administration. Add to this the fact that there are different rules applying to different combinations, as well as the fact that certain combinations executed prohibit others, and you can imagine that an impressive system is needed to efficiently and effectively handle all these rules, which are essentially business rules.

3 Requirements Placed on the Project High demands were placed by ADP on the FlexBenefits product, which was to be developed in-house by PNA, under the control of ADP. To give an impression of the difficulty level of the project (and consequently the analysis and development method to be used for successfully completing this complex project) the main requirements are listed here: 1.

2.

The product would have to be complete and flexible; changes in government or collective labor agreements should not require any re-programming. In this aspect, FlexBenefits had to be completely future-proof. All possible future restrictions and prerequisites, as well as how these could be applied, had to be covered by the product. This implies that FlexBenefits would be a generic product, working in a rule-based fashion. The user interface for entering the company and personnel group policies was to be constructed in such a way, that employers could enter these policies themselves, independent of the IT-department. This implies a domain or target-group specific graphical user interface.

750

M. Nijssen, I. Lemmens, and R. Mak

3.

4.

5.

FlexBenefits would have to be a single product, that would work in combination with several of ADP’s Personnel Information Management (PIM) products. PIMs are an essential part of flexible benefits, because they contain the relevant employee information (such as wages, amount of holidays, overtime worked, birth-date/age) used for exchanging flexible benefits. PIMs are also used, after the exchange of sources and targets, to record the final employee choices. The “single benefits product – multiple PIM bases” requirement implies technical flexibility in exchanging information with other products. When entering policies, it should not be possible to overrule a higher level of legislation. For example, if national law dictates that a fulltime employee must receive at least 20 days of holiday leave, then downstream (e.g. personnel group) policy levels needed to comply with these. This implies that FlexBenefits should have built-in compliance. The employee should be able to have a clear view of the sources and targets available, and the (financial) impact of exchanging one against another. When the employees would be making their choice, illegal choices should be made impossible by the product. Also, it should be clear to the employee which rules are applicable in a given situation, and if a certain action is not possible, what the reason was for this – in a language the employee could understand. This implied understandability, transparency and clarity.

4 The Use of Fact-Based Modeling in the Project 4.1 Introduction to NIAM2007, the Fact Based Modeling Approach Used NIAM2007, which is known in Dutch as “Kenniskunde” [5] is a fact-orientation conceptual modeling method with a strong pedigree in business application. NIAM2007 is a successor of NIAM [8] and the predecessor of CogNIAM. NIAM2007 was the formal internal standard for information analysis at ADP, at the time of the FlexBenefits project. In the second half of 2009, the internal information analysis standard within ADP was upgraded to CogNIAM. The major difference with NIAM2007 is that CogNIAM expands this approach with the integral use of OMG’s BPMN for process modeling aspects and output in OMG’s SBVR [7] structured language, amongst others. These additional features were therefore not utilized in the FlexBenefits project. 4.2 Philosophy of NIAM2007 Applied to the Project and in Communication with the Stakeholders The use of the fact oriented approach using NIAM2007 resulted in the following: A. The use of concept definitions. Within ADP (as in other larger organizations), and to design a successful product that would fulfill the wishes of the stakeholders, it was essential that the internal disciplines (marketing, sales, development, customer service, management) would work together effectively and efficiently. Within NIAM2007, there are extensive procedures on how to

Fact-Orientation Applied to Develop a Flexible Employment Benefits System

B.

C.

D.

E.

751

define concepts and generate a concept tree in order of knowledge acquisition. This means that each new concept is defined using already defined concepts. Although the accurate definition of the concepts took quite some time in the beginning of the project, this was not minded by the stakeholders since they could see that clarity on this point was essential before the project started. For example, it took some time before the basic concept of “client” was clearly defined, because of different opinions between marketing and IT on what it entailed. For IT, each company (be it within a group) had a unique identifier, while to marketing, a group of related companies was ‘one account’. The use of clear, natural language concept definitions greatly aided all stakeholders involved in the project in communicating effectively; misunderstanding and ambiguity was avoided. [1, 2, 3, 4] The use of concrete examples. While many domain experts and other people involved in development projects like to discuss things on a general level, it was the systematic use of concrete examples that caused the requirements to become unambiguous and accurate. By using practical cases described in natural language and posing questions formulated in natural language, interaction between domain experts of collective labor agreements (for example) on the one hand and the business analysts on the other hand, was effective and clarifying. Also, to discover and clarify the applicable rules, concrete examples were drawn up and the domain experts were asked if they were allowed, and if not, why they would not be allowed. This way, an accurate and validated model of the flexible benefits arena was built up. The use of verbalization/sentence patterns for the application screens and the associated graphical representation. By providing verbalizations with every application screen, all stakeholders could follow the information being depicted. In the help file, the concept definitions associated with the variable fields in the screen were explained. Integrated use of the same concrete examples as cases, in all aspects of the development process, such as prototyping screenshots, legislation examples, documentation. For the illustrative examples to be used, several fictional “characters” and their associated employee benefit wishes were created. For example: Jan Smit, 37 years of age, who works 32 hours per week at HollandMetal, which falls under the collective labor agreement for metal working employees. Jan wants to use his flexible benefits possibilities to maximize his leave, and is willing to sacrifice his profit sharing bonus and part of his monthly salary to achieve this. The mapping and consequent use of domain-specific jargon. It is the philosophy of NIAM2007 (already introduced in the seventies [8]) that one should speak the jargon of the ‘client’, so the jargon of the benefits and payroll world was mapped to synonyms to the world which was known by all participants of the project. Extending this towards the graphical arena, it was decided that the application screens (which would allow the client’s payroll expert to enter company or personnel group regulations) would have two forms of native jargon support. On the one hand, a sentence pattern which verbalizes the concrete rule/legislation as it is being created, and on the other hand a graphical representation depicting the

752

M. Nijssen, I. Lemmens, and R. Mak

impact and associated restrictions of the rule/legislation as it is being created. Examples are shown in the next section. F. Reduced (perceived) complexity, by using all the above to structure legislation. Quite often, when reading through the specifications which included concept definitions, sentence patterns, examples and other aspects, comments were made by the domain experts saying that “by doing it this way, you make it seem so easy”. 4.3 The Use of a Central Knowledge Repository for Consistency When developing FlexBenefits, the four phases of software development (information analysis, programming, testing, and documentation) were all addressed and supported from one central knowledge repository, in this case PNA’s Doctool. This repository contained all the NIAM2007/fact orientation ‘artifacts’ which captured the analysis and design of the FlexBenefits application. By the fact orientation artifacts, we mean [2,3] 1. 2. 3. 4. 5. 6.

the structured concept definitions, fact types, sentence patterns (fact type readings), constraints, derivation rules, exchange rules and events.

Additionally, the repository also contained elements which helped support the technical realization of the product. These included source documentation (e.g. relevant legislation, collective labor agreements) and how they were linked to the analysis, concept screen shots which appeared in various functional documents, and automatic generation of database scripts, amongst others.

4.4 Statistics of the Project The main statistics of the FlexBenefits analysis performed and registered in PNA’s Doctool repository are as follows:

Fact-Orientation Applied to Develop a Flexible Employment Benefits System

Fact orientation artifact (NIAM2007) Concept definitions (structure) Fact Type Diagrams Placeholders (roles) Sentence patterns Constraints Derivation rules

753

Amount 1260 125 1410 327 704 20

Due to confidentiality and ownership agreements, the authors are not in a position to disclose the underlying fact-oriented model.

5 Examples of the Finished Product: FlexBenefits 5.1 Figure 1: The Main Screen for the Employee

754

M. Nijssen, I. Lemmens, and R. Mak

Figure 1 shows an individual employee’s personal flexible benefits ‘playing field’, in this case consisting of only one source (Monthly Salary) and six different targets to choose from. By selecting a source and a target, sliders appear. By dragging either the source or target slider, both adjust while the associated benefits are exchanged and instantly valued and calculated. By pressing the blue information button, verbalization of the restriction(s) coupled to the source or target is displayed, as well as a visual (traffic light) indication of whether the restriction is being obeyed. In a transient/intermediate state, it may be that a restriction is not yet being obeyed, resulting in a red traffic light. 5.2 Employer Screen, Adding a Restriction

When adding a restriction (in this example a minimum and maximum constraint, for the source Monthly salary), the domain expert entering the restriction is guided through a wizard, whereby on the left side, the restriction choices and associated

Fact-Orientation Applied to Develop a Flexible Employment Benefits System

755

variables are entered, while on the right side the restriction is depicted both graphically as well as verbalized. The choices to be made for minimum and maximum restriction amounts are: ‘not applicable’, ‘fixed amount’ and ‘to be determined via a Function’. This last option shows the flexibility of FlexBenefits; a function can take any employee data that is stored in the PIM as input, and have it be manipulated via the generic function editor, to achieve a personalized applicable value for the employee in question.

6 Conclusions and Recommendations Fact oriented modeling enables analysts to precisely and understandably model a knowledge or business domain [1]. From a business perspective, many problems are branded as “IT” problems but really boil down to communication problems [2]. Or rather, the problem that the information and knowledge cannot be effectively captured and accurately shared between all stakeholders or the people involved in projects. Traditional IT methods like UML fail to effectively use natural language and the semantics associated with a business domain in a structured and accurate way and fail to reach complete and unambiguous stakeholder comprehension of the analysis. By using fact orientation and applying its associated principles, large productivity and speed of development gains were made in the FlexBenefits project. The use of concrete examples, concept definitions, natural language, and jargon of the business were instrumental in clarifying and specifying the business requirements. This also avoided placing a burden on the stakeholders to learn a foreign “IT” language. By storing the requirements in a central fact oriented repository, different output documents for the different participants were generated, thereby always up to date and consistent. The maintainability of the knowledge stored in the repository is also optimal. By using fact orientation as well as the central repository, it was clear beforehand what the impact of proposed changes would be. The FlexBenefits project was very successful from a business point of view. This can be attributed for a decisive part to the use of fact oriented modeling throughout the project. We therefore recommend the widespread adoption and use of fact orientation in business (and IT) settings, for achieving maximum understanding and maintainability of knowledge domains and their associated software applications.

References 1. Bollen, P.: Fact-Oriented Modeling in the Data-, Process- and Event Perspectives. Meersman, R., Tari, Z., Herrero, P. (eds.) OTM-WS 2007, Part I. LNCS, vol. 4805, 591–602. Springer, Heidelberg (2007) 2. Rozendaal, J.: Industrial Experience with Fact Based Modeling at a Large Bank. Meersman, R., Tari, Z., Herrero, P. (eds.) OTM-WS 2007, Part I. LNCS, vol. 4805, 678–687. Springer, Heidelberg (2007)

In: pp. In: pp.

756

M. Nijssen, I. Lemmens, and R. Mak

3. Vos, J.: Is There Fact Orientation Life Preceding Requirements? In: Meersman, R., Tari, Z., Herrero, P. (eds.) OTM-WS 2007, Part I. LNCS, vol. 4805, pp. 688–698. Springer, Heidelberg (2007) 4. Melli, G., McQuinn, J.: Requirements Specification Using Fact-Oriented Modeling: A Case Study and Generalization. In: Meersman, R., Tari, Z., Herrero, P. (eds.) OTM-WS 2008. LNCS, vol. 5333, pp. 738–749. Springer, Heidelberg (2008) 5. Nijssen, G.: Kenniskunde 1A. PNA Publishing Heerlen (2001) 6. Nijssen, G.: Flexibele Arbeidsvoorwaarden. PNA Publishing Heerlen (2004) 7. Bollen, P.: SBVR: A Fact-Oriented OMG Standard. In: ORM 2008 Workshop. Springer, Heidelberg (2008) 8. Nijssen, G.: A Framework for Discussion in ISO/TC97/SC5/WG3, 1978, 78.09/01, 1-144

Business Semantics Management Supports Government Innovation Information Portal Geert Van Grootel1, Peter Spyns1,2, Stijn Christiaens2,3, and Brigitte Jörg4 1

Vlaamse overheid – Departement Economie, Wetenschap en Innovatie Koning Albert II-laan 35, bus 10, B-1030 Brussel, Belgium [email protected] 2 Vrije Universiteit Brussel – STAR Lab Pleinlaan 2, Gebouw G-10, B-1050 Brussel, Belgium [email protected] 3 Collibra NV/SA Brussel Business Base, Ransbeekstraat 230, B-1120 Brussel, Belgium [email protected] 4 Deutsches Forschungszentrum für Künstliche Intelligenz – Bereich Sprachtechnologie Stuhlsatzenhausweg 3, 66123 Saarbrücken, Germany [email protected]

Abstract. The knowledge economy is one of the cornerstones of our society. Our economic prosperity and development is derived for a large part from technical knowledge. Knowledge unlocks innovation, which in turns spawns new products or services, thereby enabling further economic growth. Hence, an information system unlocking scientific technical knowledge is an important asset for government policy and strategic decisions by industry. In this paper it is explained how business semantics management and related tools are applied to realise the above mentioned endeavour.

1 Background Needing a new system for managing research information, the Flemish department of Economy, Science and Innovation (EWI) launched the Flanders Research Information Space programme (FRIS)1. The term is used to refer both to the virtual environment of research information and the program that is being setup in order to create this research information space. The FRIS concept creates a virtual research information space covering Flemish players in the field of economy, science and innovation (see Fig. 1) – see e.g. [16] for some other use cases of a prototype in a related area. Within the space, research information can be stored and exchanged in a transparent and automated way. The FRIS program is centred on three strategic goals: • accelerate the innovation value chain by efficient and fast access to research information for all relevant stakeholders; • offer improved customer services (e-government); • increase efficiency and effectiveness of the R&D policy. 1

Flanders Research Information Space (FRIS): www.ewi-vlaanderen.be/fris

R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 757–766, 2009. © Springer-Verlag Berlin Heidelberg 2009

758

G. Van Grootel et al.

The strategic goals will be achieved by a combination of service development and a managed change process. A first realisation is the FRIS research portal (www. researchportal.be) to exhibits current research information on projects, researchers and organisations of the Flemish universities.

Fig. 1. The representation of the FRIS with data providers (universities, data centres supporting the Open Archives Initiative2 …), utilities (classifications, …) and services (maintenance of scientific curriculum vitas (CVs), research portal called IWETO, …)

A key feature is that data can be immediately collected at the point of creation in the operational processes of data providers (e.g., universities, funding bodies …). E.g., the first hand information on a research project is already made available during the assessment process of an application for funding. Entering this information is part of the process – at the point of creation – and will be done by the applying organisation itself. The data are up-to-date and are supposedly more accurate (than second hand information entered by non or less related people elsewhere). Also, parallel data gathering processes (e.g., research administrators gathering data at regular intervals, but not related to assessment processes) can be eliminated, resulting in a lot of administrative work being spared.

2 Material CERIF [7] is the standard of choice for the information interchange between the system that will be part of FRIS. CERIF that stands for Common European Research Information Format is a recommendation to EU member states for the storage and 2

Open Archives Intitiative (OAI): http://www.openarchives.org/

Business Semantics Management Supports Government Innovation Information Portal

759

exchange of current research information [8,9,10]. The custodianship of the CERIF standard has been transferred to euroCRIS3, a non for profit organisation that maintains and develops CERIF and promotes the use of it for research information exchange. CERIF is centred on a limited set of basic concepts: • the business objects (entities) of the research and innovation domain: project, person, organisational unit, publication, event,…. – see Fig. 2; • the relations through time that exist between these objects; • support for multilingual text attributes; • a separated semantics storage layer.

 Fig. 2. CERIF entities and their relationships in abstract view, with Core entities (Project, Person, OrgUnit) in the lower centre, Result entities (Publication, Patent, Product) in the upper centre, and 2nd Level entities presented as a contextual environment around the Core and Result entities. The little circles with entities represent their recursive relationships.

In the next phase of the FRIS research portal we will realise the integration of the portal data with the publication repositories of the data suppliers. CERIF as the exchange format and as the basic mode for the database interface allows for searching in and browsing through the data including the formalised semantic links between the database objects. More concretely, this means information about a researcher with his research context: project, organisations, publications can be linked according to the 3

euroCRIS home: http://www.eurocris.org/public/home/

760

G. Van Grootel et al.

formal CERIF semantics, and thus be presented in different ways: simple lists, collaboration graphs, competences maps4, etc.

3 Work in progress 3.1 Why Business Semantics Management? Traditionally CERIF has been modelled using Entity-Relationship (E-R) modelling techniques. While this technique is excellent for modelling activities of database designs, it is less efficient for communication with domain experts. The learning curve for the domain experts to understand the E-R model and translate it back to their conceptual knowledge is quite steep. Probably this difficulty constitutes one of the main reasons why the acceptance of CERIF is only slowly growing. Also domain experts at EWI have been struggling for quite some time with the problem of how to express and explain adequately and flexibly conceptual models underlying the FRIS application to the other stakeholders involved (mainly non technical persons). Domain experts and stakeholders should not be bothered with how to think in a (new) formal language: adequately capturing and organising domain knowledge is a task sufficiently demanding as it is and mainly happens via the use of natural language. Business Semantics Management (BSM) is the set of activities to bring stakeholders together to collaboratively realise the reconciliation of their heterogeneous metadata and consequently the application of the derived business semantics patterns to establish semantic alignment between the underlying data structures [2]. BSM relies heavily on fact oriented modelling, the basis of which has been described in [11] (ORM) and [20] (NIAM), and makes to a large extent use of natural language. ORM focuses more on verbalising the conceptual model for an easy validation process with domain experts, while NIAM puts more emphasis on using natural language as starting point and elicitation vehicle to build the conceptual model. Also, fact oriented modelling is much more flexible and sustainable than attribute-value modelling. BSM recognizes the need for different roles to distribute complexity and improve the work process. Domain experts work on semantic reconciliation and produce semantic patterns, as close to their natural language as possible, while application developers use these patterns as input for semantic application (see Fig. 4 below): to semantically align (or commit) their systems while providing feedback to the domain experts. Collibra’s Information Enabler, a runtime semantics engine, can then apply these semantics by translating from existing legacy systems (e.g. the OAI Protocol for Metadata Harvesting5 ) to CERIF. 3.2 Some Difficulties with the Current E-R Representation of the CERIF Model The latest CERIF 2008 – 1.0 release newly introduced the Semantic Layer for capturing formal contextual roles and types; by that, the semantics in the relationships between the CERIF entities is now being maintained flexibly and independently within 4 5

As realized with: http://www.ist-world.org/ http://www.openarchives.org/pmh/

Business Semantics Management Supports Government Innovation Information Portal

761

the Semantic Layer, in natural language, based on the CERIF concepts, architecture, structure and style [10]. However, the fact that roles of the relations between entities and classifications for entities are not explicit in the E-R model, makes it non trivial for humans to read and understand the model. E.g., think of a Project (with a known identifier, associated classifications and a set of basic attributes) and a Person (also known by an identifier and a set of attributes) in the role of promoter with respect to a project. To express this relationship in CERIF the entities used are shown in Fig. 3.

Fig. 3. Excerpt of some E-R model entities of Fig. 2 in physical view, with the CERIF Core entities cfPerson and cfProject, language-related entities cfProjectTitle, cfProjectAbstract, cfClassTerm, …, selected link entities cfProject_Person and cfProject_Classification, and entities from the Semantic Layer cfClassification and cfClassificationScheme

In CERIF, a time-constrained relationship, with a defined role is established in lin entities, i.e., the cfProject_Person link entity (see Fig. 3), or the classification (i.e. typification) of projects in the cfProject_Classification entitity via referenced IDs. The upper right set of entities represents the strength of the CERIF E-R model: the semantic layer. It is designed to store all possible roles of relations and all possible types or classifications associated with entities that have been established by IDs in link entities. In the example case the Classification Scheme used for cfProject_Person roles is called cfProjectPersonRoles and the cfClassification entity is the storage for the “P” value, while the language dependent associated entity cfClassificationTerm stores the human readable version of the value in a specified natural language: “promotor” in Dutch6. The association of specific classifications with instances uses a similar connection within the semantic layer, in this example via the entity cfProject_Classification. This allows for the association of multiple classifications belonging to different Classification Schemes with a project. For instance one scheme used for project types and two others for association with two different thesauri; disciplines or application domains. Each of the business objects (CERIF entities) has a limited set of attributes, apart from the basic object identifier. Relationships between objects are achieved by means of linking entities consisting of (i) the identifiers of the objects taking part in the relation, (ii) a start and (iii) end date and (iv) a defined role of the relation (by ID reference to the 6

Some entities are language dependent and allow for the storage of different language versions.

762

G. Van Grootel et al.

Semantic Layer). In essence, every instance of a linking entity is a time constrained binary relation. The instances of objects taking part in a linking relation to the same object (i.e. cfPerson_Person) represent recursive relationships. The roles of the relations are referred from the semantic layer of CERIF. This semantic layer physically consists of a set of interrelated entities enabling the storage of schemes and the instances representing all possible roles from all possible relations. The semantic layer is also used for the storage of classifications (i.e. types) associated with the objects (entities). Much information in the research domain needs a representation in multiple languages. The support of multilingual features is very important in countries where several official languages are spoken and maintained. CERIF supports multiple language features for names, titles, descriptions, keywords, abstract and even for the semantics. For a domain expert to understand how a set of business facts is expressed by using CERIF – including the content of the semantic layer both the insight in the CERIF ER model and knowledge of the content (contextual semantics) is needed. 3.3 Business Semantics Management and CERIF While the CERIF model 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 on the modelled domain facts to domain experts and end users. In order to overcome these difficulties, EWI has decided to express the business facts in the domain concerned by the use of fact based modelling, thereby using the expertise and tools7 of Collibra. Fig. 5. shows some binary fact types that can be derived from the original CERIF model (see Fig. 2). One can appreciate the clarity and understandability of the binary fact types compared to the E-R scheme (see Fig. 3).

Fig. 4. Business Semantics Management (BSM) overview

Currently, the focus of applying BSM on CERIF has been semantic reconciliation: domain experts that collaboratively capture business semantics. This phase consists of five activities (see Fig. 4), which we briefly describe here8 in the context of the work on CERIF. Note that some activities can be performed simultaneously: 1. Scope: defining the borders of the current iteration of BSM. For CERIF, which is already a well worked out initiative, we have used the core entities (see Fig. 2) as starting point for different iterations. Scoping helps in grounding discussions: one

7 8

Available from http://www.collibra.com/trial For a more elaborate description on BSM, see [2].

Business Semantics Management Supports Government Innovation Information Portal

2.

3.

4.

5.

763

can always refer back to the source documents (or other boundaries) to bring a difficult (and sometimes philosophizing) discussion back on track. Create: generate fact types (lexons9) from the collected sources in the scoping activity. The focus lies on getting all the facts without leaving much room for discussion (divergence). Refine: clean the collected facts by following some simple rules (a first step towards convergence). For instance, decide where typing is relevant by determining which concepts share differentia (e.g., the concept “Text” in Fig. 5). Another example is splitting a semantic pattern in smaller, more reusable patterns each describing some part of the model (e.g., Person pattern, Address pattern). Articulate: create informal meaning descriptions as extra documentation. These descriptions can serve as anchoring points when stakeholders have used different terms for the same concepts (i.e., detecting synonyms). Where available, descriptions already existing can be used (e.g., the euroCRIS website on CERIF) to speed up the process and facilitate reuse. Unify: collect the input from the various stakeholders and combine them in agreed upon and shared semantic patterns. This is an activity that leaves room for discussion when necessary. Any unresolved issues can be tackled here, based on the deliverables produced in the previous activities. In the EWI case, the activity was performed more or less simultaneously with the other activities as the relevant domain experts were participating.

The Collibra Studio supports many of the activities described above, thereby further assisting the domain experts in capturing their business semantics: (i) a fact editor allowing the domain expert to simply key in the facts in natural language; (ii) a visual editor (based on [19]) providing a graphical way of presenting and browsing through the collection of lexons (see Fig. 5); and (iii) a concept editor with a built-in browser for searching the web for already existing informal meaning descriptions (e.g., on the euroCRIS website, on Wikipedia, …). 3.4 Ontologising the CERIF Model Having a standard conceptual schema, c.q. the CERIF model, (see Fig. 3) is not enough to guarantee flawless interoperability and information exchange. Intelligent agents have to be able to exchange ”meaningful” messages while continuing to function autonomously (interoperability with local autonomy as opposed to integration with central control). Hence, there should not be any confusion about which data are labelled as belonging to which category or being associated with which label. Even in the ontology literature, authors do not always make a clear distinction between a global domain concept and a local conceptual schema term [17]. Next to the schema itself, agreement (or least univocity) should be achieved on the terminology of the schema: what is exactly meant by the names of the entities and relationships. Most importantly, interoperability requires a precise and formal definition 9

Informally a lexon is a fact type that may hold for some domain, expressing that within a context the head term may plausibly have the tail term occur in role with it (and inversely the tail term maintains a co-role relation with the head term) [17]. Lexons operate on the linguistic level. We refer to [1] for a formalisation of DOGMA, including the notion of lexons.

764

G. Van Grootel et al.

Fig. 5. The Collibra tool used during the modelling phase (semantic constraints yet to be added)

of the intended semantics of an ontology (see also [12,14] for more and other details in this discussion). Not only does this presuppose a definition in natural language, also a formalisation is needed to impose additional restrictions on the relationships between the entities. This separation corresponds to the DOGMA double articulation principle [17] for ontology modelling: the distinction between the domain conceptualisation (generic facts) and the application conceptualisation (application constraints) [18]. Verbalising the entire ontology (including the restrictions) ensures a good understanding by the domain experts and knowledge engineers of the various data providers involved. In particular, when multilinguality is required, as is here the case, it is extremely important to distinguish between a level of linguistic utterances and a language neutral conceptual definition of the labels and terms [16].

4 Discussion An open question remains what to do with “complex concepts” (e.g., “cfProject_Person”). The question of naming conventions for complex concepts arises from the assumption that every concept refers to a piece of reality. Sometimes the meaning is felt to be too broad and some specialisation (expressed in natural language by a compound “project classification” or a circumscription “person who works on a project”) is wanted. Currently, we tend to reject “complex concepts”, albeit it more on philosophical grounds (“notions are not to be multiplied without necessity” = Occam’s razor). Practice should show if sufficient necessity is available.

5 Future Work Over the coming months and years, the FRIS research portal will roll out a range of new services as part of the research information space. The possibilities are numerous: a white guide (who does what?), library of publications by a particular researcher

Business Semantics Management Supports Government Innovation Information Portal

765

(digital library), a service for updating and reusing researchers’ CVs and provision of information on patents, to name but a few – see Fig. 1. In the future, more effort is to be spent on applying insights from formal ontologies to avoid modelling errors. Methods like OntoClean [4] or a more formal foundation of some often occurring relationships ([6] might be a good starting point) should be applied as a first “sanity check” on newly created ontologies.

6 Conclusion The CERIF standard is, by its nature and status of standard, an ideal candidate to be “ontologised”. For reasons of data quality and integrity as few ambiguities as possible concerning the meaning and use of domain terminology should occur. This requirement holds in particular in a context of a networked configuration, consisting of a limited number of data providers, a central portal and an unlimited number of potential data users (human and/or artificial) of various types of organisations (see Fig. 1). An ontology is exactly meant for this purpose. The case presented in this paper, namely how to build a generic model for research information exchange in Flanders, shows that business semantics management are sufficiently easy to apply by non technical stakeholders and domain experts. In addition, it also provides an interesting case that illustrates how fact oriented modelling can be used as a robust basis for ontology modelling – an exercise already supported by appropriate tools by Collibra turning academic insights (mainly the DOGMA modelling methodology [1,2,11,13,14,18,19]) into industrial practice. In short, it is an ambitious endeavour and, for the Flemish government, it is an innovating and fresh [‘fris’ = ‘fresh’ in Dutch] approach.

References 1. De Leenheer, P., de Moor, A., Meersman, R.: Context Dependency Management in Ontology Engineering: a Formal Approach. In: Spaccapietra, S., Atzeni, P., Fages, F., Hacid, M.-S., Kifer, M., Mylopoulos, J., Pernici, B., Shvaiko, P., Trujillo, J., Zaihrayeu, I. (eds.) Journal on Data Semantics VIII. LNCS, vol. 4380, pp. 26–56. Springer, Heidelberg (2007) 2. De Leenheer, P., Christiaens, S., Meersman, R.: Business Semantics Management with DOGMA-MESS: a Case Study for Competency-centric HRM. Journal of Computers in Industry: Special Issue about Semantic Web Computing in Industry (in print, 2009) 3. Guarino, N.: Formal Ontologies and Information Systems. In: Guarino, N. (ed.) Proc. of FOIS 1998, pp. 3–15. IOS Press, Amsterdam (1998) 4. Guarino, N., Welty, C.: An Overview of OntoClean. In: Staab, S., Studer, R. (eds.) Handbook on Ontologies, International Handbook on Information Systems, pp. 151–172. Springer, Heidelberg (2004) 5. Guarino, N., Oberle, D., Staab, S.: An Introduction to Ontologies. In: Studer, R., Staab, S. (eds.) Handbook of Ontologies, International Handbooks on International Infomation Systems, 2nd edn. Springer, Heidelberg (fothcoming) 6. Guizzardi, G., Wagner, G., Herre, H.: On the Foudations of UML as an Ontology Representation Language. In: Motta, E., Shadbolt, N.R., Stutt, A., Gibbins, N. (eds.) EKAW 2004. LNCS (LNAI), vol. 3257, pp. 47–62. Springer, Heidelberg (2004)

766

G. Van Grootel et al.

7. Jörg, B.: The Common European Research Information Format Model (CERIF). In: Asserson, A. (ed.) CRISs for the European e-Infrastructure. Data Science Journal (in Print, 2009) 8. Jörg, B., Jeffery, K., Asserson, A., van Grootel, G.: CERIF2008 - 1.0 Full Data Model (FDM) - Model Introduction and Specification. euroCRIS (2009) 9. Jörg, B., Krast, O., Jeffery, K., van Grootel, G.: CERIF2008XML - 1.0 Data Exchange Format Specification, euroCRIS (2009) 10. Jörg, B., Jeffery, K., Asserson, A., van Grootel, G., Rasmussen, H., Price, A., Vestam, T., Karstensen Elbæk, M., Houssos, N., Voigt, R., Simons, E.J.: CERIF2008-1.0 Semantics, euroCRIS (2009) 11. Halpin, T.: Information Modeling and Relational Databases: from conceptual analysis to logical design. Morgan Kaufmann, San Francisco (2001) 12. Meersman, R.: The Use of Lexicons and Other Computer-Linguistic Tools. In: Zhang, Y., Rusinkiewicz, M., Kambayashi, Y. (eds.) Semantics, Design and Cooperation of Database Systems; The International Symposium on Cooperative Database Systems for Advanced Applications (CODAS 1999), pp. 1–14. Springer, Heidelberg (1999) 13. Meersman, R.: Ontologies and Databases: More than a Fleeting Resemblance. In: d’Atri, A., Missikoff, M. (eds.) OES/SEO 2001 Rome Workshop. Luiss Publications (2001) 14. Spyns, P., Meersman, R., Jarrar, M.: Data modelling versus Ontology engineering. In: Sheth, A., Meersman, R. (eds.) SIGMOD Record Special Issue, vol. 31 (4), pp. 12–17 (2002) 15. Spyns, P., Van Acker, S., Wynants, M., Jarrar, M., Lisovoy, A.: Using a novel ORM-based ontology modelling method to build an experimental Innovation router. In: Motta, E., Shadbolt, N.R., Stutt, A., Gibbins, N. (eds.) EKAW 2004. LNCS (LNAI), vol. 3257, pp. 82–98. Springer, Heidelberg (2004) 16. Spyns, P., De Bo, J.: Ontologies: a revamped cross-disciplinary buzzword or a truly promising interdisciplinary research topic? Linguistica Antverpiensia NS(3), 279–292 (2004) 17. Spyns, P.: Object Role Modelling for Ontology Engineering in the DOGMA framework. In: Meersman, R., Tari, Z., Herrero, P. (eds.) OTM-WS 2005. LNCS, vol. 3762, pp. 710– 719. Springer, Heidelberg (2005) 18. Spyns, P., Tang, Y., Meersman, R.: An ontology engineering methodology for DOGMA. Journal of Applied Ontology 1-2(3), 13–39 (2008) 19. Trog, D., Vereecken, J., Christiaens, S., De Leenheer, P., Meersman, R.: T-Lex: a Rolebased Ontology Engineering Tool. In: Meersman, R., Tari, Z., Herrero, P. (eds.) OTM 2006 Workshops. LNCS, vol. 4278, pp. 1191–1200. Springer, Heidelberg (2006) 20. Verheijen, G., Van Bekkum, J.: NIAM, an information analysis method. In: Proceedings of the IFIP TC-8 Conference on Comparative Review of Information System Methodologies (CRIS 1982). North-Holland, Amsterdam (1982)

OnTheMove Academy 2009 Organizers’ Message

We are very happy to re-establish the tradition of organizing what is now called the OTM Academy, the workshop for coaching PhD students with promising work. The term “academy,” originating from Greek antiquity, implies a strong mark of quality and excellence that is upheld and promoted by its members. This label is equally valid in our context. OTMA PhD students receive the opportunity of publishing in a highly reputed publication channel, namely, the Springer LNCS proceedings of the OTM workshops. Well-respected researchers and practitioners, the OTMA faculty members, critically reflect on the students’ work in a highly positive and inspiring atmosphere to improve not only their research capacities but also their presentation and writing skills. Even a derived notion of exclusiveness and good repute applies thanks to the new OTMA on-line community and virtual “Hall of Fame,” for encouraging all participants to strengthen networking. In order to stimulate the idea of excellence even better, Collibra NV (www.collibra.be) generously sponsors the OTMA 2009 best paper award as is announced on our redesigned website. For taking up this challenging task, we would like to considerably thank the other OTM Academy faculty members, namely: – – – – –

Erich J. Neuhold (University of Vienna, Austria), OTMA Dean Alfred Holl (University of Applied Sciences, Nuremberg, Germany) Maria Esther Vidal (Universidad Simon Bolivar, Caracas, Venezuela) Adam Wierzbicki (Polish-Japanese Institute of IT, Warsaw, Poland) Josefa Kumpfm¨ uller (Vienna, Austria), OTMA Integrated Communications Chair

The OTM Academy could also rely on a highly international Program Committee to review the submitted papers. Beside the OTMA faculty members, it consisted of the following personalities, whom we gratefully thank for their effort and time. – – – – –

Christoph Bussler (Merced Systems Inc., Redwood Shores, USA) Jaime Delgado, (Universitat Polit`ecnica de Catalunya, Barcelona, Spain) Ling Feng, (Tsinghua University, Beijing, China) Fr´ed´eric Le Mou¨el (University of Lyon, Lyon, France) York Sure (SAP Research, Karlsruhe, Germany)

In total, we received 11 abstract submissions from eight different countries. The papers were independently assessed by at least three or four reviewers. Three of the accepted papers are technical papers coming from advanced PhD students who want to discuss their achievements so far. Three other accepted papers are position papers from junior PhD students who present their research plans. This R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 767–768, 2009. c Springer-Verlag Berlin Heidelberg 2009 

768

Preface

implies an overall acceptance rate of 54%. We hope that you will find the papers of this next researcher generation promising and inspiring for your own research activities. Peter Spyns Anja Schanzenberger

Automatic Detection of Terminology Evolution Nina Tahmasebi L3S Research Center, Appelstr. 4, DE-30167 Hannover, Germany [email protected]

Abstract. As archives contain documents that span over a long period of time, the language used to create these documents and the language used for querying the archive can differ. This difference is due to evolution in both terminology and semantics and will cause a significant number of relevant documents being omitted. A static solution is to use query expansion based on explicit knowledge banks such as thesauri or ontologies. However as we are able to archive resources with more varied terminology, it will be infeasible to use only explicit knowledge for this purpose. There exist only few or no thesauri covering very domain specific terminologies or slang as used in blogs etc. In this Ph.D. thesis we focus on automatically detecting terminology evolution in a completely unsupervised manner as described in this technical paper.

1

Introduction

Finding relevant information in documents or resources that are older than one’s lifespan is difficult if one has no prior knowledge about the language of that time. As language evolves, past language is forgotten and new terminology is adapted reflecting on written text produced. As such texts are stored in archives; the evolving language becomes present in the archive. When an archive user without prior knowledge about these changes queries the archive, the results will be limited to the user’s terminology. This leads to a semantic gap between the terminology used when querying and the terminology used for creating documents that are stored in the archive. While we previously could visit a library and ask for expert advice from a librarian, the Web era now provides us with more challenges. Firstly the amount of information on the Web vastly succeeds the amount of information found in any one library; secondly new domains are established and changing at a faster rate. There are no longer any domain experts to help us query the knowledge banks, which results in an increasing need of automatic ways to find terminology evolution. As an example of terminology evolution in an archive, let us take the Russian city of St. Petersburg. In 1703 it was named St. Pieter Burh and shortly after it was renamed to St. Petersburg. It kept the name until 1914 when it changed to Petrograd and then in 1921, to Leningrad. The name stayed Leningrad until 1991 when it changed back to St. Petersburg. When having no prior knowledge of these changes, a query of the current name 

This work is partly funded by the European Commission under LiWA (IST 216267).

R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 769–778, 2009. c Springer-Verlag Berlin Heidelberg 2009 

770

N. Tahmasebi

”St. Petersburg” in The Times1 spanning from 1785 to 1985 returns less than 80% of the relevant documents. This goes to show that terminology evolution does affect the result space of search in long term archives. Another type of terminology change is represented by the term ”rock” which added the meaning ”music” to its previous ”stone”. Language can also change due to political correctness; ”fireman” is now more often referred to as ”fire fighter” due to an increasing amount of women in the profession. For a classification see [17]. The main contribution of this Ph.D. thesis is to overcome these difficulties by (1) proposing a model for describing terminology evolution. Furthermore we will (2) propose a completely automatic method for detecting terminology evolution which can be divided into (a) finding evolution of word senses and (b) from this deriving at evolution of terms. We will also (3) develop methods for evaluating the outcome. Task (1) is expeded to finsih in 2009, task (2) in 2011. The final deadline for this thesis is 2012.

2

Related Work

The act of automatically detecting terminology evolution given a corpus can be divided into two subtasks. The first one is to automatically determine, from a large digital corpus, the senses of terms. This task is generally referred to as Word Sense Discrimination. The second task is to automatically detect evolution. To our knowledge little previous work has been done directly in this topic and thus we mostly investigate state of the art in related fields. 2.1

Word Sense Discrimination

In this thesis we review Word Sense Discrimination (WSD) techniques, which is the formal term for techniques used to find word senses given a collection of texts. These techniques can be divided into two major groups, supervised and unsupervised. Due to the vast amounts of data found on the Web and in Web Archives, we will be focusing on unsupervised techniques. Most WSD techniques are based upon clustering which can be divided into hard and soft clustering algorithms. In hard clustering an element can only appear in one cluster, while soft clustering allows each element to appear in several. Due to the polysemous property of words, soft clustering is most appropriate for Word Sense Discrimination. In Sch¨ utze [15] it is said that the basic idea of WSD is to induce senses from contextual similarities. Using the Buckshot algorithm Sch¨ utze clusters second order co-occurrence vectors from a training set into coherent clusters representing word senses. The centroids of each cluster are used to label ambiguous words from the test set. An alternative approach is proposed in [7] where a word similarity measure based on [6] is presented. By evaluating an automatically created thesaurus using this similarity measure, it is shown that the measure is appropriate for word senses. Based on this a clustering algorithm called Clustering 1

http://archive.timesonline.co.uk/tol/archive/

Automatic Detection of Terminology Evolution

771

By Committee (CBC) is presented in [14]. It aims to form as many committees as possible under the condition that the newly formed committee is not similar to an existing committee. The paper also proposes a method for evaluating the output of a WSD algorithm to WordNet [10], which has since been widely used [2,3,5]. CBC is shown to outperform other known algorithms such as Buckshot and K-means, in both recall and precision. A third category of WSD techniques is presented in [4]. Here a network of co-occurring words is built from the collection. A clustering is made based on the clustering coefficient of each node, also referred to as curvature. A more thorough investigation of the curvature measure and the curvature clustering algorithm is made in [3]. An evaluation of the curvature algorithm is made on the BNC corpus using the methods proposed in [14]. A higher precision than the one reported for CBC is found and it is noted that the high performance of curvature comes at the expense of low coverage. 2.2

Detecting Evolution

Analysis of communities and their temporal evolution in dynamic networks has been a well studied field in recent years. A community can be modeled as a graph where each node represents an individual and each edge represent interaction among individuals. When it comes to detecting evolution, the more traditional approach has been to first detect community structure for each time slice and then compare these to determine correspondence [8]. These methods can be argued to introduce dramatic evolutions in short periods of time and can hence be less appropriate to noisy data. Representing the traditional approach a framework called Monic [16] is proposed for modeling and tracking cluster evolutions. The disadvantages of the method are that the algorithm assumes a hard clustering and that each cluster is considered a set of elements without respect to the links between the elements of the cluster. In a network of lexical co-occurrences this can be valuable since the connections between terms give useful information to the sense being presented. In [12] a way to detect evolution is presented which also takes in to the account the edge structure among cluster members. In contrast to the traditional approach [8] proposes a framework called FacetNet. FacetNet discovers community structure at a given time step t which is determined both by the observed data at t and by the historic community pattern. FacetNet is unlikely to discover community structure that introduces dramatic evolutions in a very short time period. Depending on the characteristics of the word graph derived from our collection it might be a suitable approach to filter out noise. An alternative method of finding evolutions in networks can be inspired by [11]. Here a method for object identification with temporal dimension is presented. In our setting we could consider each cluster found in a snapshot as one observation of an object. We can then cluster observations from different snapshots in order to determine which senses are likely to belong to the same object and be evolutions of one another. An observation outside of a cluster can be considered similar to the sense represented by the cluster, but not as an evolved version of that sense.

772

N. Tahmasebi

A method for describing and tracking evolutions can be found in the related field of Temporal Text Mining. In [9] themes are found and tracked over time. A theme evolution graph is defined that seems particularly suitable for describing terminology evolution and is similar to what is proposed in [17]. To our knowledge only one previous work has been published in the area of Terminology evolution [1]. Here an orthogonal approach to ours is presented, where the aim is to find good query reformulations to concurrent language using language from the past. A term from a query can be reformulated with a similar term if the terms in the resulting query are also coherent and popular. Terms are considered similar if they co-occur with similar terms from their respective collections.

3

Problem Statement

In order to describe terminology evolution, we need a model. In [17] I developed an overall model which describes terminology evolution independently of what methods are used for solving each sub task. 3.1

Terminology Evolution Model

To represent the relation between terms and their meanings we introduce the notion of concept and represent meanings as connections between term and concept nodes in a graph. A concept represent a sense and can be seen as a synset used in WordNet [10]. To be able to describe terms and their meanings we define a term concept graph (TCG). In a TCG each term is associated with its concepts (word senses) found from a collection. The graph carries a sense of time by annotating each edge with the time stamp inherited from the collection. φ : W × T → (W × P(C × P(T )))

(1)

(w, t)  → (w, {(c1 , {t}), . . . , (cn , {t})}) where w ∈ W , t ∈ T and for all i = 1 . . . n: ci ∈ C. Here P denotes a power set, i.e. the set of all subsets, W the universe of terms, C the universe of all clusters and T are time stamps. Although φ generates only one timestamp for each termconcept relation, we introduce the power set already here to simplify the next steps. We call the set of all TCGs derived from a collection for a terminology snapshot. Once several terminology snapshots have been constructed, these will need to be compared in order to find terminology evolution. This comparison is made by merging two TCGs and outputting a new TCG. The newly constructed TCG carries the gathered information of the merged TCGs by allowing for several time annotations on each edge. To shorten the notation we define τ as a set of time stamps ti , i.e. τ ∈ P(T ) and a term concept relation can be written as a pair (ci , τi ). The main difficulty in the merging step comes from decisions concerning two similar clusters, see Fig. 1. When two clusters are different as in the case with c2 and c4 the merging is trivial. In the merged TCG the term w is associated with both c2 and c4 and the time annotations stay the same as in

Automatic Detection of Terminology Evolution

773 c1

TCGt1

TCGt1Ut2

TCGt2

c3

t1 t1

c1

w

t2

w t1

w t2

c2

t2

c3

c4

t2 t1

c4

c2

Fig. 1. Merging TCGs from t1 and t2 into one TCG containing all information about w until time t2

the original TCGs. With c1 and c3 , a decision must be made whether the differences come from the underlying collection or if c1 evolved into c3 . The function representing the merging step can more formally be described by the following: ψ : (W × P(C × τ )) × (W × P(C × τ )) → (W × P(C × τ ))

(2)

((w, {(c1 , {t}), . . . , (ci , {t})}), (w, {(cj , τj ), . . . , (cm , τm )})) → (w, {(c1 , τ1 ), . . . , (cn , τn )})  where ci , cj ∈ C, t ∈ T and τi , τj ∈ τ for all i, j. It should be clear that the set of concepts ci in the resulting graph of ψ does not necessarily have to be a subset of the concepts {c1 , . . . cm } from the input graphs, e.g. in Fig. 1, the concepts c1 and c3 could be merged (by union, etc.) and considered as a new concept. ψ can be iteratively applied to a TCG from time tN and the TCG containing all knowledge about a term up to time tN −1 . A TCG cannot directly be used for determining evolutions between terms and therefore we need a method for associating a concept with the relevant terms. For a given concept c, the function θ : C → P(W × τ ) returns the set of terms used to express c, together with time stamp sets which denote when the respective terms were in use. 3.2

Research Hypothesis

In our terminology evolution model, we assume that there are some ’true’ functions φ, ψ and θ that correctly and exhaustively models language from the underlying collections. Because these functions are unknown, automatically detecting terminology evolution becomes finding approximations for φ, ψ and θ.

4

Proposed Approach

The techniques which will be developed in this thesis for detecting terminology evolution will be divided into two main parts. The first will mainly concentrate

774

N. Tahmasebi

on finding word senses from a collection in an unsupervised manner, i.e. perform WSD including preprocessing data, terminology extraction and creation of terminology snapshots. The second task is to detect evolution in an automatic fashion and can be described as merging terminology snapshots to first find evolution of clusters and from this derive evolution of terms. For this thesis we will mainly focus on the second task and apply existing technologies for the first task to create input for task two. 4.1

Word Sense Discrimination

In this thesis we have chosen to include Terminology extraction as a subtask of WSD because it very much affects the results of the sense discrimination. We consider nouns as terms and once the relevant terms have been identified in a collection, a relational matrix is constructed. We have chosen the method presented in [3] which is a graph theoretical approach. Each node is a noun and there exists an edge between two nodes if they are separated by ’and’, ’or’ or commas in the collection. Following [3] we cluster the matrix using the curvature clustering algorithm with different clustering coefficients. These clusters are used to create TCGs. One issue to be tackled is to determine which terms from a concept that are associated with the concept, i.e. finding θ. Some terms are supporting terms for the concept while other terms are more important. In the case of fireman, the term ”hose” might not be directly related to the concept and hence this member of the concept should not be pointing to the concept. Applying the clustering algorithm iteratively and as the clustering becomes stricter, monitoring which cluster members stay the same, can give us clues on which terms are more or less relevant for the cluster. 4.2

Tracking Evolution

Using the graph model to find concepts in the previous step has the advantage of clustering nodes with links. This means we can consider a concept to be more than a set of terms because we know how they relate to each other. Since two similar clusters can represent different senses if the nodes are linked differently, the links can aid the comparison. For tracking clusters we plan on using the approach presented in [12], which considers also link information between nodes. One interesting aspect is to see if clusters or communities representing word senses behave similarly to communities of co-authorships or telecommunication graphs. In [12] it is found that small communities should be stable in order to survive while larger communities need to be dynamic. The main difference between tracking cluster evolution and tracking terminology evolution is the notion of members or nodes. Members are traditionally considered fixed; an author is always the same author even when its membership in clusters changes over time. When tracking concepts, it is not only word senses that change over time, but also the members themselves. E.g. the term ”pretty” meant ”cunning” and ”crafty” and now means ”attractive” and ”good looking”. To tackle this problem existing models need to be extended and adapted to our

Automatic Detection of Terminology Evolution

775

purposes. Another large issue arises once we have found the evolution of concepts, i.e. we are able to track clusters over time. As discussed above, not all terms in a cluster are relevant to the cluster and hence we need to determine which terms from the concepts that can be considered evolutions of the target term in a TCG. One possible solution could be to introduce probabilities associated with cluster evolutions as well as between terms themselves. Then the probability for the target term in a TCG to evolve to a candidate term can be modeled using the cluster evolution probability as well as the internal ’importance’ of a node to a cluster using a network flow graph.

5

Evaluation Methods

To evaluate the first step of the model, we evaluate the output of the word sense discrimination. We evaluate the clusters outputted by the curvature clustering against WordNet using techniques presented in [14] with tools from WordNet::Similarity2 package. To our knowledge no evaluation methods for the second step, i.e. automatic terminology evolution detection, have previously been published. Hence there are no reference datasets or measures to use. We plan on doing an evaluation on The Times corpus by manually choosing some examples of terms where there is evidence of evolution as well as terms without evolution in the archive. For each term we will verify if our terminology evolution algorithm can detect evolution in a way corresponding to the manual assessment. Success will be measured in the number of correctly assessed cases.

6

Results

Preliminary experiments are run on roughly 10% of The Times Archive, using 4 years of data every 50 years. For each collection we extract nouns, lemmatize them and build a graph as described in Sec. 4.1. An edge is kept if the corresponding nodes co-occure more than twice in the collection. We use a clustering coefficient of 0.5 which gives relatively stable senses [3,4,13]. We also use coefficient 0.3 hoping to get a broader coverage but also senses that are less stable and hence have higher probability of evolution. We can already see some interesting trends. Firstly the number of clusters corresponds well to the number of nodes (distinct nouns) found in the co-occurrence graph as seen in Fig. 2(a). Secondly the graphs created for these years, all have high precision when evaluated using the approach from [14] with similarity threshold 0.25 [3,14]. In Fig. 2(b) we see a distinction between years 1785 − 1836 and 1885 − 1985. The higher precision in the early period is shown to be statistically significant with 95% confidence. The dip in this curve can partially be explained by the sizes of the collection. The same filtering is used regardless of the size of the collection. Instead filtering should be adjusted based on the collection size. e.g. for 1935, if 2

A description of this package can be found on http://www.d.umn.edu/ tpederse/ similarity.html

776

N. Tahmasebi

200 180 sr 160 tes 140 lu c 120 f 100 o re b 80 m 60 u N 40 20 0

8000

1

7000

0,95

6000 5000 4000 3000 2000

se d o n f o re b m u N

1000

# nodes in graph

# clusters 0.5

0,7 0,65

0

# clusters 0.3

0,9

n 0,85 o sii 0,8 ce r P 0,75

0,6

(a)

cc= 0,3

cc = 0,5

(b)

Fig. 2. Initial experiments using 10% of The Times Archive, where cc is the clustering coefficient used

an edge is kept with a frequency above 6, the precision of the clusters increases to 0.95 and 0.96 for cc = 0.3 and 0.5 respectively. The distinction between early and later years is shown for the number of distinct nodes in the graphs and the number of clusters using both coefficients. It is also the case that during this period we find a higher amount of WordNet terms among all extracted terms than in the latter period, also this with a 95% confidence level. This is interesting because the behavior cannot be seen in the proportion of nouns extracted from all terms from the collections.

7

Discussion

One of the larger difficulties in detecting terminology evolution is determining if two similar clusters should be considered the same or evolutions from each other. The main difficulty lies in that we are only making approximations of word senses and these rely very much on the underlying collection. Assume we have 100 documents describing the term ”rock”, some describing the ”music” sense of rock while others describing the ”stone” sense. Applying WSD techniques on several random partitioning into batches of 50 documents would yield in different results for each partitioning. If a human expert assessed two clusters on the same sense from two different partitioning, it would be a fairly easy decision, even with some missing terms in one cluster. While for automatic detection of terminology evolution, this is a more difficult decision to make. When are the differences between two clusters dependent on the underlying collection, and when has there been evolution? Another issue arises when using the TCG to find and describe evolution. Describing terminology evolution like in the case with ”rock” is straight forward given the TCG model. A concept representing the new sense of the term is added and the appropriate timestamp is given to the edge between the concept and the term. The ”St. Petersburg” example on the other hand is more complicated. It must first be determined that the concept nodes associated to the terms ”Leningrad”, ”Petrograd” and ”St. Petersburg” are in fact the same and from this arrive at the fact that ”Leningrad” and ”Petrograd” can be used to

Automatic Detection of Terminology Evolution

777

expand the query ”St. Petersburg”. The methodology for this could invite many ’false positive’.”Sean Penn” and ”Guy Ritchie” are both terms that would be associated with the concept node representing ”Madonna”, both being husbands of her in different periods of time. If the model can identify the ”Madonna” node as representing the same concept for both these terms, then we could draw the conclusion that ”Sean Penn” can be expanded with ”Guy Ritchie” in the same way as with the ”St. Petersburg” example.

8

Conclusions and Future Work

As discussed above, my Ph.D. thesis aims at finding ways to automatically detect terminology evolution. We have identified the first step in this process to be automatic detection of word senses from a collection. The second step is to discover evolution of these senses and from this dervie at evolution of terms. So far the initial experiments have shown that the performance of the WSD algorithm chosen, is stable over time. The word senses found by the algorithm map well to synsets from WordNet and with a low clustering coefficient, we are able to get a higher coverage of the collection. We will conduct large scale experiments on The Times collection to get a more comprehensive overwiev. The next step for this thesis will be to determine which terms are relevant to the concepts in order to create TCGs. When this first task has been solved we will continue with tracking evolution of clusters representing word senses. Here we will take into account the linkage information between the nodes in the clusters in order to better map senses from different periods in time. We plan on adapting current algorithms for tracking clusters to better fit the terminology evolution scenario as discussed above. We will conduct experiments to monitor the life span of clusters to see if the same properties hold for word senses as for network clusters. The last step of the process will be to dervie evolution of terms from the word sense evolutions found in the previous step. The technologies used are very much dependent on the outcome of, as well as technologies used in, the previous steps. One possibility is to consider cluster evolution probabilities, as well as term importance in a cluster, to calculate flows using a graph flow model and from these flows derive at terminology evolution.

Acknowledgements We would like to thank Times Newspapers Limited for providing the archive of The Times for our research.

References 1. Berberich, K., Bedathur, S., Sozio, M., Wiekum, G.: Bridging the terminology gap in web archive search. In: WebDB (2009) 2. Deschacht, K., Francine Moens, M., Law, I.C.F.: Text analysis for automatic image annotation. In: Proc. of the 45 th Annual Meeting of the Association for Computational Linguistics. East Stroudsburg (2007)

778

N. Tahmasebi

3. Dorow, B.: A graph model for words and their meanings. PhD thesis, University of Stuttgart (2007) 4. Dorow, B., Widdows, D., Ling, K., Eckmann, J.P., Serqi, D., Moses, E.: Using curvature and Markov clustering in graphs for lexical acquisi tion and word sense discrimination. In: 2nd Workshop organized by the MEANING Project, Trento, Italy, February 3-4 (2005) 5. Ferret, O.: Discovering word senses from a network of lexical cooccurrences. In: Proc. of the 20th international conference on Computational Linguistics, Morristown, NJ, USA, ACL, p. 1326 (2004) 6. Lin, D.: Using syntactic dependency as local context to resolve word sense ambiguity. In: Proc. of the 35th Annual Meeting of the Association for Computational Linguistics and Eighth Conference of the European Chapter of the Association for Computational Linguistics, Morristown, NJ, USA, ACL, pp. 64–71 (1997) 7. Lin, D.: Automatic retrieval and clustering of similar words. In: Proc. of the 17th international conference on Computational linguistics, Morristown, NJ, USA, ACL, pp. 768–774 (1998) 8. Lin, Y.R., Chi, Y., Zhu, S., Sundaram, H., Tseng, B.L.: Facetnet: a framework for analyzing communities and their evolutions in dynamic networks. In: Proc. of the 17th international conference on World Wide Web, pp. 685–694. ACM, New York (2008) 9. Mei, Q., Zhai, C.: Discovering evolutionary theme patterns from text: an exploration of temporal text mining. In: Proc. of the eleventh ACM SIGKDD international conference on Knowledge discovery in data mining, pp. 198–207. ACM Press, New York (2005) 10. Miller, G.A.: Wordnet: A lexical database for english. Communications of the ACM 38, 39–41 (1995) 11. Oyama, S., Shirasuna, K., Tanaka, K.: Identification of time-varying objects on the web. In: Proc. of the 8th ACM/IEEE-CS joint conference on Digital libraries, pp. 285–294. ACM, New York (2008) 12. Palla, G., Barabasi, A.L., Vicsek, T.: Quantifying social group evolution. Nature 446(7136), 664–667 (2007) 13. Palla, G., Der´enyi, I., Farkas, I., Vicsek, T.: Uncovering the overlapping community structure of complex networks in nature and society. Nature 435(7043), 814–818 14. Pantel, P., Lin, D.: Discovering word senses from text. In: Proc. of ACM SIGKDD Conference on Knowledge Discovery and Data Mining, pp. 613–619 (2002) 15. Sch¨ utze, H.: Automatic word sense discrimination. Journal of Computational Linguistics 24, 97–123 (1998) 16. Spiliopoulou, M., Ntoutsi, I., Theodoridis, Y., Schult, R.: Monic: modeling and monitoring cluster transitions. In: Proc. of the 12th ACM SIGKDD international conference on Knowledge discovery and data mining, pp. 706–711. ACM, New York (2006) 17. Tahmasebi, N., Iofciu, T., Risse, T., Niederee, C., Siberski, W.: Terminology evolution in web archiving: Open issues. In: Proc. of 8th International Web Archiving Workshop in conjunction with ECDL (2008)

Ambient Information Systems to Support the Elderly in Carrying Out Their Activities of Daily Living Juan Pablo García-Vázquez1 and Marcela D. Rodríguez2 1

Doctoral Student, Institute of Engineering, MyDCI, Autonomous University of Baja California, Mexicali, México 2 Advisor, School of Engineering, MyDCI, Autonomous University of Baja California, Mexicali, México {jgarcia,marcerod}@uabc.mx

Abstract. As they age, older adult’s present losses in their functional capabilities which cause them can’t continue performing their activities of daily living (ADL) independently at home. We propose Ambient Information Systems (AIS) as appropriate pervasive devices to promote their independent living. Therefore our aim is to determine the utility and usability of AIS to support the independent life of older adults by helping them to perform their activities. In this paper we present preliminary results of a case study that we carried out for understanding the problems and needs that older adults face in doing some of their activities of daily living. In particular, we present results regarding the elderly problems to adhere to their medication prescription. Based on these results we propose AIS to support older adults to medicate. Finally, we present the design attributes incorporated into this AIS, which were identified from the design taxonomies of AIS reported in the literature. Keywords: Ambient Information Systems, Elderly, Activities of Daily Living.

1 Introduction During aging, older adults present losses in their functional capabilities. This may cause older adults to stop performing their activities of daily living (ADLs) at home independently. Consequently they need to be assisted in different ways: they may need help to complete an activity; they need to be reminded as they may forget some events or tasks that impede completing an activity appropriately; they may need to be warned when facing risks associated with performing an activity; and they may need to be motivated or persuaded in order to maintain a healthy lifestyle. Several technologies have been proposed to support elders’ carry out their activities of daily living. One example is the use of assistive technologies like robots and software agents that deal with motor limitations and sensory and cognitive problems in older adults. Such is the case of Robot-O-Care II which helps older adults with their mobility and some household tasks [1]. Intelligent agents or systems that provide recommendations of suitable food recipes, taking into account their nutritional profile [2]. The aforementioned technologies may increase elders’ quality of life and aims to eliminate the necessity of having a caregiver continually taking care of elders. However, there is R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 779–788, 2009. © Springer-Verlag Berlin Heidelberg 2009

780

J.P. García-Vázquez and M.D. Rodríguez

evidence that older adults may perceive these systems as obtrusive and restrictive of their privacy [3]. Most of the assistive technology we found in the literature has been designed for older adults that have a functional limitation [1][4]. These systems can cause functional dependence [5] if they are used for older adults that do not have a severe functional or cognitive limitation but only require some help to continue performing their activities with autonomy. Older adults that are still independent need technologies that encourage them to continue performing their activities by themselves. We propose Ambient Information Systems (AIS) that enable older adults to complete their activities of daily living at home. Ambient Information Systems describe a large set of applications that publish information in a highly non-intrusive manner, adhering to Mark Weiser’s concept of calm technology. The information sources may manifest as both novel devices and as devices embedded in common objects, such as toys, furniture, clothes, jewelry and even our own bodies. The behavioral characteristics of such systems are that they: display information that is important but not critical, can move from the periphery to the focus of attention and back again, focus on tangible representations in the environment, provide subtle changes to reflect updates in information, and finally, they are aesthetically pleasing and environmentally appropriate [6]. Therefore, AIS can be embedded in the tools and objects that elders currently use to carry out their activities by providing information that reminds elders to perform an activity, warns them of a risk associated with an activity or provides clues about how to accomplish a step in an activity or task. The aim of this research work is to determine the usefulness and ease of use of AIS to support the independent life of older adults by enabling them to perform their ADLs. In this paper, we present the design rationale of AIS for supporting one of the activities considered relevant for living independently, which is medicating. Before presenting this AIS, section 2 presents AIS proposed for improving different aspects of people’s well being. Section 3 presents our approach, including the methodology followed for addressing the identified research questions. Section 4 describes the preliminary results. And finally, section 5 presents the conclusions and future work.

2 Related Work Several AIS have been proposed for improving the quality of life and well being of people, but a few of them have been designed for addressing the needs of older adults. For instance, we identified AIS designed for motivating persons to adopt healthy life styles. Such as Ubifit Garden which is an AIS for mobile phones that presents a garden that blooms to make persons aware of their physical activities they perform daily [7]; and the Breakaway AIS, which is a sculpture in form of a chair that changes its position to encourage people to perform a physical activity, such as walking, after detecting the user has been sitting for a long period of time [8]. We also identified AIS designed for informing elders’ caregivers and family members regarding the elders' activities and health status. For instance, Digital Family Portrait [9] and CareNet[10] are AIS that allow family members or caregivers to monitor elders’ health status, activities and some of their events such as medicating, falls and relationships, using a digital portrait with a picture of the elder augmented with icons that are related to those activities.

Ambient Information Systems to Support the Elderly in Carrying Out Their Activities

781

3 Our Approach We propose Ambient Information Systems (AIS) that enable older adults to carry out their ADLs at home [11]. To reach this end, we consider that AIS should be used by older adults when they are still independent in order for the systems to make “aging at home” feasible. We believe that technology should promote their independent living by encouraging them to continue performing their activities by themselves. For instance, to correct a vision problem people use eyeglasses and are therefore able to continue reading without assistance from others. Therefore, during the design of AIS the elderly’s needs and problems regarding their natural functional limitations such as cognitive, visual and auditory decline should be considered. For addressing the above aspects, the following research questions have been identified: 1. What are the design attributes that should be considered for designing AIS that support the activities of daily living of older adults? To address this question, we analyzed the taxonomies and design guidelines for AIS that have been proposed in [6][12][13][14]. 2. How useful are AIS for supporting the autonomy of older adults in their activities of daily living? We plan to develop AIS to evaluate the strategies used for helping older adults to perform their activities. Some of these strategies are persuasion, reminding, coaching or preventing risks associated with an activity of daily living. 3.1 Research Methodology For addressing the above research questions, we are following a methodology that includes the following phases: • Analysis of the design attributes of AIS. We analyze the taxonomies and heuristics that have been proposed for designing and evaluating ambient information systems [6][12][13][14]. This allows us to indentify attributes of design that should be used in the development of AIS that will support older adults to live independently at home. • Case study. To identify the desirable features of AIS, we first need to understand the problems that older adults face when performing their activities of daily living. To reach this end, we selected to study the medicating activity by using ethnographic techniques such as observation, interviews and questionnaires. To analyze the data obtained from these techniques, we used Activity Theory which enables us to focus on the interaction of human activity and consciousness within its relevant environmental context [16]. • Design and implementation. We apply the results from previous phases to propose and develop AIS. For instance we may consider the tools commonly used by older adults for carrying out their activities such as potential devices to be computationally enhanced to present relevant information for completing their activities as we present in [15]. • Evaluation. We plan to evaluate the ease of use and usefulness of the strategies incorporated into the ambient information system for helping older adults to perform their ADLs.

782

J.P. García-Vázquez and M.D. Rodríguez

4 Preliminary Results It has been determined that successful independent living requires that older adults be capable of performing the Basic Activities of Daily Living (BADL) as well as the Instrumental Activities of Daily Living (IADL) [17]. For this reason, our work will focus on analyzing activities that belong to the categories of BADL and IADL, such as medicating which is an IADL. Medication adherence has been identified as a problem that contributes to increasing health-care services utilization. Some studies have evaluated strategies in which health personnel, such as nurses or pharmacists, provide support to elders and educate them to improve their medication adherence [18]. The interventions strategies vary from providing face-to-face instruction, telephone consultations and written information. However, there is a lack of consensus as to how adherence should be effectively promoted, assessed and evaluated [18]. The aforementioned studies provide evidence that medication assistance is becoming a very important aspect of elderly care giving, and furthermore, motivate our work. We present preliminary results regarding a case study carried out to understand the problems faced by the elderly as they medicate. We have also identified some of the design attributes that should be incorporated into AIS that help the elderly take their medication appropriately. 4.1 Case Study The aim of the case study we carried out was to: • Identify needs and problems that older adults face in adhering to their medication prescription. • Identify tools or objects that older adults use to medicate. • Identify the factors that help or hinder their medication adherence. Protocol. For this study, we selected older adults (OA) with no cognitive or functional disease to impede them from carrying out their daily activities. All OA selfmanaged their medications and were taking similar medications. We carried out contextual semi-structured interviews based on the Medication Management Instrument for Deficiencies in the Elderly (MedMaIDE), which is an assessment instrument for potential issues surrounding medication compliance and management in the home setting [18]. The interviews covered three aspects considered important for proper medication management according to the MedMaIDE instrument: i) What a person knows about the medication she is taking; ii) whether a person knows how to take her medication; and iii) whether a person knows how to get her medication from a doctor or pharmacy [18]. We also added questions to find out the place in the home where a person takes her medication; and the supporting resources a person uses to remember how to adhere to her medication. Contextual semi structured interviews were conducted with six OA between 62 and 73 years old. Problems with Medicating. From the interviews, we identified that OA have the following problems adhering to their medication routine:

Ambient Information Systems to Support the Elderly in Carrying Out Their Activities

783

• Older adults forget to take their medicines on time. Two (2) OA commented that they have forgotten to take their medicines, due to the fact that they take several medicines and on different schedules. • Older adults are not able to read the text of their medicines. Four (4) of them stated that they have problems reading the small text of their medicines. • Older adults take expired medicines. Two (2) of the four (4) OA that have problems reading the small text of their medications commented that this was an impediment to realizing that a medication has expired before taking it. Strategies to Adhere to Medication Prescriptions. We observed that older adults have their own strategies to adhere to their medication prescriptions: • Participants have their own techniques to avoid taking incorrect doses and medicines; i.e. an older adult (OA4) stated: “I place my medicines in order so I do not take them twice” and (OA2) said: “I put the medicine I take daily in this bowl”. • Older adults use resources to remind themselves of their doctors ‘appointments in order to refill their medicines. In this sense, an older adult stated (OA2): “I have an appointment card and in my work I have a calendar in which I mark my appointments with the doctor”. and AO1 said: “my daughter and I have our appointments with the doctor the same date”.

Fig. 1. Structure of the medicating activity by following the Engeström activity model

Activity Modeling. We used Activity Theory to identify the objects and/or tools that older adults use to adhere to their medication prescription, the community members that participate in the activity and the factors that benefit and limit the activity [16]. Fig. 1 presents the model of the medication activity for older adults that have the objective of visiting their doctors in order to have their medication available (expected outcome). For achieving this objective older adults use physical tools such as a

784

J.P. García-Vázquez and M.D. Rodríguez

health care cards and calendars, which they use for scheduling their appointments. However, to achieve the objective, older adults need the participation of their community members. For instance, an older adult (AO3), need the participation not only of her doctor and pharmacists, but also of her husband to take her to the medical appointment. The interactions among the elderly and their community are limited by rules. In this case, the elder meeting with the doctor is limited by the schedule of the appointment. We also identified one of the factors that may affect the way the activity is performed. This factor is related with the place in which older adults take their medicines: the kitchen. Older adults provided arguments that indicated that this is the place in which they spent more time. Additionally, two (2) older adults indicated that the kitchen is the place in which they find the instruments they use for medicated. One (1) older adult indicated that since he spends more time in the kitchen, this also facilitates not forgetting to medicate.

llll1111111 a)

b)

Fig. 2. a) WENOMA interface for coaching elderly how to take a medicine; b) Elderly wearing a WENOMA Prototype

4.2 Design of AIS for Supporting Medication Adherence We designed a prototype Wearable Notification Display for Medication Adherence (WENOMA) for enhancing a help button in the context of a project that will study the impact of using help buttons to provide permanent socio-medical assistance to the elderly (Figure 2b)[19]. The WENOMA is an ambient information system to assist older adults in taking their medicines by Reminding older adults they need to (a) take their medicines and (b) refill them on time. To do this, the system coaches the user by presenting critical information that enables them to carry out these two specific tasks, such as (a) doses to take and (b) doses left in the medicine container. If an older adult persists in not performing any of these two important tasks, the notification display will periodically remind and coach the user in order to persuade him to achieve their medicating routine. The proposed user interface for the WENOMA system is shown in Figure 2. The figure 2a presents the user interface for coaching elderly of the medications and doses to take. It consists of the following elements: a) medicine name, b) doses, c) icon representing the disease or health problem treated with the medication, d) current time, e) number of pills to take at current time. The figure 2b presents an older adult wearing a WENOMA prototype.

Ambient Information Systems to Support the Elderly in Carrying Out Their Activities

785

Design Attributes. WENOMA addresses the following design attributes from taxonomies and design guidelines for AIS that have been proposed in [6][12][13][14]: Notification Level. This is defined by Matthews such as degree to which AIS alert the person [12]. Matthews et al [12] defined the following levels listed in ranges from lower to higher notification: ignore, change blind, make aware, interrupt and demand action, considering the models: inattention, divided attention and focused attention propose by psychology of human attention science. In inattention the objects are not directly available for conscious awareness but may still affect behavior; Divided attention and focused attention, represent the two ways that humans consciously perceive stimuli, by distributing attention over several objects or using all attentional resources to focus on one stimulus[12]. WENOMA prototype uses higher notification levels that consider divided and focused attention because it provides older adults critical information about their medication when it requires their attention. Thus WENOMA prototype is not currently using lower levels such as ignore and change blind, because convey information in a way that consumes no conscious awareness. WENOMA uses the notification levels make aware, interrupt and demand action. The make aware level is used by WENOMA to represent information of some importance for the activity [12]. For instance, WENOMA provides information to older adults to remind them that it is time to take their medicines or that their medicines are running out. The interrupt and demand action is used by WENOMA to represent information that should grab focused attention temporarily distracting the user from their activity. But demand action also requires that the user perform action to stop the alerting [12]. For instance, an older adult is performing an activity such as reading a book, and then WENOMA use an interrupt notification level using an audio modality through strident sound to notify them that it is important to take their medicines and this demands action of older adults to go to their medicine dispenser to stop the notification. Modality of Notification. This attribute describes how the data from the world is encoded in visual, tactile, olfactory, auditory and movement elements to convey information to the persons [6][14]. The WENOMA use different modalities of notification that make an older adult aware of the importance of performing relevant tasks regarding his medication. For instance, a slight audible alarm is used as a cue to attract his attention. Then, the older adult may focus on reviewing the critical information presented on the display, such as the name of the medicine and doses to take. To present this critical information, we are using visual elements, such as text and icons that easily coach the older adult regarding his medication. Our intention is to use visual notification modalities that do not demand the user’s attention for long periods and that can be easily read and be interpreted. Representation of ambient information system. This attribute describes the computationally enhanced objects required to become an Ambient Information System. In [6][14] it is stated that an AIS can be represented as a physical object developed for a specific purpose, for instance the Breakaway [8]. The AIS can also be integrated in objects that currently exist in our physical environment, such as the CareNet Display [10] which is a portrait. Finally, it has been identified that AIS can be a 2D representation that displays information by means of traditional screen technology, such as the Ubifit Garden for mobile phones [7]. Considering these definitions, we identified two

786

J.P. García-Vázquez and M.D. Rodríguez

ways to digitally enhance home objects to create AIS for helping older adults to carry out their activities. Thus, we defined that AIS can be an aesthetic object or an enhanced tool in the elderly home. An aesthetic object while is embedded in are objects used to decorate homes or objects that older adult can wear, i.e., portraits, lamps and jewelry. An enhanced tool is an AIS embedded into the tools and/or instruments those older adults already use to perform their ADLs. The representation of WENOMA is considered an aesthetic object representation because it is embedded in a bracelet that the elderly wear as any other jewelry they normally wear.

Fig. 3. WENOMA states for supporting elderly’ medication adherence

4.3 Strategies of WENOMA for Support Older Adults with Their Medication Adherence Our wearable notification display (WENOMA) presents critical information that enables older adults to complete their medicating activity appropriately. To reach this end, we propose that the WENOMA system uses the following three strategies which are illustrated as states diagram of the system in figure 3: Reminding older adults they need to (a) take their medicines and (b) refill them on time. To do this, the display coaches the user by presenting critical information that enables them to carry out these two specific tasks, such as (a) doses to take and (b) doses left in the medicine container that is running out. If an older adult persists in not performing any of these two important tasks, the notification display will periodically remind and coach the user in order to persuade him to achieve their medicating routine.

5 Conclusions and Future Work The application of MedMaIDE in the case study allowed us to identify the common problems that older adults face to adhere to their medication prescription. Using Activity Theory was a valuable tool for analyzing the study data and identifying the objects and tools that older adults use to perform their activities and the members of

Ambient Information Systems to Support the Elderly in Carrying Out Their Activities

787

the elderly community that help them to carry out their activities. This enables us to propose AIS integrated in the objects and tools that elderly currently use for carrying out their activity or proposed new ones, as the Wearable Notification Display for Medication Adherence. We plan to consider the object and tools that elderly use to perform their medication adherence to propose new prototypes of AIS that support medication adherence, and identify other attributes of design. We will extend the case study by including other group of older adults to strengthen our results and validate the models of activity we have already obtained. We plan to carry out a usability evaluation of the WENOMA to support the medication adherence and evaluate the utility of the strategies incorporating into the system for reminding, coaches and persuading to older adults in their activities. Acknowledgment. I thank CONACyT for the scholarship granted, my co-advisor Angel G. Andrade and the members of my thesis committee. I also thank Adán Espinoza for his participation in the design of WENOMA, and especially I thank the older adults that participated in the case study.

References 1. Graf, B., Hands, M.J., Kubacki, S.R.D.: Robotic Home Assistant Care-O-Bot II, pp. 2343– 2344. IEEE, Los Alamitos (2002) 2. Aberg, J.: Dealing With Malnutrition: A Meal Planning System for Elderly. In: Proceedings of the AAAI Spring Symposium on Argumentation for Consumers of Health Care, Stanford University, CA, USA, pp. 1–7 (2006) 3. Demiris, G., Rantz, M., Aud, M., Marek, K., Tyrer, H., Skubic, M., Hussam, A.: Older adult’s attitudes towards and perceptions of smart home technologies: a pilot study. In: Medical Informatics, The Internet in Medicine, pp. 87–94 (2004) 4. Russo, J., Sukojo, A., Helal, S., Davenport, R., Mann, W.: SmartWave Intelligent Meal Preparation System to Help Older People Live Independently. In: Proceedings of the Second International Conference on Smart homes and health Telematic (ICOST 2004), Singapore (September 2004) 5. Hensel, B., Demiris, G., Courtney, K.: Defining Obtrusiveness in Home Telehealth Technologies: A Conceptual Framework. Journal of American Medical Informatics Associations, pp. 428–431 (2006) 6. Pousman, Z., Stasko, J.: A Taxonomy of Ambient Information Systems: Four Patterns of Design. In: Proceedings of the working conference on advanced visual interfaces, pp. 67– 74. ACM, Italy (2006) 7. Consolvo, S., McDonald, D.W., Toscos, T., Chen, M.Y., Froehlich, J., Harrison, B., Klasnja, P., LaMarca, A., LeGrand, L., Libby, R., Smith, I., Landay, J.A.: Activity Sensing in the Wild: A field Trial of Ubifit Garden. In: Proceedings of the Twenty-Sixth Annual SIGCHI, Conference on Human Factors in Computer Systems, pp. 1797–1806 (2008) 8. Jafarinaimi, N., Forlizzi, J., Hurst, A., Zimmerman, J.: An Ambient Display Designed to Change Human Behavior. In: Jafarinaimi, N., Forlizzi, J., Hurst, A., Zimmerman, J. (eds.) CHI 2005 Extended Abstracts on Human Factors in Computing Systems, pp. 1945–1948. ACM, New York (2005) 9. Mynatt, E.D., Rowan, J., Craighill, S., Jacobs, A.: Digital family portraits: supporting peace of mind for extended family members. In: Proceedings of the SIGCHI Conference on Human Factors Systems, pp. 333–340. ACM, New York (2001)

788

J.P. García-Vázquez and M.D. Rodríguez

10. Consolvo, S., Towle, J.: Evaluating an ambient display for the home. In: CHI 2005 Extended Abstracts on Human Factors in Computing Systems, pp. 1304–1307. ACM, New York (2005) 11. García-Vázquez, J.P., Rodríguez, M.D., Andrade, A.G.: Ambient Information Systems for Supporting Elder’s Independent Living at Home. In: International Workshop of Ambient Assisted Living (IWAAL 2009), pp. 702–705. Springer, Heidelberg (2009) 12. Matthews, T., Dey, A.K., Mankoff, J., Carter, S., Rattenbury, T.: A toolkit for Managing User Attention in Peripherals Displays. In: UIST 2004: Proceedings of the 17th annual ACM symposium on User interface software and technology, pp. 247–256. ACM, USA (2004) 13. McCrickard, D.S., Catrambone, R., Stasko, J.T.: Evaluating Animation in the Periphery as a Mechanism for Maintaining Awareness. In: Proceedings of the IFIP Conference on Human-Computer Interaction, Georgia Tech Institute, pp. 148–156 (2001) 14. Tomitsch, M., Kappel, K., Lehner, A., Grechenig, T.: Towards a Taxonomy for Ambient Information Systems. In: Workshop on the Issues of Designing and Evaluating Ambient Information Systems, CEUR Workshop Proceedings, Canada, May 13 (2007) 15. Kuutti, K.: Activity theory as a potential framework for human-computer interaction research. In: Nardi, B.A. (ed.) Context and Consciousness: Activity theory and HumanComputer interaction, pp. 17–44. Massachusetts Institute of Technology, Cambridge (1995) 16. Engestrom, Y.: Learning by expanding: an activity-theoretical approach to developmental research. Orienta-Konsultit, Helsinki (1987) 17. García-Vázquez, J.P., Rodríguez, M.D., Andrade, A.G., Saldaña, D., Ruelas, E., Mercado, F.: Ambient Information Systems for Supporting Ageing in Place. In: 6th International Conference on Information Technology: New Generations (ITNG 2009), pp. 1232–1237. IEEE, Los Alamitos (2009) 18. Lawton, M.P.: Aging and performance on home tasks, pp. 527–536. Human Factors and ergonomics society (October 1990) 19. Espinoza, A.-N., García-Vázquez, J.P., Rodríguez, M.D., Andrade, A.G., García- Peña, C.: Enhancing Wearable Help Button to Support the Medication Adherence of Older Adults. To appear in IEEE Proceedings of Latin-American Conference on Human-Computer Interaction, November 9-11 (2009) 20. Orwing, D., Brandt, N., Gruber-Baldini, A.L.: Medication Management Assessment for Older Adults in the Community, the Gerontologist, pp. 661–668 (2006)

K 4R – Knowledge to the Power of RESTful, Resourceful and Reactive Rules Ricardo Amador CENTRIA, Universidade Nova de Lisboa, Portugal http://centria.di.fct.unl.pt/

Abstract. The Web of today clearly answers questions of the form “What is the representation of ...?”. The Semantic Web (SW) of tomorrow aims at answering questions of the form “What is the meaning of ...?”. It is our stance that in order to realize the full potential of the original concept proposed by Tim Berners-Lee et al. (in Scientific American, May 2001), the SW must also answer, in a meaningful way, questions of a dynamic and active nature, like “What to do if ...?” or “What to do when ...?”. Moreover, SW questions of the form “What to do ...?” must be expressed and answered in a declarative, compositional and language agnostic way. It is our (hypo)thesis that formally established concepts, viz. the Web’s REST architectural style, declarative SW representation of resources based on Description Logics (e.g., OWL-DL), and Reactive Rules (e.g., “on Event if Condition do Action” –ECA– rules), provide the proper theoretical foundations to achieve this goal. This paper describes our current research proposal, K 4R (pronounced, with an Italian flavor, “Che fare?”), towards achieving a declarative model for expressing (re)active behavior in and for the SW.

1 Introduction Back in 2001, at the inception of the Semantic Web (SW), Tim Berners-Lee et al. [16] stated that the “real power of the Semantic Web will be realized when people create many programs that collect Web content from diverse sources, process the information and exchange the results with other programs”. About a year later, James Hendler et al. [26] identified “the critical emerging application of the discovery and combination of web services” as a key SW technology. Despite this early recognition of the relevance of active components for the success of the SW, some years later, in 2006, the recap of the available SW technology [37] does not include a single mention to such active components. How is “[common] people [expected to] create many programs” and consequently realize the “real power of the Semantic Web”? This question remains unanswered and still relevant. Though not mentioned in [37], much research effort has been dedicated in the last years towards enabling “the discovery and combination of web services” on a semantic level, e.g. [38]. The Semantic Web Services (SWS) Community has submitted several proposals to the W3C, viz. OWL-S, WSMO, SWSF and WSDL-S. To the present, the only W3C Recommendation concerning SWS is SAWSDL which contemplates only the semantic annotation of Web Services (WS). Such annotation makes functional building blocks (i.e. services) closer to the common user, but in the end current results R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 789–799, 2009. c Springer-Verlag Berlin Heidelberg 2009 

790

R. Amador

of the SWS approach do not relieve the common user of the burden of actually integrating those building blocks into tailored functional units of behavior. For this purpose, the SWS Community suggests automatic service composition though recognizing that “the Web service environment is highly complex and it is not feasible to generate everything in an automatic way” [36]. Let’s take a “trivial example”, from [16], which “occurs when Pete [a common user] answers his phone and the stereo sound is turned down”. The building blocks for this behavior might be available as specialized services, viz. an event detection service that detects that Pete has answered his phone, a query service capable of collecting local devices with a volume control, and an active service that actually turns down the volume of such devices. Those services may be describable and discoverable on a semantic level, which makes Pete’s task much easier. But how is Pete to say how he wants to use those services in order to achieve such a basic behavior? Pete is not a programmer, otherwise he would program a tiny service for that purpose. Pete does not know how to computationally achieve the behavior he wants, he only knows what is the desired behavior: “when a call is answered if there are devices to turn down then turn them down”. Pete does not see this simple statement as an instance of a business workflow or as the result of some careful planning process. For Pete this statement is as simple as the rules he uses in his e-mail application to organize the messages he sends/receives. Pete’s intuition is correct. His statement has an obvious rewrite into a form of rules with a known declarative semantics: Event-Condition-Action (ECA) Rules. As such, Pete shouldn’t need to program anything, all he should do is state the rule(s) of behavior that he wants his SW agent1 to honor. Providing the formal foundations that will allow Pete to do just that is the research challenge that we propose to address with the present research proposal. In the following, we start by clearly stating our research goal (Sect. 2), summing up other efforts related to it (Sect. 3), and proposing a concrete work plan to achieve our goal (Sect. 4). Section 5 further details how preliminary results lead us to the current proposal, and Sect. 6 discusses the originality and potential contribution of our proposal. Sect. 7 concludes the paper.

2 Objectives Reactive Rules (RR) may be partitioned into Reactive Derivation Rules and Active Rules (cf. [2]). The former account for the definition of complex events/actions in terms of simpler ones and for establishing causal relationships from actions to events. The latter establish if and when to perform actions, and may take several forms, viz. Production Rules (PR) and several variations of ECA Rules. PR have the general form ‘if Condition then Action’, and are commonly mistaken for Logical Derivation Rules, whose declarative semantics they do not share. The most common form of ECA Rules is ‘on Event if Condition do Action’ but other forms, like ECAP (which includes a post-condition to 1

The term ‘agent’ is used in this paper in the same general sense as used in [16] or in [38], i.e. “as any software entity, possibly with problem-solving capabilities, including intelligent autonomous agents [27]”.

K 4R – Knowledge to the Power of RESTful, Resourceful and Reactive Rules

791

be verified after the action) and EC n An (with several guarded actions), have also been proposed. The general Research Goal addressed by the present proposal: – includes the definition of a computational model, based on RR, that will provide proper formal foundations to allow common people, lacking programming skills, to declaratively express (re)active behavior in and for the SW; – excludes the (re)search for proper tools that are mandatory to make such a formal model actually usable by common people. This general challenge, previously motivated in Sect. 1, is to be pursued under the following Research Constraints: 1. any expression of behavior in the SW should be transparent at the semantic level; 2. any expression of behavior in the SW should be made available, both at specification and evaluation time, in full conformance with the Web’s REST architectural style [23] as instantiated by the Web’s architecture and its HTTP2 protocol; 3. expressions of behavior not obeying the previous constraints must not be excluded. These constraints state that our (re)search must be for a computation model that is both Resourceful and RESTful, but must not withstand backward compatibility with current expressions of Web behavior (e.g. WS). Before proceeding, it is relevant to emphasize and clarify the actual implications of such constraints given our research goal: – SW Reactive Rules should be fully transparent SW Resources with a mandatory abstract and formal Representation, i.e. the search is not for (yet) another XML markup for (reactive) rules, instead an OWL ontology is to be delivered; – SW Reactive Rules should be Web Resources, i.e. they must be URI addressable (if persistent3 ) and accommodate distinct concrete Representations; – full SW transparency must not be mandatory, semantical opacity must be allowed at all levels but always in a controlled way, e.g. a Reactive Rule component, like an event specification, must be allowed to be expressed in a SW opaque way —using some concrete markup or textual syntax— but its nature and interface must always be fully transparent; – all the Resources included in our computational model must honor the REST uniform interface of the Web, i.e. the functionality of the computational model is to be instantiated into HTTP methods in full compliance with the HTTP specification; – any extension to this uniform interface must be taken as a last resort to be avoided; if absolutely required, such extension, in order to be considered, must be properly identified, justified and rooted in proper theoretical foundations (e.g. [23,29]). It is our stance that the previously stated goal is achievable under these constraints, i.e. HTTP, with a proper SW definition of Resources and the available standard Web representations, is more than enough to achieve our goal. SWS have their role to play when it comes down to actually specify, e.g., actions; however, a general model of Reactive Rules should be achievable without resorting to SWS. 2 3

HTTP - HyperText Transfer Protocol, http://w3.org/Protocols. Unidentified resources are part of the SW, viz. RDF blank nodes. How to conciliate unidentified resources with the REST notion of (identified) resources is still an open challenge, as recent W3C notes show (e.g., Cool URIs for the Semantic Web, http://w3.org/TR/cooluris).

792

R. Amador

3 Related Work The need to contemplate reactive behavior in the Web seems to be an undisputable matter. The clear recognition of such need dates, at least, back to 19984. Throughout the years it has motivated several proposals on different levels and from different communities. The REST [23] community is aware of this open matter both on pragmatical5 and theoretical levels (e.g. [29]). The WS community has even issued several standard proposals, cf. [40,39]. Proper standardization is still an open matter. ECA Rules were intensively studied in the field of Active Databases (ADBMS), cf. [35], and are currently used in different fields like Workflow Management (WfMS), e.g. [30,11], and Multi-Agent Systems (MAS), e.g. [14,28]. In the MAS field [18] there are also attempts towards defining general models for evolution and reactivity including declarative approaches like [22,8]. ECA Rules were first proposed in the context of the SW back in 2003 [34], following previous XML-based proposals [12]. In the following years, between 2004 [33,21] and 2008 [9], considerable effort was dedicated, within WG-I56 of the R EWERSE project, in order to achieve a model for evolution in the SW based on reactivity. This effort contemplated two distinct approaches: a language homogeneous approach instantiated into a concrete ECA rule language for the SW, viz. XChange7 [20,19], and a language heterogeneous approach based on a general framework for ECA Rules in the SW [32,31]. The latter led to the development of two prototypes: MARS8 [13,25] and r3 [41,2]. MARS followed a markup-based approach where, e.g., languages are identified by XML namespaces, whereas r3 followed an ontology-based approach where, e.g., languages and language symbols are OWL individuals. Production Rules have also been proposed, as an alternative to ECA Rules [17], to model (re)active behavior in and for the Web. Standardization of different forms of Reactive Rules is currently under consideration by three standard bodies, viz. W3C9 , OMG10 and RuleML11 .

4 Work Plan In order to effectively pursue our research goal, previously stated in Sect. 2, the following Research Hyphoteses have been formulated and require confirmation: 1. RR are describable on an abstract/semantic level using currently standardized SW formalisms, i.e. RR can be true SW Resources; 4

5 6 7

8 9 10 11

WISEN Workshop on Internet Scale Event Notification, July 13-14, 1998, University of California, Irvine (UCI), USA, http://www.isr.uci.edu/events/twist/wisen98/. HTTP Subscription, http://rest.blueoxen.net/cgi-bin/wiki.pl?HttpSubscription. R EWERSE WG I5 Evolution and Reactivity, http://rewerse.net/I5. XChange: A rule-based language for programming reactive behavior on the Web, http://rewerse.net/I5/XChange. MARS: Modular Active Rules for the Semantic Web, http://rewerse.net/I5/MARS. RIF Production Rule Dialect (RIF-PRD), http://w3.org/TR/rif-prd. Production Rule Representation (PRR), http://www.omg.org/spec/PRR. Reaction RuleML, http://ibis.in.tum.de/research/ReactionRuleML.

K 4R – Knowledge to the Power of RESTful, Resourceful and Reactive Rules

793

2. such an abstract model of RR is an open model that embraces language heterogeneity, neither mandating nor excluding any specific concrete representation (e.g. some concrete markup); 3. such an abstract model fulfils the role of abstract syntax for the purpose of defining the semantics of RR; 4. RR provide a model of behavior for the SW with a declarative semantics; 5. such a declarative semantics is computationally groundable, or at least has a functionally equivalent computational model; 6. such a computational model/grounding is realizable in full conformance with the Web instantiation of the REST architectural style. To attain confirmation of the previous hypotheses a Research Work Plan with three phases is proposed: 1. Feasibility Assessment. Achieve thorough understanding of RR on a computational level and in the context of the SW; additionally formulate a first proposal for an abstract description of RR using standardized Web formalisms. 2. Declarative Definition. Formal definition of a declarative semantics for RR based on an abstract syntax formalized using some form of Description Logic; evaluation of results with respect to the proposed hypotheses. 3. Operational Implementation. Computational grounding of declarative semantics; evaluation of results with respect to related work and results of the previous phase. To realize the previous work plan different Research Methods12 will be used in accordance with the nature of each phase: – phases 1 and 3 are to be supported by the implementation of prototypes, and proper definitions based on Web standards (e.g. OWL ontologies and XML markups); – phase 2 is to be supported by appropriate theoretical formalisms, viz. Model-theoretic semantics, Fixpoint Semantics, Kripke Structures and Description Logics; – phase 3 may also require the support of theoretical formalisms for the definition of operational semantics, e.g. Transition Systems and Abstract State Machines; – all phases are to be validated before proceeding to the next phase; – phase 1 validation is to be realized against realistic application scenarios (e.g., [7]), by integrating different concrete languages (e.g., SPARQL, XQuery, WSDL2), as required by those scenarios; – phase 2 shall be validated against existing rule standards (e.g., CL, JSR-94, PRR, RIF-BLD, RIF-PRD, RuleML) both for abstract syntax and semantics adequacy; phase 2 validation must identify any deviation from the research hypotheses, and any unavoidable deviation must be properly justified at this point; – phase 3 is to be validated both on a pragmatical and theoretical level; on a pragmatical level, phase 3 prototype is to be validated for its Web RESTfulness and expressiveness against the scenarios of phase 1, and integration with other reactive platforms (e.g., EVOLP, MARS, Protune, ruleCore, XChange) is to be attempted; on a theoretical level, the computational grounding (as implemented by phase 3 prototype) is to be demonstrated to be conformant with the declarative semantics which resulted from phase 2. 12

Together with [6] and the development infrastructure for the prototypes, the items mentioned between brackets constitute the most relevant Research Material required.

794

R. Amador

5 Current State The present work started in 2005, when we first joined project R EWERSE. At that point we had a WIDER13 view of the challenge here presented. Such a WIDER view was targeted at the full research goal introduced in Sect. 2. It contemplated no exceptions, in fact our main focus was to be on tools themselves, not on the formal foundations. Throughout the duration of the R EWERSE project we attained a better understanding of the actual complexity of our WIDER goal. After careful evaluation of the results of the project we came to the conclusion that we needed to focus on defining a formal declarative model, leaving WIDER perspectives open for the future. Most of the results currently available were obtained within the R EWERSE project. Besides the author’s key contribution towards defining the heterogeneous and ontology-based approach of R EWERSE WG-I5, his main contribution to R EWERSE was r3 (i.e. Resourceful Reactive Rules). r3 is a prototype of a SW Rule Engine for ECA Rules which is capable of dealing with rules that use different languages either at the rule component level (event, condition, action), or within each component (by algebraic composition, based also on different algebraic languages). Such languages may range from general purpose to domain/application specific languages. At the heart of the r3 prototype is the decision to fully embrace the SW and base its implementation on an RDF model. Every resource that matters to an r3 engine is to be described using terms defined by a foundational OWL-DL ontology. Natively r3 “talks” RDF/XML (using HTTP POST for communication, SOAP wrapped or not), but any other XML serialization of an RDF model is acceptable, provided an appropriate (bi-directional) translator is available (or implemented). Any request received by an r3 engine is expected to be translated into an RDF model which is then added to an internal ontology that includes every resource known to a particular r3 engine. This internal ontology must also be dynamically completed by means of automatic retrieval of missing pieces of information directly from the SW. Each r3 engine directly supports a static set of languages. A Java library that abstracts, e.g., translation and communication details is available to help the integration of different languages as (static) components of an r3 engine, either by implementing them from scratch or by wrapping existing implementations. More importantly, the set of languages supported by an r3 engine is dynamically extendable live on the SW. Every r3 engine is exposed online as an RDF resource. As soon as an r3 engine becomes aware of another r3 engine, the former fetches the RDF description of the latter which includes all the languages it supports (directly or indirectly). Consequently the former becomes a broker that indirectly supports also the languages supported by the latter. r3 is available online (cf. [41]) including the integration of several languages, viz. EVOLP, HTTP, Protune, Prova, SPARQL, Xcerpt, XChange, XPath, XQuery, XSLT, and some utilities (e.g. send mail actions). Since the first draft of our approach [5], all the main r3 results were refereed and published [32,31,1,2]. A detailed account of those (and other more technical) results is included in [3] together with a detailed description of the realistic use-cases that were used to validate r3 (e.g., [24]). The work described in [4], that led to the integration of 13

Web

Integrated

Development

tools

for

http://code.google.com/p/wider3/wiki/WIDER.

Evolution

and

Reactivity

(WIDER),

K 4R – Knowledge to the Power of RESTful, Resourceful and Reactive Rules

795

Protune, introduces the general –and novel– concept of reactive SW policies and gave us the opportunity to further complement our validation of r3 heterogeneity after the end of R EWERSE. Evaluation. Phase 1 of the proposed work plan is completed and validated. Following the research methods proposed in Sect. 1, all the objectives were accomplished, namely: a prototype of an ECA engine for the SW is available [41]; an OWL-DL ontology for RR is available [2]; and both the prototype and the ontology have been validated against realistic application scenarios (e.g., [24]) realized through the proper integration and use of several languages [3]. Most notably, and as far as we know, the results included in [2] constitute the only attempt to formally define and classify RR in an ontology. Nevertheless, the POSTbased API used by r3 does extend this ontology by adding concepts like Message (cf. [3]), thus introducing an undesirable level of complexity that comes close to a serviceoriented approach; a clear resource-oriented (REST) approach will certainly reduce that complexity and avoid such r3 specific concepts. Work on phase 2 has started. The integration of r3 with EVOLP and Protune raised some unanswered issues like representing explanations and answer-set models; the classification of RR included in [2] does not exclude (re)active forms of derivation rules which r3 does not support; these issues when considered together under a clear REST constraint of a uniform interface (i.e. HTTP); led us to the conclusion that the declarative level envisaged for phase 2 required a more general definition of SW Knowledge Resources on an ontological level. For this purpose we have already defined the KR2RK ontology [10]. This ontology is yet to be integrated with [2] and properly validated against existing rule standards. That is the focus of our current work together with the definition of a declarative semantics that uses KR2RK as its abstract syntax.

6 Discussion Reactive Rules provide a declarative and loosely-coupled model of behavior which, given the proper tools, may empower the common user to define tailored behaviors in and for the SW. This claim is supported by the success of PR in different fields of expertise, even if they express no declarative model of behavior. It is our stance that there is a semantical ambiguity in the condition component of PR that hinders their declarativeness: it is not clear if a Production Rule expresses an action to be taken when something is true or when something becomes true. From our point of view, this ambiguity is at the core of most semantical discrepancies among different PR implementations. The declarativeness of ECA Rules is much clearer and their current use by common users in specific fields, like mailbox management, is quite promising. Since 2000 [15], the great majority of SW research efforts have been concentrated on querying the SW. Matters like evolution and (re)active behavior, though unanimously accepted as relevant in the context of the SW, seem to be forgotten. In this general state of affairs a few exceptions exist and are worth mentioning: the work of the SWS community, the work of WG-I5 of project R EWERSE, and the efforts of the MAS community to demonstrate applicability of their results to the SW. Nevertheless when confronted with pragmatical choices most of these efforts seem to ignore that the SW is

796

R. Amador

being built on strong theoretical concepts, namely REST and (logical) Knowledge Representation. When it comes down to make things work, foundational research work in the field of SW Evolution seems to be ruled by service-oriented and markup-based approaches, when it should be ruled by resource-oriented and ontology-based approaches. Oddly enough, we have come to a point where most standardization efforts concerning SWS are ontology-based, whereas all standardization efforts concerning rule languages for the Web, viz. RIF and RuleML, are mainly concerned with providing syntactical representations (i.e markups). An ontology-based approach is particularly relevant if RR are to embrace language heterogeneity thus allowing, e.g., the use of domain/application specific languages that express concepts familiar to the user. Nevertheless, concrete representations of RR are required for this purpose. Among others, such concrete representations may be verbal, textual, graphical or markup-based; the SW supports all of them provided that eventually they are transparent on an abstract/semantical level. Such an abstract/semantical representation is in fact the only mandatory representation for SW Resources, and it is our stance that SW Rules are first of all SW Resources describable on logical terms like any other SW Resources. Both r3 and MARS demonstrate that such an heterogeneous and ontology-based approach is feasible. We are not aware of any other effort that comes close to modeling RR in such a language agnostic way. The most common approach to model RR, in the context of the SW, is to define a concrete rule language, thus limiting at the syntactical level the reactive expressiveness provided at the semantical level. A quick look at the specification of other proposals for (re)active rule languages for the SW, like RIF-PRD or XChange, is enough to identify a typical part of the syntactical specification where the supported events and actions are enumerated. In some cases, the provision for external actions and events is included, thus implying the use of some specific protocol. We are not aware of any proposal that relies on a RESTful approach for this purpose, i.e. none of the current proposals assumes that there is already a Web protocol (HTTP) which constitutes the uniform interface of the Web and that in order to use this protocol all that is required is the definition of resources and representations. Modeling RR as true SW Resources includes acknowledging that they are also Web Resources that should honor HTTP has their uniform REST interface. We believe that no other protocol or interface, e.g. WS, is required to use RR as a general model of integration for SW behavior. Contrasting with MARS (and with all other proposals) our proposal clearly makes two choices: REST and SW Resources. We are not concerned with services or with concrete resource representations. The declarative, heterogeneous, ontological and RESTful nature of our proposal, to model reactive behavior in and for the SW, make it a unique proposal in the current SW state-of-the-art.

7 Conclusion The Web of today clearly answers questions of the form “What is the representation of ...?”. The Semantic Web (SW) of tomorrow aims at answering questions of the form “What is the meaning of ...?”. It is our stance that, in order to realize the full potential

K 4R – Knowledge to the Power of RESTful, Resourceful and Reactive Rules

797

of the original SW concept proposed in [16], the SW must also answer, in a meaningful way, questions of the form “What to do ...?”. Such questions must be expressed and answered in a declarative, compositional and language agnostic way. It is our (hypo)thesis that formally established concepts, viz. the Web’s REST architectural style, declarative SW representation of resources based on Description Logics (e.g., OWL-DL), and Reactive (e.g., ECA) Rules, provide the proper theoretical foundations to achieve this goal. Based on this hypothesis, in this paper we have presented our research proposal towards achieving a declarative model for expressing (re)active behavior in and for the SW. Reactive Rules provide a loosely-coupled model of behavior and a component structure particularly suited to allow the semantically transparent expression of tailored behaviors through the composition of behavior fragments expressed using different languages. Given the proper tools and domain specific languages, that express concepts familiar to common users, such a model may even empower common users to define themselves the (rules of) behavior of their own personal (or professional) SW agents as envisaged in [16]. Since 2005, within R EWERSE WG-I5, we have been “maturing” our language agnostic and ontology-based approach to Evolution and Reactivity in the SW, and a considerable amount of (preliminary) results has been achieved (cf. Sect. 5). These results have demonstrated that our approach is feasible. More recently, after R EWERSE, it became clear to us that the service-oriented complexity of these results was not mandatory. In fact, the most recent evolutions of our work (yet to be validated, cf. also Sect. 5), strongly suggest that by adding REST constraints to our approach, and consequently re-using the Web’s uniform interface, we will be able to drop concepts of a more operational nature (e.g. Message, Service and Interface). To properly apply a REST approach more meaningful resources are required and those resources are the concepts that matter the most. For this purpose we have chosen to broaden the scope of our ontology-based approach, and extend it –on a general level– to other domains of Knowledge Representation (KR). The goal is not to model the specificities of every KR paradigm, but instead to establish a general foundational layer for KR supporting a resource-oriented approach, and then focus on the specificities of the paradigm of rule-based reactivity. The interested reader may find future evolutions of K 4R online at http://k4r.googlecode.com/. Acknowledgements. This research has been funded, until Feb. 2008, by the European Commission and by the Swiss Federal Office for Education and Science within the 6th Framework Programme project R EWERSE number 506779. Since March 2008, the author acknowledges the financial support of the Portuguese “Fundac¸a˜ o para a Ciˆencia e a Tecnologia” under “Programa Operacional Sociedade do Conhecimento”. All the work presented and proposed here has been supervised by Prof. Dr. Jos´e J´ulio Alferes, who acts as principal advisor for the doctoral studies of the author.

References 1. Alferes, J.J., Amador, R.: Towards a foundational ontology for reactive rules. In: ESWC 2007 (2007), http://www.eswc2007.org/posters.cfm 2. Alferes, J.J., Amador, R.: r 3 - a foundational ontology for reactive rules. In: Meersman, R., Tari, Z. (eds.) OTM 2007, Part I. LNCS, vol. 4803, pp. 933–952. Springer, Heidelberg (2007)

798

R. Amador

3. Alferes, J.J., Amador, R., Behrends, E., Franco, T., Fritzen, O., Krippahl, L., May, W., Schenk, F.: Prototype on the RDF/OWL level (2007), http://rewerse.net/deliverables/m42/i5-d9.pdf 4. Alferes, J.J., Amador, R., K¨arger, P., Olmedilla, D.: Towards reactive semantic web policies: Advanced agent control for the semantic web. In: Bizer, C., Joshi, A. (eds.) ISWC 2008 (Posters & Demos). CEUR-WS.org, vol. 401 (2008) 5. Alferes, J.J., Amador, R., May, W.: A general language for evolution and reactivity in the semantic web. In: Fages, F., Soliman, S. (eds.) PPSWR 2005. LNCS, vol. 3703, pp. 101– 115. Springer, Heidelberg (2005) 6. Alferes, J.J., Bailey, J., Berndtsson, M., Bry, F., Dietrich, J., Kozlenkov, A., May, W., Patranjan, P.-L., Pinto, A.M., Schroeder, M., Wagner, G.: State-of-the-art on evolution and reactivity (2004), http://rewerse.net/deliverables/i5-d1.pdf 7. Alferes, J.J., Berndtsson, M., Bry, F., Eckert, M., Henze, N., May, W., Patranjan, P.-L., Schroeder, M.: Use-cases on evolution, and reactivity (2005), http://rewerse.net/deliverables/m12/i5-d2.pdf 8. Alferes, J.J., Gabaldon, A., Leite, J.: Evolving logic programming based agents with temporal operators. In: IAT, pp. 238–244. IEEE, Los Alamitos (2008) 9. Alferes, J.J., May, W., Eckert, M.: Evolution and Reactivity in the Semantic Web. In: Semantic Techniques for the Web, The Rewerse Perspective. LNCS, vol. 5500. Springer, Heidelberg (2009) 10. Amador, R., Alferes, J.J.: Knowledge resources towards RESTful knowledge (March 2009), http://k4r.googlecode.com/files/200903_kr2rk.pdf 11. Bae, J., Bae, H., Kang, S.-H., Kim, Y.: Automatic control of workflow processes using eca rules. IEEE Trans. Knowl. Data Eng. 16(8), 1010–1023 (2004) 12. Bailey, J., Poulovassilis, A., Wood, P.T.: An event-condition-action language for XML. In: WWW 2002. ACM, New York (2002) 13. Behrends, E., Fritzen, O., May, W., Schubert, D.: An ECA engine for deploying heterogeneous component languages in the semantic web. In: Grust, T., H¨opfner, H., Illarramendi, A., Jablonski, S., Mesiti, M., M¨uller, S., Patranjan, P.-L., Sattler, K.-U., Spiliopoulou, M., Wijsen, J. (eds.) EDBT 2006. LNCS, vol. 4254, pp. 887–898. Springer, Heidelberg (2006) 14. Berndtsson, M., Chakravarthy, S., Lings, B.: Result sharing among agents using reactive rules. In: Kandzia, P., Klusch, M. (eds.) CIA 1997. LNCS, vol. 1202, pp. 126–137. Springer, Heidelberg (1997) 15. Berners-Lee, T.: Opening Keynote: RDF and the Semantic Web. XML 2000, Washington, DC (December 2000) 16. Berners-Lee, T., Hendler, J., Lassila, O.: The semantic web. Scientific American, 29–37 (May 2001) 17. Berstel, B., Bonnard, P., Bry, F., Eckert, M., Patranjan, P.-L.: Reactive rules on the web. In: Antoniou, G., Aßmann, U., Baroglio, C., Decker, S., Henze, N., Patranjan, P.-L., Tolksdorf, R. (eds.) Reasoning Web. LNCS, vol. 4636, pp. 183–239. Springer, Heidelberg (2007) 18. Bordini, R.H., Braubach, L., Dastani, M., Fallah-Seghrouchni, A.E., G´omez-Sanz, J.J., Leite, J., O’Hare, G.M.P., Pokahr, A., Ricci, A.: A survey of programming languages and platforms for multi-agent systems. Informatica (Slovenia) 30(1), 33–44 (2006) 19. Bry, F., Eckert, M.: Rule-based composite event queries: The language xchangeEQ and its semantics. In: Marchiori, M., Pan, J.Z., Marie, C.d.S. (eds.) RR 2007. LNCS, vol. 4524, pp. 16–30. Springer, Heidelberg (2007) 20. Bry, F., Eckert, M., Patranjan, P.-L.: Reactivity on the web: Paradigms and applications of the language xchange. J. Web Eng. 5(1) (2006) 21. Bry, F., Furche, T., Patranjan, P.-L., Schaffert, S.: Data retrieval and evolution on the (semantic) web: A deductive approach. In: Ohlbach, H.J., Schaffert, S. (eds.) PPSWR 2004. LNCS, vol. 3208, pp. 34–49. Springer, Heidelberg (2004)

K 4R – Knowledge to the Power of RESTful, Resourceful and Reactive Rules

799

22. Costantini, S., Tocchio, A.: A logic programming language for multi-agent systems. In: Flesca, S., Greco, S., Leone, N., Ianni, G. (eds.) JELIA 2002. LNCS (LNAI), vol. 2424, pp. 1–13. Springer, Heidelberg (2002) 23. Fielding, R.T.: Architectural Styles and the Design of Network-based Software Architectures. PhD thesis, University of California, Irvine (2000) 24. Franco, T., Alferes, J.J., Krippahl, L., Amador, R.: Bio-informatics reactivity features through the semantic web. In: Burger, A., Paschke, A., Romano, P., Splendiani, A. (eds.) SWAT4LS 2008. CEUR-WS.org, vol. 435 (2008) 25. Fritzen, O., May, W., Schenk, F.: Markup and component interoperability for active rules. In: Calvanese, D., Lausen, G. (eds.) RR 2008. LNCS, vol. 5341, pp. 197–204. Springer, Heidelberg (2008) 26. Hendler, J., Berners-Lee, T., Miller, E.: Integrating applications on the semantic web. Journal of the Institute of Electrical Engineers of Japan 122(10), 676–680 (2002) 27. Jennings, N.R., Sycara, K.P., Wooldridge, M.: A roadmap of agent research and development. Autonomous Agents and Multi-Agent Systems 1(1), 7–38 (1998) 28. Jiang, L., Liu, D.y.: A survey of multi-agent coordination. In: Arabnia, H.R. (ed.) ICAI 2006, pp. 65–71. CSREA Press (2006) 29. Khare, R.: Extending the Representational State Transfer (REST) Architectural Style for Decentralized Systems. PhD thesis, University of California, Irvine (2003) 30. Knolmayer, G., Endl, R., Pfahrer, M.: Modeling processes and workflows by business rules. In: van der Aalst, W.M.P., Desel, J., Oberweis, A. (eds.) Business Process Management. LNCS, vol. 1806, pp. 16–29. Springer, Heidelberg (2000) 31. May, W., Alferes, J.J., Amador, R.: Active rules in the semantic web: Dealing with language heterogeneity. In: Adi, A., Stoutenburg, S., Tabet, S. (eds.) RuleML 2005. LNCS, vol. 3791, pp. 30–44. Springer, Heidelberg (2005) 32. May, W., Alferes, J.J., Amador, R.: An ontology- and resources-based approach to evolution and reactivity in the semantic web. In: Meersman, R., Tari, Z. (eds.) OTM 2005. LNCS, vol. 3761, pp. 1553–1570. Springer, Heidelberg (2005) 33. May, W., Alferes, J.J., Bry, F.: Towards generic query, update, and event languages for the semantic web. In: Ohlbach, H.J., Schaffert, S. (eds.) PPSWR 2004. LNCS, vol. 3208, pp. 19–33. Springer, Heidelberg (2004) 34. Papamarkos, G., Poulovassilis, A., Wood, P.T.: Event-condition-action rule languages for the semantic web. In: Cruz, I.F., Kashyap, V., Decker, S., Eckstein, R. (eds.) SWDB 2003 (2003) 35. Paton, N.W. (ed.): Active Rules in Database Systems. Springer, New York (1999) 36. Rao, J., Su, X.: A survey of automated web service composition methods. In: Cardoso, J., Sheth, A.P. (eds.) SWSWPC 2004. LNCS, vol. 3387, pp. 43–54. Springer, Heidelberg (2005) 37. Shadbolt, N., Hall, W., Berners-Lee, T.: The semantic web revisited. IEEE Intelligent Systems Journal, pp. 96–101 (May/June 2006) 38. Sycara, K.P., Paolucci, M., Ankolekar, A., Srinivasan, N.: Automated discovery, interaction and composition of semantic web services. J. Web Sem. 1(1), 27–46 (2003) 39. Vinoski, S.: More web services notifications. IEEE Internet Computing 8(3), 90–93 (2004) 40. Vinoski, S.: Web services notifications. IEEE Internet Computing 8(2), 86–90 (2004) 41. Resourceful Reactive Rules (r3 ), http://rewerse.net/I5/r3

Automatic Construction of a Semantic, Domain-Independent Knowledge Base David Urbansky University of Technology Dresden, Department of Computer Science [email protected]

Abstract. In this paper, we want to show which difficulties arise when automatically constructing a domain-independent knowledge base from the web. We show possible applications for such a knowledge base to emphasize its importance. Current knowledge bases often use manuallybuilt patterns for extraction and quality assurance which does not scale well. Our contribution to the community will be a technique to automatically assess extracted information to ensure high quality of the information and a method of how the knowledge base can be kept up to date. The research builds upon the existing WebKnox system for Web Knowledge Extraction which is able to extract named entities and facts from the web. This is a position paper.

1

Introduction

The web hosts millions of information pieces and is still growing at a rapid pace. No single human can have an overview of all web pages and the information they provide, thus, the trend towards a machine “understandable” web has been proposed in the semantic web initiative [3]. If machines can read, “understand” (disambiguate) and aggregate information pieces from many different sources, the human can consume the desired information much faster. In different knowledge domains the approaches for retrieving and extracting knowledge can vary. This requires more human effort in configuring the extraction system. We want to minimize the human effort and therefore need a generic system that automatically builds a structured knowledge base from the information that is available on the web. Such a knowledge base has many possible applications. We pick two application domains which seem most important for our research: 1. Entity Dictionary for Information Enrichment. Imagine the possible scenario: A user reads the name of a movie that he does not know on a web page, he or she might leave the page and search for the movie on a search engine to learn more about it. If we have a large knowledge base with semantic information about entities (such as movies or persons), we can recognize and enrich them for a human user. In the described scenario, we could find additional information such as the director or release date of the mentioned movie and provide the user with this information directly on R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 800–804, 2009. c Springer-Verlag Berlin Heidelberg 2009 

Automatic Construction of a Semantic, Domain-Independent Knowledge Base

801

the web page. Since the information from the knowledge base is semantic, we could also disambiguate entity names, that is, we would provide information about the person “Queen Elizabeth II” on a web page about the English queen and information about the ship “Queen Elizabeth II” on a web page about travel and cruise ships. 2. Repository for the Semantic Web. In the vision of the semantic web [3], the information on the web is becoming more machine readable. This allows many new applications, that the human end user can benefit from. Today, many domain ontologies have been created and connected (DBPedia, MusicBrainz etc.) in order to allow machines to reason over that information and gain new insights for the human. The desired knowledge base will be centralized, connected to existing ontologies and thus, be a part of open information for the semantic web. The ontology will be represented in RDF(S) and OWL and users can query the knowledge base using SPARQL. The remainder for this paper is structured as follows. First, we review systems for information extraction, aggregation and knowledge base building. Second, we describe shortcomings of these systems, third, we pose research questions and explain how we want to address these shortcomings in the future, fourth, we describe the current state of WebKnox (Web Knowledge eXtraction), a system for information extraction from the web, and finally we conclude the paper with an outlook on the working plan.

2

Related Work

In this section, we review several significant domain-independent information extraction systems and knowledge bases. KnowItAll [5], TextRunner [2], GRAZER [11] and Set Expander for Any Language [9] are domain-independent, information extraction systems that automatically extract entities and facts from the web. All of these systems are mainly redundancy-based, that is, that they rely on the assumption that a fact or entity occurs many times on the web. For ensuring a high precision of the extracts, assessment mechanisms such as statistical methods or graph algorithms are used. Freebase1 , DBpedia[1], YAGO[6], Wolfram Alpha2 and True Knowledge3 are semantic knowledge bases. In contrast to the first group of systems, these knowledge bases were constructed using domain- or website specific extraction algorithms. Freebase, Wolfram Alpha and TrueKnowledge rely on human user input to keep information up to date. The other knowledge bases are kept up to date by regularly re-indexing their information. All of the mentioned systems and knowledge bases have insufficiencies in one or more of the following areas that we want to address with WebKnox. First 1 2 3

http://www.freebase.com, accessed 16/08/2009 http://www.wolframalpha.com, accessed 16/08/2009 http://www.trueknowledge.com, accessed 16/08/2009

802

D. Urbansky

of all, we can not only rely on a few sources and human editors if we want to have a broad knowledge base, that is, we need to treat all web pages as possible sources of information. Second, we need to store the extracted information semantically, third, we need to automatically assess extracted information ensuring high quality of the knowledge base and finally we need to find efficient, automatic techniques to keep the knowledge base up to date. In the following section, we pose the research questions that address these requirements.

3

Research Questions and Approaches

How can we ensure high precision of the extracted information? Since we want as little human involvement as possible assessing the extractions in the knowledge base, we must ensure that uncertain extractions are automatically ranked by their confidence, that is, we need to find and evaluate “trust” measures for sources and extractions. Several approaches have been used in current state-of-the-art systems, such as URNS [4], Pointwise-Mutual-Information (PMI) [5], Random Graph Walk [9] and using search engine rankings and duplication information [10]. In [8], we have proposed a self-supervised machine learning algorithm for scoring fact extractions. We now want to explore how good similar machine learning classification algorithms perform on extracted entities. For example, if the movie entity “The Dark Knight” was extracted many times, using several of the entity extraction techniques, we should have a higher confidence in its correctness as if it was only extracted once from one single source. Also textual features such as capitalization of the names can help classifying entities. How can we keep the knowledge base up to date? Unlike humans, an automated system can read millions of documents each day. That enables the system to find and extract new knowledge faster. We want to investigate into automatically reading news feeds (blogs, forums etc.) to extract new knowledge. For example, letting WebKnox read thousands of news feeds about movies and cinema, we could extract information about the upcoming movie “Iron Man 2” very quickly when a news item states “[...]has signed for the upcoming movie Iron Man 2[...]”. Where and how can we find new entities? Currently, our system uses three retrieval and extraction techniques to find and extract entities for known concepts from the web [7]. So far, we evaluated the entity extraction only on popular concepts such as mobile phones or countries. To find entities for more obscure concepts such as cookies, perfumes or pencils we need to find other mechanisms. One approach in this direction is to analyze user queries for possible unknown entities. For example, if we know the concept “cookie” and the query “calories Banana Split Creme Oreo” is received, we could try to find out that “calories” is an attribute of the “cookie” concept and the rest of the query is an entity. Also, we will investigate whether domain specific databases from the Deep Web can help finding new entities.

Automatic Construction of a Semantic, Domain-Independent Knowledge Base

4

803

Current State of WebKnox

WebKnox is divided into two main extraction processes as shown in Figure 1. First, the entity extraction process gets a set of predefined concept names as input (for example “Movie”, “Mobile Phone“ or “Country”) and then queries a multi-purpose search engine such as Google to retrieve pages with possible entity occurrences. The extracted entities are then written into the knowledge base. After the knowledge contains some entities, the fact extraction process reads those entity names and also gets predefined information about the attributes that are searched for the entity’s concept. For example, the fact extraction process reads the movie entity “The Dark Knight” from the knowledge base and the attributes “runtime”, “director” and “release date” from the knowledge ontology. The process then queries a search engine again, tries to extract facts, assesses the extractions and writes the results back to the knowledge base. More details can be found in [8] and [7].

Fig. 1. Overview of extraction flow

5

Conclusion and Work Plan

In this paper we have shown existing approaches to extract information from the web and build semantic knowledge bases. We have described the shortcomings of these systems and how we are planning to address them. Our future work is structured as follows. 1. Create Use Cases First, we will describe use cases in each of the application domains for a semantic knowledge base. The use cases will help to understand the requirements for such a knowledge base in more detail. 2. Research on Related Work Second, we are going to find state-of-the-art approaches for knowledge base updating and extraction assessment. We will also need to implement some of the most relevant algorithms (PMI, URNS, random graph walk) to have a baseline for our own approach.

804

D. Urbansky

3. Design and Experimentation In the third phase, we will create verifiable hypotheses that lead the design and experimentation process for our own solutions. This phase will start early, as practical problems can be recognized quickly. 4. Evaluation In the last phase, we will create a real life testing set for our assessment approach and compare it to the identified state-of-the-art algorithms. Furthermore, we will evaluate how quickly the knowledge base is updated with correct information in different domains.

References 1. Auer, S., Bizer, C., Kobilarov, G., Lehmann, J., Cyganiak, R., Ives, Z.G.: DBpedia: A nucleus for a web of open data. 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., Cudr´e-Mauroux, P. (eds.) ASWC 2007 and ISWC 2007. LNCS, vol. 4825, pp. 722–735. Springer, Heidelberg (2007) 2. Banko, M., Cafarella, M.J., Soderland, S., Broadhead, M., Etzioni, O.: Open Information Extraction from the Web. In: Proceedings of the 20th International Joint Conference on Artificial Intelligence, pp. 2670–2676 (2007) 3. Berners-Lee, T., Hendler, J., Lassila, O.: The Semantic Web. Scientific American 284(5), 28–37 (2001) 4. Downey, D., Etzioni, O., Soderland, S.: A Probabilistic Model of Redundancy in Information Extraction. In: Proceedings of the 19th International Joint Conference on Artificial Intelligence, pp. 1034–1041. Professional Book Center (2005) 5. Etzioni, O., Cafarella, M., Downey, D., Popescu, A.-M., Shaked, T., Soderland, S., Weld, D.S., Yates, A.: Unsupervised named-entity extraction from the Web: An experimental study. Artificial Intelligence 165(1), 91–134 (2005) 6. Kasneci, G., Ramanath, M., Suchanek, F.M., Weikum, G.: The YAGO-NAGA approach to knowledge discovery. SIGMOD Record 37(4), 41–47 (2008) 7. Urbansky, D., Feldmann, M., Thom, J.A., Schill, A.: Entity Extraction from the Web with WebKnox. In: Proceedings of the Sixth Atlantic Web Intelligence Conference (to appear, 2009) 8. Urbansky, D., Thom, J.A., Feldmann, M.: WebKnox: Web Knowledge Extraction. In: Proceedings of the Thirteenth Australasian Document Computing Symposium, pp. 27–34 (2008) 9. Wang, R.C., Cohen, W.W.: Language-Independent Set Expansion of Named Entities Using the Web. In: The 2007 IEEE International Conference on Data Mining, pp. 342–350 (2007) 10. Wu, M., Marian, A.: Corroborating Answers from Multiple Web Sources. In: Proceedings of the 10th International Workshop on Web and Databases (WebDB 2007) (2007) 11. Zhao, S., Betz, J.: Corroborate and Learn Facts from the Web. In: KDD 2007: Proceedings of the 13th ACM SIGKDD International Conference on Knowledge discovery and data mining, pp. 995–1003. ACM, New York (2007)

Solving Identity Management and Interoperability Problems at Pan-European Level Sergio Sánchez García and Ana Gómez Oliva DIATEL – Universidad Politécnica de Madrid, Ctra. Valencia Km.7, 28031, Madrid, Spain {sergio, agomez}@diatel.upm.es

Abstract. In a globalized digital world, it is essential for persons and entities to have a recognized and unambiguous electronic identity that allows them to communicate with one another. The management of this identity by public administrations is an important challenge that becomes even more crucial when interoperability among public administrations of different countries becomes necessary, as persons and entities have different credentials depending on their own national legal frameworks. More specifically, different credentials and legal frameworks cause interoperability problems that prevent reliable access to public services in a cross-border scenarios like today’s European Union. Work in this doctoral thesis try to analyze the problem in a carefully detailed manner by studying existing proposals (basically in Europe), proposing improvements in defined architectures and performing practical work to test the viability of solutions. Moreover, this thesis will also address the long-standing security problem of identity delegation, which is especially important in complex and heterogeneous service delivery environments like those mentioned above. This is a position paper. Keywords: eIdentity, identity federation, identity delegation, interoperability.

1 Introduction Many European countries have traditionally used a universal system of identification based on a single document that is provided to all individuals. The content and function of the document are broadly similar in all cases, as it is normally used as a method for identifying individuals in dealings with either public administrations or some private companies who need to identify users of their services. Given that the document reflects a person’s identity, civil servants or company employees can directly verify someone’s identity on sight. Nevertheless, Internet and the gradual incorporation of the public to the digital society have led to changes in this scenario, as ever more administrative processes in both public institutions and service providers are being conducted online. Therefore, a growing demand exists for systems of identification that can enable such transactions without a loss of guarantees in the terms of security. This has given rise to the need to provide the public with an electronic or digital identity that will allow people to identify themselves online with at least the same guarantees as with a public identity card in personal interactions. R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 805–809, 2009. © Springer-Verlag Berlin Heidelberg 2009

806

S. Sánchez García and A. Gómez Oliva

With a view to solving this problem, most countries in the European Union are engaged in the implementing of electronic identification cards or eID cards whose outward appearance is similar to present-day identification cards, except that it includes a chip. This chip can electronically store information on identity and enables interaction with certain validation applications, thus allowing users to digitally prove their identity. Europeans are living in an environment that is not only increasingly digitalized, but which is increasingly globalized. Today, a citizen of Spain can work for a German company and perform his or her work in Belgium and do so problemfree, in theory; such a person must be able to interact with the company and with different public administrations online. This global environment leads to a series of problems that arise when we ask questions like the following: How could a person with a Spanish electronic identification card access online services provided by German public administration? And what about the person’s employment data as a worker in Belgium? Further, how can German public institutions manage the identity data of the Spanish national?

2 Material and Related Work Answers to the questions posed above are no simple matter; in any event, these will involve the specification and development of a set of technical and organizational infrastructures that can define, administer and manage attributes related to the identity of individuals. These infrastructures are called Identity Management systems, or IDMs. On the basis of action plans launched by the European Union, in recent years a number of initiatives have focused on achieving pan-European interoperability between identity management systems. Although most of these initiatives are nothing more than theoretical proposals that solve some problems without providing a comprehensive solution, some do go further and propose architectures that are now in the pilot stage. Coupled with standards and proposals such as SAML (Security Assertion Markup Language), WS-* (Web Services standards and recommendations) or Liberty, these proposals constitute the base material for a study of both the present state of affairs and for work related to the subject of this paper; further, they will be used to formulate the set of hypotheses that will guide continuing research work. Therefore, a brief analysis follows of the most outstanding of these proposals. One of the first studies or projects related to interoperability of identity management systems was the Modinis eIDM Study [1], which studied the use of electronic identity management systems in the European Union and analyzed the most significant consequences of using these eIDM systems. The study’s main contribution to interoperability was its definition of a model or conceptual framework (the Modinis Conceptual Framework), which is essentially a federation-based portal that incorporates the key proposals made in the project on the general organization and basic principles that should govern eIDM infrastructure at a pan-European level. It is based on a federated model that relies on a series of identity portals in each Member State responsible for authenticating entities at a national level and deciding the trust level granted to authentication processes in another Member State, so that each State will accept as equivalents the authentication levels and mechanisms used in another State on the basis of a set of criteria, while no specific Europe-wide infrastructure would be required.

Solving Identity Management and Interoperability Problems at Pan-European Level

807

Another interesting system is the TLS-Federation [2]. This project aimed at providing a regulatory and interoperable working framework for identity management at a pan-European level. It focused on employing technologies and standards that were sufficiently well-known and on protecting of the user side against possible scenarios of identity theft. The system is based on the use of certificates during the authentication process and is built upon a user-centered approach in which identity and privacy attributes are directly managed by the user. It is the only solution that requires no, or very little additional installation, and it does not demand conversion of session credentials in online access from the domain of any Member State within the pan-European domain. The GUIDE project (Creating a European Identity Management Architecture for eGovernment) [3] sought to develop a model for identity interoperability within the European Union, so as to enable Member States to trust the identity of an entity – whether individuals or companies – in another State. The underlying concept involves a federated network of identity management in which members, users, institutions and companies throughout the European Union can participate in identity information exchanges without compromising the privacy or security of the information. It requires membership in circles of trust based on operational agreements, thus yielding a federation of service providers and identity providers. Many Member States are involved in the development of such federations at a national level but they are often being created in isolation from one another. The objective of GUIDE was to define an architecture to enable the joining of these federations into a large circle of trust with a view to creating a single identity environment throughout the European Union. Another proposal for a pan-European identity management system is STORK (Secure idenTity acrOss boRders linKed) [4]. This recently-begun project seeks to develop and test common specifications for mutual and secure recognition of national electronic identities (eID) of participating countries. Their specific objectives include defining common models and specifications for the mutual recognition of eIDs between countries, verifying in a real environment easy and secure eID solutions to be used by individuals and companies and achieving coordination with other initiatives of the European Union in order to maximize the usefulness of eID services. To do this, they propose a model based on preliminary studies conducted by IDABC (Interoperable Delivery of European eGovernment Services to public Administrations, Businesses and Citizens) [5] that describe, at a high level, a federated model for interoperability that is technologically neutral and which supports multiple levels of authentication.

3 Research Hypotheses Having discussed the identity management systems that might be considered the most significant at a pan-European level, an overall assessment can be made of them and a series of conclusions drawn as the basis for a hypotheses upon which a thesis could be formulated. Out of all the models presented, it would seem rational to assume that the path to follow would lead to a system based on federation and multi-level operation. Indeed, all the systems discussed herein have a federated infrastructure that can separate

808

S. Sánchez García and A. Gómez Oliva

provision of the service from processes related to digital identity that are necessary to provide said service – i.e., user registration, generation and storage of identity and authentication data. The fact that the system is multi-level also facilitates, a priori, the incorporation of all countries with digital identity and an identity management system, thus speeding up the implementation of the system. Another aspect to be underlined that is common to MODINIS [1], IDABC [5] and STORK [4] is the meager or non-existent need to deploy a pan-European infrastructure and their capacity to quickly and easily add to the system countries that are less developed or which have fewer resources. Due consideration must also be given to the use of standards that have been sufficiently tested and accepted, if possible, as with TLS in the TLS-Federation model. With respect to outstanding problems that require a solution, that of trust is perhaps the most important. Specifically, trust levels must be established that will allow users with a certain type of identity tokens from their own country to be authenticated at a global level, but also with equivalences and trust levels in authentications. Consequently, authorization levels could be established in access to service providers by member states in the federated identity network. Another issue to be solved is semantic interoperability, which is closely linked to multilevel operability. Incorporation within a pan-European system of solutions that have already been implemented at a national level demands translation between representation formats at interconnection points, which also implies a need to establish a certain degree of semantic interoperability. Finally, although no less important, there is the problem of identity delegation and authorization. Many transactions today are performed by legal representatives who are authorized to act on our behalf. For example, an individual in Spain can authorize another person to engage in all transactions necessary to file an income tax return with the authorities. Likewise, a person can have different roles simultaneously within the identity management system, acting as both an individual and the legal representative of a company or organization; that is, the identity of a person or entity can be delegated to another, thus empowering the latter person to act, to all intents and purposes, as if he or she were the former person or entity. Since none of the proposals discussed herein even address this issue, none of them offer a solution to it.

4 Work Planned On the basis of the hypotheses formulated, future work on the thesis will primarily seek to solve two of the problems found: first, the problem related to interoperability in environments of multi-level authentication arising from the need for a translation mechanism; and, secondly, the problem of delegation. For the latter case, thesis work will endeavor to propose a global solution for delegation that is both secure and sufficiently flexible to adapt to any architectures that should arise in the future. In addition, solutions will also be sought for problems found in the architectures proposed to date. Thorough follow-up will also be performed on proposals in progress such as STORK [4], attempting to provide, to the extent possible, solutions to any problems that may be identified. Given that this thesis work is being carried out in the framework of a national project (TSI2006-4864 Plataforma telemática de

Solving Identity Management and Interoperability Problems at Pan-European Level

809

Administración Electrónica basada en coreografía de servicios [Telematic platform of electronic government based on a choreography of services]) validation is available on a small scale for testing, in a real city council, the viability of the solutions proposed.

5 Conclusions Today, pan-European identity management in public administrations has become a major challenge to which a solution has not yet been found. Even though proposals exist, none of them constitute a complete and fully validated solution. Upcoming work on this thesis will endeavor to provide an in-depth study of solutions conceived to date, comparing them, identifying problems and supplying solutions both to problems found and problems not addressed – as in the case of delegation -, with a view to allowing the results to be given their proper weight when a pan-European identity management system is adopted. Acknowledgments. This thesis is part of the work being conducted by the research group T>SIC, to which the authors herein belong, as part of the project TSI2006-4864 Plataforma telemática de Administración Electrónica basada en coreografía de servicios [Telematic platform of electronic government based on a choreography of services], which is supported by the Spanish Ministry of Education and Science under the national R+D+I plan.

References 1. ModinisIDM, https://www.cosic.esat.kuleuven.be/modinis-idm/ twiki/bin/view.cgi/Main/WebHome 2. Bruegger, B.P., Hühnlein, D., Schwenk, J.: TLS-Federation - a Secure and Relying-PartyFriendly Approach for Federated Identity Management, http://porvoo14.dvla.gov.uk/documents/tls_federation_final.pdf 3. GUIDE, Creating a European Identity Management Architecture for eGovernment, http://istrg.som.surrey.ac.uk/projects/guide/overview.html 4. STORK, Secure idenTity acrOss boRders linked, http://www.eid-stork.eu/ 5. Majava, J., Graux, H.: Common Specifications for eID interoperability in the eGovernment context. IDABC European eGovernment Services (December 2007), http://ec.europa.eu/idabc/servlets/Doc?id=30989

An Application Framework for a Situation-Aware System Support for Smart Spaces Arlindo Santos and Helena Rodrigues Centro Algoritmi, Escola de Engenharia, Universidade do Minho, Campus de Az´ urem, 4800-058 Guimar˜ aes, Portugal

Abstract. Despite a considerable research effort towards system support for smart spaces, in recent years we have been witnessing a growing perception about a persistent gap between the promises of the area and its real achievements. We are investigating a situation-aware system support for smart spaces that builds on a new set of assumptions and design principles, based on user-controlled associations between global services and local resources. The realisation of this concept raises important challenges across a model for global autonomous applications that enables them to integrate the functionality and resources of multiple situations. This research work aims at investigating such a model and evaluating the concept of situation-aware system support for smart spaces.

1

Introduction

Smart spaces are ordinary environments equipped with visual, audio and other sensing systems, pervasive devices, and networks that can perceive and react to people, sense ongoing human activities and respond to them [7]. Realising this vision requires infrastructures that are able to transparently manage the resources in the physical environment and provide an integrated execution environment for application development. They should provide the framework for the integration of an open, diverse and a priori unknown set of services into a functioning system, addressing key issues such as discovery, selection and spontaneous interaction between entities. Despite the wide range of existing platforms, it is not much easier today to build a smart space than it was years ago [2,7,14], and it is clear that the field has not matured yet to the point of enabling incremental research, a cornerstone for any research area (see section 2). We are investigating a new approach to system support for smart spaces that builds on a new set of assumptions and design principles [11]. The new approach is based on user-controlled associations between global services and local resources and breaks the one-to-one association between a particular physical space and a particular combination of services. Instead, the concept of Situation, seen here as a socially meaningful activity that involves multiple people and can take place anywhere, is introduced as the context for the aggregation of resources and global functionality under a common purpose. A key step in enabling a situation is to associate it with the set of applications that supports the R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 810–814, 2009. c Springer-Verlag Berlin Heidelberg 2009 

An Application Framework for a Situation-Aware System Support

811

functionality deemed appropriate for that specific situation. The local resources are also associated, subject to negotiation, to all the different situations that could occur at their physical environment. This way, multiple layers of functionality could easily be created on top of the same space to provide any type of specific support. The realisation of this concept raises important challenges across a model for global autonomous applications that enables them to integrate the functionality and resources of multiple situations, while enabling them to be combined and appropriated in many ways. This research work aims at investigating such a model and evaluating the concept of situation-aware system support for smart spaces. The object of research is directed towards the evaluation of infrastructure as a tool for development of applications by authors without experience in programming. We hope these applications to be re-usable elements that can easily become building blocks to the creation of multiple systems.

2

Related Work

There are a few ambitious middleware systems that were proposed as metaoperating systems capable of providing an integrated programming model for application developers [1,3,4,6,13]. Despite this considerable research effort, in recent years we have been witnessing a growing perception about a persistent gap between the promises of the area and its real achievements. A major conclusion at influent events in the field, such as UbiSys06 and CMPPC07, was that most systems have never had any real use outside their own development environment and incremental research has been the exception. We argue that there are four fundamental reasons for this limited success [11]. The first is a chicken and egg problem with applications. Without widely accepted reference scenarios, it is very hard to identify requirements and make informed design decisions on the type of system support that may be needed. Without a rich and operational infrastructure it is very hard to create an integrated environment where meaningful applications may emerge. The second is the implicit knowledge that prevails in those systems. Even though discovery, selection and dynamic interaction are all key goals for most platforms, there is too much hidden behaviour and too many assumptions about the environment that must be in place to bootstrap and deploy the system [2]. A third problem results from a vision of smart spaces as caring environments that sense and intelligently react to people, which raises very complex requirements associated with the need to model, detect or infer peoples feelings, intents or situations of life [8]. A final reason is the strong coupling between physical space and functionality, but we argue that Human activity is too dynamic, subtle and mobile to be captured in the infrastructure of any specific physical space. On the other hand, the problem with the creation of ubiquitous software applications is very severe. Particularly, the application programming model [3,5,10] (context-aware, service-oriented, user-centric, environment-centric, taskoriented, etc) is important for software planning and development phases. Roman et al. [12] have identified six patterns that were required for all applications:

812

A. Santos and H. Rodrigues

multi-device utilization, user-centrism, run-time adaptation, mobility, contextsensitivity, and ubiquitous computing environment independence; and have identified five design guidelines: low-level system support, boot-strapping, scripting, application development and management support, and end-user support, which were considered essential to support ubiquitous computing environments and to increase number of application developers. The Ubiquitous Web Applications Working Group focuses on extending the Web for enabling distributed applications of many kinds of devices including sensors and effectors. Application areas include home monitoring and control, home entertainment, office equipment, mobile and automotive [15]. Also following the Web 2.0 path [9], the Facebook social network offers an application framework oriented to application rapid development cycle and sharing with objective of increasing the number of application and developers. Current state-of-the-art on ubiquitous application frameworks have not been designed for supporting situation-aware application characteristics and requirements, situation we have identified as a new research path for ubiquitous applications development frameworks.

3

Research Hypotheses

This work builds on the assumption that a situation-based infrastructure represents an important paradigm shift in System Support for Smart Spaces and opens new paths towards the long-time goals of this area. The overall system model addresses the limitations identified in section 2 by approaching system support for smart spaces from a new perspective that is characterised by associating functionality with the concept of a Situation. Applications for a situation are viewed as self-contained blocks of functionality that are globally available and may serve multiple situations. A person creating system support for a particular situation will attach to that situation whatever applications may be useful. Applications will take advantage of the resources and content that have previously been associated with the situation. Functionality emerges from the combination of the application logic with the interaction capabilities of local resources within the framework of a particular situation. This particular approach reduces the complexity of basic applications and also blurs the distinction between system support and applications. The goal of this work is to develop an application framework for a situation-aware system support for smart spaces, addressing the necessary meta-level concepts, protocols, application development interfaces and tools to automate and control the life cycle, sharing, and execution of applications. This dissertation wants to show that: An application framework for a situation-aware system support for smart spaces will provide the basis for third-party developers to experiment creatively and open the way for more creative and open-ended appropriations of the functionality supported by the system, while reducing the required programming skill level.

An Application Framework for a Situation-Aware System Support

4

813

Work Plan

Situation-aware applications correspond to a logical block that is able to provide functionality directly to users within the context of a situation, by leveraging on the resources and content associated with that situation. This view is inspired by the Facebook, OpenSocial and other Web 2.0 application models, in which application development is open and existing applications can be shared between multiple pages, have their own functionality, but their data and services be easily combined and appropriated in many ways. Currently, we are building an Application Programming Interface to enable applications to access the main situation-aware infrastructure services. Developers will be able to add the situation context to their application by utilizing situation accounting, presence, document, location, and messages data. This task aims at supporting case studies prototyping, which evaluation will provide early feedback on state-of-the-art and new application patterns. Next, the definition of the application model will consider the application’s life cycle, the hosting and the integration of application output with situation resources both for desktop and web applications. At this stage we will consider mainly the reutilization and sharing application patterns. From the perspective of making applications developments more expedite and accessible to other domains specialists, including developing, deployment and evaluation, this work will investigate the development of a tool for rapid authoring of situation-aware applications. Finally, the evaluation task aims at evaluate in what extent the Application Programming Framework successfully contributes for the realisation of classical and new smart space scenarios. More precisely, we want to measure in what extent we reduce the overwhelming effort it was to take someone elses middleware and build smart spaces computing applications on top of it, and because of that how the goal of having a widely accepted middleware that is effectively used by multiple developers of smart environments is yet to happen.

5

Conclusions

The goal of having a widely accepted middleware is yet to happen, and there is lack of common ground and metrics for evaluation. There is absence of established reference scenarios or clear demands for smart spaces and ubiquitous computing: all domains have different constraints and so hamper common approaches to system support for applications. We propose an application framework for a situation-aware system support for smart spaces which aims at democratizing application development following the Web 2.0 path. Our objective is to promote incremental research, given that infrastructure will be open and designed for re-use and sharing of local resources and applications in different situations. Multiple entities will have the possibility to use this infrastructure to create a diverse set of smart spaces, leading to a rich test bed for the identification of new requirements and for improving our understanding of this problem domain.

814

A. Santos and H. Rodrigues

References 1. Ballesteros, F.J., Soriano, E., Guardiola, G., Leal, K.: The plan b os for ubiquitous computing. voice control, security, and terminals as case studies. Pervasive and Mobile Computing 2(4), 472–488 (2006); Special Issue on PerCom 2006 2. Friday, A., Roman, M., Becker, C., Al-Muhtadi, J.: Guidelines and open issues in systems support for ubicomp: reflections on ubisys 2003 and 2004. Personal Ubiquitous Comput. 10(1), 1–3 (2005) 3. Garlan, D., Siewiorek, D., Smailagic, A., Steenkiste, P.: Project aura: Toward distraction-free pervasive computing. IEEE Pervasive Computing 1(2), 22–31 (2002) 4. Grimm, R., Davis, J., Lemar, E., Macbeth, A., Swanson, S., Anderson, T., Bershad, B., Borriello, G., Gribble, S., Wetherall, D.: System support for pervasive applications. ACM Trans. Comput. Syst. 22(4), 421–486 (2004) 5. Hen, I.Y., Jansen, E., Helal, S.: A comparison of two programming models for pervasive computing. In: International Symposium on Applications and the Internet Workshops, 2006. SAINT Workshops 2006, p. 4 (2006) 6. Johanson, B., Fox, A., Winograd, T.: The interactive workspaces project: Experiences with ubiquitous computing rooms. IEEE Pervasive Computing 1(2), 67–74 (2002) 7. Kindberg, T., Fox, A.: System software for ubiquitous computing. IEEE Pervasive Computing 1(1), 70–81 (2002) 8. Leahu, L., Sengers, P., Mateas, M.: Interactionist ai and the promise of ubicomp, or, how to put your box in the world without putting the world in your box. In: UbiComp 2008: Proceedings of the 10th international conference on Ubiquitous computing, pp. 134–143. ACM, New York (2008) 9. Oreilly, T.: What is web 2.0: Design patterns and business models for the next generation of software. Communications & Strategies, First Quarter 2007, 13 (2007) 10. Pinto, H., Jose, R., Campos, J.C.: An interaction model and infrastructure for localized activities in pervasive computing environments. In: 2007 IEEE International Conference on Pervasive Services, New York, USA, pp. 232–241. IEEE, Los Alamitos (2007); IEEE International Conference on Pervasive Services, Istanbul, Turkey, July 15-20 (2007) 11. Rodrigues, H., Jos´e, R.: Towards a new research agenda in system support for smart spaces. Draft report, Centro Algoritmi, Escola de Engenharia, Universidade do Minho (July 2009) 12. Roman, M., Al-Muhtadi, J., Ziebart, B., Campbell, R., Mickunas, D.: System support for rapid ubiquitous computing application development and evaluation. In: System Support for Ubiquitous Computing Workshop (UbiSys 2003) in conjunction with UbiComp 2003, Seattle, WA (2003) 13. Roman, M., Hess, C., Cerqueira, R., Campbell, R.H., Nahrstedt, K.: Gaia: A middleware infrastructure to enable active spaces. IEEE Pervasive Computing 1, 74–83 (2002) 14. Storz, O., Friday, A., Davies, N., Finney, J., Sas, C., Sheridan, J.: Public ubiquitous computing systems: Lessons from the e-campus display deployments. IEEE Pervasive Computing 5(3), 40–47 (2006) 15. W3C. Ubiquitous web applications working group (2009), http://www.w3.org/2007/uwa/Activity.html

SWWS 2009 PC Co-chairs’ Message The Web has now been in existence for quite some time, and it has produced a major shift in our thinking on the nature and scope of information processing. It is rapidly moving toward an application deployment and knowledge deployment that requires complex interactions and properly structured underlying semantics. There has been a sudden upsurge of research activity in the problems associated with adding semantics to the Web. This work on semantics will involve data, knowledge, and process semantics. The international IFIP workshop on Semantic Web and Web Semantics (SWWS 2009), in its fifth year, provided a forum for presenting original, unpublished research results and innovative ideas related to this voluminous quantity of research. This year we decided to organize SWWS into a number of tracks, namely: - SAWSDL - Semantics Annotations for Web Service Description Language - SEMELS - Semantic Extensions to Middleware Enabling Large-Scale Knowledge Applications - COMBEK - Community-Based Evolution of Knowledge-Intensive Systems - WSA - Web Semantics and Applications In previous OTMs some of these were organized as separate workshops. However, to provide a unifying forum, we chose to field these into tracks within the broader framework of SWWS. WSA addresses the broader issues of Web semantics and gives some important examples of applications. SAWSDL addresses issues related to adding semantics to Web services focused on the W3C-produced SAWSDL, which gives a lightweight bottom–up specification for adding semantics annotations to WSDL. SEMELS seeks to utilize the widely used non-semantic integration approach based on middleware systems to the case of semantically based systems providing knowledge mediation, co-ordination and functionalities. COMBEK emphasizes the role of the community for community-driven evolution of shared knowledge structures and repositories such as ontologies, folksonomies and shared conceptual models. Each of these submissions was rigorously reviewed by at least two experts. The papers were judged according to their originality, significance to theory and practise, and presentation at the workshop. We feel that the SWWS 2009 papers will inspire further research in the areas of the Semantic Web and its applications. We would like to express our deepest appreciation to the authors of the submitted papers and would like to thank all the workshop attendees. We would also like to thank the Program Committee members and external reviewers for their efforts in maintaining the quality of papers and turning the SWWS 2009 workshop into a success. November 2009

Elizabeth Chang Ernesto Damiani Tharam S. Dillon

R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, p. 815, 2009. © Springer-Verlag Berlin Heidelberg 2009

On Constructing, Grouping and Using Topical Ontology for Semantic Matching Yan Tang, Peter De Baer, Gang Zhao, and Robert Meersman VUB STARLab 10G731, Vrije Universiteit Brussel Pleinlaan 2, 1050 Elesene Brussels, Belgium {yan.tang, pdebaer, robert.meersman}@vub.ac.be, [email protected]

Abstract. An ontology topic is used to group concepts from different contexts (or even from different domain ontologies). This paper presents a pattern-driven modeling methodology for constructing and grouping topics in an ontology (PAD-ON methodology), which is used for matching similarities between competences in the human resource management (HRM) domain. The methodology is supported by a tool called PAD-ON. This paper demonstrates our recent achievement in the work from the EC Prolix project. The paper approach is applied to the training processes at British Telecom as the test bed.

1 Introduction and Motivation In the EC Prolix project1, we need to calculate competency gaps between a learning module (such as a learning material or a course), a person’s profile (such as his Curriculum Vitae), and the descriptions of a job in the human resource management (HRM) domain. An HRM ontology is required for calculating this kind of gaps and providing semantic reasoning. We use the concept of topical ontology and ontological topics [14] as they provide freely combined, easily manageable concept sets, which can be from different contexts and even from different ontologies. In this paper, we will illustrate a pattern-driven topical ontology creation methodology (PAD-ON), its supported tool PAD-ON suite and how to use the topical ontology in the simple semantic matching algorithm. It is applied to a use case from British Telecom in Amsterdam2 – finding the conceptual similarities between the learning materials and assessment materials. The paper is organized as follows. Chapter 2 is the paper background. We present PAD-ON in chapter 3. Chapter 4 1

2

The EC Prolix (FP6-IST-027905, Process-Oriented Learning and Information Exchange, http://www.prolixproject.org/) is project co-funded by the European Commission under the Sixth Framework Program. It is to align learning with business processes in order to enable organisations to faster improve the competencies of their employees according to continuous changes of business requirements. http://www.bt.com/

R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 816–825, 2009. © Springer-Verlag Berlin Heidelberg 2009

On Constructing, Grouping and Using Topical Ontology for Semantic Matching

817

discusses how to use the resultant ontology in the semantic matching algorithm. Chapter 5 is the result of the paper. The paper related work and the comparison between our work and the others’ are discussed in Chapter 6. We conclude and illustrate our future work in chapter 7.

2 Background 2.1 Ontology and DOGMA An ontology is a specification of a conceptualization [7]. The concepts, relationships, and other distinctions relevant for modelling a domain are defined and specified. In the DOGMA (Developing Ontology-Grounded Methods and Applications, [9, 11,13]) framework, one constructs (or converts) ontologies by the double articulation principle into two layers: 1) the lexon base layer that contains a vocabulary of simple facts called lexons, and 2) the commitment layer that formally defines rules and constraints by which an application (or “agent”) may make use of these lexons. A lexon is a quintuple , , , , , where is a context identifier, within which the terms , are defined. The role and co-role refer to the relations that the concepts share with respect to one another. For example, a lexon , , , , a fact that “a driver’s license is issued to a driver”, and “a driver has a driver’s license”. A commitment contains a set of rules in a given syntax, and describes a particular application view of reality, such as the use by the application of the (meta-) lexons in the lexon base, e.g. we may apply the uniqueness constraint on the lexon in order to have has a constraint - “one driver’s license is issued to at most one driver”. Ontologies modeled in DOGMA can be further implemented in an ontology language, such as OWL3 and RDF(S)4. The specification (as defined by Gruber [7]) takes the form of the definitions of representational vocabulary (such as lexons and commitments in DOGMA), which provide meanings for the vocabulary and formal constraints on its coherent use. 2.2 Topical Ontology A topical ontology is specified into five blocks of specifications (Fig. 1). They are the basis, assertions, topics, applications and instances described as below. •

•

3 4

The specification of Basis identifies the conceptual objects and their typological relationship. In DOGMA, the basis is a lexon set that only contains lexons with “is-a” (or “part-of”, “subtype”, “subclass” etc.) relationships, for instance, lexon , , , , . This kind of lexons can be represented graphically as a hierarchical, acyclic tree. The Assertions asserts how the conceptual objects interact with each other. It contains the lexons that have “free” relations or playing “free” roles with each other, e.g. lexon , , , , . This kind of lexons can be represented graphically as a non-directed network.

OWL Web Ontology Language: http://www.w3.org/TR/owl-features/ RDF(S) Resource Description Framework (Schema): http://www.w3.org/TR/rdf-schema/

818

Y. Tang et al.

•

•

•

The Topics groups the relationships and assertions into a topical map of larger reusable units. We consider a topic as a collection of lexons. Although the theoretical basis for topics is different from that of a context, a topic can sometimes play the role of a context. The Applications select, constrain and contextualize topics, relationships and assertions to formulate abstracts about business data and processes in view of specific application semantics. It is a set of ontological commitments that contain constraints and axioms. The Instance lists concrete references or values about conceptual objects, relationships and assertions. For example, an instance of “skill level” in the lexon , , , , can be “good”.

Note that a lexon in the block of Instance, Application and Topics needs to be defined in either the block of Basis or the block of Assertions, or both.

Fig. 1. Ontology building blocks

3 Pattern-Driven Topical Ontology Modeling Methodology (PAD-ON) This methodology contains three steps: 1) create pattern(s); 2) create ontological basis (subtypes of each element in the patterns); 3) create ontological assertions; 4) group lexons in the ontological basis and the ontological assertions into topics; 5) model ontological commitments for the applications and populate the instances of some concepts. The design pattern in this paper is an extension to the design pattern discussed in [14], which consists of five elementary elements: Participant, Action/Process, Object, Attribute and State (Fig. 2). On step 1, our task is to define the patterns as illustrated above. We can use different resources, such as the Organization for Economic Co-Operation and Development (OECD5), and the O*NET6, to define the patterns based on Fig.2. For instance, we extend the pattern in Fig.2 with OECD key competence framework, the conceptualization of which focuses on the person and his action, the manner and means. It stresses the interaction between individuals at work. We refine Participant into Person. The State of the action is further detailed into the Instrument and Manner. Accordingly, we have a pattern as illustrated in Fig.3. 5 6

http://www.oecd.org http://online.onetcenter.org/

On Constructing, Grouping and Using Topical Ontology for Semantic Matching

819

Fig. 2. Pattern used for HRM ontology

Fig. 3. A pattern in Conceptual Graph [12]: Persons act or interact on objects by instruments in manners

The elements in Fig.3 are specified as below. • Person/Actor: an initiator of an event or performer of an action, it is a Participant or Person • Act/Interact: an action or even, in which a Participant or Person is lined to another Participant or Person. • Object: an affected or resultant entity in an action, event or process. It has no volition and is inanimate. • Instrument: a means with which an Actor causes an event or performs an action. It pertains to the State of an action, process or event. • Manner: a state or form of an action, process or event. It pertains to the State of an action, process or event. On step 2, we define the subtypes of each element in the above pattern. For instance, the subtypes of “Person” (Fig.3.) are defined in Table 1. Table 1. Lexon table that contains the subtypes of „Person“ (Basis level) Head Term Customer Employee junior employee senior employee …

Role is a is a is a is a …

co-role super type of super type of super type of super type of …

Tail Term Person Person employee employee …

820

Y. Tang et al.

On step 3, we create lexons that does not contain hierarchical relationships as roles as the ontological assertions (Table 2). Table 2. Lexon table that contains lexons at the Assertion level Head Term

Role

Co-Role

Tail Term

Person performance Person Person Person Person …

differentiate has make accept learn from give …

is differentiated by is of is made by is accepted by is learned from is given by …

performance level performance level Mistake Mistake Mistake Feedback …

On step 4, we create ontological topics. The topics are considered as freely combined contexts, each of which accumulates lexons that are described at the basis level and assertion level into a set. There are two types of topics in the BT use case – assessment capacities and learning materials. There are in total 10 capacities: Trustworthy, Coaching for performance, Helpful, Bottom Line, Inspiring, Drive for results, Straightforward, Customer connected, Heart, Professional/ technical. For instance, “Coaching for performance” contain the lexons as shown in the table below. Table 3. Lexon table of topic „Coaching for performance“ Head Term

Role

co-role

Tail Term

person person person person person person …

observe ally with negotiate with Support Replace Give …

is observed by is allied with is negotiated with is supported by is replaced by is given by …

agenda person person person person promise …

The learning materials are linked to BT learning skills, which can be categorized into 4 groups: 1) Process skills, such as knowledge of fault handling, 2) Soft skills, such as ability to cooperate, 3) Technical skills, such as voice-T1 and DSL-T4, 4) Administrative and other skills, such as the ability of handle the calendar and the ability of making customer report. For instance, learning material “Senior SAT” correspond to the ontological topic “Senior SAT” as shown in Table 4. Table 4. Lexon table of topic „Senior SAT“ Head term

Role

co-role

Tail term

person

use

is used by

Information

person

identify

is identified by

Information

On Constructing, Grouping and Using Topical Ontology for Semantic Matching

821

Table 4. (continued) person

locate

is located by

person

access

is accessed by

Information

TS page

is a

super type of

Information

sheet information

is a

super type of

Information

network drawing

is a

super type of

Information

…

…

…

…

Information

On step 5, we model ontological commitments that make use of the lexons created in the previous steps. Note that these commitment models need to be further implemented and integrated into the real applications.

4 Ontological Topics for Semantic Matching Currently, we use a tool called DMatch, which contains lexical matching algorithms, such as Levenshtein distance [8], and set comparison supported by thesaurus, such as WordNet [5]. The discussion on the matching algorithms and evaluation of different matching algorithms is out of the scope of this paper. The principles of using topical ontology for semantic matching are the issues that need to be discussed here. With topical ontology, the matching can happen between two topics. For instance, we can find the conceptual similarity between assessment capacity “Coaching for performance” (topic “Coaching for performance”, which contains the lexons in Table 3) and learning material “Senior SAT” (topic “Senior SAT”, which contains the lexons in Table 4). We take one lexon from each topic and compare their lexon terms. Below is a list of lexons where lexon and topic Ζ , ,

, ,

,

,

, ,

,

, , , ,

, , , ,

, ,

,

is similar to because they both contain the lexon term “person”. is similar to as the term “schedule” from and the term “agenda” from are in the same SynSet. and are similar because both the term “senior employee” from and the term “junior employee” from contain the string “employee”. The roles are used for the comparison as well, but in a weighted way. For instance, we can give the weights for the specific role pairs as in Table 5. Note that we shall allow end users to provide the weights.

822

Y. Tang et al. Table 5. An example of weights for specific roles

Role/co-role pair) is a (Subtype of)/supertype of is a (Subclass)/superclass of Part-of/contain Require/is required by Has/belongs to Has property/is property of Equivalent to/equivalent to Has member/is member of Use/is used by

Weight 0.8 0.8 0.5 0.5 0.5 0.2 1 0.5 0.1

Note that the roles in a topic are not used for the matching. Only the roles are used to connect two terms from two topics are used for the matching. In other words, these roles and relevant lexons belong to the domain ontology Ω, but not . For instance, , ,

,

, ,

, ,

, ,

Ω Ω

Then, the topics , ζ , , are similar because , contain the lexon term “person”, which is linked to “senior employee” from by and linked to “junior employee” from by . In particular, the similarity between and is 0.8 (as same as between and , and , and ) because “is a”/”supertype of” role pair has the weight of 0.8 in Table 5. Including lexon terms and roles, the constraints in the commitment layer of Ω are the third component used for the semantic matching. For instance, the constraint exclusive-or draws a similarity of 0 between two lexons from two topics. In the above discussion, the matching happens between two topics. It can as well happen between a topic and a set of topics. For example, we can search a set of relevant learning materials that can be used to enhance the assessment capacity “Coaching for performance”. In this case, we need to find out for each lexon in this topic, whether it exists in other topics or not, using the same matching strategy as discussed above. In this chapter, we have discussed principles of using topical ontology for the semantic matching. In the next chapter, we will illustrate the results.

5 Result The methodology is implemented in a tool called PAD-ON Suite (Fig. 4). Users are able to create the patterns and specify the elements with concepts defined in the ontological basis and ontological assertions. With PAD-ON suite, we have created in total 496 lexons, which are used and grouped in 49 ontological topics (Table 6). These topics include 10 assessment capacities, 9 OECD keys and 30 learning materials Table 7 shows the similarities between topics.

On Constructing, Grouping and Using Topical Ontology for Semantic Matching

823

Fig. 4. PAD-ON suit (Screenshot) Table 6. Number of lexons in 49 topics (data is collected on July 5, 2009) Ontological topic name (selected) Assessment capacity Trustworthy Helpful Inspiring Heart Coaching for performance Bottom line Drive for results Customer connected … Learning material Fault handling introduction system (FH 1) Fault handling escalation (FH 2) …

Number of lexons 56 43 19 12 39 27 84 54 … 11 20 ….

Table 7. Similarites between topics (selected) Topic pair Trustworthy, FH 1 Heart, FH 1 …

Similarity 0.38 0.24 …

Topic pair Trustworthy, FH 2 Heart, FH 1 …

Similarity 0.21 0.22 …

6 Related Work and Discussion Pattern-driven methodologies for creating domain ontologies are used to (semi-) automatically create ontologies by populating concepts in patterns. A related work of

824

Y. Tang et al.

this paper is OntoCase [2], which retrieve and select patterns from a set of ontological patterns. The patterns that get high ranks are further used by ontology-based applications, such as search engines. Chenine et al. [3] use context based ontology design architecture in the form of Principle-Subject-Support (PSS) pattern, for creating distributed, heterogeneous and multi-functioned, application ontology. It is applied to create a military domain ontology. Presutti and Gangemi [10] discuss how to extract and describe emerging content ontology design patterns (CP), and how to compose, specialize and expand them for ontology design. They illustrate two CPs and apply them in the music industry domain. Other related work can be found in [1, 4, 11].

7 Conclusion and Future Work In this paper, we have discussed the design of a pattern-driven topical ontology modeling methodology (PAD-ON), which is supported by a tool called PAD-ON suit. The resultant ontology is used by the semantic matching engine. In the future, we will design and implement a more generic matching framework, which contains many matching strategies from different perspectives, such as linguistic, relational database modeling and graph theory. Acknowledgement. This paper is support by the EC Prolix project.

References 1. Aranguren, M.E., Antezana, E., Kuiper, M., Stevens, R.: Ontology Design Patterns for bioontologies: a case study on the Cell Cycle Ontology. BMC Bioinformatics 9(5), S1 (2008) 2. Blomqvist, E.: Pattern ranking for semi-automatic ontology construction. In: Proceedings of the 2008 ACM symposium on Applied computing table of contents, Fortaleza, Ceara, Brazil, pp. 2248–2255 (2008) ISBN:978-1-59593-753-7 3. Chenine, M., Kabilan, V., Lozano, M.G.: A Pattern for Designing Distributed Heterogeneous Ontologies for Facilitating Application Interoperability. In: Proceedings of 3rd Open INTEROP Workshop On Enterprise Modeling and Ontologies for Interoperability (EMOI 2006), collocated with CAiSE 2006 (2006) 4. Clark, P., Thompson, J., Porter, B.: Knowledge patterns. In: Cohn, A.G., Giunchiglia, F., Selman, B. (eds.) Proceedings of KR 2000: Principles of Knowledge Representation and Reasoning, pp. 591–600. Morgan Kaufmann, San Francisco (2000) 5. Fellbaum, C.: WordNet: an electronic lexical database (Language, Speech, and Communication). MIT Press, Cambridge (1998) 6. Gruber, T.R.: Toward Principles for the Design of Ontologies Used for Knowledge Sharing. In: Guarino, N., Poli, R. (eds.) Workshop on Formal Ontology, Padva, Italy. In Book, Formal Ontology in Conceptual Analysis and Knowledge Representation. Kluwer Academic Publishers, Dordrecht (1993) 7. Levenshtein, VI: Binary codes capable of correcting spurious insertions and deletions of ones (original in Russian). Russian Problemy Peredachi Informatsii, 12–25 (1965)

On Constructing, Grouping and Using Topical Ontology for Semantic Matching

825

8. Meersman, R.: Ontologies and Databases: More than a Fleeting Resemblance. In: d’Atri, A., Missikoff, M. (eds.) Proceedings of OES/SEO 2001 Rome Workshop. Luiss Publications (2001) 9. Presutti, V., Gangemi, A.: Content Ontology Design Patterns as Practical Building Blocks for Web Ontologies. In: Li, Q., Spaccapietra, S., Yu, E., Olivé, A. (eds.) ER 2008. LNCS, vol. 5231, pp. 128–141. Springer, Heidelberg (2008) 10. Rector, A., Rogers, J.: Patterns, properties and minimizing commitment: Reconstruction of the GALEN upper ontology in owl. In: Gangemi, A., Borgo, S. (eds.) Proceedings of the EKAW 2004 Workshop on Core Ontologies in Ontology Engineering (2004) 11. Sowa, J.F.: Conceptual Structures: Information Processing in Mind and Machine. Addison-Wesley, Reading (1984) 12. Spyns, P., Meersman, R., Jarrar, M.: Data Modeling versus Ontology Engineering. SIGMOD Record: Special Issue on Semantic Web and Data Management 31(4), 12–17 (2002) 13. Zhao, G., Meersman, R.: Architecting Ontology for Scalability and Versatility. In: Meersman, R., Tari, Z. (eds.) OTM 2005. LNCS, vol. 3761, pp. 1605–1614. Springer, Heidelberg (2005)

Query Results Clustering by Extending SPARQL with CLUSTER BY Agnieszka L  awrynowicz Institute of Computing Science, Poznan University of Technology, ul. Piotrowo 2, 60-965 Poznan, Poland [email protected] Abstract. The task of dynamic clustering of the search results proved to be useful in the Web context, where the user often does not know the granularity of the search results in advance. The goal of this paper is to provide a declarative way for invoking dynamic clustering of the results of queries submitted over Semantic Web data. To achieve this goal the paper proposes an approach that extends SPARQL by clustering abilities. The approach introduces a new statement, CLUSTER BY, into the SPARQL grammar and proposes semantics for such extension.

1

Introduction

Dynamic clustering is a way of organizing search results that has gained an attention from academia [12,13] and from commerce. The technique of dynamic clustering consists on grouping search results into clusters generated from the search results themselves. The user after submitting a query to the search engine is often faced by a large number of search hits, and forced to further perform query results exploration to find out what the data source contains. Therefore, the clusters may help him/her more quickly and easily understand the retrieved results, and save the time otherwise spent on analysing them. The task of dynamic clustering has been commonly addressed in the context of clustering textual Web search results. For instance, Vivisimo/Clusty1 is an example of a successful commercial application of this idea. This paper, however, concentrates on the novel task of clustering the results of queries submitted to the structured Semantic Web [1] data. The proposition of applying the functionality of Web search clustering engines in the context of the open and distributed Semantic Web environment is motivated by the fact that although the Semantic Web data is structured, the user may not know the structure and granularity of the data apriori. Therefore data retrieval from the Semantic Web may be more of the spirit of information retrieval from unstructured text, rather than the retrieval from local, relational databases. The goal of this paper is to enable declarative means for invoking query results clustering. These declarative means are supposed to provide a framework to which clustering methods and algorithms may be plugged in. This paper contributes to achieving this goal by proposing to extend the standard Semantic 1

http://clusty.com

R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 826–835, 2009. c Springer-Verlag Berlin Heidelberg 2009 

Query Results Clustering by Extending SPARQL with CLUSTER BY

827

Web query language SPARQL [16] with CLUSTER BY statement that enhances SPARQL with grouping capabilities. The extension adds new syntax elements to the SPARQL grammar that facilitate clustering of query results. The paper proposes the grammar, as well as the semantics for this extension. The rest of the paper is structured as follows. In Section 2 the motivations and requirements for the new SPARQL extension are provided. Section 3 provides the details of the extension. Section 4 discusses possible realization of the framework. Section 5 discusses the related work, and Section 6 concludes the paper.

2

Motivation and Requirements

Why GROUP BY is Not Sufficient?. In order to provide the motivation and discuss the requirements for the new SPARQL extension let us present the following motivating scenarios. Scenario 1. The user Anna searches for natural monuments located in East-Central Europe. She would like to have the monuments grouped by their proximity. Scenario 2. The user Jos´e submits a query on Portuguese paintings. He wants the answers to be grouped by movements (styles of artworks). Classically, aggregation abilities are provided by SQL-like GROUP BY clause. Although GROUP BY is not officially supported by SPARQL, there are engines (for example Virtuoso2 , Jena3 ), that support the GROUP BY functionality. Despite that, after the analysis of the above scenarios, one can notice that classical GROUP BY semantics is not proper to solve either of the above tasks. Let us consider the first scenario. Would be grouping by longitude and latitude what the user Anna actually expects? GROUP BY semantics is to partition the results by identical values. Since no natural monuments share the same coordinates, as an effect of such grouping one row for each value would be created, which obviously would not meet the needs of the user. Let us further consider the second scenario. In this case it is possible that two paintings share the same style. However, by simply using GROUP BY the user Jos´e may still obtain too many groups to easily interpret them. For example the list of the art movements that belong to the avant-garde movement is as follows: art nouveau, conceptual art, cubism, expressionism and many more. Moreover the groups may be related to each other (e.g. by subclass-superclass relation) what is not captured by the semantics of the GROUP BY clause. Since the semantics of GROUP BY is ”crisp”, in both discussed cases the user obtains too many results. Notice also that in case of scenarios involving distributed and open environments, another general problem of GROUP BY may be the requirement for a user to understand the data apriori - before submitting a query. While grouping could be considered as helpful for users to understand the data granularity, the semantics of GROUP BY actually requires from users this knowledge to specify good grouping conditions in a query. 2 3

http://virtuoso.openlinksw.com http://jena.sourceforge.net/ARQ/

828

A. L  awrynowicz

Since there are problems with achieving the desired behaviour in a declarative fashion by means of classical GROUP BY, the proposition to extend SPARQL with CLUSTER BY statement is justified. Design Issues for CLUSTER BY. There are several issues that have been identified to address during the design of the functionality of the new SPARQL extension. These issues follow into two main categories: 1. What would be the output of a query with CLUSTER BY statement? 2. How to incorporate clustering algorithms and their parameters into the framework? As pointed out in [14], a SPARQL query consists of three parts. The pattern matching part offers the features of graph pattern matching like optional parts, union of patterns, filtering etc., and the possibility of indicating the data source to be matched by a pattern. The computed output of the pattern may be modified by solution modifiers, which are classical operators such as projection, distinct, order etc. The third part of the query is constituted by its output which may be of different types such as yes/no queries, selections of values of variables matching the patterns, construction of new triples, or description of resources. The desired semantics of the query enhanced with CLUSTER BY would be to provide the original query results itselves as well as the assigned clusters. It is also worth noting that some clustering algorithms are able to generate a hierarchy of clusters. Such hierarchy provides additional meaning to the generated clusters. It might be also desirable to provide an intensional description for each cluster to supply the user with the generalized information about the cluster content. These descriptions should be then retrieved as the result of a query as well. Taking into account the above considerations, as an answer to the first question, the following important design choices for the CLUSTER BY extension are proposed: – since clustering is supposed to operate on originally generated query results, we propose to integrate CLUSTER BY clause execution after the pattern matching part of a query, that is in its solution modifiers part, – we propose to separate all the metadata concerning the generated clusters (e.g. cluster descriptions, cluster hierarchy) from the results of a query themselves. In order to achieve this we propose to add to each result one variable that would store the identifier of the cluster assigned to the result. Moreover additionally to the cluster idenfitiers in the query answers, we propose to generate clustering metadata as the new output type in the form of a set of triples. To answer the second design question, one needs to provide a solution for incorporating the clustering algorithms execution to an effect of executing a query enhanced with CLUSTER BY. This incorporation should be seamless, that is any other steps should not be required to initiate the clustering process, except submitting a query itself. For this reason we propose to add additional syntax

Query Results Clustering by Extending SPARQL with CLUSTER BY

829

elements to SPARQL grammar that would allow the specification of the clustering parameters. In order to realize the proposed design choices we need to extend SPARQL by the new elements and define semantics for them. In the next section we describe the details of these extensions.

3 3.1

Extending SPARQL with CLUSTER BY Preliminary Definitions

Let I, B, and L be a pairwise disjoint sets of IRIs, blank nodes, and literals respectively. A triple (s, p, o) ∈ (I ∪ B) × I × (I ∪ B ∪ L) is called and RDF triple, where s is the subject, p the predicate and o the object. Let V be the infinite set of query variables disjoint from the above sets. A basic graph pattern (BGP) is a set of triple patterns which are RDF triples. An RDF graph is a set of RDF triples. A SPARQL query evaluation is based on matching graph patterns to subgraphs in the queried RDF graphs. A graph matching algorithm for evaluating SPARQL query tries to find an exhaustive set of mappings μ(v → t) of query variables v ∈ V to RDF terms t, where t is a member of the set union (I ∪B ∪L). A mapping μ is called a solution mapping. By Ω is denoted a multiset (or bag) of possible solution mappings. 3.2

Grammar of CLUSTER BY

One of the important goals of this work is to follow the original syntax and semantics of SPARQL as much as possible. Table 1 shows an excerpt of the grammar of SPARQL SELECT rule extended with CLUSTER BY. The extensions and new rules are shown in bold. The ClusterByClause statement is added to the standard SPARQL grammar rule of SolutionModifier. The ClusterByClause is further expanded, and a new keyword CLUSTER BY is introduced. After the CLUSTER BY keyword there should be specified a list of variables according to which the results are supposed to be clustered. Furthermore, a new keyword AS is introduced, after which there should be Table 1. The excerpt of the extended SPARQL grammar ::= ’SELECT’ ( ’DISTINCT’| ’REDUCED’ )? ( Cluster? Var+ | ’*’ ) DatasetClause* WhereClause SolutionModifier SolutionModifier ::= OrderClause? LimitOffsetClauses? ClusterByClause? SelectQuery

ClusterByClause UsingClause Cluster Method Params

::= ’CLUSTER’ ’BY’ Var+ ’AS’ Cluster UsingClause? ::= ’USING’ Method (’(’Params’)’)? ::= VAR1 ::= IRI REF ::= TriplesBlock

830

A. L  awrynowicz Table 2. Prefixes used in the paper

@prefix @prefix @prefix @prefix @prefix @prefix @prefix @prefix @prefix @prefix @prefix

rdf: . owl: . xsd: . dc: geo: dbpedia: dbpedia-owl: smo: sqrco: ex: art: .

specified a variable that would be bound to the identifier of the cluster. The same variable should be also listed in the variable list in the SelectQuery statement. To allow the specification of clustering parameters there is an optional UsingClause provided in the ClusterByClause. This clause can be omitted, which would indicate the query answering engine is supposed to use the default clustering method. The UsingClause adds a new keyword USING which is followed by an indentifier of a clustering method and optional list of the method parameters. As there are numerous clustering methods and algorithms available, in order to support flexible choice, we propose the parameters to be specified by a set of triples in which the terms from some common ontologies and vocabularies are used. Table 3 shows two example queries that correspond to the motivating scenarios from Section 2 and use the proposed syntax. All the prefixes used in the paper are listed in Table 2. 3.3

Semantics of CLUSTER BY

In order to enable specifying the cluster associated with an answer to SPARQL query we define a notion of clustered solution mappings. This definition is based on the definition of solution mapping as proposed in the SPARQL specification [16]. Definition 1 (Clustered Solution Mapping). A clustered solution mapping μ˙ is a pair (μ, c), where μ is a solution mapping (as defined in [16]), and c is a cluster identifier associated with μ. Furthermore, we propose a new algebra operator, called cluster assignement operator, that assigns cluster identifiers to solution mappings. To every solution mapping it adds a new variable binding which maps a literal representing cluster identifier to the specified variable. Definition 2 (Cluster Assignement Operator). Let Ω be a multiset of solution mappings, let v be a query variable which is not bound in any μ ∈ Ω, and let c denote the cluster identifier to which the variable v is bound. The result of an application of the cluster assignement operator is a multiset of clustered solution mappings Ω˙ and is defined as follows ClusterAssignement(v, Ω) = {μ|(μ, ˙ c) ∈ Ω˙ ∧ μ˙ = μ ∪ (v → c)}

Query Results Clustering by Extending SPARQL with CLUSTER BY

831

Table 3. Example queries in which the syntax of CLUSTER BY clause is used Query 1 SELECT ?x ?latitude ?longitude ?c WHERE ?x rdf:type ex:NaturalMonument ?x locatedIn ex:East_Central_Europe ?x geo:lat ?latitude ?x geo:long ?longitude CLUSTER BY ?latitude ?longitude AS ?c USING ( sqrco:usesAlgorithm smo:hasParam ?p1 ?p1 rdf:type sqrco:NumberOfClusters ?p1 owl:hasValue xsd:integer(’4’) ) Query 2 SELECT ?x ?y ?c WHERE ?x rdf:type art:Painting ?x dbpedia-owl:movement ?y ?z dc:authorOf ?x ?z dbpedia-owl:nationality dbpedia:Portugal CLUSTER BY ?y AS ?c USING ( sqrco:usesFeatureExtractionMethod )

In order to enable getting cluster metadata together with the clustered answers as a result of a query we define an additional operator, called cluster metadata operator. As an output this operator produces a cluster hierarchy and cluster descriptions which are defined below. Definition 3 (Cluster Hierarchy). A cluster hierarchy H is a partially ordered set C, , where each element c ∈ C is a cluster identifier, and  is a binary relation that imposes ordering on the elements of C. Definition 4 (Cluster Intensional Description). Let c ∈ C be a cluster identifier, and Ω˙ c be a set of clustered solutions of the form μ˙ i = (μi , c), i = 1, ..., n. A cluster intensional description d ∈ D gives a meaning of all elements μ˙ i ∈ Ω˙ c by specifying the necessary conditions that any element belonging to the set Ω˙ c meets.

832

A. L  awrynowicz

Finally the cluster metadata operator is defined. Definition 5 (Cluster Metadata Operator). Let Ω be a multiset of solution mappings. The result of an application of the cluster metadata operator consists of: a hierarchy H of cluster identifiers c ∈ C, and a set D of cluster intensional descriptions d: ClusterM etadata(v, Ω) = H ∪ D In general, it is allowed that D = ∅.

4

Realizing the Framework

The proposed framework for extending SPARQL does not prescribe any precise means to represent clustering parameters or clustering metadata such as cluster hierarchy and cluster descriptions. In order to implement the framework the ontology SPARQL Query Results Clustering Ontology (SQRCO) has been developed that enables representing input parameters for clustering and metadata of the obtained results. For representing the clustering parameters SQRCO uses the terms from SPARQL Mining Ontology (SMO) [8] ontology as well as it defines its own terms. Table 3 shows the usage of the terms from SQRCO (for instance NumberOfClusters) to represent input parameters of the clustering. The ontology is designed also to represent metadata of the generated clusters such as cluster identifiers, their hierarchical structure, and their intensional descriptions. For this purpose SQRCO includes concepts like ClusterID, IntensionalDescription, and properties parentOf, hasIntensionalDescription. The relation parentOf imposes ordering on the set of cluster identifiers which results in a hierarchy of cluster identifiers rooted at the cluster identifier root. For an illustration of how the terms from SQRCO are used to represent the generated clustering metadata Table 4 is provided that contains the example metadata for the art movements scenario discussed overall the paper. There are numerous possibilities of incorporating feature extraction techniques, clustering algorithms, as well as concept learning methods (for intensional descriptions generation) into the proposed framework. The properties of a particular solution, such as computational complexity, would depend on the methods and algorithms chosen to fill the framework. The detailed discussion of solutions is out of the scope of this paper. Some steps towards realizing an instantiation of the query results clustering idea have been done in the recent work [7,10] by the author of this paper. The work concerned query results clustering in case of data represented in Web Ontology Language (OWL), and included an implementation in JAVA, using KAON2 reasoning engine4 and Weka data mining software5 . The preliminary tests proved the feasibility of the query results clustering idea and its instantiation especially in terms of the running time which is crucial in on-the-fly query 4 5

http://kaon2.semanticweb.org http://www.cs.waikato.ac.nz/ml/weka

Query Results Clustering by Extending SPARQL with CLUSTER BY

833

Table 4. Set of triples representing clustering metadata with use of the terms from SQRCO ontology :root

a owl:Ontology .

:c3

a sqrco:ClusterID; sqrco:parentOf :c1, :c3 . a sqrco:ClusterID; sqrco:hasIntensionalDescription :desc1; sqrco:parentOf :c2 . a sqrco:ClusterID; sqrco:hasIntensionalDescription :desc2 . a sqrco:ClusterID .

:desc1 :desc2

a _:bn1 . a _:bn2 .

_:bn1

a owl:Class; owl:intersectionOf ( [ owl:onProperty art:characterizedBy; owl:someValuesFrom [ a owl:Class; owl:unionOf ( art:DramaticLight art:DramaticColour ) ] ] [ owl:hasValue "17th Century"^^xsd:string; owl:onProperty art:hasLinguisticPeriod ] )

:c1

:c2

_:bn2

rdf:type

.

art:Baroque .

results processing. This encouraged further work on the idea and its formalization provided in this paper, where the precise specification of the framework for invoking SPARQL query results clustering by extending the query language is proposed. Another solutions under the proposed framework are current or ongoing work.

5

Related Work

There are numerous extensions of SPARQL in the literature. These range from extensions for computing semantic associations [9], through extensions to process spatio-temporal data [15], data streams [2], and trust values [6]. However, to the best of our knowledge ours is the first work on extending SPARQL with clustering abilities. The SPARQL syntax does not even support the standard grouping, yet. However, some of the engines (already mentioned

834

A. L  awrynowicz

in the paper) implement GROUP BY clause functionality following the semantics known from SQL. The idea of grouping and aggregating SPARQL query results with the GROUP BY clause functionality different from that of SQL was investigated in [17]. This work has been inspired by the Web search results clustering engines, Clusty, and Carrot2. Recently there has been also an interest in clustering structured query results. However, there are very few works on this topic so far, and they concern clustering the results of SQL queries [11,18]. As such these works assume different language of database, as well as different language of queries. For example, the approach proposed in [11] is designed for numerical data, and the one proposed in [18] is designed for discrete spatial data. Nevertheless, introducing new constructs into queries whose semantics is to cluster query results has already been proposed in [11], and [18]. In [3,4] the methods for clustering the data represented in OWL (description logics) were proposed. Several approaches to clustering Semantic Web data were explored in [5]. However, those works do not assume the specific task of clustering query results that we address, nor they propose any extensions of SPARQL. The closest work to ours is the proposition of extending SPARQL with data mining abilities [8]. In that work, however, the idea is to first execute a special type of query to build a model of the data (by using a training set of data), and at the second stage, apply another kind of query for prediction or classification tasks using the already built model. This solution differs from what we wanted to achieve in the type of tasks addresed as well as in the functionality of the approach.

6

Summary and Future Work

The contribution of the paper is the proposition of a declarative way for invoking dynamic clustering of the results of queries submitted over Semantic Web data. In particular, the paper proposes the extension of SPARQL by a new statement, CLUSTER BY, that supplies SPARQL wih clustering abilities. The SPARQL grammar for the extension is proposed, and its semantics discussed. Some steps towards realizing the proposed framework are reported. The plan for the future work assumes work on the implementation of the clustering solutions that could be plugged into the proposed framework.

References 1. Berners-Lee, T., Hendler, J., Lassila, O.: The Semantic Web. Scientific American 284(5), 34–43 (2001) 2. Bolles, A., Grawunder, M., Jacobi, J.: Streaming SPARQL - Extending SPARQL to Process Data Streams. In: Bechhofer, S., Hauswirth, M., Hoffmann, J., Koubarakis, M. (eds.) ESWC 2008. LNCS, vol. 5021, pp. 448–462. Springer, Heidelberg (2008) 3. Fanizzi, N., d’Amato, C., Esposito, F.: Induction of Optimal Semi-distances for Individuals based on Feature Sets. In: Proc. of the DL 2007 Workshop (2007)

Query Results Clustering by Extending SPARQL with CLUSTER BY

835

4. Fanizzi, N., d’Amato, C., Esposito, F.: Conceptual Clustering and Its Application to Concept Drift and Novelty Detection. In: Bechhofer, S., Hauswirth, M., Hoffmann, J., Koubarakis, M. (eds.) ESWC 2008. LNCS, vol. 5021, pp. 318–332. Springer, Heidelberg (2008) 5. Grimnes, G.A., Edwards, P., Preece, A.D.: Instance Based Clustering of Semantic Web Resources. In: Bechhofer, S., Hauswirth, M., Hoffmann, J., Koubarakis, M. (eds.) ESWC 2008. LNCS, vol. 5021, pp. 303–317. Springer, Heidelberg (2008) 6. Hartig, O.: Querying Trust in RDF Data with tSPARQL. In: Aroyo, L., Traverso, P., Ciravegna, F., Cimiano, P., Heath, T., Hyv¨ onen, E., Mizoguchi, R., Oren, E., Sabou, M., Simperl, E. (eds.) ESWC 2009. LNCS, vol. 5554, pp. 5–20. Springer, Heidelberg (2009) 7. Jozefowska, J., Lawrynowicz, A., Lukaszewski, T.: Clustering results of conjunctive queries over knowledge bases in OWL. In: Proc. of ESWC 2009 poster session (2009) 8. Kiefer, C., Bernstein, A., Locher, A.: Adding Data Mining Support to SPARQL via Statistical Relational Learning Methods. In: Bechhofer, S., Hauswirth, M., Hoffmann, J., Koubarakis, M. (eds.) ESWC 2008. LNCS, vol. 5021, pp. 478–492. Springer, Heidelberg (2008) 9. Kochut, K., Janik, M.: SPARQLeR: Extended Sparql for Semantic Association Discovery. In: Franconi, E., Kifer, M., May, W. (eds.) ESWC 2007. LNCS, vol. 4519, pp. 145–159. Springer, Heidelberg (2007) 10. Lawrynowicz, A.: Grouping results of queries to ontological knowledge bases by conceptual clustering. In: Nguyen, N.T., Kowalczyk, R., Chen, S.-M. (eds.) ICCCI 2009. LNCS (LNAI), vol. 5796, pp. 504–515. Springer, Heidelberg (2009) 11. Li, C., Wang, M., Lim, L., Wang, H., Chang, K.C.-C.: Supporting ranking and clustering as generalized order-by and group-by. In: Proc. of SIGMOD 2007, pp. 127–138 (2007) 12. Osinski, S., Weiss, D.: Carrot2: Design of a Flexible and Efficient Web Information Retrieval Framework. In: Szczepaniak, P.S., Kacprzyk, J., Niewiadomski, A. (eds.) AWIC 2005. LNCS (LNAI), vol. 3528, pp. 439–444. Springer, Heidelberg (2005) 13. Osinski, S., Weiss, D.: A Concept-Driven Algorithm for Clustering Search Results. IEEE Intelligent Systems 20(3), 48–54 (2005) 14. P´erez, J., Arenas, M., Gutierrez, C.: Semantics and Complexity of SPARQL. In: Cruz, I., Decker, S., Allemang, D., Preist, C., Schwabe, D., Mika, P., Uschold, M., Aroyo, L.M. (eds.) ISWC 2006. LNCS, vol. 4273, pp. 30–43. Springer, Heidelberg (2006) 15. Perry, M., Sheth, A., Jain, P.: SPARQL–ST: Extending SPARQL to Support Spatiotemporal Queries, Kno.e.sis Center Technical Report. KNOESIS-TR-2009-01 (November 3, 2008), http://knoesis.org/students/prateek/sparql-st-www09-tr.pdf 16. Prud’hommeaux, E., Seaborne, A.: SPARQL Query Language for RDF. Technical report, W3C Recommendation (January 15, 2008) 17. Seid, D.Y., Mehrotra, S.: Grouping and Aggregate queries Over Semantic Web Databases. In: Proc. of ICSC 2007, pp. 775–782. IEEE Computer Society, Los Alamitos (2007) 18. Zhang, C., Huang, Y.: Cluster By: a new sql extension for spatial data aggregation. In: Proc. of 15th ACM International Symposium on Geographic Information Systems, ACM-GIS 2007, p. 53 (2007)

An Agent-Based Data Mining System for Ontology Evolution Maja Hadzic and Darshan Dillon Digital Ecosystems and Business Intelligence Institute, Curtin University of Technology GPO Box U1987, Perth 6845, Australia {m.hadzic, darshan.dillon}@curtin.edu.au

Abstract. We have developed an evidence-based mental health ontological model that represents mental health in multiple dimensions. The ongoing addition of new mental health knowledge requires a continual update of the Mental Health Ontology. In this paper, we describe how the ontology evolution can be realized using a multi-agent system in combination with data mining algorithms. We use the TICSA methodology to design this multi-agent system which is composed of four different types of agents: Information agent, Data Warehouse agent, Data Mining agents and Ontology agent. We use UML 2.1 sequence diagrams to model the collaborative nature of the agents and a UML 2.1 composite structure diagram to model the structure of individual agents. The Mental Heath Ontology has the potential to underpin various mental health research experiments of a collaborative nature which are greatly needed in times of increasing mental distress and illness. Keywords: ontology evolution, data mining, multi-agent system, multi-agent system design, mental health, mental health ontology.

1 Introduction The complex nature of mental health makes it a very interesting research topic. Most mental illnesses are poorly understood as they are caused by the interplay of multiple factors. The lack of understanding of mental illnesses, in combination with the rapid changes pervading our societies, is becoming a serious threat to mental health. The revolutionary development of technology has resulted in the rapid introduction of cutting-edge technologies into our societies. We have become very dependent on sophisticated technologies and the ways in which they have made our lives more comfortable. However, there is evidence to suggest that this material comfort has failed to bring us better health, greater inner peace and a greater sense of meaning, purpose and satisfaction [1]. While the lives of individuals may have improved in some ways, evidence in [1] suggests that the general health and well-being of individuals within our societies have deteriorated. Since 1960: (1) the divorce rate has doubled, (2) the teen suicide rate has tripled, (3) the recorded rate of violent crime has quadrupled, (4) the prison population has quintupled, (5) the percentage of babies born to unmarried parents has increased six fold, and (6) cohabitation (a predictor of future divorce [2]) has increased sevenfold. Moreover, it appears that these problems R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 836–847, 2009. © Springer-Verlag Berlin Heidelberg 2009

An Agent-Based Data Mining System for Ontology Evolution

837

are increasing over time, and are gaining momentum rather than being random events. The World Health Organization predicts that depression will most probably be the major cause of disability worldwide by 2020 [3]. Due to the complexity of the mental health domain, mental health research has been extended to include research from other knowledge domains. Mental illness is not simply a case of blood tests and prescription of medications. It is much more than that. There is a need for physiologists, molecular biologists, biochemists, neurologists, neuroscientists, psychologists, psychiatrists, drug therapists, herbalists, sociologists, theologises, etc. as well as information and computer scientists, to collaborate in their research. A large number of research teams are undertaking various studies to examine the relationship between mental health and other aspects of personal wellbeing such as physical health, finances, social relationships, emotional well-being and spirituality [4]. We have designed the Mental Health Ontology to define and represent these various aspects of mental health [4]. However, due to the rapid increase of newly derived knowledge, this Mental Health Ontology needs to be continually updated. We used the five-step TICSA methodology [6] to design a multi-agent system that supports the dynamic update of the Mental Health Ontology. The different agents of the systems cooperate and collaborate with each other to achieve this common goal. The collaborative effort of the various types of agents determines the performance of the multi-agent systems, namely, the efficiency of the Mental Health Ontology update. A number of techniques have been proposed for the ontology evolution and these are discussed in Section 2. In Section 3, we provide more detail about Mental Heath Ontology. In Section 4, we describe how we use the TICSA approach to design the multi-agent system for the ontology evolution. In this section, we discuss the five different steps of the TICSA methodology and explain the pattern matching approach used to validate the ontology update. We give our final remarks in Section 5.

2 State of Play A number of systems have been proposed and used for ontology evolution. Mao et al. [7] introduced a large-scale Web Ontology for Traditional Chinese Medicine (TCM). The authors highlight the need for ontologies to self-evolve and specialize in their domain knowledge. Specifically, they refer to the context-specific elements of the large-scale ontologies, namely, sub-ontologies. The local repository called an ‘ontology cache’ uses the sub-ontologies as they evolve. The sub-ontology evolution approach is based on a genetic algorithm for reusing large-scale ontologies. Triple-based encoding, fitness function, and genetic operators were used to support the evolution. In the system proposed by Afsharchi and Far [8], agents consult each other to identify new concepts and design an ontology to include these new concepts. Individual agents create and learn their own conceptualization. The learning of new concepts is supervised by other agents. The supervising agent uses positive and negative examples to teach this concept to an interested agent. The learning agent feeds this information into a concept learner. Voting and elimination of examples is used to resolve conflicts. This system has the potential to improve communication between different agents that operate using different ontologies.

838

M. Hadzic and D. Dillon

Ottens et al. [9] have developed Dynamo, a self-organizing multi-agent system, which (1) uses automatic text processing to create an ontology draft, and (2) interacts with a domain expert to finalize the ontology construction. The system uses newly added information to adapt the existing network of concepts. The system and the ontology designers modify the network in a cooperative way. Li and Yang [10] discuss an agent-based approach for managing ontology evolution in a Web services environment. They examine the inter-processes between different ontologies from the agent's perspective and apply an agent negotiation model in reaching agreement. Additionally, the authors describe an extended negotiation strategy which is expected to provide sufficient information in decision making in each round of negotiation. Numerous existing ontology-evolution systems make use of software agents. The difference between the existing approaches and our approach is that we aim to use data mining algorithms in the ontology evolution process.

3 Mental Health Ontology In our previous work [5], we introduced Mental Health Ontology as being composed of three sub-ontologies: Illness Type, Symptoms, Factor (Cause) and Treatment (see Figure 1).

Fig. 1. Top-level hierarchy of Mental Health Ontology

By collating information from the International Statistical Classification of Diseases and Related Health Problems, 10th Revision (ICD-10) published by the World Health Organization (WHO) [11] and the Diagnostic and Statistical Manual of Mental Disorders, Fourth Revision (DSM-IV) by the American Psychiatry Association [12], we have identified thirteen types of mental illnesses, including among others: psychotic disorders, anxiety disorders, personality disorders, mood disorders, substance-related disorders, etc. Each of the types is further classified into

An Agent-Based Data Mining System for Ontology Evolution

839

it subtypes. For example, ‘anxiety disorder’ is classified into eight different sub-types such as obsessive-compulsive disorder, panic disorder, social phobia, etc. The exact causes of mental illness are still unknown. We have classified the factors that affect mental health under the following five categories: (1) genetic, (2) physical, (3) environmental, (4) personal and (5) microorganisms. The genetic, physical, environmental, personal and microbial factors are interconnected and mutually dependent on one another. For this reason, we need to approach mental health as being a function of multiple dimensions. This necessitates the analysis of each dimension both individually and in relation to other dimensions. Genetic factors include variations/mutations of human DNA that affect mental health, such as the mutations in G72/G30 gene complex which is associated with schizophrenia [13]. Physical factors define and describe physical conditions that may affect mental health. For example, Vitamin B deficiency may result in depression, liver failure may cause hallucinations, multiple sclerosis may result in mood disorders, and tubercular meningitis may result in personality disorders. Additionally, it has been reported that physically active people tend to have better mental health [14]. For this reason, physical activity has been successfully used as a non-pharmacological treatment for depression [15,16]. Physical activity may reduce the symptoms of anxiety, improve social skills and cognitive functioning, and be a beneficial adjunct to programs that target alcoholism and substance abuse [17]. Environmental factors include factors surrounding us over which we have less control. These include our physical, financial and social environments. For example, our physical environment is determined by climate, living conditions, noise, pollution, etc. Social environment captures factors determined by our relationships with others. Kawachi & Berkman [18] highlight the beneficial roles that social ties play in individuals’ mental well-being. However, not all relationships are beneficial. It has been reported that the financial environment affects our health. Studies of the Data from the National Health Interview Survey, the National Survey of Families and Households, the Survey of Income and Program Participation indicate that increases in income significantly improve mental health [19]. However, the same study claims that increases in income increase the prevalence of alcohol consumption which in its turn may be damaging to both physical and mental health. Personal factors relate to the factors surrounding us over which we have more control. These include our beliefs, emotions and responses. Bergin [21] evaluates the effect of spirituality on mental health. He makes it clear that religion can have both positive and negative effects. The negative situations are marked by evil masquerading as religious dogma, namely, misuse of religion for selfish interests. The positive impact is marked by a highly individual experience, a true personal conviction or commitment and is manifested in dramatic personal healing or transformation. The effect of emotions on mental health has also been examined. Dr Colbert [20] defines destructive emotions in terms of their origin, nature and manifestations. He also explains the negative effect of these emotions on our health. Our immediate responses to complex situations can have a long-term impact on our mental health. Recently it was reported [22] that microorganisms such as ‘viruses’ or ‘bacteria’ may exist that could affect mental health. More research is required to explain why

840

M. Hadzic and D. Dillon

mental illness appears to be transmittable; is this caused by a microorganism or is the wellness/illness ‘contiguous’ ? As the mental health domain is still a grey area and the exact causes of mental disorders are unclear, the precise strategies for treatment cannot be developed at this stage. A number of studies have established the correlation between chemical imbalances in the brain and specific psychiatric conditions which subsequently led to the development of pharmacotherapy for mental health [27, 28]. However, a large number of psychoactive drugs produce serious side effects [23, 24, 25, 26]. In recent years, significant advances have been made in the field of psychotherapy, an interpersonal intervention which employs one or more of a range of specific psychological techniques facilitated through a psychotherapist. These include behavioral therapy [29, 30], cognitive therapy [31, 32], humanistic therapy [33], play therapy [34], psychodynamic therapy [35, 36] as well as rehabilitation programs. Group and family therapies are also often useful in assisting individuals to cope with stress. Most studies suggest that an integrated treatment approach involving both drugs and psychotherapy is more effective than either treatment method used alone [37, 38]. The three ontology ‘dimensions’ contain very different information and are orthogonal to each other. The Illness Type sub-ontology is more a classifying ontology and is strongly hierarchically supported. The Factor (Cause) sub-ontology is strongly based on scientific research and exposes the different kinds of factors that may affect our mental health, both positively and negatively. The Treatment subontology is a combination of classification and research ontology. Designing new drugs is research work but, for example, all the discovered drugs can be hierarchically classified. All three dimensions are different from each other and each dimension is unique. But jointly, they give an overall picture and a good overview of the current knowledge about mental health.

4 System Design In this section, we describe a multi-agent system that uses data mining algorithms in the intelligent update of the Mental Health Ontology. We have adopted the TICSA approach described in [6] to design the multi-agent system. The TICSA methodology consists of the following five steps: 1. 2. 3. 4. 5.

Identify Agent Types According to Their Responsibilities Define Agent’s Intelligence Define Agent’s Collaborations Protect the System by Implementing Security Requirements Assemble Individual Agents

4.1 Identify Agent Types According to Their Responsibilities In this step, we identify specific agent types and the corresponding function required to enable the intuitive flow of processes involved in the ontology evolution. Each agent works on a specific aspect of the overall problem with the various types of agents having different but complementary functions.

An Agent-Based Data Mining System for Ontology Evolution

841

Fig. 2. Information, Data Warehouse, Data Mining and Ontology agents

In our system, we make use of four different types of agents as shown in Figure 2: (1) Information agents, to extract raw data from various databases and upload them to a dedicated data warehouse; (2) Data Warehouse agent, to systematically manage the data within the data warehouse; (3) Data Mining agent, to mine the data from the warehouse, reveal interesting patterns from the data and derive new knowledge; (4) Ontology agent, to employ the derived knowledge to update the Mental Health Ontology. 4.2 Define Agent’s Intelligence The agents of the system need to be equipped with the knowledge that enables them to perform their task intelligently. They need to be able to identify and extract target data, to systematically store and manage data, to intelligently analyze the data, to communicate with each other, etc. The knowledge base has been predominantly used to provide agents with intelligence and enable them to perform their role efficiently and effectively. Some researchers prefer to use oontology rather than a knowledge base as the ontology is a more expressive knowledge model [39]. We use a combination of knowledge bases and ontologies in our system. 4.3 Define Agent’s Collaborations The effective collaboration between the different agent types contributes greatly to the efficiency of the system’s performance. In the multi-agent structure shown in Figure 1,

842

M. Hadzic and D. Dillon

the processing cycle starts from the Information agents. Information agents are situated over various databases and have access to mental health information such as experiential data and results. This network of Information agents can be set up for one specific research centre which undertakes several mental health projects. In this case, each database contains data and results specific to a particular research project. Another option is to set up the network of Information agents for an alliance of research centres sharing the same vision but working on different aspects of a mental health problem. In this case, each database contains data and results specific to a particular research centre. It is also possible for one research centre to have more than one database. Each Information agent extracts data of interest from its own database and sends it to the Data Warehouse agent. The database architecture is consistent throughout the system; i.e. the data found in different databases has the same format. This can be achieved with the help of ontologies. The consistent data structure enables the Data Warehouse agent to manage and integrate the data more easily. As the data originates from various databases, it is very likely that some overlaps and redundancies in the data will appear. The Data Warehouse agent analyses the incoming data and selects valid data. The selected data are systematically added to the data warehouse. The systematic addition of data enables the Data Mining agent to understand the data and mine them for interesting patterns. We have developed a number of data mining algorithms for both structured and semi-structured data. The Data Mining agent uses the existing algorithms such as those discussed in [40, 41] to derive interesting patterns from the mental health data. The derived information is forwarded to the Ontology agent. Ontology agent matches the newly derived information with the information contained in the Mental Heath Ontology. If exact overlap is found, the structure of the Mental Heath Ontology remains unchanged. If the comparison reflects some differences, the newly derived information is incorporated into the ontology structure. This last step is semi-automatic, requiring the assistance of a human agent to validate the newly introduced change. The multi-agent system can be represented using the UML 2.1 sequence diagram where composite classes have more than one port and can be used to represent different roles of the same agent. This will enable us to represent agents which play more than one role concurrently. A sequence diagram is generally defined across the page by a series of rectangles, each of which represents a class. A distinct agent can be represented by a rectangle at the head of the sequence diagram. Each of these rectangles has a dotted line running vertically down the page. These dotted lines are known as ‘lifelines’. As one goes down the page, time passes as messages flow between the agents. A single rectangle (agent) could have many ports (roles) without changing the semantics of the UML 2.1 sequence diagram. There are three points worth noting in our sequence diagram: (1) The lifelines of agents are solid throughout since agents tend to be persistent (2) Each rectangle represents a composite class which implements an agent type, and (3) Each distinct role played by an agent is represented by a distinct port on the rectangle with its own lifeline.

An Agent-Based Data Mining System for Ontology Evolution

Information Agent

Data W arehouse Agent

843

O ntology Agent

Data Mining Agent Collect

t e xt

t e xt

Send

Request new data. Request receipt confirmation.

Send mental illness data. Confirm data received. Request to extract knowledge. Knowledge extraction confirmation. Send extracted knowledge

Change suggestion.

Change decision. Return updated ontology.

Fig. 3. UML 2.1 Sequence Diagram that models inter-agent communication

From the sequence diagram shown in Figure 3, we can see that the user makes an initial request to the Information agent to extract data about mental illness from databases where it is stored (request new data). The Information agent responds to the user (request receipt confirmation) indicating that it has received the request. Once the Information agent has extracted this data, it sends the data to the Data Warehouse agent (send mental illness data) with a request that this agent input it into the data warehouse. As soon as the Data Warehouse agent gets the data from the Information agent, it sends a message back to the Information agent confirming that it has received the data (confirm data received). Once the Data Warehouse agent has put the new data into the data warehouse, it usually sends a request to the Data Mining Agent to use this data to extract new knowledge (request to extract knowledge). The Data Mining agent responds to the Data Warehouse agent to indicate that it received a request to extract knowledge from the data (knowledge extraction confirmation). Once the Data Mining agent has finished extracting the knowledge from the data, it sends that knowledge to the Ontology agent (send extracted knowledge). The Ontology agent uses that knowledge to do a comparison between the new knowledge and the existing ontology to see if there are any differences. The Ontology agent is then able to return a suggestion to the user as to whether or not the ontology should be updated, and if so, what the changes should be (change suggestion). The user then makes a decision as to what changes should be made, if any (change decision). Finally, the Ontology agent returns the final version of the ontology to the user (return updated ontology). As illustrated, the sequence diagram is a very rich modeling tool for describing the entire cycle from user request to user deliverable for this particular application with respect to inter-agent dynamics.

844

M. Hadzic and D. Dillon

Ontology Agent

Controller Collect

Knowledge/Ontology Comparison

Change Suggestion

Send

Ontology Update

Fig. 4. UML 2.1 composite structure diagram that models the Ontology agent

4.4 Protect the System by Implementing Security Requirements In our multi-agent system, all nine security requirements mentioned in [42] must be addressed. We discuss here the security requirements for Information agents. Analogously, we also address security requirements for other agents. We must ensure that the data available via databases are available only to Information agents (confidentiality). The access rights of the Information agents must be defined (access control). Identity of the Information agents must be verified (authentication). The ease of access and use of data by Information agents needs to be ensured (availability). Information agents must guarantee that the data provided to the Data Warehouse agents are identical to the data at the source database (integrity). Information agents must verify their involvement in communication/interaction with the database (non-repudiation). The Information agents must comply with the given set of rules and regulations established by the system designers (compliance). The Information agents must provide relevant and reliable information to the Data Warehouse agent (service). The Information agents must be fully committed to accomplishing their own goals and the overall goals of the system (commitment). 4.5 Assemble Individual Agents The structure of individual agents can be represented by a UML 2.1 composite structure diagram with parts and ports. Each part represents a distinct area of processing within the agent. Each port represents a different role played by the agent. Since a regular composite structure diagram does not have these semantics, we have created the stereotype to reflect these additional meanings. Here we will discuss the internal structure of the Ontology agent. An analogous approach applies for the other agent types. The following is a UML 2.1 composite structure diagram based on this stereotype [40]. It represents the internal processing of the Ontology agent. It has four distinct areas of processing. Firstly, there is a Controller part that manages all the other parts

An Agent-Based Data Mining System for Ontology Evolution

845

and directs inputs, outputs, and internal data flows. The part labeled Knowledge/Ontology Comparison is responsible for taking the new knowledge extracted by the Data Mining agent, and comparing it with the ontology to determine any differences between the two. This will provide a basis for suggested updates to the ontology, if any. The next processing step for the Ontology agent is to determine whether changes are required and if so, what they could be (Change Suggestion). Finally, once the user makes a decision, the Ontology agent will need to actually make the required changes to the existing ontology (Ontology Update). The Ontology agent plays two distinct roles and these are reflected by the two ports (Collect, Send) at the border of the composite structure diagram. Our use of UML 2.1 permits us to effectively model some of the key internal characteristics of the Ontology agent.

5 Conclusion We have developed an evidence-based ontological model that defines the mental health domain. Due to the constant increase of knowledge regarding mental health, this Mental Health Ontology requires continual update. We have utilized the TICSA (Types, Intelligence, Collaboration, Security and Assembly) approach to design a multi-agent system that will automate the ontology update using the synergy of data mining and agent technologies. We have envisioned this project to involve various mental health research centres which will provide data in order to address and encompass different aspects of mental health. This architecture will support the creation of a world-wide collaborative environment which is greatly needed in a time of increasing mental distress and illness. We are in the early implementation stage of the system, and our progress will be reported in subsequent papers.

References [1] Myers, D.G.: The American Paradox: Spiritual Hunger in an Age of Plenty. Yale University Press (2000) [2] Hall, D.R., Zhao, J.Z.: Cohabitation and Divorce in Canada: Testing the Selectivity Hypothesis. Journal of Marriage and the Family 57, 421–427 (1995) [3] Lopez, A.D., Murray, C.C.J.L.: The Global Burden of Disease, 1990-2020. Nature Medicine 4, 1241–1243 (1998) [4] Hadzic, M., Chen, M., Brouwer, R.: A Modern Approach to Total Well-being. In: Ulieru, M., Palensky, P., Doursat, R. (eds.) IT Revolutions 2008. LNICST, vol. 11, pp. 140–150. Springer, Heidelberg (2009) [5] Hadzic, M., Chen, M., Dillon, T.S.: Towards the Mental Health Ontology. In: Proceedings of the IEEE International Conference on Bioinformatics and Biomedicine, USA (2008) [6] Hadzic, M., Chang, E.: TICSA Approach: Five Important Aspects of Multi-agent Systems. In: Proceedings of the International IFIP Workshop on Semantic Web & Web Semantics, On The Move Federated Conferences, Mexico (2008) [7] Mao, Y., Wu, Z., Tian, W., Jiang, X., Cheung, W.K.: Dynamic sub-ontology evolution for traditional Chinese medicine web ontology. Journal of Biomedical Informatics 41, 790–805 (2008)

846

M. Hadzic and D. Dillon

[8] Afsharchi, M., Far, B.H.: Automated Ontology Evolution in a Multi-Agent System. In: Proceedings of the First International Conference on Scalable Information Systems, Hong Kong (2006) [9] Ottens, K., Aussenac-Gilles, N., Gleizes, M.-P., Camps, V.: Dynamic Ontology CoEvolution from Texts: Principles and Case Study. In: Proceedings of the International Workshop on Emergent Semantics and Ontology Evolution, Korea (2007) [10] Li, L., Yun, Y.: Agent negotiation based ontology refinement process and logo mechanisms for service applications. In: Service Oriented Computing and Applications, vol. 2/1, pp. 15–25. Springer, Heidelberg (2008) [11] World Health Organization: International Statistical Classification of Diseases and Related Health Problems, 10th Revision, World Health Organization (2007) [12] American Psychiatric Association: Diagnostic and Statistical Manual of Mental Disorders, 4th edn., Text Revision (DSM-IV-TR). American Psychiatric Publishing (2000) [13] Goldberg, T.E., Straub, R.E., Callicott, J.H., Hariri, A., Mattay, V.S., Bigelow, L., Coppola, R., Egan, M.F., Weinberger, D.R.: The G72/G30 Gene Complex and Cognitive Abnormalities in Schizophrenia. Neuropsychopharmacology 31, 2022–2032 (2006) [14] U.S. Surgeon General’s Report on Physical Activity and Health (1996) [15] Phillips, W.T., Kiernan, M., King, A.C.: Physical Activity as a Nonpharmacological Treatment for Depression: A Review. Complementary Health Practice Review 8(2), 139– 152 (2003) [16] Pilu, A., Sorba, M., Hardoy, M.C., Floris, A.L., Mannu, F., Seruis, M.L., Velluti, C., Carpiniello, B., Salvi, M., Carta, M.G.: Efficacy of Physical Activity in the Adjunctive Treatment of Major Depressive Disorders: Preliminary Results. Clinical Practice and Epidemiology in Mental Health 3 (2007) [17] Taylor, C.B., Sallis, J.F., Needle, R.: The Relation of Physical Activity and Exercise to Mental Health. Public Health Report 100(2), 195–202 (1985) [18] Kawachi, I., Berkman, L.F.: Social Ties and Mental Health. Journal of Urban Health 78(3), 458–467 (2001) [19] Ettner, S.: New Evidence on the Relationship between Income and Health. Journal of Health Economics 15(1), 67–85 (1996) [20] Colbert, D.: Deadly Emotions: Understand the Mind-Body-Spirit Connection that can Heal or Destroy You. Thomas Nelson (2003) [21] Bergin, A.E.: Values and Religious Issues in Psychotherapy and Mental Health. American Psychologist 46(4), 394–403 (1991) [22] Wenner, M.: Infected with Insanity: Could Microbes Cause Mental Illness. Scientific American (2008), http://www.sciam.com/article.cfm?id=infected-with-insanity [23] Pacher, P., Kecskemeti, V.: Cardiovascular Side Effects of New Antidepressants and Antipsychotics: New Drugs, Old Concerns? Current Pharmaceutical Design 10(20), 2463– 2475 (2004) [24] Check, E.: Antidepressants: Bitter pills. Nature 431, 122–124 (2004) [25] Friedman, R.A., Leon, A.C.: Expanding the Black Box-Depression, Antidepressants, and the Risk of Suicide. The New England Journal of Medicine 356, 2343–2346 (2007) [26] Werneke, U., Northey, S., Bhugra, D.: Antidepressants and sexual dysfunction. Acta Psychiatrica Scandinavica 114(6), 384–397 (2006) [27] Schildkraut, J.J.: The catecholamine hypothesis of affective disorders: a review of supporting evidence. American Journal of Psychiatry 122, 609–622 (1965) [28] Oke, A.F., Adams, R.N.: Elevated thalamic dopamine: possible link to sensory dysfunctions in schizophrenia. Schizophrenia Bulletin 13(4), 589–604 (1987)

An Agent-Based Data Mining System for Ontology Evolution

847

[29] Lindsley, O., Skinner, B.F., Solomon, H.C.: Studies in behavior therapy (Status Report I). Metropolitan State Hospital, Walthama (1953) [30] Clark, D.M., Fairburn, C.G.: Science and Practice of Cognitive Behaviour Therapy. Oxford University Press, Oxford (1997) [31] Beck, A.T.: Cognitive Therapy and the Emotional Disorders. International Universities Press (1975) [32] Scott, J., Williams, J.M., Beck, A.T.: Cognitive Therapy in Clinical Practice: An Illustrative Casebook. Routledge (1989) [33] Aanstoos, C., Serlin, I., Greening, T.: History of Division 32 (Humanistic Psychology) of the American Psychological Association. In: Dewsbury, D. (ed.) Unification through Division: Histories of the divisions of the American Psychological Association. American Psychological Association, V, Washington (2000) [34] Ray, D., Bratton, S., Rhine, T., Jones, L.: The effectiveness of play therapy: Responding to the critics. International Journal of Play Therapy 10/1, 85–108 (2001) [35] Leichsenring, F.: The effectiveness of psychodynamic therapy, A review using criteria of evidence-based medicine. Zeitschrift Fur Psychosomatische Medizin Und Psychotherapie 48/2, 139–162 (2003) [36] Reck, C., Mundt, C.: Psychodynamic therapy approaches in depressive disorders. Pathogenesis models and empirical principles. Der Nervenarzt 73(7), 613–619 (2002) [37] Klerman, G.L., Dimascio, A., Weissman, M.: Treatment of depression by Drugs and Psychotherapy. American Journal of Psychiatry 131, 186–191 (1974) [38] Saeed, A.: Integrated Psychiatric Treatment for Mental Disorders. The Journal of the Royal Society for the Promotion of Health 108/3, 107–109 (1988) [39] Maedche, A.D.: Ontology Learning for the Semantic Web. Kluwer Academic Publishers, Norwell (2003) [40] Hadzic, F., Dillon, T.S., Tan, H., Feng, L., Chang, E.: Mining Frequent Patterns using Self-Organizing Map. In: Tanier, D. (ed.) Advances in Data Warehousing and Mining Series. Idea Group Inc. (2007) [41] Hadzic, M., Hadzic, F., Dillon, T.S.: Domain Driven Tree Mining of Semi-structured Mental Health Information. In: Cao, L., Yu, P.S., Zhang, C., Zhang, H. (eds.) Data Mining for Business Applications. Springer, Heidelberg (2009) [42] Dillon, D.S., Dillon, T.S., Chang, E.: Using UML 2.1 to model Multi-Agent Systems. In: Proceedings of the 6th IFIP Workshop on Software Technologies for Future Embedded and Ubiquitous Systems, Italy (2008)

A Hybrid Concept Similarity Measure Model for Ontology Environment Hai Dong, Farookh Khadeer Hussain, and Elizabeth Chang Digital Ecosystems and Business Intelligence Institute, Curtin University of Technology, GPO Box U1987 Perth, Western Australia 6845, Australia {hai.dong,farookh.hussain,elizabeth.chang}@cbs.curtin.edu.au

Abstract. In this paper, we present a hybrid concept similarity measure model for the ontology environment. Whilst to date many similar technologies have been developed for semantic networks, few of them can be directly applied to the semantic-rich ontology environment. Before the measure model is adopted, an ontology is required to be converted into a lightweight ontology space, and within it all the ontology concepts need to be transformed into the pseudoconcepts. By means of this model, ontology concept similarities are measured respectively based on the content of pseudo-concepts and the structure of the lightweight ontology space. Afterwards, the two aspects of concept similarity are leveraged as the eventual product. In addition, an experiment is conducted to evaluate the measure model based on a small ontology. Conclusions are drawn and future works are planned in the final section. Keywords: concept similarity measure, latent semantic indexing, ontology, semantic similarity models.

1 Introduction Semantic relatedness refers to human judgment about the extent to which a given pair of concepts are related to each other [1]. Studies have shown that most people agree on the relative semantic relatedness of most of pairs of concepts [2, 3]. Therefore, approaches are required in order to measure the extent of semantic relatedness and similarity between concepts. In fact, many such techniques have been developed in the field of information retrieval (IR) [4-6], Natural Language Processing (NLP) [710], medicine [11], and bioinformatics [1, 12, 13] etc. In the field of computer science, ontology is defined by Gruber [14] as “an explicit specification of conceptualization”, which comprises objects (concepts) and relations among objects (concepts). It seems that the existing semantic similarity models can be directly applied to the ontology environment, in order to compute the ontology concept similarities. However, there are two issues observed in the existing semantic similarity models when applying them to the ontology environment, which are described as follows: •

Most of the models are designed for semantic networks. A semantic network is defined as “a graphic notation for representing knowledge in patterns of

R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 848–857, 2009. © Springer-Verlag Berlin Heidelberg 2009

A Hybrid Concept Similarity Measure Model for Ontology Environment

•

849

interconnected nodes and arcs” [15]. WordNet is a typical example of a semantic network, in which words or phrases are represented as nodes and are linked by multiple relations. Current semantic similarity models focus on estimating similarities between nodes. Since these nodes normally consist of single words or simple phrases, these models ignore the content of the nodes and deduce similarities based on the relative distance between the nodes or the position of the nodes in the whole semantic network. Nevertheless, in the ontology environment, each ontology concept is defined with semantic-rich contents. For example, in the Web Ontology Language (OWL), each class is defined by its annotation properties, data type properties, object properties, and so on. Hence, it is obvious that the content of ontology concept cannot be ignored when computing concept similarities within the ontology environment. Most of the models are designed for definitional networks. A definitional network is a subset of semantic networks, in which the only type of relation is class/subclass, or called is-a [15]. Therefore, it is easy to visualize that each definitional network is a hierarchy of nodes linked by the is-a relations. In contrast, an ontology is more complicated than a definitional network. Although most ontologies also follow a hierarchical structure, the types of relations among concepts are more flexible and customizable. Obviously, the existing semantic similarity models may meet challenges when dealing with the multi-relational ontologies.

In order to address the two issues above, in this paper, we propose a hybrid concept similarity measure model, by considering both the aspect of the concept content-based similarity measure and the aspect of the ontology structure-based similarity measure, with the purpose of measuring concept similarities within the ontology environment. The remainder of the paper is structured as follows: in Section 2 we present a framework of a lightweight ontology space for dealing with the issue of multirelations within the ontology environment; in Section 3 we present a hybrid concept similarity measure model based on the framework; in Section 4 we implement an evaluation to the model in terms of a case study; the conclusion and future works are presented in the final section.

2 Converting an Ontology to a Lightweight Ontology Space Before we present our hybrid concept similarity measure model, in order to solve the problem of multiple relations within the ontology environment, we are required to convert an ontology to a lightweight ontology space in which our proposed model can be applied. Here we define the lightweight ontology space, which comprises two basic definitions as follows: Definition 1. Pseudo-concept ς It is well known that in semantic web documenets (SWD), there are various relations available among ontology concepts. Therefore, it is necessary and challenging to take into account these relations when computing the similarity among concepts. To overcome this challenge, we define a pseudo-concept ς for a ontology concept c as a

850

H. Dong, F.K. Hussain, and E. Chang

combination of (c, α, δ, ο, γo), where in the RDFS/OWL-annotated semantic web documents (SWDs), c is the name (or Uniform Resource Identifier (URI)) of the concept c, α is the annotation property(s) of the concept c, δ is the datatype property(s) of the concept c, o is the object property(s) of the concept c, and γo is the name(s) of the object concept(s) to which o relates. Definition 2. Lightweight Ontology Space Based on the pseudo-concepts, we define a lightweight ontology space as a space of pseudo-concepts, in which the pseudo-concepts are linked only by is-a relations. An is-a relation is a generalization/specification relationship between an upper generic pseudo-concept and a lower specific pseudo-concept. The lower concept inherits all the properties of the upper concept. In fact, the is-a relation often appears in SWDs, e.g., it can be represented as in RDFS and OWL. As a result, when transforming an ontology to a lightweight ontology space, we need to reserve the is-a relations and encapsulate all other properties into the pseudo-concepts. Subsequently, we use an example in order to illustrate the process that converts an ontology to a lightweight ontology space. Fig. 1 presents an example of an ontology – a camera ontology, which originates from the cognominal ontology given by the Protégé-OWL tutorial [16]. We can see that there are seven concepts involved in this ontology linked by two different types of relations – is-a and has. To convert this camera ontology to a lightweight ontology space, we must encapsulate the has relations and reserve the is-a relations. According to the two definitions above, the lightweight ontology can be found in Fig. 2, in which each pseudo-concept is represented below: ς1= {Purchasable_Item} ς2= {Camera, has, Storage_Device} ς3= {Storage_Device} ς4= {Digital_Camera, has, Memory_Card}

Fig. 1. An example of ontology– a camera ontology

A Hybrid Concept Similarity Measure Model for Ontology Environment

851

Purchasable_Item ς1

Camera

Storage_Device

ς2

ς3

Digital_Camera

Film_Camera

Film

Memory_Card

ς4

ς5

ς6

ς7

Fig. 2. The lightweight ontology for the camera ontology

ς5= {Film_Camera, has, Film} ς6= {Film} ς7= {Memory_Card} We need to construct a pseudo-concept for an ontology concept because each pseudoconcept comprises almost all the properties that can be used to comprehensively define a concept and thus we can recognize a pseudo-concept as the textual description of a concept, which makes it possible to measure the similarity of two concepts by contrasting the contents of their pseudo-concepts.

3 A Hybrid Concept Similarity Measure Model It is recognized that many available IR approaches can be utilized to compute concept similarities based on the content of pseudo-concepts. However, we observe an issue here – whereas the similarity of two concepts can be measured by contrasting the content of their pseudo-concepts, this approach is not sufficient to reveal the extent of their similarity. The reason is that an ontology can be represented as a graph in which each concept is a node and relations are arcs among the nodes, and obviously the similarity of two nodes also relates to the structure of the graph and the relative distance between the two nodes [4, 17]. Jiang et al. [17]’s model inspires us to integrate the factor of the pseudo-concept content and the factor of the lightweight ontology structure to compute the extent of similarity between two concepts. In this section, we present a hybrid concept similarity measure model integrating the two factors above. Our proposed hybrid model involves two sub-models. The first sub-model measures the concept similarities based on the content of pseudo-concepts, by means of the Latent Semantic Indexing (LSI) approach [18]. The second submodel measures the concept similarities based on the structure of lightweight ontology graph, by means of an approach originating from the enhanced topic-based

852

H. Dong, F.K. Hussain, and E. Chang

vector model (eTVSM) [17]. The product of the two sub-models is two conceptconcept matrixes. Then we integrate the two matrices to obtain a new concept-concept matrix that indicates the extent of similarity between concepts. To illustrate the working mechanism of the hybrid model, we will compute the concept similarity values for the camera ontology displayed in Fig.1. 3.1 Pseudo-Concept Content-Based Concept Similarity Measure Model As described earlier, a pseudo-concept can be regarded as a textual description of a concept. In this section, we propose to make use of the LSI model to compute the extent of similarity between each pair of concepts of an ontology based on the extent of their pseudo-concepts. The main reason for applying the LSI model is to construct a concept-concept matrix for an ontology in which each element is the similarity value between the two corresponding concepts. This matrix is the product of a normalized concept-index term matrix and its transposed matrix. The normalized concept-index term matrix is obtained by the tf-idf model [19] and by normalizing each row to 1. Finally, all pairwise concept similarity values from the ontology example presented in Section 2 are given in Table 1. Table 1. Pseudo-concept content based concept similarity values for the camera ontology

c1 c2 c3 c4 c5 c6 c7

c1 1 0 0 0 0 0 0

c2 0 1 0.5 0.11 0.11 0 0

c3 0 0.5 1 0 0 0 0

c4 0 0.11 0 1 0.11 0 0.5

c5 0 0.11 0 0.11 1 0.5 0

c6 0 0 0 0 0.5 1 0

c7 0 0 0 0.5 0 0 1

3.2 Lightweight Ontology Structure-Based Concept Similarity Measure Model As mentioned earlier, the structure-based approach originates from the topic similarity measure model for the topic map environment. In our model, we employ this method in the environment of the lightweight ontology space. As there is only one type of relation in the lightweight ontology space, the weights of relations can be viewed as equal and the issue of weights of relations can be ignored in the measurement process. The process of computing the extent of the concept similarity can be divided into two processes: 1) determining the pseudo-concept vectors based on a lightweight ontology structure; 2) obtaining a concept similarity matrix by means of the scalar product of the pseudo-concept vectors. The operational vector space dimensionality is specified by the number of pseudo-concepts in a lightweight ontology space. The heuristics behind this process can be found from [17]. Finally, the pair-wise concept similarity values from the camera ontology in Fig. 1 are given in Table 2.

A Hybrid Concept Similarity Measure Model for Ontology Environment

853

Table 2. Lightweight ontology structure based concept similarity values for the camera ontology

c1 c2 c3 c4 c5 c6 c7

c1 1 0.83 0.83 0.76 0.76 0.76 0.76

c2 0.83 1 0.4 0.91 0.91 0.36 0.36

c3 0.83 0.4 1 0.36 0.36 0.91 0.91

c4 0.76 0.91 0.36 1 0.66 0.33 0.33

c5 0.76 0.91 0.36 0.66 1 0.33 0.33

c6 0.76 0.36 0.91 0.33 0.33 1 0.66

c7 0.76 0.36 0.91 0.33 0.33 0.66 1

3.3 Integrating the Products of the Two Models Section 3.1 and Section 3.2 present two concept similarity matrixes (C and L) based on the pseudo-concept content and the lightweight ontology structure respectively. In this section, we leverage both of these matrices in order to yield a new matrix that is able to indicate the similarities among concepts in a more precise manner. We define a matrix S in which each element is the weighted arithmetic mean between counterparts in matrices C and L as shown in Equation (1). The similarity value between two concepts is also the weighted arithmetic mean between the content-based concept similarity value (simc(ci, cj)) and the structure-based concept similarity value (sims(ci, cj)).

Si , j = sim(ci , c j ) = (1 − β ) simc (ci , c j ) + β sims (ci , c j ) = (1 − β )Ci , j + β Li , j

(1)

(0 ≤ β ≤ 1)

When β=0.5, sim(ci, cj) equals to the arithmetic mean between simc(ci, cj) and sims(ci, cj). Returning to the ontology example in Fig. 1, the pair-wise concept similarity values when β=0.5 are shown in Table 3. Table 3. Combined concept similarity values for the camera ontology (β=0.5)

c1 c2 c3 c4 c4 c6 c7

c1 1 0.42 0.42 0.38 0.38 0.38 0.38

c2 0.42 1 0.45 0.51 0.51 0.18 0.18

c3 0.42 0.45 1 0.18 0.18 0.46 0.46

c4 0.38 0.51 0.18 1 0.39 0.17 0.42

c4 0.38 0.51 0.18 0.39 1 0.42 0.17

c6 0.38 0.18 0.46 0.17 0.42 1 0.33

c7 0.38 0.18 0.46 0.42 0.17 0.33 1

4 Evaluation In order to evaluate the hybrid concept similarity measure model that we proposed in this paper, based on our ontology example in Fig. 1, we compare the results from the hybrid model with the results from the content (LSI)-based model, in order to decide which group of results is closer to our perception of the objective world. First of all, let us analyze the results from the content-based model in Table 1. We interpret the results by providing a descending sequence of similar concepts for each

854

H. Dong, F.K. Hussain, and E. Chang

concept in the camera ontology, which are shown in Table 4. By reviewing the interpretation from Table 4, we find the following problems from the content-based concept similarity matrix: (1) The extent of the similarity between c1 and c2 to c6 should be able to be measured. (2) Film_Camera and Digital_Camera should be put prior to Storage_Device as the more similar concepts of Camera. (3) Storage_Device should be similar to Film and Memory_Card other than Camera. (4) Camera and Film_Camera should be closer to Digital_Camera other than Memory_Card. (5) The most similar concept of Film should be Storage_Device and Memory_Card other than Film_Camera. (6) Camera and Digital_Camera should be closer to Film_Camera other than Film. (7) The most similar concept of Memory_Card should be Storage_Device and Film other than Digital_Camera. Table 4. Interpretation of the content-based concept similarity values for the camera ontology Concept No. c1 c2 c3 c4 c5 c6 c7

Concept Purchasable_Item Camera Storage_Device Digital_Camera Film_Camera Film Memory_Card

Descending sequence of similar concepts Storage_Device>Film_Camera=Digital_Camera Camera Memory_Card>Camera=Film_Camera Film>Camera=Digital_Camera Film_Camera Digital_Camera

Second, we start to analyze the matrix obtained by the hybrid model from Table 3. The interpretation of the model for each concept of the camera ontology can be found from Table 5. Table 5. Interpretation of the hybrid concept similarity values for the camera ontology Concept No.

Concept

c1

Purchasable_Item

c2

Camera

c3

Storage_Device

c4

Digital_Camera

c5

Film_Camera

c6

Film

c7

Memory_Card

Descending sequence of similar concepts Camera=Storage_Device>Digital_Camera=Digital_C amera= Film=Memory_Card Film_Camera=Digital_Camera>Storage_Device>Pur chasable_Item>Film=Memory_Card Film=Memory_Card>Camera>Purchasable_Item>Fil m_Camera=Digital_Camera Camera>Memory_Card>Film_Camera>Purchasable_ Item>Storage_Device>Film Camera>Film>Digital_Camera>Purchasable_Item>St orage_Device>Memory_Card Storage_Device>Film_Camera>Purchasable_Item>M emory_Card>Camera>Digital_Camera Storage_Device>Digital_Camera>Purchasable_Item> Film>Camera>Film_Camera

A Hybrid Concept Similarity Measure Model for Ontology Environment

855

The defect of this table is that it ranks and returns all available concepts for each concept in the ontology. However, in the real life, users usually only need the most similar concepts for each concept and the less similar concepts may be ignored. Therefore, there is a need for filtering some concepts with weak similarities and we need to set up a filter bar to remove some less similar concepts. There are two usual ways of setting up a filter bar, which are: • •

Choosing a threshold value, in other words, the concepts with lower similarities than the threshold value are filtered from the ranked list for each concept. Choosing a filter concept, in other words, the concepts ranked behind the filter concept are abandoned from the ranked list for each concept.

In this experiment, we use the second method to filter the less similar concepts. Since the root concept is used to define the domain of the ontology, and all the other concepts are theoretically relevant to this concept, it is unnecessary to include this concept when obtaining concept similarities. Hence, we choose Purchasable_Item as the filter concept, and the filtered results are shown in Table 6. Table 6. Interpretation of the filtered hybrid concept similarity values for the camera ontology Concept No. c2 c3 c4 c5 c6 c7

Concept Camera Storage_Device Digital_Camera Film_Camera Film Memory_Card

Descending sequence of similar concepts Film_Camera=Digital_Camera>Storage_Device Film=Memory_Card>Camera Camera>Memory_Card>Film_Camera Camera>Film>Digital_Camera Storage_Device>Film_Camera Storage_Device>Digital_Camera

Compared with Table 4, we find that these results correct almost all the problems found from Table 4, which can basically agree with our perception of the extent of similarity between concepts within the camera ontology. Therefore, by means of this experiment, we preliminarily prove that the hybrid concept similarity model is more precise than the content-based model, which provides a better set of answers to human’s perceptions of the relations between objects in the world.

5 Conclusion and Future Work In this paper, by means of analyzing the existing semantic similarity models, we observe two issues when applying them to the ontology environment. The first is that these models ignore the content of ontology concepts; the second is that these models can be used only for the semantic networks in which nodes are only linked with is-a relations. In order to solve the two issues, we design a concept similarity measure model for the ontology environment. This model considers both the content and structure of the ontology. In order to realize this model, first of all, we need to convert an ontology to a lightweight ontology space, which preserves the is-a relations and combines other relations as the content of the ontology concepts. For the contentoriented concept similarity measure, we employ the LSI model and generate a

856

H. Dong, F.K. Hussain, and E. Chang

concept-concept similarity matrix. For the structure-oriented concept similarity measure, we employ the topic similarity measure approach, in order to create another matrix. Eventually, we combine the two matrices and produce a new concept-concept similarity matrix. In order to evaluate the performance of this model, in terms of a camera ontology, we compare the product of the model with the product of the LSI model. The comparison indicates that the former has better performance than the latter. Additionally, we intend to implement our concept similarity model in the large-scale knowledge base. Moreover, we intend to compare the performance of our method against contemporary approaches in the literature. At the time of writing this paper, we have conducted the above research comparison work and have documented in [20].

References 1. Pedersen, T., Pakhomov, S.V.S., Patwardhan, S., Chute, C.G.: Measures of semantic similarity and relatedness in the biomedical domain. Journal of Biomedical Informatics 40, 288–299 (2006) 2. Miller, G., Charles., W.: Contextual correlates of semantic similarity. Language and Cognitive Processes 6, 1–28 (1991) 3. Rubenstein, H., Goodenough, J.B.: Contextual Correlates of Synonymy. Communications of the ACM 8, 627–633 (1965) 4. Rada, R., Mili, H., Bicknell, E., Blettner, M.: Development and Application of a Metric on Semantic Nets. IEEE Transactions on Systems, Man and Cybernetics 19, 17–30 (1989) 5. Srihari, R.K., Zhang, Z.F., Rao, A.B.: Intelligent indexing and semantic retrieval of multimodal documents. Information Retrieval 2, 245–275 (2000) 6. Sussna, M.: Word Sense Disambiguation for Free-text Indexing Using a Massive Semantic Network. In: The Second International Conference on Information and Knowledge Management (CIKM 1993), pp. 67–74. ACM, Washington (1993) 7. Li, Y., Bandar, Z.A., McLean, D.: An Approach for Measuring Semantic Similarity between Words Using Multiple Information Sources. IEEE Transactions on Knowledge and Data Engineering 15, 871–882 (2003) 8. Lin, D.: Automatic retrieval and clustering of similar words. In: the 17th COLING, pp. 768–774. ACM, Austin (1998) 9. Resnik, P.: Semantic similarity in a taxonomy: an information-based measure and its application to problems of ambiguity in natural language. Journal of Artificial Intelligence Research 11, 95–130 (1999) 10. Rosenfield, R.: A maximum entropy approach to adaptive statistical modelling. Computer Speech and Language 10, 187–228 (1996) 11. Steichen, O., Bozec, C.D., Thieu, M., Zapletal, E., Jaulent, M.C.: Computation of semantic similarity within an ontology of breast pathology to assist inter-observer consensus. Computers in Biology and Medicine 36, 768–788 (2006) 12. Othman, R.M., Deris, S., Illias, R.M.: A genetic similarity algorithm for searching the Gene Ontology terms and annotating anonymous protein sequences. Journal of Biomedical Informatics 41, 65–81 (2008) 13. Sevilla, J.L., Segura, V.c., Podhorski, A., Guruceaga, E., Mato, J.M., Martínez-Cruz, L.A., Corrales, F.J., Rubio, A.: Correlation between Gene Expression and GO Semantic Similarity. IEEE/ACM Transaction on Computational Biology and Bioinformatics 2, 330– 338 (2005)

A Hybrid Concept Similarity Measure Model for Ontology Environment

857

14. Gruber, T.: A translation approach to portable ontology specifications. Knowledge Acquisition 5, 199–220 (1995) 15. Sowa, J.F.: Semantic Networks. In: Shapiro, S.C. (ed.) Encyclopedia of Artificial Intelligence. Wiley, Chichester (1992) 16. Costello, R.L.: OWL ontologies (2009) 17. Kuropka, D.: Modelle zur repräsentation natürlichsprachlicher dokumente. ontologiebasiertes information-filtering und -retrieval mit relationalen datenbanken. In: Becker, J., Grob, H.L., Klein, S., Kuchen, H., Müller-Funk, U., Vossen, G. (eds.) Advances in Information Systems and Management Science. Logos Verlag Berlin, Berlin (2004) 18. Furnas, G.W., Deerwester, S., Dumais, S.T., Landauer, T.K., Harshman, R.A., Streeter, L.A., Lochbaum, K.E.: Information retrieval using a singular decomposition model of latent semantic structure. In: 11th ACM SIGIR Conference on Research and Development in Information Retrieval, pp. 465–480 (1988) 19. Baeza-Yates, R., Ribeiro-Neto, B.: Modern Information Retrieval. ACM Press, Harlow (1999) 20. Dong, H., Hussain, F.K., Chang, E.: A concept similarity measure model for enhancing the dependability of semantic service matchmaking in the service ecosystem. IEEE Transactions on Service Computing (submitted, 2009)

Semantic Wiki as a Basis for Software Engineering Ontology Evolution Natsuda Kasisopha, Pornpit Wongthongtham, and Farookh Khadeer Hussain Digital Ecosystems and Business Intelligence Institute Curtin University of Technology, Perth, WA 6102, Australia [email protected], {P.Wongthongtham, Farookh.Hussain}@cbs.curtin.edu.au

Abstract. Ontology plays a vital role in sharing a common understanding of the domain among groups of people and provides terminology interpretable by machines. Recently, ontology has grown and continued to evolve constantly, but there are not many tools to provide an environment to support ontology evolution. This paper introduces a framework to support the management and maintenance leading to the evolution of Ontology by focusing on Software Engineering Ontology. The proposed framework will take into account the users' perspectives on the ontology and keep track of the comments in a formal manner. We propose the use of technology such as Semantic MediaWiki as a means to overcome the aforementioned problems. Keywords: Semantic Wiki, Ontology Management and Evolution, Software Engineering Ontology.

1 Introduction Sharing a common understanding of structured information amongst people, software agents and machines, has become more demanding for the industry, because information systems and computer technology are a part of every field nowadays. This is the main reason for using ontology embedded within application systems [1]. The development process and evolution process of ontology involves skilled ontology engineers and knowledge engineers but not users. Thus, the ontology is difficult for users to comprehend and does not fully serve users due to a lack of communication about ontology technical knowledge and domain knowledge between users and ontology engineers and knowledge engineers. Also, users have no involvement in the development and evolution processes, which confines the perspective of the ontology to a group of Ontology engineers and Knowledge engineers [1, 2]. Recently, the ontology has grown very rapidly reflecting the ever growing body of knowledge. To maintain ontology in such a condition, the ontology engineers need to capture the changes of ontology and introduce a new version to users. It would take some time for the new ontology version to be delivered to users and it is most likely that the ontology would change again before the ontology has been delivered [1, 3]. In this paper we propose a methodology for ontology evolution which takes the users into account as well. R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 858–865, 2009. © Springer-Verlag Berlin Heidelberg 2009

Semantic Wiki as a Basis for Software Engineering Ontology Evolution

859

The remainder of this paper is organized in the following manner. In Section 2, we discuss and present the motivation of our work. In Section 3, we propose our proposed methodology for ontology evolution. The significance of our work in presented and discussed in Section 4. Finally, the conclusions from the paper are drawn in Section 5, along with discussion about the future work.

2 Background Software engineering ontology is the knowledge that has been consensually agreed by a group of domain experts to define a common sharable knowledge of the software engineering domain. Its concepts and constraints are defined to meet the standards and formal meaning of terms [4]. More specifically, Software Engineering Ontology (henceforth abbreviated as SEOntology) has conceptualised the Software Engineering knowledge. Many existing ontologies, including the Software Engineering Ontology, have domain experts who fully control its development and evolution process. However, it is crucial to note that such ontology development and evolution processes do not involve the users. This becomes a problem when domain knowledge is confined to a group of domain experts or individuals. Consequently, the ontology becomes complicated for users to use and to understand. The gap between domain knowledge (encoded in the ontology) and users then becomes greater. Users cannot access the domain experts for clarification or to discuss issues. As a result, users lose the motivation to use the ontology, thereby leading to a decline in the community acceptance of the ontology. Additionally, the domain knowledge encoded in the ontology is evolving rapidly and constantly. Thereby, the users do not know which version of the ontology to use. The aforementioned issues result in the ontology lacking maintainability, becoming obsolete and impracticable. Moreover, there is no suitable tool capable of effectively providing an environment for the discussion and formalisation of issues (from the perspective of users), supporting ontology evolution, and maintaining the various versions of the ontology [3]. Ontology development and evolution is a collaborative work requiring community consensus and more importantly community involvement. It should not consider only individual perspectives. The community of users should be involved in the ontology evolution process. Mika et al [5] have suggested that the influence of user involvement would make the architecture of Semantic Web successful and useful for the end-users as well. Preliminary work done by Mika et al [6] and Hoto et al [7] has also suggested that the enhancement, education and obtainment of formal ontology can be done by social software using various empirical techniques. These preliminary results have indicated that the social approach is a very promising direction that can put the SEOntology into practice, thus contributing to the software engineering community. The crucial previously mentioned issue, regarding the non-involvement of the users could be addressed by employing a semantic wiki. This approach enables users to share, discuss, comment, and tag issues or problems on software engineering knowledge encoded in the Software Engineering Ontology. The semantic wiki allows users to collaboratively edit and annotate the knowledge. By employing a semantic wiki, the users are able to express their understanding of certain concepts and

860

N. Kasisopha, P. Wongthongtham, and F. Khadeer Hussain

interpret them in ways different from current ones defined in the SEOntology. By making use of semantic wiki, the opinions/views of the users about the ontology (or certain concepts in the ontology) can be taken into account. In this paper we propose a system framework to support the SEOntology evolution and management by involving remote team members that geographically work on software development. The members are able to efficiently and effectively communicate and share up-to-date knowledge encoded in the SEOntology. The system framework uses the Semantic Wiki based approach to support the ontology’s maintainability and management.

3 Toward Semantic Wiki as a Basis for Ontology Evolution One of the key features of our proposed ontology evolution framework is the use of social network. Our proposed system supports remote collaborative ontology evolution and maintenance. The conceptual framework of the semantic wiki-based ontology evolution system architecture is shown in Figure 1. It is grounded in the notion of several components and data elements. Communication mechanisms such as blogs enable users to raise, share, discuss, comment and tag issues in an informal and lightweight manner. Blogs encourage people to engage in remote discussion, communication and collaboration. It is a preferable way to raise and discuss issues since it is more personal and people are more willing to engage in discussions. We integrate the Ontology into it through an open Ontology APT. Based on the subjects, semantic wiki-based Ontology evolution can be collaboratively edited and annotated by a group of domain experts. The semantic

Fig. 1. Overall system architecture

Semantic Wiki as a Basis for Software Engineering Ontology Evolution

861

Fig. 2. Semantic wiki-based ontology evolution architecture

wiki-based ontology evolution is used by domain experts to express understandings of certain concepts and interpret them in ways different from current ones defined in the ontology. In this way, people can see how the meanings of terms have emerged. The collective knowledge within this Wiki can then be acquired through various text and data mining techniques. Our ontology semantic wiki-based ontology evolution approach considers both users’ opinions and experts’ decisions. Our proposed semantic wiki-based ontology evolution architecture is shown in Figure 2. The data elements of issues, proposals, and opinions are automatically categorised and stored in the database. Thus, they are represented as unresolved query pages, misunderstanding clarification pages and ontology modification pages in the semantic wiki-based ontology evolution (see Figure 2). In the prototype system, we use Apache Tomcat for our server to run WebProtege [8], MySQL [9], and PHP [10]. WordPress [11] and its plug-ins are used for creating blog communication systems. It is also linked to the ontology through Web-Protege. We use an open-source system to create the semantic wiki-based ontology evolution, i.e. semantic media wiki [12] with integration of the ontology. The complete sets of revision histories are stored in a Wiki server. This provides a preliminary tracking mechanism that facilitates “the quality assessment” extremely essential to the project solution recommendation for ontology evolution. For example, Lim et al [13] have suggested that Wiki articles’ qualities and contributions can be effectively measured using these revision editing data. However, Lim et al [13] and Hu et al [14] focus on the quality of each article by developed Basic, PeerReview and Probview models, whereas our work focuses more on the quality of each concept/term edited/defined in the Wiki. Nevertheless, the system needs quality assessment measures on both articles completeness and concepts integrity even though this requires not only distinct quality measurement models but also effective information extraction techniques that can capture important concepts from edited Wiki articles.

862

N. Kasisopha, P. Wongthongtham, and F. Khadeer Hussain

The quality of concept/term edited/defined on the Wiki are assessed by allowing domain experts and users to ensure that the definition of concepts is relevant to the target shared concept [15]. In other word, we are going to take advantage of the “Self - Healing” effect of Wikipedia by having reputation mechanisms. In addition, other quality related factors such as word count, article length [18], and rating on articles are possibly evaluated for Content Quality Assessment of Wiki articles. Tan et al. [19] have made considerable progress in mining semi-structured information and limited forms of partial structured natural language which can be further studied and leveraged by our system in order to facilitate the “extraction and mining” process. Once the quality assessment, data mining and information extraction are done, domain experts and ontology engineers will collaboratively discuss and decide concepts that need to be updated. The Semantic Wiki will provide an authentication and access level control as part of its overall framework. Each team member will have a username and password as part of the authentication process. Access level control will restrict the accessible information based on the privileges of each different user group. Users would be divided into three groups: Domain experts, Ontology engineers and Project manager. Domain experts are users who maintain the integrity of the domain. They will have full privilege to modify the knowledge encoded in the ontology. Ontology engineers are users who ensure that the ontology is consistent. Full privilege access is granted to the ontology engineers to maintain the consistency of the ontology. Project managers and members are users who can access and modify the project information encoded in the ontology. All of them can raise issues and make changes regarding the ontology evolution, closely monitored by domain experts and ontology engineers. This framework employs two categories of the Software Engineering Ontology, i.e. Software Engineering Domain Knowledge and Software Engineering Sub Domain Knowledge. The Software Engineering Domain Knowledge represents generic concepts of the software engineering and its relations captured in the ontology. The concepts captured in the ontology can be partially used depending on the problem domains. Software Engineering Sub Domain Knowledge represents some concepts of software engineers for a particular problem domain. For each project, the existing project information or actual data including project agreements and project understanding are instance knowledge of the Software Engineering Sub Domain Knowledge. The project information that especially fulfils a particular project requires the software engineering knowledge to define instance knowledge in the ontology [20].

4 Significance of Our Work We discuss the significance of this research under two broad sections, namely: 1. The scientific significance or the scientific contribution; (and) 2. The impact on the field. From a scientific perspective, this research proposes a novel framework, which employs the use of Semantic Wiki for ontology evolution and ontology management. The impact on the field of software engineering from this research includes the following:

Semantic Wiki as a Basis for Software Engineering Ontology Evolution

863

• Increase of Communication and Resource efficiency: Lack of communication and resources are the main factors that may potentially lead to other problems. This research provides an adequate management of these factors. The SEOntology is shared and reused as centralised domain knowledge. Hence, users can access the knowledge encoded in the ontology at all times, leading to an increase in resource efficiency. Furthermore, the ontology becomes up-to-date as users keep updating and raising ontology issues. Finally, the system will benefit from the user’s motivation to resolve issues and maintain the ontology evolution via the system. • Increased Productivity of all the involved parties: Since the issues are clearly identified upfront and the solution to those issues is agreed upon within the community, this would result in an increase of productivity of all the involved parties. Additionally, the system allows users to access the domain knowledge effortlessly and instantaneously. The more effortless and instantaneous the system is, the more productive the users would be. Moreover, it is important to note that the users are not overloaded as they do not have the responsibility of additional tasks, such as conducting training sessions or maintaining the domain knowledge system. • Cost Abatement: The third major impact of this proposed research is that it would result in cost abatement. Increase in communication and resource efficiency, would directly lead to cost savings. Additionally, the approach reduces evolution costs as the system allows users to participate in the evolution process. Also, the cost of equipment and storage for the domain knowledge database systems can be reduced as the domain knowledge is centralised and stored in one database system. All these factors would translate to significant cost abatement.

5 Conclusion and Future Work Semantic technologies make use of ontologies to make knowledge accessible and understandable by machines. However, it is important to note that knowledge is not a static aspect and it always keeps on evolving and growing with time. This leads to ontology evolution and ontology maintenances requirements. In this paper, we propose the conceptual framework of our proposed method for SEOntology evolution. It is important to note that this paper documents our preliminary research findings. Our future work will be focussed along two main dimensions. We intend to investigate the issues of ontology alignment and ontology versioning in the Semantic Wiki environment. Additionally, we will be carrying out validation and verification of our proposed system using a prototype system. The prototype system would be engineered by making use of tools such as PHP, Protégé and Semantic MediaWiki. Using the prototype system, we would measure the performance of our proposed system by making use of certain metrics for benchmarking purposes. Further evaluation activities such as making use of the prototype platform to obtain feedback from users [21] will be carried out in order to find issues with the prototype. We would try to get additional feedback about the prototype by making use of focus groups. The focus user groups are the software development team members who are working on the multi-site software engineering projects. In order to make the platform more effective,

864

N. Kasisopha, P. Wongthongtham, and F. Khadeer Hussain

the evaluation and validation will be divided into an iterative cycle of six months as the platform can be adjusted and enhanced based on the obtained validation.

References 1. Gendarmi, D., Lanubile, F.: Community-Driven Ontology Evolution Based on Folksonomies. In: Meersman, R., Tari, Z., Herrero, P. (eds.) OTM 2006 Workshops. LNCS, vol. 4277, pp. 181–188. Springer, Heidelberg (2006) 2. Zhdanova, A.V., et al.: Community-driven ontology management: DERI case study. In: The 2005 IEEE/WIC/ACM International Conference on 2005 Proceedings in Web Intelligence (2005) 3. Siorpaes, K.: Lightweight community-driven ontology evolution. 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., Cudré-Mauroux, P. (eds.) ASWC 2007 and ISWC 2007. LNCS, vol. 4825, pp. 951–951. Springer, Heidelberg (2007) 4. Seontology Website - Software engineering ontology (SEOntology), http://www.seontology.org/ (cited May 21, 2009) 5. Mika, P.: Social Networks and the Semantic Web: The Next Challenge. IEEE Intelligent Systems 1541-1672, 82–84 (2005) 6. Mika, P.: 4th International Semantic Web Conference Ontologies Are Us: A Unified Model of Social Networks and Semantics (2005) 7. Hotho, A., et al.: Emergent Semantics in BibSonomy. In: Proc. Workshop on Applications of Semantic Technologies, Informatik 2006, Dresden (2006) 8. WebProtege - Protege Wiki, http://protegewiki.stanford.edu/index.php/WebProtege (Cited) 9. MySQL - Wikipedia, the free encyclopedia, http://en.wikipedia.org/wiki/MySQL (cited May 22, 2009) 10. PHP: Hypertext Preprocessor, http://www.php.net/ (cited May 22, 2009) 11. WordPress Blog Tool and Publishing Platform, http://wordpress.org/ (cited) 12. Krötzsch, M., Vrandecic, D., Völkel, M.: Semantic mediawiki. In: Cruz, I., Decker, S., Allemang, D., Preist, C., Schwabe, D., Mika, P., Uschold, M., Aroyo, L.M. (eds.) ISWC 2006. LNCS, vol. 4273, pp. 935–942. Springer, Heidelberg (2006) 13. Lim, E.P., et al.: Measuring Qualities of Articles Contributed by Online Communities. In: IEEE/WIC/ACM Conference on Web Intelligence (2006) 14. Hu, M., et al.: Measuring article quality in wikipedia: models and evaluation. In: Proceedings of the sixteenth ACM Conference on information and knowledge management. ACM, Lisbon (2007) 15. Correndo, G., Alani, H., Smart, P.R.: A Community Based Approach for Managing Ontology Alignments. In: 3rd International Workshop on Ontology Matching, Karlsruhe, Germany (2008) 16. Stein, K., Hess, C.: Does it matter who contributes: a study on featured articles in the german wikipedia. In: Proceedings of the eighteenth conference on Hypertext and hypermedia. ACM, Manchester (2007) 17. Adler, B.T., Alfaro, L.d.: A content-driven reputation system for the wikipedia. In: Proceedings of the 16th international conference on World Wide Web. ACM, Banff (2007) 18. Blumenstock, J.E.: Size matters: word count as a measure of quality on wikipedia. In: Proceeding of the 17th international conference on World Wide Web. ACM, Beijing (2008)

Semantic Wiki as a Basis for Software Engineering Ontology Evolution

865

19. Tan, H., et al.: Tree model guided candidate generation for mining frequent subtrees from XML documents. ACM Trans. Knowl. Discov. Data 2(2), 1–43 (2008) 20. Wongthongtham, P., et al.: Development of a Software Engineering Ontology for Multisite Software Development. IEEE Transactions on Knowledge and Data Engineering, 1 (2008) 21. Katakula, J.: A Framework for Employee Performance Measurement in an Online Collaborative Environment like MediaWiki. In: Curtin Business School, Curtin University of Technology (2008)

Implementation of a Service-Based Grid Middleware for Accessing RDF Databases Isao Kojima and Masahiro Kimoto Information Technology Research Institute, National Insutitute of Advanced Industrial Science and Technology(AIST) Umezono1-1-4, Tsukuba, Ibaraki 305 Japan {isao.kojima,m-kimoto}@aist.go.jp

Abstract. This paper presents the design and implementation of a service-based RDF database middleware suite called DAI-RDF, an extension of the OGSA-DAI middlewarewhich currently supports relational and XML databases. DAI-RDF provides various RDF data processing activities including SPARQL query language, ontological primitives, and reasoning functions. Since DAI-RDF is based on service-based grid architecture, it is easy to use to support large-scale distributed semantic grid applications. Performance evaluation, including evaluation of the reasoning functions included, shows the usefulness of the system. Keywords: Service based Grid, RDF, OGSA, SPARQL, Ontology.

1 Introduction One goal of Grid computing[1] is to provide useful computational infrastructure which enables highly parallel applications to handle large amounts of distributed data. Along with the growth of the grid application area, the need for Semantic Web technologies, such as ontology handling and inference capability, began to emerge. Semantic Grid [2] is intended to extend the Grid by giving information and services well-defined meanings, better enabling computers and people to work in cooperation. In this activity, there are several important research issues, such as, how to support large-scale semantic web applications using scalable Grid infrastructure, and how to enhance Grid applications with Semantic Web technology. In Semantic Web applications, RDF (Resource Description Framework) [3] is the essential data structure needed to support semantics. This means that semantic data access infrastructure in the Grid environment should support RDF databases. However, up until now there has been no implementation of grid middleware, and no standard access specification for accessing RDF data. For example, popular gridbased database access middleware suites, such as OGSA-DAI [4] and AMGA [5] were not able to handle RDF data directly. On the other hand, many RDF databases [6][7][8] support remote access based on the http protocol, and there is also a set of W3C standard specifications for accessing RDF data [9][10] using the SPARQL[11] query language. These RDF database systems with W3C specifications are, however, not sufficient for supporting distributed applications in the Grid environment. For instance, many Grid applications R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 866–876, 2009. © Springer-Verlag Berlin Heidelberg 2009

Implementation of a Service-Based Grid Middleware for Accessing RDF Databases

867

utilize a function called “third party transfer” which allows servers to transfer the data to yet another, different (third-party) site. Support of this function is very useful, particularly in cooperative data processing of applications among distributed servers. This function also requires its own security function, called GSI (Grid Security Infrastructure) [1] which supports the delegation of security credentials. However, these functionalities are not supported by existing W3C specifications or by relevant middleware which handles RDF data. Supporting GSI is also important in being able to combine database processing services with various grid tools such as Globus MDS ((resource) Management and Discovery System) [12]. The final issue is that the W3C standard specifications are only for the SPARQL language, and there is no standard access method for handling ontologies, although many existing RDF systems provide similar ontology handling APIs [6][7]. SPARQL is a graph matching language and there are no semantics capabilities, such as those required for RDF(S) and OWL. We need to have ontological access capability if we want to handle the semantics of RDF(S). Based on these motivations, the authors are working on a set of access protocol specifications for RDF databases called WS-DAI-RDF(S) [13], which can support SPARQL and ontological primitives. The activity is ongoing in the DAIS-WG (Database Access and Integration Service Working Group) in the OGF (Open Grid Forum). The authors are also working on a reference implementation of the middleware called DAI-RDF, which is presented in this paper. An early prototype called OGSA DAI-RDF was presented in [14] and this paper presents the current implementation, which satisfies the in-discussion WS-DAI specification for RDF [15]. The structure of the paper is as follows. Section 2 presents an overview of the approach of DAI-RDF. The architecture and the structure of the middleware suite are discussed in Section 3. Performance evaluation results are shown in Section 4. Section 5 describes the current status and the future direction of the software.

2 The DAI-RDF Approach In order to overcome the problems touched on above, the approach in DAI-RDF is to extend the OGSA-DAI [4] database middleware suite to support RDF databases. OGSA-DAI is a database access middleware suite which is in development at OMII (Open Middleware Infrastructure Institute)-UK. It provides web service-based database access and data processing functionalities based on the OGSA architecture, which is defined in OGF. Currently, OGSA-DAI supports two types of database system. The first type is relational databases, such as Oracle, MySQL and PostgreSQL. The second type is XML databases, such as eXist and Xindice. Based on OGSA-DAI, we have achieved the implementation of the following functional features. A Secure Distributed Processing Framework Utilizinging GSI: As described in the previous section, supporting third-party transfer is very useful for achieving distributed query processing, which allows the exchange of intermediate results between database servers. In this case, the authentication between one server and another server (a third party site) might cause a security problem that can not be solved by the simple authentication mechanism of the client. GSI provides a safe

868

I. Kojima and M. Kimoto

authentication infrastructure based on the delegation of credentials, and OGSA-DAI supports GSI. GSI support is also used to combine database processing with other grid services, such as computational services and data transfer services, under one single authentication mechanism. This function has also proved useful in our S-MDS application [16, 17], which combines grid tools and RDF data processing. Easy-to-Use Programming for Service-Based Distributed Database Processing through Support of the OGSA-DAI Activity Framework: In the case of distributed database processing, it is often necessary to perform a series of data processing tasks on one site. An example could be as follows, 1) 2) 3) 4)

Access the database server using the SPARQL query language Join the results with other results which came from other SPARQL servers. Compress or convert the resulting join. Send the result to another server with HTTP (or another protocol).

It is obvious that this sequence of operations can be achieved with a web servicebased workflow language. However, it is not efficient to perform this set of operations on a single server using HTTP-based inter-service protocols. OGSA-DAI provides a function unit called Activity, and several Activities can be combined into a Workflow. A Workflow is a unit of the request to the database service. In this case, each of above four operations can be accomplished as Activities, and a Workflow, which is composed of a set of Activities, is sent to the server as one request. The Activity Framework provides an easy-to-use distributed RDF database programming environment with little overhead, even when combining several separate data operations. It should be noted that all existing OGSA-DAI activities, such as data compression, data conversion, and data transfer activities, can be combined with our new RDF processing activities. These activities, including third party transfer, will also be useful as the implementation base for distributed RDF query processing problems [18, 19], and for a federated SPARQL [20, 21]. Interoperability for Accessing Various Databases by Implementation of OGF Standard WS-DAI: In the DAIS-WG of OGF, there is an access standard called WS-DAI (Web Service Database Access and Integration), which provides servicebased remote database access. The core WS-DAI specification [22] provides a model independent access pattern, and two specific implementations, WS-DAIR [23] and WS-DAIX [24] are defined to access relational databases and XML databases respectively. The main feature of the WS-DAI specification is to provide indirect result transfer when the size of the result is very large. Currently, there are ongoing attempts to test the interoperability between OGSA-DAI and AMGA. Based on the same approach, the authors are also working on another WS-DAI specification for accessing RDF data resources (WS-DAI RDF(S)) [13]. In this specification, the SPARQL query language and ontological primitives are both supported. Our DAI RDF is also intended to be a reference implementation of WS-DAI RDF(S), able to access different RDF products with a single access protocol.

Implementation of a Service-Based Grid Middleware for Accessing RDF Databases

869

Moreover, it will be easy to interoperate with various other database products if we support RDF databases within the same WS-DAI framework. In summary, extending OGSA-DAI to support RDF is very useful for achieving RDF database infrastructure over the Grid. Our work is unique since there are no other activities aimed at extending OGSA-DAI to support RDF databases, especially in synchronization with activities to set standard specifications to access an RDF database under the WS-DAI of OGF.

3 The Architecture and Implementation of DAI-RDF

3

Here, we present the design approach for the architecture and the actual implementation of DAI-RDF. 3.1 Overview of the System Fig.1. shows the architectural overview of DAI-RDF. Basically, we added the RDF data resource type to the existing OGSA-DAI data resource types. The original data resource types consist of relational and XML resource types. DAI-RDF GUI

Activities

Messages

XMLDB GridFTP/FTP

OGSA-DAI

・

XSLT

Data Manipulation Activities

SPARQL

Ontology

Insert Delete

Reasoning

Product Driver Interface

WS-DAI

XMLDB Activities

OGSA-DAI-RDF Activities

WS-DAI Compliant clients

WS-DAI-RDF(S) Querying

& RDF

RDB

Data Transport Activities

GT4 AXIS

Apache/Tomcat

SPARQL/XML

SQL Activities

DAI-RDF Sesame

DAI-RDF

Jena

DAI-RDF

Fig. 1. The structure of the DAI-RDF system

For RDF data resource types, we have implemented a set of Activities as categorized into the following types; 1) SPARQL Activity (SPARQLQueryActivity): Accesses a data resource using the W3C SPARQL query language. 2) Reasoning Activity (ontologyReasonerActivity): Performs the reasoning function on a set of RDF triples (RDF Graph) based on certain semantics schemes, like OWL or RDFSchema.

870

I. Kojima and M. Kimoto

3) Graph Management (GraphManagementActivity) and Triple Management (TripleManagementActivity) Acitivities: Provides basic I/Os for RDF Graphs and Triples. This enables insertion, deletion, and modification of the target RDF graphs and/or triples. (Currently, we are not able to handle updates for the inferred graphs) 4) Ontology Handling Activities: Provides a basic set of ontological primitives. Since the ontological specifications in WS-DAI-RDF(S) [13] are still under discussion, our implementation is based on an early version of WS-DAIOnt [25] and the current WS-DAI-RDF(S) Ontology (Profile0). We also provided basic interfaces for the still-under-discussion OGF standard WSDAI RDF(S) Querying [15] on top of DAI-RDF (except for the factory pattern). Since W3C has already set the standards related to SPARQL [11], we implemented these interfaces so as to have as much compatibility with these standards. For instance, the query is sent with a format based on the W3C SPARQL Protocol for RDF specification [9]. The result bindings of a SELECT query are also based on the W3C SPARQL Query Results XML Format [10]. For application programming, each Activity also supports a java API in order to provide a java programming environment, as shown in Fig.2. // Get DRER. DataRequestExecutionResource drer = server.getDataRequestExecutionResource(drerID); // Build the individual activities making the workflow and connect them up. //SPARQL Query Acitivity. SPARQLQuery query = new SPARQLQuery(); query.setResourceID(dataResourceID); query.addExpression(“ SELECT ? Title WHERE{ ……… } ……….. query.addOutputType(xmlUtils.getOutputType());

");

//Request Status. DeliverToRequestStatus deliver = new DeliverToRequestStatus(); deliver.connectInput(loadTuples.getDataOutput()); // Workflow Creation and construction by Adding activities PipelineWorkflow workflow = new PipelineWorkflow(); ….. workflow.add(query); workflow.add(deliver); // Execute. try{ RequestResource requestResource = drer.execute(pipeline,

RequestExecutionType.SYNCHRONOUS); }

Fig. 2. A portion of a sample of java code for DAI-RDF

As in Fig.2, a unit of OGSA-DAI execution is called a workflow. In this workflow example, the SPARQLQuery Activity (query) and the DeliverToRequestStatus Activity (deliver) make up a workflow (workflow.add). These activities can be executed in parallel if there is no relationship between the activities. 3.2 Implementation Issues and the Solutions Here, we present the implementation issues encountered in developing DAI-RDF, and their solutions.

Implementation of a Service-Based Grid Middleware for Accessing RDF Databases

871

1) Provide a Product Driver Interface In RDF database systems, there are no common access protocols such as the JDBC interface for relational databases. Although the SPARQL protocol supports an HTTPbased access protocol, there is no common interface for ontology handling and graph management functions. This means that RDF database middleware must handle every variation in software products. This might lead to a lack of extensibility for the future support of new RDF databases. Also, DAI-RDF is an extension of OGSA-DAI middleware solutions, so that all DAI-RDF components must be modified whenever OGSA-DAI is changed. In order to solve these issues, we designed a platformindependent driver interface as shown in Fig.1. For instance, if you want to set up a Jena database, you need to specify only the Jena driver class when configuring the RDF data resource. Currently we support Jena, Sesame, and Boca by implementing corresponding database drivers. This architecture provides the extensibility for supporting other RDF database products. By using this structure, we will not need to modify the driver even when OGSA-DAI middleware is upgraded. 2) Implementation of a Reasoning Activity Reasoning is supported in various ways in existing software products. For instance, the following types of reasoning support are provided by SPARQL. 1. 2.

3.

Creation of an inferred graph separately. Reasoner creates yet another graph and a query with reasoning is performed on the created graph. An example is Jena. Supply of a Reasoning Switch:An option is provided to choose whether the query processing needs a reasoning function or not. If the reasoning switch is ON, the SPARQL query processing is done with reasoning. Several systems such as AllegroGraph also provide this option. Configuration of the RDF resource with a reasoning option. In Sesame2, a user can configure the resource with reasoning. In this case, the query is always carried out with reasoning if the resource is configured to do so.

The problem here is what model should be used if we want to support all three product types in a single framework. It must be said that it is very difficult to integrate them into a single model. In DAI-RDF, we have adopted a model based on 1. which splits the reasoning function with the SPARQL interface. The reason for the split is that, the reasoning function is currently outside of the focus of SPARQL and related W3C standards. In this approach, the inferred graph is created explicitly in a separate reasoning activity. However, this might cause a performance problem, and we will evaluate this approach in Section.4. 3) Support of Two I/O types for all RDF Activities (Streamed data and URLs ) The main target of a SPARQL query is generally a set of graphs (default graphs and named graphs) specified with URLs. On the other hand, Activity output and input is generally a piped stream of data. Thus, all DAI-RDF activities support these two types of I/O parameter patterns, as shown in Fig.3. For instance, any graph in the input set of graphs of a SPARQLQuery Activity can be a set of URLs or a set of the output of other Activity output streams. This achieves flexibility in database processing workflow programming. For Stream, we supports several binary data formats (such as the Jena model and the Sesame repository), along with the standard data formats (XML and N3).

872

I. Kojima and M. Kimoto Query Result RDF Data Stream

Inferred RDF Data Stream

RDF Data Stream

SPARQL Query Statement Activity

Reasoning Activity

URLs of Graphs Inferred Triples

URLs of Inferred Graphs

URLs of Result Sets

Fig. 3. Piped Input/Output and URLs for connecting Activities // Get DRER. ,,,,,,, Reasoner GetReasoner reasoner = new GetReasoner(); reasoner.setResourceID(dataResourceID); DAIRDFXMLUtilities xmlUtils = new DAIRDFXMLUtilities(reasonerConfigFile); ArrayList<String[]> schemaGraphStreamData = xmlUtils.getStreamDataList("schema-graph-stream-data"); ArrayList<String[]>instanceGraphStreamData = xmlUtils.getStreamDataList("instance-graph-stream-data"); ArrayList<String> instanceGraphUri = xmlUtils.getGraphUriList("instance-graph-uri"); ArrayList deliver = new ArrayList(); ,,,,,,,,, reasoner.addInstanceGraphsAsArray(instanceGraphURIArray); reasoner.addReasoningDataOutputType(xmlUtils.getSimpleTagElement ("data-output-type")); reasoner.addOntologyReasoningType (xmlUtils.getSimpleTagElement("ontology-reaonser-type")); ….. // SPARQL query. SPARQLQuery query = new SPARQLQuery(); query.setResourceID(dataResourceID); query.addExpression(xmlUtils.getSimpleTagElement("expression")); query.connectReasoner(reasoner.getDataOutput()); query.addOutputType(xmlUtils.getSimpleTagElement("sparql-output-type")); … // Workflow. ,,,,,, pipeline.add(reasoner); pipeline.add(query); pipeline.add(deliverToRequestStatus); //

Fig. 4. A portion of a java program which represents the workflow .diagram of Fig.3

Fig.4. shows the portion of java code which connects the Reasoner and SPARQL activities with data streams. Note that these workflows can perform cooperative operations between distributed services, and the user can program a distributed database processing task by constructing a set of workflows.

4 Performance Evaluation We evaluated 1 the performance of DAI-RDF. The first item we analyzed was the response time of SPARQL query processing. The data used was Wordnet [26] and the 1

Opteron2.0Ghz x 2way, 6GB memory, 500GBdisks, SUSE Linux9. Java1.5 Heapsize512MB.

Implementation of a Service-Based Grid Middleware for Accessing RDF Databases

873

Fig. 5. Query response time per the number of result records returned to the client Table 1. Detailed time analysis of SPARQL query processing time (seconds) Number of results

32 64 128 256 512 1024 2048 4096 8192 16383

Total response time (same as in Fig.5-Jena) 7.2474 7.7051 7.1442 7.1894 7.3276 8.0345 7.9485 8.4111 9.4505 11.2763

SPARQLQuery activity processing time OGSA-DAI overhead[28] DAI-RDF Query XML data middleware Execution construction overhead time (Jena) time (from model) 0.0462 0.0014 6.4983 0.7012 0.0240 0.0012 7.0637 0.6962 0.0236 0.0017 6.9647 0.2090 0.0220 0.0019 6.6118 0.5893 0.0268 0.0024 6.6345 0.6626 0.0695 0.0015 6.6079 1.3555 0.0227 0.0014 6.9375 0.9867 0.0240 0.0020 6.1200 2.2651 0.0256 0.0015 6.7810 2.6422 0.0218 0.0016 6.9483 4.3045

result is shown in Fig.5 and Table 1. Fig.5 shows the response time using the Sesame and Jena software. As shown in Fig.5, the result depends on the performance of the underlying software implementation and the size of the resulting data. Table 1 shows a detailed analysis of the case in Fig.5 (Jena with MYSQL). As this result clearly shows, the most time consuming factor is constructing the resulting XML data structure from the Jena model. Currently it is done by triple-by-triple processing using the Jena API. Since the Sesame implementation can output XML directly, the time difference in Fig.5 is caused mostly by this step. As in 3.2, DAI-RDF supports a binary format (the Jena model or the Sesame Repository) for intermediate data transfer so that this step is only used in the final step of the data processing task. In general, the overhead of DAI-RDF is not a performance bottleneck factor.

874

I. Kojima and M. Kimoto Table 2. Time analysis of Reasoning with SPARQL query processing time (seconds) Server

Total Response Time

Implementation

Jena (mysql) Sesame

Reasoner (RDFS) DAI RDF overhead

Reasoning execution time

SPARQLQuery Activity DAI-RDF overhead

Query execution time

1.0435 1.6494

0.051 0.063

0.397 0.0553 0.763 0.0540

0.0059 0.0537

1.6053

0.116

0.773 0.0448

0.0442

XML data composition

0.049

(MemoryStore)

Sesame (NativeStore)

Table 3. The results of LUBM benchmarks (seconds)

Q1 4.0097

Q2 timeout

Q3 6.946

Q4 4.848

Q5 16.8041

Q6 6.3892

Q7 timeout

Q8 109.5456

Q9 timeout

Q10 6.1108

Q11 3.4489

Q12 3.1776

Q13 8.9399

Q14 6.0145

Table 2 shows the performance of reasoning/inference processing using Sesame and Jena. The data is in OWL format from [16] and the reasoning is done with RDF(S). The result shows that combining two activities does not cause the performance problem described in Section 3.2. The reason is the implementation of OGSA-DAI in which activities are linked together as a single program (especially in DAI3.0) Finally, Table 3 shows the result of using the LUBM benchmark [29] to show the scalabitliy of the middleware for large datasets and applications. Compared with [29], this result shows the reasonable response times obtained, so that the DAI-RDF middleware suite can be considered useful for large scale applications. In summary, we believe that our middleware suite provides reasonable performance for constructing distributed RDF applications.

5 Conclusions The current version of DAI-RDF is now available at http://www.dbgrid.org/. The platforms supported are DAI2.2 and DAI3.1. The WS-DAI RDF(S) interface is not fully supported since we found that JAXB [30] could not create the appropriate EndPointReference which the WS-DAI Core [22] requires. The following software was used. 1) The Semantic Service Registry of AIST Semantic SOA [31] was used for tracking our internal application. The repository is used for finding service metadata which is written in OWL-S and RDF. 2) Metadata Storage of the S-MDS extensions [17] was also used. Ongoing development includes distributed SPARQL query processing based on an extension of our other product, OGSADQP/XML[32].

Implementation of a Service-Based Grid Middleware for Accessing RDF Databases

875

References 1. Foster, I., Kesselman, C.: The Grid 2: Blueprint for a New Computing Infrastructure, 2nd edn. The Elsevier Series in Grid Computing. Morgan Kauffman, San Francisco (2003) 2. Semantic Grid Community Portal, http://www.semanticgrid.org 3. Resource Description Framework, http://www.w3.org/RDF/ 4. OGSA-DAI Project, http://www.ogsadai.org.uk/ 5. ARDA Metadata Catalog Project, http://amga.web.cern.ch/amga/ 6. Jena Semantic Web Framework, http://jena.sourceforge.net/ 7. Sesame :RDF Schema Querying and Storage, http://www.openrdf.org/ 8. IBM Semantic Layered Research Platform (Boca), http://ibm-slrp.sourceforge.net/ 9. Clark, K.: SPARQL Protocol for RDF, W3C Recommendation (January 15, 2008), http://www.w3.org/TR/rdf-sparql-protocol//2006/ CR-rdf-sparql-protocol-20060406/ 10. Beckett, D.: SPARQL Query Results XML Format, W3C Recommendation (January 15, 2008), http://www.w3.org/TR/rdf-sparql-XMLres/ 11. Prud’hommeaux, E., Seaborne, A.: SPARQL Query Language for RDF, W3C Recommendation (January 15, 2008), http://www.w3.org/TR/rdf-sparql-query/ 12. Globus Monitoring and Discovery System, http://www.globus.org/mds/ 13. Esteban, M., Kojima, I., Mirza, S., Corcho, O., Gomez, A.: Accessing RDF(S) data resources in service-based Grid infrastructures. Concurrency and Computation: Practice and Experience 21(8), 1029–1051 (2009) 14. Kojima, I.: Design and Implementation of OGSA-DAI-RDF. In: 3rd GGF Semantic Grid Workshop, Athens, Greece (2006) 15. Kojima., I., Said, M.P.: Web Services Data Access and Integration – The RDF(S). Realization (WS-DAIRDF(S)) Querying, Open Grid Form (2009), http://forge.gridforum.org/sf/go/doc14074?nav=1 16. Said, M.P., Kojima, I.: S-MDS: Semantic Monitoring and Discovery System for the Grid. Journal of Grid Computing 7(2) (2009) 17. Said, M.P., Kojima, I.: Semantic Grid Resource Monitoring and Discovery with Rule Processing based on the Time-Series Statistical Data. In: Grid 2008, pp. 358–360 (2008) 18. Stuckenschmidt, H., et al.: Index Structures and Algorithms for Querying Distributed RDF Repositories. In: WWW Conference, pp. 613–639 (2004) 19. Kokkinidis, G., Sidirourgos, L., Christophides, V.: Semantic Web and Peer to Peer. In: Staab, S., Stuckendchmidt, H. (eds.). Springer, Heidelberg (2006) 20. Federated SPARQL, http://www.w3.org/2007/05/SPARQLfed/ 21. DARQ, Federated Queries with SPARQL, http://darq.sourceforge.net/ 22. Antonioletti, M., et al.: Web Services Data Access and Integration - The Core (WS-DAI) Specification, Version 1.0, DAIS Working Group, Open Grid Forum (2006) 23. Antonioletti, M., et al.: Web Services Data Access and Integration - The Relational Realisation (WS-DAIR) Specification, 1.0. DAIS Working Group, Open Grid Forum (2006) 24. Antonioletti, M., et al.: Web Services Data Access and Integration - The XML Realization (WS-DAIX) Specification, 1.0., DAIS Working Group, Open Grid Forum (2006) 25. Gutierrez, M.E., et al.: WS-DAIOnt-RDF(S): Ontology Access Provision in Grid. In: Grid 2007 (2007) 26. WordNet, http://wordnet.princeton.edu/

876

I. Kojima and M. Kimoto

27. Dobrzelecki, B., et al.: Profiling OGSA-DAI Performance for Common Use Patterns, UK All-Hands Meeting (2006) 28. Wang, K., et al.: Performance Analysis of the OGSA-DAI 3.0 Software, Information Technology: New Generations. In: ITNG 2008, pp. 15–20 (2008) 29. Guo, Y., Pan, Z., Heflin, J.: LUBM: A Benchmark for OWL Knowledge Base Systems. Journal of Web Semantics 3(2) (2005) 30. JAXB, https://jaxb.dev.java.net/ 31. Sekiguchi, S.: AIST SOA for Building Service Oriented e-Infrastructure. In: Sixth IEEE International Symposium on Cluster Computing and the Grid, CCGRID 2006 (2006) 32. Lynden, S.J., Pahlevi, S.M., Kojima, I.: Service-based data integration using OGSA-DQP and OGSA-WebDB. In: GRID 2008, pp. 160–167 (2008)

Towards a Reactive Semantic Execution Environment Srdjan Komazec and Federico Michele Facca Semantic Technology Institute (STI) - Innsbruck ICT Technologiepark, Technikerstrasse 21a, 6020 Innsbruck, Austria [email protected]

Abstract. Managing complex and distributed software systems built on top of the service-oriented paradigm has never been more challenging. While Semantic Web Service technologies offer a promising set of languages and tools as a foundation to resolve the heterogeneity and scalability issues, they are still failing to provide an autonomic execution environment. In this paper we present an approach based on Semantic Web Services to enable the monitoring and self-management of a Semantic Execution Environment (SEE), a brokerage system for Semantic Web Services. Our approach is founded on the event-triggered reactivity paradigm in order to facilitate environment control, thus contributing to its autonomicity, robustness and flexibility.

1

Introduction

Current trends in software development show more and more a growth of loosely coupled and widely distributed heterogeneous systems based on the Web. In the recent past, research efforts mainly concentrated on solving the problem of integration of such systems by leveraging semantic technologies. For example, the work related to the Web Service Modeling Ontology (WSMO)[1] framework originated from this problem. We think for the same reasons that semantic technologies can facilitate the integration of loosely coupled and heavily distributed systems, they can also efficiently and effectively support their monitoring and reactivity. Oberle[2] paved the road by studying the benefit of semantic technologies to support development and management of the middleware-based applications. Our research does not simply aim at improving management and monitoring of distributed software systems through semantics, we aim at increasing the level of automation of such systems inline with the Semantic Web Service approach. Thus we think it is possible to relieve humans from performing certain maintenance operations for such systems by making them self-manageable and adaptable through the adoption of a formal description of the system and the actions that can be performed on it to govern its overall behavior dynamically. Naturally, the approach presented can be applied to any distributed software system. In this paper we focus on a Semantic Execution Environment (SEE), a complex distributed system that enacts the Semantically Enabled Serviceoriented Architecture lifecycle. In this way we are self-reflective: We are testing R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 877–887, 2009. c Springer-Verlag Berlin Heidelberg 2009 

878

S. Komazec and F.M. Facca

our approach, based on Semantic Web Services, to manage themselves. Moreover, this simplifies the implementation work needed for lifting events from the syntactic level to the semantic one, given that SEE is already semantically enabled and current efforts toward its description based on semantic technologies are ongoing. The approach we present adopts the WSMO framework for the description of SEE components, related events and their correlation (in term of ontologies) while the reactive behavior enabling self-management of the systems is described in terms of Abstract State Machines (ASM). The paper structure is the following: Section 2 presents SEE and its limitations; in Section 3 we describe our approach detailing its formal grounding; Section 4 applies the approach to the SEE; in Section 5 we provide a discussion of related research efforts. Finally, Section 6 summarizes the work presented and depicts future work directions.

2

The Semantic Execution Environment

Reactivity can improve behavior in many ways such as performance, adaptation, stability and resilience to failures. In this paper we apply our research on semantically-enabled monitoring and reactivity to a family of complex service brokerage platforms based on semantic technologies called Semantic Execution Environment (SEE)[3]. SEE is foreseen as the next generation of service-oriented computing based on machine processable semantics. Its aim is the automation of all the steps of the (semantic) web service’s lifecyle: i.e., discovery, composition, ranking and selection, data and process mediation, choreography, orchestration, and invocation. For each step of the lifecyle, SEE adopts a dedicated broker service; brokers are orchestrated together in the workflows to enable complex scenarios where the different steps of the lifecyle are covered. Even though many research efforts have driven the SEE initiative and its standardization, little work has been done so far in the area of SEE monitoring and self-management, e.g. Vaculin et al.[4]. The observation is that the temporal and highly dynamic knowledge related to the SEE execution (and execution of external Web Services) can enable a high level of self-management. In particular, we foresee the following areas in which SEE can be improved by the application of our approach. Closing the Knowledge Control Loop. Monitoring of SEE broker services represents an indispensable step towards creating a more adaptable environment. Rich and valuable knowledge is produced during the environment execution that can be used for various purposes. For example, service invocation time and availability can be collected to affect the service ranking. Historical data can also be used to identify performance bottlenecks in the environment, restore the systems state at some point in time or even predict future behavior of the environment. Fault Management. Failure detection of the broker and external services can be fixed by a number of strategies such as discovering and employing other components/services capable of fulfilling the user goal or reattempting to accomplish

Towards a Reactive Semantic Execution Environment

879

the task with the same service. Special attention must be given to the capability of the failed service to persistently change the state. In such a case, a compensation mechanism must be provided to suppress the effects of the previously unsuccessful invocation. Self-managed Environment. While SEE is contributing to the dynamic usage of Web Services, its behavior is rather fixed. It is not capable of coping with unexpected situations (e.g. failover of collaborating peers or unavailability of resources such as ontologies and Semantic Web Service descriptions). Furthermore, the overall system functionality is predefined and fixed which hinders any possibility to react to unusual circumstances, i.e. to dynamically change the process when confronted with new conditions. This situation requires support of a rule-based event-triggered reactivity in order to enable a reliable and adaptable environment. For example, in order to enable a Web-scale behaviour of SEE, it could be interesting to introduce some heuristic in its behaviour: when the discovery process takes too long, SEE stops the process and considers only the services discovered till that moment.

3

Monitoring and Self-management of Semantic Execution Environment

The architecture of our solution represents an implementation of the closed control loop paradigm. Systems based on this paradigm observe its parameters and autonomously respond with appropriate actions, as presented in Figure 1. All the SEE brokers are instrumented, thus capable of emitting events. The events are registered in the storage governed by the ontologies. Decisions regarding the actions taken upon sensing/deriving knowledge about the system are delegated to the Reactivity Engine. The engine detects (complex) situations of interest by consulting the registered events, analyzing them in some broader context (e.g. consulting additional knowledge) and selects appropriate actions, which will be enacted over the system. Ontologies. To enable the formalization of the monitored system and its events, and to support the resolution of heterogeneity conflicts, we rely on a stack of ontologies comprising the knowledge base of runtime system behavior. Implementation of the ontologies is flexible enough to give an opportunity to adjust them to a specific domain of application. We provide two upper level ontologies: – Time ontology - which enables reasoning about time points and intervals, – Events ontology - which classifies basic events that can be observed in the domain of interest. The foundational concepts of Time and Events ontologies share the same ground principles as presented in the work of Pedrinacci et al.[5]. The Time ontology defines basic time-related notions such as TimeInstance and TimeInterval

880

S. Komazec and F.M. Facca

Network

Goals

Services

Ontologies

Invoker

Grounding

Choreography

Data Mediation

Selection and Ranking

Composition

Discovery

Network

Mediators

Fig. 1. Architecture of the presented approach

as well as set of axioms (e.g. before, after, etc.) which enable reasoning about time notions compliant to Allen’s algebra[6]. Events ontology relies on Time ontology and defines MonitoringEvent and MonitoringActivity as the ground concept. MonitoringEvent represents a point in time when an event of interest happened and is related to the domain component responsible for its generation (the generatedBy property). Since we are envisioning applications of the framework in a distributed environment (where clock synchronization represents an issue), the concept defines two distinctive time points (occursAt which stands for the component local time when the event occurred, and receivedAt which is the time point of event reception by a monitoring subsystem). MonitoringActivity represents a time interval bounded by two MonitoringEvent occurrences. Modeling a Component and Its Behavior. We adopted WSMO for modeling service’s (i.e. broker’s) capability and behavior. The usage of a SWS framework suits our needs because it gives formal characterization of a service’s functionality which can be easily related to the events represented in the ontological manner and to the reactivity rules. Modeling Global Reactivity. The global system behavior can be modeled by relying on various techniques, such as Finite State Machines, Petri Nets, and UML State Chart diagrams. The assertions stated above are main motivating

Towards a Reactive Semantic Execution Environment

881

factors to select Abstract State Machines (ASM)[7] as the used approach. Reasons to use ASMs compared to the the other approaches stem from the set of properties that distinguish them and makes them more suitable, such as arbitrary levels of abstraction, formality, minimality, state-based, and maximality. An approach used to describe ASMs is borrowed from Scicluna et al.[8]. An ASM consists of a finite set of transition rules which are executed in parallel. The rules operate on top of a finite collection of static and dynamic functions. Values of the former cannot change during a run of a machine, while values of the latter can be changed by environment (agents interacting with the machine) or the machine itself. Our approach regards reactive behavior as a pair signature, rulereact where – signature is a state signature which precisely defines the structure of the state in the context of the Knowledge Base (KB), and – rule is a set of guarded transition rules. A state signature is a pair KB, modess where KB is a knowledge base that defines concepts comprising the state and mode is a set of modes which take a form of type, conceptmode where – type can be one of the symbols static, in, out, shared or controlled, as described by [8], and – concept is a concept defined in KB. A guarded transition rule can take the form of – – – – – – –

an if-then rule cond, ruleif , a forall rule variables, cond, rulef orall , a choose rule variables, cond, rulechoose , a piped rule rule, an add rule αadd , an update rule αupdate , and a delete rule αdelete .

where cond is a condition such that the set of free variables in it corresponds with variables which is a set of variable identifiers; rule is a nonempty set of guarded transition rules and α is a fact (i.e. variable free instance of knowledge). The ASM description is additionally extended with rules that enable invocation and discovery of Web Services. The invokeWS rule wsIRI, f actinvokeW S invokes the Web service identified by wsIRI and uses fact as input data. The discoverWS rule goalIRI, wsIRIdiscoverW S executes discovery based on the goal identified by goalIRI and binds to the variable wsIRI result of the discovery process.

882

4

S. Komazec and F.M. Facca

First Prototype Implementation

Although the research presented in this paper is not yet mature we have realized a first prototype to validate our claims. The prototype is based on the case study introduced in Section 2. Extension of the Event Ontology. The Event Ontology briefly discussed in Section 3 has been extended with the definitions of events and activities related to the SEE domain. This ontology relies on the Reference Ontology for Semantically-enabled Service Oriented Architecture[9], which formalizes notions of interest such as Service Description, Goal Description, etc. For example, the InvokeWebServiceActivity from the extended ontology describes either successful or unsuccessful invocation of an external Web Service (the distinction is made by the usage of appropriate MonitoringEvent type, InvokeWebServiceEnded or InvokeWebServiceFailed ). Instrumentation of the SEE Environment. Event acquisition is performed by proper instrumentation of the observed brokers during which suitable lifting mechanisms are used, i.e. transformation of collected low-level data to the semantically represented counterparts according to the extended ontology. Instrumentation has been conducted by application of Aspect Oriented Programming which provides a non-intrusive technique for weaving the crosscutting behavior (like security, monitoring, logging, etc.) into the code. The developed aspects are merely collecting data needed to create the appropriate MonitoringEvent and MonitoringActivity instances and storing these instances into the repository that is used by the Reactivity engine. 4.1

Examples of Self-management Behavior

Closing the Knowledge Control Loop. Many service-related properties such as Web Service availability, response times and number of failed invocations over the total number of invocations can affect the service rating during the ranking and selection step. Let’s assume that there exists a Quality of Service ontology used by the Ranking broker which holds an instance of the Ranking concept for each external service registered in the system. The Ranking concept has a couple of associated attributes like hasWebService, which identifies a Web Service, hasRankingValue, which defines current ranking value for the Web Service and hasAvgDuration, which is the average duration of time experienced during past Web Service invocations. Let’s further assume that, for the sake of simplicity, ranking is defined as rank(ws)new = rank(ws)old −

tend − tstart − Tavg Tavg

where ws represents the Web Service identifier, tstart and tend represent starting and ending time for the Web Service invocation and Tavg represents the

Towards a Reactive Semantic Execution Environment



883



reactivity RankingAdaptation stateSignature importsOntology{ ”http://www.sti−innsbruck.at/ontologies/Ranking#”, ”http://www.sti−innsbruck.at/ontologies/EventsOntology#” } in events# out ra#Ranking



transitionRules forall {?event, ?ranking} with ?event [ startTime hasValue ?startTime, endTime hasValue ?endTime, hasWebService hasValue ?wsID ] memberOf events#InovokeWebServiceActivity and ?ranking [ hasWebService hasValue ?wsID, hasAvgDuration hasValue ?tAvg, hasRankingValue hasValue ?rankOld ] memberOf ra#Ranking do update ?ranking [ hasWebService hasValue ?wsID, hasRankingValue hasValue ?rankOld − (?endTime − ?startTime − tAvg) / tAvg, ]memberOf ra#Ranking endForall



Listing 1. Updating ranking value after Web Service invocation

average duration of the Web Service invocation. It is worth noting that each time the Web Service is successfully invoked an instance of the InovokeWebServiceActivity is generated which has, as associated attributes, startTime, endTime, and hasWebService, thus identifying the invocation of the particular Web Service. An example of reactive behavior which updates the Web Service ranking value upon detection of the InovokeWebServiceActivity instance is presented in Listing 1. Fault Management and Self-managed Environment. A service invocation failure situation can be resolved in a different ways depending upon the adopted strategy. In the case of idempotent method invocation the operation can be repeated again in order to exclude issues bound to underlying network failures. Successive invocation failures can further be regarded as a service-related issue, in which case the system can decide whether to enact the second best solution to fulfill the user goal. This behavior is represented in Listing 2. The first forall rule identifies one sole occurrence of the InvokeWebServiceActivity which has failed (i.e. closing activity event is of the type InvokeWebServiceFailed ). The response of the system is to initiate another invocation of the same service with the same input data. The second forall rule detects two occurrences of failed InvokeWebServiceActivity related to the same session and Web Service invocation. In this case the system exercises another discovery and invokes the newly discovered Web Service. Initial experiments show that the application of the proposed approach to SEE improves its functionality by reducing the number of system failures and by allowing for example, QoS ranking of services.

884

5

S. Komazec and F.M. Facca

Related Work

Reactive behavior is drawing attention to many areas of computer science. The early work of Harel et al.[10] clarified the founding notions of reactive systems by relying on the statecharts method (grounded in Finite State Automata, FSA). By that time it was clear that a reactivity modeling approach needs to support state-based computational processes, but FSA was abandoned very soon since it does not support modularity neither hierarchical structures and suffers from exponential growth of state and transition numbering. Nowadays, reactivity represents a core pillar of IBM’s Autonomic Computing initiative[11], which advocates system self-management by introducing a monitor-analyze-plan-execute control loop based on knowledge, thus relieving humans from of the responsibility of directly managing systems. Veanes et al.[12] presented an approach to on-the-fly testing of reactive systems based on Abstract State Machines. Besides testing, our approach envisions support for complete reactive behavior development (i.e. modeling, implementation, testing and execution). Active Databases largely contributed to the body of knowledge around reactive systems. The work of Chakravarthy et al.[13] introduces a language called Snoop on top of which they define different detection contexts and event detection architecture (based on even-detection trees). Gehani et al.[14] gave yet another formalization of complex event expressions and associated operators as well as an incremental detection technique based on FSA. Our work has been directly inspired by the paradigm since Web Service Modeling eXecution environment (WSMX) instances coupled with the reactive engine can be seen as managed elements in a collaborative environment tailored in the P2P fashion. Schmidt et al.[15] introduced a survey on current trends in the field of eventdriven reactivity where they examined a variety of approaches in the area of Complex Event Processing (CEP) and Event-Condition-Action (ECA) rules. According to their categorization, our solution resides in the area of logic-based approaches, where the most prominent work is represented by Paschke[16]. Monitoring represents the first step in establishing the reactive behavior of a system. Wang et al.[17] enumerate a number of events that can be produced by SOAs where the observability of the specific event type depends on the possibility of positioning appropriate probes in the monitored object. However, the research community showed only limited interest in Semantic Web Service monitoring. Vaculin et al.[4] defined an event taxonomy and a solution for detection of complex events in the context of the OWL-S choreographies. Nevertheless, the existing approaches are not considering any application of the service capability and behavior models (i.e. service choreography and orchestration) during the monitoring functions, neither monitoring of the overall SEE environment. Oberle[2] presented an ontology-based approach to support development and administration of the middleware-based applications. Although currently absent, formal characterization of the Semantic Execution Environments can contribute to the annotation and processing of the complex events produced by them.

Towards a Reactive Semantic Execution Environment



885



reactivity ServiceInvocationFailureRecovery stateSignature importsOntology { ”http://www.sti−innsbruck.at/ontologies/TimeOntology#TimeOntology”, ”http://www.sti−innsbruck.at/ontologies/EventsOntology#EventsOntology”, ”http://www.semantic−soa.org/ReferenceOntology”} in domain#GoalDescription transitionRules forall {?x} with ?x memberOf InvokeWebServiceActivity and ?x[hasInputInstances hasValue ?inputInstance] and ?x[hasWebService hasValue ?ws] and ?x[endTime hasValue ?xEndTime] and ?xEndTime memberOf InvokeWebServiceFailed and naf ?x[after hasValue ?z] and naf ?x[before hasValue ?m] do invokeWS(?ws, ?inputInstance) endForall



forall {?x, ?y} with ?x memberOf InvokeWebServiceActivity and ?y memberOf InvokeWebServiceActivity and ?x[hasWebService hasValue ?ws] and ?x[hasInputInstances hasValue ?inputInstance] and ?y[hasWebService hasValue ?ws] and ?x != ?y and ?x[hasSessionID hasValue ?sId] and ?y[hasSessionID hasValue ?sId] and ?x[endTime hasValue ?xEndTime] and ?y[endTime hasValue ?yEndTime] and ?xEndTime memberOf InvokeWebServiceFailed and ?yEndTime memberOf InvokeWebServiceFailed and ?x[before hasValue ?y] and naf ?x[after hasValue ?z] and naf ?y[before hasValue ?m] do discoverWS(?goal, ?wsNew) invokeWS(?wsNew, ?inputInstance) endForall



Listing 2. Implementation of the reactive behavior used to recover from service invocation failures

6

Conclusions and Future Work

In this paper we presented an approach towards semantically enabled monitoring and self-management of Semantic Execution Environments. Our solution is based on a set of ontologies (namely Time, Event and Domain) which provides a unified space for registering and reasoning about run-time service broker behavior. The components are represented as Semantic Web Services which enables comprehensive and formal description of their capabilities and behavior. Representation of the reactive behavior is assigned to Abstract State Machines, which represent yet another formal state-based approach to model a system behavior in a concise and expressive manner. Usage of the approach has been exemplified in a case study related to the Semantic Execution Environment. The study showed an elegant yet powerful way to define and execute reactive behavior in cases of service invocation failure, which indicates the value of the presented approach. In the future, we will concentrate on integrating a fast Complex Event Processing (CEP) engine to raise the overall system performance by lifting the load of complex event detection from the ASM engine (i.e. instead of using a reasoner). Additionally, for the use case, we plan to enrich WSMX brokers with a

886

S. Komazec and F.M. Facca

management interface that supports timed events in order to be able to generate periodic events on behalf of the managed component. This will allow periodic progress checking of the complex computations (e.g. discovery running over a large set of services) and timed notifications (e.g. taking results of the discovery before completion of the process over the entire set of registered services). Acknowledgments. The work published in this paper is funded by the E.C. through the COIN IP (Project No. 216256). The authors wish to acknowledge the Commission for their support.

References 1. Fensel, D., Lausen, H., Pollers, A., de Bruijn, J., Stollberg, M., Roman, D., Domingue, J. (eds.): Enabling Semantic Web Services: The Web Service Modeling Ontology. Springer, Heidelberg (2007) 2. Oberle, D. (ed.): Semantic Management of Middleware. Springer Science + Business and Media, Heidelberg (2005) 3. Fensel, D., Kerrigan, M., Zaremba, M. (eds.): Implementing Semantic Web Services: The SESA Framework. Springer, Heidelberg (2008) 4. Vaculin, R., Sycara, K.: Specifying and Monitoring Composite Events for Semantic Web Services. In: Proceedings of the 5th IEEE European Conference on Web Services (November 2007) 5. Pedrinaci, C., Domingue, J., Alves de Medeiros, A.K.: A Core Ontology for Business Process Analysis. In: Bechhofer, S., Hauswirth, M., Hoffmann, J., Koubarakis, M. (eds.) ESWC 2008. LNCS, vol. 5021, pp. 49–64. Springer, Heidelberg (2008) 6. Allen, J.F.: Maintaining knowledge about temporal intervals. Commun. ACM 26(11), 832–843 (1983) 7. Borger, E., Stark, R. (eds.): Abstract State Machines: A Method for High-Level System Design and Analysis. Springer, Heidelberg (2003) 8. Scicluna, J., Polleres, A., Roman, D.: Ontology-based Choreography and Orchestration of WSMO Services. Technical Report D14v0.2, Semantic Technology Institute (STI) Innsbruck (2006) 9. Norton, B., Kerrigan, M., Mocan, A., Carenini, A., Cimpian, E., Haines, M., Scicluna, J., Zaremba, M.: Reference Ontology for Semantic Service Oriented Architectures. Technical report, OASIS Semantic Execution Environment TC (2008) 10. Harel, D., Pnueli, A.: On the development of reactive systems. In: Logics and models of concurrent systems, pp. 477–498. Springer, New York (1985) 11. Kephart, J.O., Chess, D.M.: The Vision of Autonomic Computing. Computer 36(1), 41–50 (2003) 12. Veanes, M., Campbell, C., Schulte, W., Kohli, P.: On-The-Fly Testing of Reactive Systems. Technical Report MSR-TR-2005-05, Microsoft Research (2005) 13. Chakravarthy, S., Krishnaprasad, V., Anwar, E., Kim, S.K.: Composite Events for Active Databases: Semantics, Contexts and Detection. In: VLDB 1994: Proceedings of the 20th International Conference on Very Large Data Bases, pp. 606–617. Morgan Kaufmann Publishers Inc., San Francisco (1994) 14. Gehani, N.H., Jagadish, H.V., Shmueli, O.: Composite event specification in active databases: Model and implementation. In: Proceedings of the 18th VLDB Conference, pp. 327–338 (1992)

Towards a Reactive Semantic Execution Environment

887

15. Schmidt, K.U., Anicic, D., Sthmer, R.: Event-driven Reactivity: A Survey and Requirements Analysis. In: Proceedings of the 3rd international Workshop on Semantic Business Process Management at 5th European Semantic Web Conference (2008) 16. Paschke, A.: ECA-LP / ECA-RuleML: A Homogeneous Event-Condition-Action Logic Programming Language. In: Proceedings of Int. Conf. on Rules and Rule Markup Languages for the Semantic Web (RuleML 2006), Athens, Georgia, USA (November 2006) 17. Wang, Q., Liu, Y., Li, M., Mei, H.: An Online Monitoring Approach for Web services. In: COMPSAC 2007: Proceedings of the 31st Annual International Computer Software and Applications Conference (COMPSAC 2007), Washington, DC, USA, pp. 335–342. IEEE Computer Society, Los Alamitos (2007)

Collaborative Building, Sharing and Handling of Graphs of Documents Using P2P File-Sharing Alan Davoust and Babak Esfandiari Department of Systems and Computer Engineering Carleton University 1125 Colonel By Drive Ottawa, Ontario, Canada

Abstract. We are interested in creating a peer-to-peer infrastructure for the collaborative creation of knowledge, with no centralized point of control. We show how documents in a P2P file-sharing network can be interlinked, using a naming scheme based on the document schema and content, rather than on the document location. The interlinked documents can be seen as a distributed graph of documents, for which we define a class of graph queries supported by our file-sharing system. Keywords: Peer-to-peer, file-sharing, graph queries, Semantic Web.

1

Introduction

Collaborative online knowledge construction efforts have gained momentum with the arrival of ”Web 2.0” technologies, and they represent a crucial step toward realizing Tim Berners-Lee’s vision of the Semantic Web [1]. Projects such as [2] rely on a centralized wiki repository where ontologies can be created and modified. The issue with such approaches is that there is ultimately a central decision point (and a single point of failure) and only one ”version of the truth” can be held. Distributed efforts relying on peer data management systems [3], [4] still aim to provide a single consistent view of data through data integration mechanisms such as ontology mappings. Our work is based on the principles of peer-to-peer (P2P) file-sharing systems such as such as Napster1 , or eMule2 , where peers act both as clients and servers, and where documents downloaded by one peer are also immediately made available by that peer. This means that more popular documents will be more heavily replicated and will be more available regardless of the turnover (arrival and departure) of peers. It also means that each peer will provide a subset of all available documents, a subset that is potentially different from those served and used by other peers. U-P2P [5,6] is a schema-based file-sharing system, where communities of peers share documents structured according to a particular metadata schema, comparable to the music-specific metadata schema of MP3 files. Each peer can manage 1 2

http://www.napster.com, no longer existing in its original form http://www.emule-project.net

R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 888–897, 2009. c Springer-Verlag Berlin Heidelberg 2009 

Collaborative Building, Sharing and Handling of Graphs of Documents

889

multiple schemas, but also create new schemas which can be themselves shared on the network, and discovered and downloaded by other peers. Peers who use the new schema thus form a new community. However, in this model, each community defines an independent and unrelated collection of documents. The next step that we see towards representing knowledge is the possibility of interlinking documents. Interlinked documents can be seen as a navigable graph, that users may “browse”, navigating from one concept to another related concept. The side-effect of this navigation is the creation of a personal sub-graph or view of the world, made available for others to build upon. Our approach to links, previously presented in [7,8] is based on a P2P-specific URI scheme with a search-based dereferencing protocol: documents are identified by their community and content, rather than by their location, as in web-based systems. In this paper we show how the resulting graph of documents can be queried and shared using a query language similar to SPARQL. The rest of this paper is organized as follows. We first introduce our naming scheme in Section 2, then present a class of graph queries supported by U-P2P in section 3.

2 2.1

URIs and Endpoints in U-P2P Formal Foundations

We briefly recall the formal model of U-P2P, that was previously presented in [9]. Communities. Our existing prototype U-P2P provides a framework with multiple communities, where each community has its specific schema, which defines the format of the documents shared within that community, its protocol, which defines how (and therefore which) peers can be reached by a query from another peer of the community, and finally its own name, which is simply an identifier of the commmunity. By analogy with the formal model of relational databases, we define each document shared in a community as a tuple (x1 , . . . , xn ). The schema SC of a community C is a single n-ary relation RC made up of n (n ≥ 2) attributes Ai . The domain of RC is a fixed infinite set DC , and we will detail further the subdomains of the attributes Ai . Intuitively, the tuples in the extension of RC correspond to the documents shared in the community. Each Peer p member of the community C hosts an p extension RC of RC . We distinguish two types of attributes for RC : metadata attributes and attachments. Metadata attributes are attributes with standard types such as strings and numbers, whereas attachments are attributes that have a “binary” domain, in the sense that there is no simple human readable representation for these attributes. In particular, RC has an attribute name that uniquely identifies each document in RC , i.e. in each community schema there is a primary key attribute that

890

A. Davoust and B. Esfandiari

we will call name. In U-P2P, this attribute is generated using a one-way hash function using the metadata attributes of the document. Intuitively, as this formalization is meant to model traditional file-sharing communities, attachments are attributes containing the binary payload of a file. In our view a file and its metadata form a single data item, which we call a document. The set of peers {pi } reachable from a given peer p can be represented by a function P rotC (p:peer) (the procedural aspects of the protocol are not modeled). For example, the Gnutella protocol with a time-to-live of 7 can be modeled by a function that returns all the peers connected to p by a path shorter than 7 hops. File-Sharing Operations. Each peer p member of a community C defines an interface to C with the following fundamental file-sharing operations: p – Publish(doc: document ): add the document doc to RC p p – Delete(doc: document): if doc is in RC , remove doc from RC . – Search(expr: expression): the expression expr is a first-order logic formula of at most n free variables, involving the attributes of RC , this search returns tuples {(pi , namej , xm1 , . . . xmk )}, where (namej , xm1 , . . . xmk ) are the metadata attributes of a document dj , pi is a peer such that pi ∈ P rotC (p) pi and dj ∈ RC . Intuitively, these search results describe documents matching the search query and available in the network (reachable via the protocol), with the identifiers of the peers that store these documents, which can then be used to download the file. – Download(name0 : document identifier, p1 : peer identifier) : copies the docp1 p ument identified by name0 from RC to RC . – Lookup(name0 : document identifier, attr: attribute): returns the value of attribute attr in the document docname0 uniquely identified by name0 .

Multiple Communities. In U-P2P, communities are themselves described in structured documents, shared in a specific community called the “Commmunity of Communities”, which we will note CCommunity . The schema of this community is the relation RCommunity with the attributes (name, schema, protocol). Each document shared in this community thus represents a community, with its unique name, and representations of its schema and protocol. In U-P2P, we have added additional attributes to this community, including community-specific presentation templates, and a description of the community. On downloading such community definition documents, a peer automatically joins the described community, and thus acquires the capability of sharing documents of that community. 2.2

URI Scheme

Within our multiple-community framework, all the instances of a particular document (replicated across the P2P network) are interchangeable and uniquely

Collaborative Building, Sharing and Handling of Graphs of Documents

891

identified within their community by their name (which we recall, is a hash obtained from the document metadata), hence fully identified within a P2P system by the pair (community name, document name). We can thus introduce a URI scheme specific to our framework, by concatenating the identifier “up2p” of our scheme, with the community and document names, separated by a slash character. In UP2P, we generate unique names of documents using an MD5 hash function, and represent its output as a 32-character hexadecimal string. We obtain 70-character document URIs such as the following example: up2p:b6b6f4dd9cd455bc647af51e03357156/0192c7eb042bae9aaafa3b0527321938. 2.3

Endpoint Attributes

In order to make use of this URI in our model, as a way to link documents, we now introduce a new type of attribute, defined by its domain, similarly to metadata and attachments. We define the fixed, infinite set C-NAMES of possible community names (i.e. the domain of the attribute name in the community CCommunity ), and the fixed, infinite set D-NAMES as the union, for all possible communities, of the domains of their name attributes. Definition 1. An attribute att is an endpoint attribute iff its domain is C-NAMES × D-NAMES. (cartesian product).

We note that this definition is of purely theoretical interest. In practice the schema of a community can be annotated to specify that a given attribute is an endpoint (or an attachment, or a metadata attribute); and a system using such endpoints would only validate the syntax of the URI. 2.4

Dereferencing Protocol

Dereferencing a URI, i.e. obtaining a document from its URI, can be done using the basic P2P File-Sharing operations search and download defined in Section 2.1. The procedure is given by the pseudocode algorithm 1. This search-based dereferencing mechanism may have a high cost, but we note that the search is specific to a community, which reduces the search space, as all peers in a P2P system will not necessarily be members of all communities. Furthermore, identifying a document by its content rather than its location provides the opportunity of getting any one of multiple copies, which makes the dereferencing more robust to churn, in the sense that when a peer leaves a community, the documents that it has published in the community may still be available from other peers. 2.5

Example

We introduce two communities, one community of documents describing movie actors, and a community of documents describing films.

892

A. Davoust and B. Esfandiari

Algorithm 1. URI dereferencing algorithm The peer performing the dereferencing is denoted by p. function dereference(up2p:id1/id2): if p not member of Cid1 then  Cid1 is the community uniquely identified by the name id1 {(pi , id1)}i=1...m ← CCommunity .search(name=id1 ) j ← select in [1 . . . m]  select a peer Community.download(pj , id1);  p joins Cid1 end if {(pi , id2)}i=1...w ← id1.search(documentId=id2 ); k ← select in [1 . . . w]  select a peer id1.download(pk , id2); return docid2  docid2 is the document of Cid1 uniquely identified by the name id2. end function

The schema of the community Cf ilm would be the relation Rf ilm with attributes (name, title, director, year, binaryf ilm). The schema of Cactor could be Ractor with attributes: (name, actorname, f ilmography), where f ilmography could be a multi-valued endpoint attribute, referencing films that this actor has played in, themselves documents shared in the community Cf ilm . We could then model the actors Elijah Wood and Liv Tyler, who played in several films of the “Lord of the Rings” trilogy. The documents representing Elijah Wood and Liv Tyler could then be3 : (livtyler, ‘Liv Tyler’, up2p:film/twotowers) (elijahwood, ‘Elijah Wood’, up2p:film/twotowers, up2p:film/fellowship) The documents describing the films would be: (twotowers, ‘The two Towers’, ‘Peter Jackson’, [binary film representation]) (fellowship, ‘The Fellowship of the Ring’, ‘Peter Jackson’, [binary film representation]) The graph induced by these example documents can be represented in the UML object diagram of Figure 1. Note that the diagram does not include all the attributes of the documents, as it would overload it.

3

Graph Queries in U-P2P

In the graph of data induced by endpoints, where vertices represent documents and edges represent endpoint attributes, we consider the class of graph queries defined by path patterns: given an input document d and a path pattern p, the query returns all documents connected to d by a path matching p. 3

The name attribute of each document should be generated by a MD5 hash, but we use reader-friendly names here to make the examples more readable.

Collaborative Building, Sharing and Handling of Graphs of Documents

893

Fig. 1. An Example graph of related U-P2P documents

The simplest patterns p define paths of length 1, i.e. a single edge. We first describe how such elementary queries can be answered, then we build on this basis to show how arbitrary path pattern queries can be answered. 3.1

Edge Pattern Queries

In the graph of data, we define a predicate to describe the edges of the graph. Definition 2. We define the predicate edge of arity 4, as follows: edge(doc1 , comm, endpoint, doc2 ) is true if the attribute endpoint of document doc1 in community comm has the value uri2 , where uri2 is the URI of document doc2 . We define queries based on the predicate edge by replacing one, both, or none of doc1 and doc2 by free (i.e. universally quantified) variables or by bound (i.e. existentially quantified) variables. We do not consider the possibility of the community or endpoint name being variables. We note that the reason to constrain the community of doc1 (i.e. to include the community in the edge definition), rather than the community of doc2 , or both, is that the endpoint attribute that characterises the edge is defined within the context of the community schema of doc1 . For the sake of simplicity, we focus on queries with one free variable, and constants, as these will be the basis of our following generalization in section 3.2. Queries with a single free variable return documents, extending the functionality of simple search queries, which is a fundamental part of file-sharing.

894

A. Davoust and B. Esfandiari

We consider the following simple declarative queries. The lower-case names denote constants, and the upper-case X and Y denote variables. {X | edge(doc1 , comm, endpoint, X)}

(1)

{X | edge(X, comm, endpoint, doc2 )}

(2)

The above queries can be respectively interpreted as: “find all documents referenced by doc1 through the attribute endpoint”, and “find all documents in community comm referencing doc2 through the attribute endpoint”. We will thus focus on those queries, for which U-P2P implements a query answering algorithm. The answers to other types of queries can easily be derived from minor modifications of our query answering algorithm, but we do not expand on this here for a lack of space. In Algorithms 2 and 3, we detail the query answering procedures for queries 1 and 2, using the basic P2P File-Sharing operations search and download, and lookup. We assume that doc is given as a URI.

Algorithm 2. Algorithm for answering query 1. function AnswerQuery2(doc, comm, endpoint) dereference(doc)  ensure that doc is stored locally uri-list ← comm.lookup(doc, endpoint)  endpoint may be multi-valued for all uri ∈uri-list do results ← results ∪ dereference(uri) end for return results. end function

Algorithm 3. Algorithm for answering query 2. function AnswerQuery1(comm, endpoint, doc) if p not member-of comm then {(pi , comm)}i=1...m ←Community.search(communityId=comm) j ← select in [1 . . . m]  select a peer Community.download(pj , comm); end if results ← comm.search(endpoint = doc) return results. end function

3.2

General Graph Queries

Based on these elementary edge queries, we now define a class of graph queries, representing sequences of edges, i.e. paths of arbitrary length in the graph of documents. This is the class of queries supported by U-P2P.

Collaborative Building, Sharing and Handling of Graphs of Documents

895

Preliminaries. Intuitively, an edge query is a pattern that matches directed edges between two documents, and for each matching edge, query 1 returns the document at the start of the edge, whereas query 2 returns the document at the end of the edge. In order to unify these two types of queries, we introduce a parametric form of the edge predicate, where the boolean parameter will indicate which document the query should return. We define the parametric predicate edgedir , where the parameter dir can take the values r (for “right”) or l (left), as follows: edgel (X, c, e, Y ) =def edge(X, c, e, Y ) edger (X, c, e, Y ) =def edge(Y, c, e, X)

(3) (4)

We can now rewrite our queries 1 and 2 as follows: {X | edge(doc, comm, endpoint, X)} = {X | edger (X, comm, endpoint, doc)}(5) {X | edge(X, comm, endpoint, doc)} = {X | edgel (X, comm, endpoint, doc)}(6) Path Pattern Graph Queries Definition 3. The class of path pattern queries is defined by the following general declarative form: {X | ∃(Y0 , . . . , Yn ),

n−1 i=1

∧

edgeb0 (X, comm0 , endpoint0 , Y0 ) edgebi (Yi−1 , commi , endpointi , Yi ) edgebn (Yn , commn , endpointn , doc)}

where the parameters of the query are: – (b0 , . . . , bn ) are boolean parameters (i.e. they take one of the two values ’r’ or ’l’) denoting one of the two forms of edgedir queries (queries 5 and 6); – (comm0 , . . . , commn ) are communities (may contain multiple occurences of a given community); – (endpoint0 , . . . , endpointn ) are endpoint attribute names, with the constraint that endpointi must be an attribute of the schema of community commi ; – doc is a document Such queries define paths of length n in a graph of documents, starting from the input document doc. Example. Based on the example of Section 2.5, involving Movies and Actors, we give the declarative form of a query for an actor who have played in the same film as the actor Kevin Bacon, given as an input to the query in the form of the URI up2p:film/kbacon: {X | ∃Y0 ,

edgel (X, actor, f ilmography, Y0) ∧ edger (Y0 , actor, f ilmography, up2p:actor/kbacon)

896

A. Davoust and B. Esfandiari

We note that this query definition could easily be extended by some additional edges to represent the famous “six degrees of separation” concept between movie actors, as made popular by the “Kevin Bacon Game”. Query Answering Algorithm. We now detail the general algorithm to answer a path pattern query, using the notations of the above definition. The general methodology is based on the linear form (paths) of the considered graph patterns: intuitively, the edges defined by each edge predicate form a path, i.e. a sequence with a natural order. The query can be answered by starting from the “end” of the path, indicated by the input variable doc in the last occurence of the edgedir predicate, i.e. the occurence associated with the index i = n. The query is answered by answering each of the subqueries associated with the index values i = 1 . . . n, starting with n then iterating in reverse to 1. Each subquery is answered using either Algorithm 2 or 3. The answers to the subquery associated with index i are documents that can then be input to the query at index i − 1, and so on until the last step, where the answers are returned. This algorithm is listed in Algorithm 4. Algorithm 4. Path Pattern Graph Query Answering Algorithm function AnswerPathQuery([b0 , . . . , bn ], [comm0 , . . . , commn ], [endpoint0 , . . . , endpointn ], doc) if dir = l then Ylist ← AnswerQuery1(commn , endpointn , doc) else if dir = r then Ylist ← AnswerQuery2(doc,commn , endpointn ) end if if n = 0 then return Ylist else for all Y ∈ Ylist do answerlist ← answerlist ∪ AnswerPathQuery([b0 , . . . , bn−1 ], [comm0 , . . . , commn−1 ], [endpoint0 , . . . , endpointn−1 ], Y ) end for return answerlist end if end function

4

Conclusions

We presented in this paper a graph data model for documents in a P2P filesharing network, and we showed a way to contribute to such a graph in a collaborative manner using basic P2P functions and a query language that builds on those functions.

Collaborative Building, Sharing and Handling of Graphs of Documents

897

Our URI scheme nicely fits with the principles of file-sharing, as it does not assume a single static location for a document, but rather identifies a document by its schema and content. Our graph data model could be compared with RDF: its main difference is that we do not see attributes as nodes in the graph: our model corresponds to an RDF graph showing only RDF links between resources. Due to space restrictions, we left out a description of our case study that validates our approach, as well as a description of our approach for reusing queries, which makes use of a custom U-P2P Community of Queries.

References 1. Berners-Lee, T., Hendler, J.A., Lassila, O.: The semantic web. Scientific American 284, 34–43 (2001) 2. Martin Hepp, D.B., Siorpaes, K.: Ontowiki: Community-driven ontology engineering and ontology usage based on wikis. In: Proceedings of the 2005 International Symposium on Wikis, WikiSym 2005 (2005) 3. Halevy, A., Ives, Z., Madhavan, J., Mork, P., Suciu, D., Tatarinov, I.: The piazza peer data management system. IEEE Transactions on Knowledge and Data Engineering 16, 787–798 (2004) 4. Adjiman, P., Chatalic, P., Goasdou´e, F., Rousset, M.C., Simon, L.: SomeWhere in the semantic web. In: Fages, F., Soliman, S. (eds.) PPSWR 2005. LNCS, vol. 3703, pp. 1–16. Springer, Heidelberg (2005) 5. Mukherjee, A., Esfandiari, B., Arthorne, N.: U-P2P: A peer-to-peer system for description and discovery of resource-sharing communities. In: ICDCSW 2002: Proceedings of the 22nd International Conference on Distributed Computing Systems, Washington, DC, USA, pp. 701–705. IEEE Computer Society, Los Alamitos (2002) 6. Arthorne, N., Esfandiari, B., Mukherjee, A.: U-P2P: A peer-to-peer framework for universal resource sharing and. In: Discovery, USENIX 2003 Annual Technical Conference, FREENIX Track, pp. 29–38 (2003) 7. Davoust, A., Esfandiari, B.: Towards semantically enhanced peer-to-peer filesharing. In: Meersman, R., Tari, Z., Herrero, P. (eds.) OTM-WS 2008. LNCS, vol. 5333, pp. 937–946. Springer, Heidelberg (2008) 8. Davoust, A., Esfandiari, B.: Towards semantically enhanced peer-to-peer filesharing. Journal of Software 4 (to appear, 2009) 9. Davoust, A., Esfandiari, B.: Peer-to-peer sharing and linking of social media based on a formal model of file-sharing. Technical Report SCE-09-04, Department of Systems and Computer Engineering, Carleton University (2009)

Management Tool for Semantic Annotations in WSDL Nicolas Boissel-Dallier1,2, Jean-Pierre Lorré1, and Frédérick Benaben2 1

EBM WebSourcing, 4 rue Amélie, 31000 Toulouse, France {nicolas.boissel-dallier, jean-pierre.lorre}@ebmwebsourcing.com 2 Ecole des Mines d’Albi-Carmaux, Route de Teillet, 81000 Albi, France [email protected]

Abstract. Semantic Web Services add features to automate web services discovery and composition. A new standard called SAWSDL emerged recently as a W3C recommendation to add semantic annotations within web service descriptions (WSDL). In order to manipulate such information in Java program we need an XML parser. Two open-source libraries already exist (SAWSDL4J and Woden4SAWSDL) but they don’t meet all our specific needs such as support for WSDL 1.1 and 2.0. This paper presents a new tool, called EasyWSDL, which is able to handle semantic annotations as well as to manage the full WSDL description thanks to a plug-in mechanism. This tool allows us to read/edit/create a WSDL description and related annotations thanks to a uniform API, in both 1.1 and 2.0 versions. This document compares these three libraries and presents its integration into Dragon the OW2 open-source SOA governance tool. Keywords: Semantic Annotations, SAWSDL, Service Oriented Architecture, ontology, SOA governance.

1 Introduction According to the World Wide Web Consortium (W3C), a web service is a software system designed to support interoperable machine-to-machine interaction over a network [1]. Web services use Web Services Description Languages (WSDL) to display what the service offers. Unfortunately, first, two versions of this W3C standard are already used (1.1 and 2.0) and, second, it is limited to syntactic (nonsemantic) data. In order to improve interoperability and reuse of code, especially in inter-enterprise collaboration contexts, information systems need to exchange machine understandable data and operations [2]. For that reason, we have to connect each web services with reference concepts which are defined between all partners. Toward this goal, the W3C published a new standard which allows to link web service description parts to semantic concepts, whatever the ontology language. This recommendation is called R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 898–906, 2009. © Springer-Verlag Berlin Heidelberg 2009

Management Tool for Semantic Annotations in WSDL

899

Semantic Annotations for WSDL and XML Schema (SAWSDL)1 and extends both WSDL standards and XML Schema specification2. This standard is an important step toward automating discovery, execution and composition of Web services. Moreover, in a concern of code reuse, it can be interesting to dispose of a SAWSDL management tool. This is the aim of EasyWSDL, presented in this article. This work is based on an ongoing work supported both by the SemEUse ANR project3 funded by the French government and by SOA4ALL4, a NESSI strategic integrated project. EBM WebSourcing involvement in these projects is focusing on high scale service distribution and semantic for next generation service infrastructure and governance. First, this paper presents WSDL standard and related open-source parsers (Section 2). Then, it introduces SAWSDL and associated tools (Section 3). The next part presents EasyWSDL, a new WSDL parser and its SAWSDL extension (Section 4), comparing to others. In order to illustrate previous points, it also presents the integration of a SAWSDL editor, based on EasyWSDL and embedded in Dragon, the SOA governance tool of the OW2 consortium (Section 5). Finally, the section 6 concludes this paper.

2 WSDL Standard and Associated Tools 2.1 Web Service Description Language WSDL is one of the three technologies which underlie Web Services (together with UDDI and SOAP). It is an XML-based language that provides a model for describing web services. It contains abstract information about operations and exchanged messages but also concrete data like network access parameters or binding protocol. Two versions of WSDL recommendation already exist: the 1.15 version (which was a W3C Submission but is still used in almost all existing systems) and the 2.06 version (which is a W3C Standard intended to replace 1.1). Both versions are functionally quite similar but have substantial differences in XML structure (renamed and removed tags). 2.2 WSDL Parsers Two aspects are important for semantics handling in a programming language: a reliable WSDL management tool and a full implementation of SAWSDL recommendation. In the next section, we present the two main WSDL handlers Java libraries which both have SAWSDL management extension namely WSDL4J and Woden. The section 4 gives more technical information and presents a benchmark. 1

http://www.w3.org/TR/sawsdl/ http://www.w3.org/TR/xmlschema-0/ 3 http://www.semeuse.org/ 4 http://www.soa4all.eu/ 5 http://www.w3.org/TR/wsdl 6 http://www.w3.org/TR/wsdl20/ 2

900

N. Boissel-Dallier, J.-P. Lorré, and F. Benaben

Web Services Description Language for Java Toolkit (WSDL4J)7 is an opensource Java library developed by IBM under CPL License and supported by SourceForge. It is the reference implementation of JSR110, the Java APIs for WSDL [3] and it is based on a WSDL 1.1 object model. WSDL4J enables to read, write and create every WSDL 1.1 tags and automatically imports required documents. Unfortunately, it doesn’t handle the XML Schema part (treated as DOM tree) and it doesn’t allow managing of WSDL 2.0 compliant documents. Woden8 is an open-source Java library which implements the W3C WSDL 2.0 recommendation. It’s an Apache project under Apache License. Woden is based on a full WSDL 2.0 object model. It enables to read, write and create WSDL 2.0 document and can translate WSDL 1.1 file into 2.0 one, in order to parse it after. Unfortunately, this additional step brings data loss in the file such as message part types (links to XML Schema). Like WSDL4J does, it also imports automatically external parts of WSDL. It doesn’t handle XML Schema but return an Apache XmlSchema object, manageable by an open-source library also available from the Apache Foundation. Woden is already used in Apache Axis29, a Web service framework, and ServiceMix10, a JBI-based [4] Enterprise Service Bus.

3 SAWSDL and Tools 3.1 Semantic Services According to [5], the goal of Semantically-enabled Service Oriented Architecture is to add feature that can provide mechanisms to automate tasks which currently require human intervention. To make Semantic Web Services (SWS) possible, some solutions have been standardized. They are proposed by various working groups, like the W3C or the European Semantic Systems Initiative (ESSI). On one hand, WSMO11 and OWL-S12 adopt a top-down approach to model services. They define complete frameworks to describe semantics for services without taking care of existing SOA technologies such as WSDL. This method is very powerful for the use of semantic in Web Services because the meta-model was made to support dynamic discovery and composition. However, this approach complicates changes on existing system because it sets rewriting of all service descriptions. On the other hand, SAWSDL and WSMO-Lite [6] adopt a bottom-up approach for service modeling: they add small increments on top of WSDL in order to keep most of existing deployed technologies. SAWSDL allows users to add semantic annotations in WSDL file from any reference ontology in WSDL files. WSMO-Lite is an evolution of SAWSDL, filling the semantic annotations with a specific service ontology based on a simplified version of WSMO. 7

http://wsdl4j.sourceforge.net/ http://ws.apache.org/woden/ 9 http://ws.apache.org/axis2/ 10 http://incubator.apache.org/servicemix/ 11 http://www.wsmo.org/2004/d2/v1.0/ 12 http://www.w3.org/Submission/OWL-S/ 8

Management Tool for Semantic Annotations in WSDL

901

The bottom-up approach seems to be a relevant choice to develop an industrial implementation of Semantic Web Services. The W3C Standard SAWSDL is one of the pillars of SWS and is compatible with WSMO-Lite submission. However, to use it in concrete projects, it is useful to dispose of an implementation of SAWSDL, which allows us to manage semantic annotations. 3.2 SAWSDL Parsers Let’s turn our attention to available SAWSDL extensions parsers. Both are developed by university research groups. SAWSDL4J13 is an open-source WSDL4J extension developed by Knoesis, a research center from Wright State University, specialized in semantic e-science. This implementation changes some interfaces of WSDL4J object model and add methods to extract and set model references and schema mappings. Semantic annotations are cleanly manageable on port types, operations, messages and parts. Others can be handled by XPath14 system (for elements and types) or with WSDL4J attribute management method (for faults and other tags). Then, SAWSDL4J handles semantic annotations with different methods as well as only manages WSDL 1.1 because of WSDL4J library. Woden4SAWSDL15 is a part of the METEOR-S16 project from LSDIS, a University of Georgia research center. It is the Woden extension for semantics management. This implementation adds a utilitarian class which extracts semantic annotations from Woden object passed in argument. The whole SAWSDL specification is covered but with read-only methods. No writing or creating method is expected for now. 3.3 Incomplete Solutions Those two implementations of the SAWSDL standard represent a first step in semantic handling but they do not meet all users’ needs. First, they manage only one version of WSDL whereas both can be used in current or future systems. In order to covers both WSDL versions, libraries and treat services should be combined differently. Next, some important functionalities are missing. For example, WSDL4J does not directly manage XML Schema while Woden4SAWSDL cannot add or edit semantic annotations. These functionalities are yet necessaries to facilitate SWS. Then, handling of descriptions and semantic annotations is not uniform in those libraries. SAWSDL4J embed semantics in its object model for main tags, use XPath for XML Schema and a third method to others tags. Woden4SAWSDL add an utilitarian class whereas all other attributes are handled with an object model. A uniform API is not essential but it can facilitate development and code comprehension. 13

http://knoesis.wright.edu/opensource/sawsdl4j/ http://www.w3.org/TR/xpath20/ 15 http://lsdis.cs.uga.edu/projects/meteor-s/opensource/woden4sawsdl/ 16 http://lsdis.cs.uga.edu/projects/meteor-s/ 14

902

N. Boissel-Dallier, J.-P. Lorré, and F. Benaben

Finally, the choice of the open-source licenses (CPL and Apache) can be incompatible with some projects due to the specificities of any type of licenses.

4 EasyWSDL and Its SAWSDL Extension EasyWSDL17 is a new WSDL open-source Java implementation developed by EBM WebSourcing for the OW2 Consortium under BSD License. It was initially developed to fulfill requirements that others did not meet, especially for WSDL management in PEtALS18, the Enterprise Service Bus of the OW2 consortium and Dragon19, the SOA governance tool. Both programs are under LGPL license which is compatible with BSD. 4.1 A Uniform Management of WSDL EasyWSDL recognize both WSDL versions. Then, it enables to read, write and create WSDL 1.1 or 2.0, with a uniform API. Figure 1 gives a representation of the three proposed approaches (WSDL4J, Woden, and EasyWSDL). As depicted by the next figure, EasyWSDL keep WSDL 2.0 tag names if possible. His full object model also follows the API and the W3C recommendations. For example, the root tag in WSDL 1.1 is definition against description in WSDL 2.0. Both API and object model in EasyWSDL use description as name. Such a native handling of both WSDL versions avoid conversion phase (existing in Woden for WSDL 1.1 treatment) which produce lost of data.

Fig. 1. Overview of the three API 17

http://easywsdl.ow2.org/ http://petals.ow2.org/ 19 http://dragon.ow2.org 18

Management Tool for Semantic Annotations in WSDL

903

EasyWSDL includes also an XML Schema management with its embedded object model. It enables to parse types tag in depth and bind those with the rest of the description (input, output, fault…) thanks to the object models. This implementation is also compliant with the recommendation. Schema handling is useful to manage input and output then enables communication between services. 4.2 The Extension System EasyWSDL was designed according to a plug-in architecture. Each model’s object is associated with a decorator pattern. This extendable layer allows developers to add properties and methods to classes, like any simple extension, but also allows users to combine them. Three extensions are already available: • SAWSDL: It makes possible the handling of semantic annotations. For more information, see Section 4.4. • WSDL4ComplexWSDL: Enables to work in distributed environments. It allows EasyWSDL to merge all imports with the main description, solving location problems. • WSDL4BPEL: Add recognition of partnerLink tags which is essential to use WSDL documents in a BPEL process. Thanks to the decorator pattern, developers may combine extensions as they need and develop new ones. For example, if a user want to manage WSDL file, taking account both semantic annotations and partnerLink tags, he just have to activate SAWSDL and WSDL4BPEL extensions. 4.3 Performances Comparisons EasyWSDL seems to meet all users’ needs but this library is only viable if it proposes an equivalent (or better) quality of services. In order to compare the three implementations of WSDL, we benched all with a large-scaled test. We used the Seekda20 database which contains more than 40000 WSDL documents. All tests were carried out under the same conditions: we created a reader object for each Java library then all WSDL file were parsed. Reading times and errors were noticed and sum up in the following table. After the first test batch (See Table 1), we can notice that WSLD4J is faster than EasyWSDL (about 20% faster). In compensation, EasyWSDL seems to be more robust (no memory leak and less parsing errors) and treat types as object model instead of a simple DOM tree. All documents from the database are in version 1.1 and Woden only accepts 2.0 descriptions. So, we passed all files in an XSLT process to make them compliant with WSDL 2.0 standard. This transformation can’t be realized on all documents: some invalid 1.1 descriptions didn’t pass the XSLT engine (1880/40257 i.e. about 4.7%). The second test shows that Woden is 53% slower than EasyWSDL with closed functionalities. Both exception managements are hardly comparable: for example, 20

http://www.seekda.com/

904

N. Boissel-Dallier, J.-P. Lorré, and F. Benaben Table 1. Performance tests with WSDL 1.1

Java library Tested files Errors21 % of success Avg. time (ms) Memory leak22

WSDL4J 40377 51 98.87 24 Yes

EasyWSDL 40377 9 99.98 30 No

Table 2. Performance tests with WSDL 2.0

Java library Tested files Avg. time (ms) Memory leak

Woden 38377 46 No

EasyWSDL 38377 30 No

Woden logs import errors while continuing parsing whereas EasyWSDL throws exception and stop handling. This is a relevant choice but produce irrelevant error-rate comparison. Furthermore, most of incompliant descriptions were stopped during 1.1 to 2.0 conversions while those files bring most of parsing problems. 4.4 SAWSDL Management As seen above, EasyWSDL provides its SAWSDL extension. It was developed under BSD license too. This implementation enables to read, write and create any semantic annotation. It respects W3C recommendation and handles semantic annotations directly from the object model, even for the WSDL 1.1 operations. It manages SchemaMapping attributes in any elements or types (simple and complex) and modelReference attributes in all WSDL tags, including XML Schema. The uniform API enables integration in any external project, without taking care of the WSDL version. Tests were performed with the SAWSDL-Test Collection23 a service retrieval test collection created to test SWS algorithms and make benchmarks. It counts 894 SAWSDL descriptions with associated OWL ontologies and XSLT schema mapping. Those tests show that semantic annotations parsing do not have any influence on performances. Other unit tests were realized to check returned values: results are similar for the three Java libraries. Then, performances of SAWSDL libraries only depend on WSDL parsers.

21

Number of errors doesn’t take into account exceptions thrown because of inaccessible files. We consider these exceptions are expected because some information is missing. 22 All parsing were initially carried out with one reader. If the resources used by the unit test increase until a memory fail, we consider the reader contains memory leak. 23 http://www.semwebcentral.org/projects/sawsdl-tc/

Management Tool for Semantic Annotations in WSDL

905

5 Development of a SAWSDL Editor within the Dragon SOA Governance Tool 5.1 Presentation of Dragon SOA governance is the ability to organize, enforce and re-configure service interactions in a SOA. Linked to this definition, we can identify two main phases for SOA Governance called design time and runtime. Ability to organize appends at design time with the registry/repository concepts. Ability to enforce and reconfigure appends at runtime with the service platform interface between the service runtime layer and the registry layer. Dragon24 is the SOA governance tool developed by EBM WebSourcing in the OW2 consortium. This open source software is designed to manage services (including lifecycle, dependencies, versioning…), WS-* policies, Service Level Agreement (SLA) and runtime. Dragon plans to manage, to stock and to use semantics to make dynamic composition of web services possible. Dragon is composed of two main components; the Registry and the Service Platform Interface. The Registry provides classical functionalities like those provided by UDDI based registry but also include some enhanced governance features like SLA contract, policy management, lifecycle management, dependency management and versioning of services and services artifacts. The Service Platform Interface is the communication layer between the Enterprise Service Bus and Dragon registry. It allows taking into account necessary policies enforcement like those specified in SLA contract or enterprise wide policies. 5.2 Integration of EasyWSDL EasyWSDL was initially developed to fulfill requirements of Dragon in terms of WSDL description and semantic annotations parsing. Dragon already included EasyWSDL but only used non-semantic functionalities. The first step to improve semantic functionalities in Dragon is to allow users to handle semantic annotations in service descriptions which are stocked in Dragon repository. This feature has to be available directly from the web-based graphic interface to enable users to manage WSDL file from any workstation. According to this objective, we create a SAWSDL editor embedded in Dragon, using its graphic interface and its repository. This editor allows users to manipulate any service description from Dragon database in order to add or edit semantic annotations. It uses an ergonomic tree system which allows to manage tags in depth. All WSDL and XML Schema tag are reachable and user can add, edit or delete semantic annotation for each, whatever the ontology language (including WSMO-Lite). Management of semantic annotations was also added in all Dragon’s pages which concern web services descriptions. For example, new fields were added in service management pages. This double annotation handling avoids separation of syntactic and semantic in the registry. 24

http://dragon.ow2.org/

906

N. Boissel-Dallier, J.-P. Lorré, and F. Benaben

6 Conclusion and Future Work SAWSDL standard has a new open-source Java library with EasyWSDL and its extension. Even if this one lack of maturity due to a recent development, it seems to be a good alternative to existing solutions. Indeed, it enables to handle both WSDL versions, including XML Schema, the whole with a full object model. Moreover, thanks to its extension system, it allows users to manage semantic annotation in any part of the document, following W3C recommendation. Finally, flexibility of attribute’s values in SAWSDL enables to refer to concepts from any ontology language. WSMO-Lite is compatible with this library and limit annotation types for an efficient industrial using. This new implementation meets needs that others did not and it could be a good base for new SWS projects. EasyWSDL is already used in Dragon and semantic annotation management is in progress. Development of the SAWSDL editor is the first step of semantic use in Dragon. Eventually, Dragon plans to provide such functionalities as service matchmaking and dynamic composition of services.

References 1. W3C, Web Services Glossary, http://www.w3.org/TR/ws-gloss/ 2. Hendler, J.: Agents and the Semantic Web. IEEE Intelligent System 16, 30–37 (2001) 3. Fermantle, P., Duftler, M.: IBM Corporation: JSR110 - Java APIs for WSDL (2006), http://jcp.org/en/jsr/detail?id=110 4. Julson, E., Hapner, M.: Sun Microsystems Inc.: JSR208 - Java business Integration (JBI) 1.0 (2005), http://jcp.org/en/jsr/detail?id=208 5. OASIS SEE TC: Reference Ontology for Semantic Services Oriented Architectures, http://www.oasisopen.org/committees/tc_home.php?wg_abbrev=semantic-ex 6. Vitvar, T., Kopecký, J., Viskova, J., Fensel, D.: WSMO-Lite Annotations for Web Services. In: Bechhofer, S., Hauswirth, M., Hoffmann, J., Koubarakis, M. (eds.) ESWC 2008. LNCS, vol. 5021, pp. 674–689. Springer, Heidelberg (2008)

SAWSDL for Self-adaptive Service Composition Teodoro De Giorgio, Gianluca Ripa, and Maurilio Zuccal` a CEFRIEL - ICT Institute Politecnico di Milano Via Renato Fucini 2, 20133 Milano, Italy {teodoro.degiorgio}@students.cefriel.it, {gianluca.ripa,maurilio.zuccala}@cefriel.it http://www.cefriel.it

Abstract. In this paper we present our experience in using SAWSDL for supporting the dynamic replacement of services inside a service composition even in presence of syntactic mismatches between service interfaces. We illustrate the guidelines we defined for adding semantic annotations to WSDL based service interface descriptions. We also present the case studies we implemented to apply our approach to some actual service oriented scenarios. Basing on the current results of our work, we finally evaluate the feasibility of using SAWSDL for solving mismatches between service interfaces at different levels and we propose some extensions. Keywords: SAWSDL, Semantic Annotations, Service Mediation, Service Composition, Service Adaptation, Service-Oriented Architectures.

1

Introduction

In a previous paper [1] we exploited SAWSDL [8] descriptions to support adaptation in the context of service composition. Some sort of adaptation is usually needed when a service to be invoked is not available and therefore should be replaced with an equivalent one: a number of syntactic mismatches can take place in this case, mainly at the interface level (i.e., the two services differ in the names and parameters of the operations exposed) or at the protocol level (i.e., the two services differ in the order in which operations must be invoked), thus preventing the further execution of the overall service composition. In order to address this problem, a mapping function between the expected service and the available one can be created every time it is needed. Current works adopting this solution usually require the manual definition of proper mapping functions at design time, thus encumbering the work of system integrators in charge of setting up service compositions. In [1] we showed that if service interfaces are semantically annotated, adaptive and dynamic replacement of services in a composition can be achieved in a more effective way. Moreover, thanks to our approach, service integrators do not need to be concerned with mapping services at the syntactical level, since we provide them with a language having a sufficient level of abstraction to define mapping functions in a more effective and user-friendly manner. R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 907–916, 2009. c Springer-Verlag Berlin Heidelberg 2009 

908

T. De Giorgio, G. Ripa, and M. Zuccal` a

In this paper we focus on the use of SAWSDL in the perspective of a service provider that aims to semantically annotate its services in order to allow their usage inside a self-adaptive service composition. The paper is organized as follows. Section 2 summarizes the problem. Section 3 presents our approach. Section 4 illustrates the case studies implemented in order to evaluate the approach with some actual service oriented scenarios. Section 5 presents a comparison with respect to other works in the same field. Section 6 draws some conclusions.

2

The Problem

In [2] we identified a number of possible simple mismatches between services, and some basic mapping functions that can be used to solve them. Such mapping functions can be combined in a script to solve complex mismatches. Scripts can be executed by a mediator that receives an operation request, parses it, and eventually performs the needed adaptations. This approach is incorporated in the SCENE [6] framework that we have developed as a part of the SeCSE project and that supports dynamic binding. A service is described by means of an interface and a protocol. Given two services S1 and S2 , a mismatch occurs when an operation request expressed in terms of the interface of S1 cannot be understood by S2 that should handle it. We distinguish between the following classes of mismatches: interface level (i.e., differences between names and parameters of the operations exposed by S1 and S2 ) and protocol level (i.e., differences in the order in which the operations offered by S1 and S2 should be invoked). The basic mapping functions we defined to solve these mismatches are the following: ParameterMapping, ReturnParameterMapping, OperationMapping, StateMapping and TransitionMapping. For further details about mismatches, mapping functions, scripts and mapping language see [2]. This approach shows the following limitations: – The definition of the script requires some human support to completely understand the mismatches and properly combine the mapping functions. – An intensive effort is needed from system integrators that, in the worst case, have to specify an adapter for each service that needs to be invoked in the composition. – It is complicated to add a new service showing mismatches at runtime, since system integrators should develop a new adapter. In order to overcome these limitations and fulfill the requirements defined in the SOA4All project [9], we extended this approach by adding a semantic layer. The semantic layer is composed of the following elements: – SAWSDL [8] service descriptions. WSMO-Lite [3] is an essential building block for the overall SOA4All architecture. WSMO-Lite realizes the WSMO [11] concepts in a lightweight manner using RDF/S and SAWSDL. – A reference ontology. Compared to our previous approach in which system integrators have to build a mapping from one service description to another, now each service provider has to annotate a service description using a common domain specific ontology.

SAWSDL for Self-adaptive Service Composition

909

– A mapping script generator. An agent that, at pre-execution time, is able to process two SAWSDL descriptions and to automatically derive a mapping script.

3

Extending Our Approach with a Semantic Layer

SAWSDL offers three kinds of annotations: modelReference, liftingSchemaMapping and loweringSchemaMapping. These attributes can be used with elements of the WSDL definition. It is also possibile to attach multiple URIs in a single annotation, but in this case no logical relationship between them is defined by the SAWSDL specification. While this flexible approach can promote the use of SAWSDL, it allows many degrees of freedom to the user. In order to solve our specific problem and to allow the automatic generation of mapping scripts, we add the following constraints: 1. 2. 3. 4.

Each operation must be annotated with a modelReference attribute, The WSDL schema must be annotated with a modelReference attribute, loweringSchemaMapping attribute is not used, Optionally the elements of the WSDL schema can be annotated with a liftingSchemaMapping attribute, 5. We rely on the data type defined in XML Schema for simple types. In the SAWSDL fragment below we show how we annotate operations. We add only a modelReference attribute to a wsdl:operation element1 . During the generation process of the mapping script, the mapping script generator elaborates two SAWSDL descriptions. For each operation of the first SAWSDL, it extracts the model reference attribute value and searches in the second SAWSDL an operation annotated to the same URI. If such operation exists, the corresponding mapping function is generated. <wsdl:portType name="portTypeName"><wsdl:operation name="operationName"> <sawsdl:attrExtensions sawsdl:modelReference="http://www.soa4all.eu/.../...#concept"/> <wsdl:input message="messageName"/> <wsdl:output message="anotherMessageName"/>

We do not annotate the wsdl:input and the wsdl:output elements. The next fragment identifies a data type definition for an input or output parameter of an operation within a service description. <xs:element name="elementTypeName"><xs:complexType><xs:sequence> <xs:element name="elementName1" type="..." sawsdl:modelReference="http://www.soa4all.eu/.../...#concept2"/> 1

Our examples refer to WSDL 1.1 but the approach can be equivalently applied to WSDL 2.0.

910

T. De Giorgio, G. Ripa, and M. Zuccal` a

<xs:element name="elementName2" type="..." sawsdl:modelReference="http://www.soa4all.eu/.../...#concept3" sawsdl:liftingSchemaMapping="http://www.soa4all.eu/.../name.ml"/> <xs:element minOccurs="0" name="elementName3" type="..." />

In the listing above, four XML Schema elements are depicted. The first one (elementTypeName) and the last one (elementName3 ) are not annotated. The first one is only a container element and its semantics can be derived by the semantic annotations of its component elements. The last one is an optional element. Elements elementName1 and elementName2 are annotated with a modelReference attribute that contains a URI pointing to a concept of an ontology. elementName2 is also annotated with a liftingSchemaMapping attribute that contains a URI that refers to a lifting schema espressed in a specific lifting schema language (see [1] for details). The presence of the liftingSchemaMapping attribute indicates the need for transformation between the WSDL element and the semantic model. An example of SOAP response message body, taken from an actual service invocation, can be found in the listing below. <ServiceResponse xmlns="http://www.soa4all.eu/example.namespace"> 0, Clear

In this example the output parameter contains two data: the temperature and a weather condition label. This information can be represented by two concepts in the semantic model: – 0 is the concept http://www.soa4all.eu/models/Weather/weather#temp, – Clear is the concept http://www.soa4all.eu/models/Weather/weather# description in the semantic model. One solution could be the insertion of these two concepts in the modelReference attribute, thus suggesting the content but not the way to extract the concept from the return element. So we create a custom lifting file that contains all the information required to solve this kind of mismatches. We do not use the loweringSchemaMapping attribute because we are facing the problem of adapting a SOAP message prepared according to a specific WSDL for invoking a service with a different WSDL description. The loweringSchemaMapping attribute could be used for adapting a service request expressed at the semantic layer to a SOAP message, so it is out of scope with respect to our specific problem. In order to annotate a WSDL service description as described above, a service provider needs an ontology that contains the right concepts with respect to the elements comprised in the WSDL specification. In Section 4 the ontologies used in our specific examples are described. They contain only concepts that we used to annotate WSDL for our examples. The last fragment represents a link between operations and parameters. For each operation it is possible to identify at least one elementTypeName of the XML Schema for the input and one for the output parameter using the element attribute.

SAWSDL for Self-adaptive Service Composition

911

<wsdl:message name="messageName"> <wsdl:part element="elementTypeName"/>

Once the WSDL description is annotated as described above, it is possible to automatically solve mismatches between services and perform the service interface adaptation.

4

Examples of Annotations for Service Adaptation

We applied our approach to some actual service oriented scenarios. Our case studies differ in the level of adaptation required and in the operational context (the scenarios are described in detail in [1] and [2]). Figure 1 shows the vocabulary for semantic descriptions of services that we used and we required from the semantic model. Figure 1 contain only concepts that we used to annotate WSDL for our examples. We can use the concepts presented to annotate other services that are compatible to the services used in the case study. It can be extended by adding other elements (e.g., instances, relations, sub concept, axiom, parameter range) to obtain other tasks and use a different terminology, as it is possible to create differences between concepts that represent operations and parameters. It is not an objective of this work to create new ontologies. We derived the concepts needed for implementing the examples starting from some actual service descriptions. 4.1

Weather Forecast

The first example considers two stateless services: TheWeather and Forecast, each exposing one operation. According to our approach, we annotated the service interfaces using the ontology shown in Figure 1 to automatically solve mismatches between these two services. The elements of the interfaces mapped to

owener login

description

wind creditCardDate

http://www.soa4all.eu/models/Weather/weather

checkAndPay logout

creditCardNum

temp response

http://www.soa4all.eu/models/CreditCard/pay amount

byLocation

isLogoutOk

password

longitude latitude

isCheckAndPayOk isLoginOk userName

Ontology Concept

hours

http://www.soa4all.eu/models/Weather/gps http://www.soa4all.eu/models/Weather/time

Fig. 1. Shared Domain Ontology

912

T. De Giorgio, G. Ripa, and M. Zuccal` a Table 1. Semantic Annotations for TheWeather

TheWeather Service Name Semantic Annotation Operation getForecast weather#byLocation latitude gps#latitude longitude gps#longitude Schema hour time#hours element temp weather#temp wind weather#wind weather weather#description

Forecast Service Name Semantic Annotation Forecast weather#byLocation latitude gps#latitude longitude gps#longitude hours time#hours return weather#response liftingForecast.ml

Table 2. Lifting Script for Forecast Service Schema element Concept Function return weather#temp stringSplitter(,) weather#description

the corresponding concepts of the ontology are shown in Table 1. The Name column represents the name of one WSDL element, while the Semantic Annotation column contains the value of the SAWSDL attributes. To help the visualization of data we omitted the common prefix of all these values, i.e., http://www.soa4all.eu/models/. These values represent resources that can be identified via URIs. In particular, we can distinguish the values in two groups: values coming from the attribute modelReference and liftingSchemaMapping. In Table 1 the only value pointing to the a lifting script is liftingForecast.ml. The content of liftingForecast.ml is summarized in Table 2 and it solves the same example described in the SOAP body response XML fragment depicted in Section 3. When all the information necessary to establish the semantic compatibility between the annotated element of the two services is provided by annotating the service description, it is possible to start the process to generate the mapping script. Figure 2 is a representation of the mapping between concepts present in the two services. It can be noted that the mapping between operations and input parameters is one to one, while return parameters temp and weather of TheWeather are mapped to the return element. Moreover, the wind element is not associated but the semantic compatibility is established due to the fact that Operations mapping

getForecast

Forecast

Input parameters mapping

Return parameters mapping

latitude

latitude

temp

longitude

longitude

wind

hour

hours

weather

Fig. 2. Weather Mapping

return

SAWSDL for Self-adaptive Service Composition

913

Table 3. Semantic Annotations for PaymentCC PaymentCC Service CCPayment Service Name Semantic Annotation Name Semantic Annotation setupConf pay#login login pay#login Operation payCC pay#checkAndPay checkCC pay#check payByCC pay#pay logout pay#logout logout pay#logout userName pay#userName user pay#userName password pay#password password pay#password success pay#isLoginOk success pay#isLoginOk Schema owner pay#owner owner pay#owner element CCNumber pay#creditCardNum credNum pay#creditCardNum expirDate pay#creditCardDate expDate pay#creditCardDate amount pay#amount amount pay#amount accepted pay#isCheckAndPayOk checkOk pay#isCheckOk completed pay#isPayOk loggedOut pay#isLogoutOk loggedOut pay#isPayOk

parsing the wind element shows that it is an optional element, for this reason all the required parameters are mapped each other and for our approach this is enough to establish that the two service interfaces are semantically compatible2 . 4.2

Credit Card

The second example consists of two stateful services: PaymentCC and CCPayment, composed by different operations. As in the previous example, the first step is to annotate the WSDL description with semantic annotations. We present the results in Table 3. In this case the common prefix is: http://www.soa4all. eu/models/CreditCard/. Basing on the rules currently implemented in our approach, the two services are compatible and Figure 3 illustrates the final mapping. In Figure 3 the payCC operation of the PaymentCC service is mapped to two operations of the CCPayment service: checkCC and payByCC. In order to adapt the service request and to invoke the CCPayment service a missing information is needed: the sequence of the invocations required by the CCPayment service. This is a protocol mapping issue, as described in [2]. In detail the operations of the CCPayment service are not indipendent but some relationships exist between them. In this case the current approach requires the intervention of a human being. A possible solution could be to describe relationship between operations in the semantic model as described in [4] about behavioural semantics. Our approach is complementary to this one and considers a situation where the service provider does not develop a complete semantic model for its service but uses a categorization of possible 2

This is an assumption of compatibility valid at pre-execution time. The actual invocation of the service can fail or produce unexpected results. This is managed by other components of our architecture that are able to react to these situations.

914

T. De Giorgio, G. Ripa, and M. Zuccal` a

Operations mapping

setupConf

Input parameters mapping userName

user

password

password

owner

owner

CCNumber

credNum

login

checkCC

success

success

checkOK accepted

payCC payByCC

logout

Return parameters mapping

expirDate

expDate

amount

amount

logout

completed

loggedOut

loggedOut

Fig. 3. Credit Card Mapping

relationships for annotating the operations listed in a WSDL. Thus another option could be to add a new attribute to the SAWSDL specification for enabling such kind of annotations and enabling the description of the order in which a client should invoke the operations of the Web Service.

5

Related Work

Service adaptation is a hot research topic in Service Oriented Architectures and Semantic Web Services. Here follows a brief description of some approaches related to SAWSDL that are particularly close to the topic of this paper. Other related work with respect to service adaptation are described in [1]. In [7] an approach for the semi-automatic creation of schema mappings based on a central ontology is developed. This approach aims to create mapping rules to transform an instance of the source schema to an instance of the target schema for solving data migration problems in an industrial scenario. The same approach can be applied also for solving the problem of adapting two Web Services, since the WSDL specification includes the use of XML Schema for the schema definition. This approach is similar to ours but it does not use directly SAWSDL as an annotation language because it is not specific for the Web Service adaptation scenario. In [5] the SIROCO middleware platform is presented. It enables the dynamic substitution of stateful services that become unavailable during the execution of service orchestrations. It assumes that the service state description is provided with the service interface descriptions according to the standard WS-Resources Framework [12]. The information managed by the SIROCO Reconfiguration Management System consist of BPEL descriptions of service orchestrations, SAWSDL descriptions of each service used in the orchestration and SAWSDL descriptions of services that may be used for the reconfiguration of the orchestration. The reconfiguration process present in the SIROCO infrastructure is based on discovering candidate

SAWSDL for Self-adaptive Service Composition

915

substitute services, identifying semantically compatible services and synchronizing the state of the resources used by the services. In SIROCO candidate substitute services, whose state descriptions exactly match the state descriptions of unavailable services, are selected. These descriptions must be provided according to the WS-ResourceProperties standard specification.

6

Conclusions

Our semantically extended approach allows the invocation of services whose interface and behavior differ from each other by means of semantic annotations. The approach addresses the following requirements defined in the SOA4All project: – Adaptation, since it enables the automation of the creation of adaptation scripts, thus overcoming some of the current limitations and issues connected to lack of standardization in service centric systems. – User-friendly composition, since it allows the development of new addedvalue services in a lightweight and effective manner and it moves some tasks, in the process of developing added-value services, from the system integrator (e.g., manual mapping for adapting service requests to actual service interfaces) to each service provider (e.g., annotation of service descriptions). – System self-reconfiguration, since it eliminates the complexity of adding new mismatching services at runtime to the service composition by developing service adapters. The main advantage of our solution is the possibility to bring the service mapping language to a higher level of abstraction by means of semantic annotations of service interfaces: we achieve service composition by building service descriptions exploiting shared domain ontologies, instead of describing service mappings at a syntactical level. This approach greatly simplifies the work of SOA4All users, since it simplifies adaptive and dynamic service composition also in an open world setting. It is possible to raise the level of abstraction reached by our approach using an additional semantic layer. An example of a semantic model that we are evaluating is WSMO-Lite [3], one of the main results of the SOA4All project [10]. In our approach we assume that all the services can be annotated by one domain ontology. There are many common scenarios for which this is applicable and semantic annotations already exists. In the examples proposed, this annotation is manually done to the ontology shown in Figure 1, but we assume that in the SOA4All project proper tools will be created for the annotation phase. Furthermore, we are working for enabling the mapping script generator to generate rules (i.e., state mapping and transition mapping rules) able to solve also protocol level mismatches. One example of protocol level mismatch is related to the credit card example in Section 4.2. These sample services list operations for enabling the payment: login, check, pay, logout. Strong dependencies exist between these operations and these dependencies are not described inside a WSDL. It

916

T. De Giorgio, G. Ripa, and M. Zuccal` a

is possible to derive these dependencies from the SAWSDL annotations if the dependency relationships between concepts are included in the semantic model. However, in our approach we would allow the service provider to specify these dependencies by means of semantic annotations instead. Thus a possible extension to SAWSDL could be to add a new attribute for annotating the operation with this kind of information.

Acknowledgments Parts of this work were sponsored by the European Commission in course of FP7 project SOA4All. The opinions expressed represent the authors’ point of view and not necessarily the one of the project participants or of the EC.

References 1. Cavallaro, L., Ripa, G., Zuccal` a, M.: Adapting Service Requests to Actual Service Interfaces through Semantic Annotations. In: PESOS Workshop. IEEE Computer Society Press, Vancouver (2009) 2. Cavallaro, L., Di Nitto, E.: An Approach to Adapt Service Requests to Actual Service Interfaces. In: SEAMS Workshops. ACM Press, Leipzig (2008) 3. Vitvar, T., Kopeck´ y, J., Viskova, J., Fensel, D.: WSMO-Lite Annotations for Web Services. In: Bechhofer, S., Hauswirth, M., Hoffmann, J., Koubarakis, M. (eds.) ESWC 2008. LNCS, vol. 5021, pp. 674–689. Springer, Heidelberg (2008) 4. Kopeck´ y, J., Vitvar, T., Bournez, C., Farrell, J.: SAWSDL: Semantic Annotations for WSDL and XML Schema. IEEE Internet Computing (2007) 5. Fredj, M., Georgantas, N., Issarny, V., Zarras, A.: Dynamic Service Substitution in Service-Oriented Architectures. In: IEEE Congress on Services - Part I (2008) 6. Colombo, M., Di Nitto, E., Mauri, M.: SCENE: A service composition execution environment supporting dynamic changes disciplined through rules. In: Dan, A., Lamersdorf, W. (eds.) ICSOC 2006. LNCS, vol. 4294, pp. 191–202. Springer, Heidelberg (2006) 7. Drumm, C.: Improving Schema Mapping by Exploiting Domain Knowledge. Universit¨ at Karlsruhe, PhD Thesis (2008) 8. W3C: Semantic Annotations for WSDL and XML Schema. W3C Recommendation (2007), http://www.w3.org/TR/sawsdl/ 9. SOA4All: Project Website, http://www.soa4all.eu 10. Ripa, G., Zuccal` a, M., Mos, A.: D6.5.1. Specification and first prototype of the composition framework. SOA4All project deliverable (2009) 11. ESSI WSMO working group, http://www.wsmo.org/ 12. Web Services Resource Framework. OASIS Standard (2006)

Adapting SAWSDL for Semantic Annotations of RESTful Services Maria Maleshkova1, Jacek Kopeck´ y2 , and Carlos Pedrinaci1 1

Knowledge Media Institute (KMi) The Open University, Milton Keynes, United Kingdom [email protected], [email protected] 2 STI Innsbruck, Innsbruck, Austria [email protected]

Abstract. RESTful services are increasingly been adopted as a suitable lightweight solution for creating service-based applications on the Web. However, most often these services lack any machine-processable description and therefore a significant human labour has to be devoted to locating existing services, understanding their documentation, and implementing software that uses them. In order to increase the automation of these tasks, we present an integrated lightweight approach for the creation of semantic RESTful service descriptions. Our work is based on hRESTS, a microformat for including machine-readable descriptions of RESTful service within existing HTML service documentation. We complement hRESTS by the MicroWSMO microformat, which uses SAWSDL-like hooks to add semantic annotations. Finally, we present SWEET–Semantic Web sErvices Editing Tool–which effectively supports users in creating semantic descriptions of RESTful services based on the aforementioned technologies.

1

Introduction

Currently, there is an increased use and popularity of RESTful services [1], which offer a more lightweight alternative to the SOAP- and WSDL-based approach. As a result, more and more Web applications and APIs follow the Representational State Transfer [2] (REST) architecture principles and expose functionalities in the form of RESTful Web services. This trend is supported by the Web 2.0 wave, which drives the creation of user-centered Web applications for communication, information sharing and collaboration. Popular Web 2.0 applications by Yahoo, Google and Facebook offer easy-to-use, resource-oriented APIs, which not only provide simple access to diverse resources but also enable combining heterogeneous data coming from diverse services, in order to create data-oriented service compositions called mashups. Even though RESTful services are already widely accepted, their potential is restricted by the current low lever of automation due to the lack of machine-readable descriptions and the limited applicability of the Semantic Web Services automation technologies. Web 2.0 principles contributed significantly to the uptake of RESTful services. As a result, the value of Web 2.0 applications is not only for the direct R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 917–926, 2009. c Springer-Verlag Berlin Heidelberg 2009 

918

M. Maleshkova, J. Kopeck´ y, and C. Pedrinaci

user, who can receive customized information, but also in exposing functionality through public REST-based APIs. However, the fact that these APIs were inspired by user-centered applications has resulted in the creation of user-oriented descriptions. Even though, the APIs are meant for machine consumption, the descriptions themselves are plain unstructured HTML documents. The lack of machine-readable descriptions is only one of the challenges, which have to be addressed in order to provide a certain level of automation for RESTful service. The fact that the majority of existing RESTful service descriptions have no semantic annotations, also has to be taken into consideration. Semantic Web Services (SWS) are proposed as means for automating many common tasks involved in using Web services. Discovery, negotiation, composition and invocation can have a higher level of automation, when Web service are supplemented with semantic descriptions of their properties. Similarly to traditional SWS, which improve the automation of WSDL-based solutions, the adding of annotations to RESTful services can bring further automation to the process of creating mashups, in addition to the discovery and invocation tasks. In this paper we present an integrated lightweight approach for the creation of semantic annotations of RESTful service by adapting SAWSDL [3]. For the creation of machine-readable RESTful service descriptions we use the hRESTS (HTML for RESTful Services) microformat [4]. Microformats [5] offer means for annotating human-oriented Web pages in order to make key information machine-readable, while hRESTS, in particular, enables the creation of machineprocessable Web API descriptions based on available HTML documentation. hRESTS is complemented by the MicroWSMO microformat [6], which enables using SAWSDL-like annotations to RESTful services. MicroWSMO introduces additional HTML classes, in order to enable the specification of a model reference, in addition to lifting and lowering relations for data grounding. Moreover, concrete semantics can be added by applying WSMO-Lite [7] service semantics, which enable the integration of RESTful services with WSDL-based ones. In this way, discovery and composition approaches no longer need to differentiate between WSDL and RESTful services, but rather simply be based on the integrated WSMO-Lite service semantics. The creation of semantic RESTful services, including both hRESTS tagging and semantic annotation, is supported by SWEET: Semantic Web sErvices Editing Tool1 . SWEET assists users in injecting hRESTS and MicroWSMO within RESTful HTML service descriptions, thus enabling the effective creation of semantic descriptions. It hides formalism complexities from the user and assists him/her in adding service metadata. The remainder of this paper is structured as follows: Section 2, provides an analysis of common ways of describing RESTful services, while Section 3 uses this analysis to deduce a lightweight RESTful service model. Our approach for creating machine-readable service descriptions, including the hRESTS microformat and the provided tool support, is described in Section 4. In Section 5, we present our adaptation of SWASDL for RESTful services, by describing the 1

http://sweet.kmi.open.ac.uk/; http://sweetdemo.kmi.open.ac.uk/

Adapting SAWSDL for Semantic Annotations of RESTful Services

919

properties of MicroWSMO and the tool support for semantic annotations offered by SWEET. Section 6 presents an overview of related formalisms and approaches. Finally, 7 provides some detail on future work and a conclusion.

2

Common RESTful Service Descriptions

In order to be able to find services and interact with them, RESTful services, and services in general, need to be described in some way. While Web applications and Web APIs contain HTML documentation, which is understandable for human users, it needs to be extended in order to become machine-readable and -processable as well. WSDL [8] is an established standard for Web service descriptions, however, it has not found wide adoption for RESTful services and only a few such services have WSDL descriptions. Similarly, WADL [9] does not seem to be gaining acceptance among API provides and instead Web applications and APIs are usually described in textual documentation. However, in order to support the automation of RESTful services, certain key aspects of the descriptions have to be made machine-readable. 1 2 3 4 5 6 7 8 9

Send SMS Service

This is a Short Message Service (SMS).

Example usage http://my.test.serv.com/SendSMS.php?recipient=tel: 447712345678&message=messagetext&sender=User&title=TheMessage
SendSMS Method recipient

List of recipent phone numbers in the format ”tel:” followed by an international phone number

message

Content of the message.

The result is a sent SMS.

Listing 1. Example HTML Service Description

Our approach suggests the hRESTS microformat, which can be used to tag service properties and produce a machine-readable service description on top of existing HTML documentation. In order to identify which elements of the service description need to be marked with hRESTS tags, we analyze existing RESTful service descriptions and derive a lightweight RESTful service model, which consists of service properties required for the completion of the discovery, composition and invocations tasks. Common RESTful service descriptions are usually given in a Web page, which contains a list of the available operations, their URIs and parameters, expected output, error message and an example. The description includes all details necessary for a user to execute the service or use it in a mashup. Based on an existing repository for Web APIs2 , which contains more than 1380 APIs, manually collected over time, we have identified three basic types of descriptions. Listing 1 shows an example of the first type of HTML descriptions of RESTful services. These descriptions contain only one or a number of operations, which are described with their corresponding parameters and URIs, within the same 2

programmableweb.com

920

M. Maleshkova, J. Kopeck´ y, and C. Pedrinaci

Web page. However, a lot of Web 2.0 applications contain a plenitude of operations. In this case, the second type of descriptions, includes one main page for the service and a number of linked pages, each of which describes one operation. This results in the requirement that the microformat used to annotate the service descriptions should include not only operations, URIs, HTTP methods, inputs and outputs but should also enable the linking of multiple operations from different Web sites to one “root” service description. activity blogs auth ∗ flickr . activity .userComments ∗ flickr . blogs . getList ∗ flickr .auth.checkToken ∗ flickr . activity .userPhotos ∗ flickr . blogs .postPhoto ∗ flickr .auth.getFrob

Listing 2. Example Resource-Oriented Description

Finally, the last type of RESTful service descriptions are the resource-oriented ones. Listing 2 shows parts of the flickr3 API documentation, where operations are not simply listed but they are rather grouped, based on the resources which they manipulate. In the example, there are three resources (activity, blogs and auth), each of which has a set of operations. Similarly, in this case the requirements for the microformat include that separate operation descriptions can be linked to a particular resource and one RESTful service. Based on these three types of RESTful service descriptions, we derive a lightweight RESTful service model that can effectively support the creation of machine-readable service descriptions.

3

Lightweight RESTful Service Model

The service examples given in Section 2 serve as the basis for identifying key service properties present in the textual documentation. These properties are formalized in a model, which specifies the service properties used for creating machine-readable RESTful service descriptions by marking HTML with hRESTS microformat tags. Generally, a RESTful service description consist of several operations, each of which is performed over a HTTP method and has a particular address (URI or a parametrized URI). Operations have inputs and outputs with corresponding data formats. In addition, outputs of one operation may link to other operations, creating a resource based “choreography”. Also, a number of operations can have distributed descriptions but belong to the same service, or can have different outputs but a common set of input parameters. In summary, the elements, which have to be identified in an unstructured HTML service description are the service body, the operations, the input and output, the address and the HTTP method. As it can be seen, this list is very similar to the one of the WSDL structure and provides the basis for a machine readable description, which can be extended and annotated with additional information such as semantic descriptions and nonfunctional properties. 3

www.flickr.com/services/api/

Adapting SAWSDL for Semantic Annotations of RESTful Services

4

921

Machine-Readable Descriptions of RESTful Services

In order to support the creation of machine-readable descriptions, we use the hRESTS microformat. Microformats facilitate the translation of the HTML tag structure into objects and properties. As a result, the visualization of the HTML description remains unchanged, while the microformat uses class and rel XHTML attributes to mark key service properties. In this way, the hRESTS microformat enables the creation of machine-readable RESTful service descriptions, on top of existing HTML documentation. hRESTS consists of a number of classes based directly on the properties identified in the previous section. However, even if the hRESTS microformat enables the creation of machine-readable RESTful service descriptions, the manual annotation of an HTML service description with hRESTS is a time-consuming and complex task. In order to support users in adopting hRESTS, we have developed SWEET. SWEET is a JavaScript Web application, which requires no installation and has the form of a vertical widget, which appears on top of the currently browsed Web page. This tool overcomes a number of difficulties associated with the annotation of Web applications and API descriptions, including the fact that the HTML documentation is viewed through a browser and that the user who wants to annotate the service descriptions, usually does not have access to manipulate or change the HTML. Therefore, we provide a browser-based annotation solution, which can be started on top of the currently viewed RESTful service description. Figure 1 shows a screenshot of SWEET. hRESTS tags can simply be inserted by selecting the relevant part of the HTML and clicking on the corresponding class node

Fig. 1. SWEET: hRESTS Annotation

922

M. Maleshkova, J. Kopeck´ y, and C. Pedrinaci

in the hRESTS panel of SWEET. In this way, the hRESTS annotation process is less error-prone, less time-consuming and much simpler for the user. The result is hRESTS annotated HTML, which can easily be converted into RDF (“Export” button), by using an implemented XSLT stylesheet. Listing 3 shows the previous service description example, annotated with hRESTS by using SWEET. It visualizes the usage of the microformat annotations, as well as the structure restrictions, which exist for the different classes. The complete Web service or API description is marked by the service class. The service may have a label, which can be used to mark the human-readable name of the service. A machine readable description can be created, even if there is no service class inserted. It is sufficient that the HTML description contains at least one operation, which is marked with the operation class. The operation description itself includes the address where it can be executed and the HTTP method. Input and output details as well as a label can also be part of the operation. 1 2 3 4 5 6 7 8 9 10 11 12 13 14

Send <span class=”label”>SMS Service

This is a Short Message Service (SMS).

Example usage <span class=”address”>http://my.test.serv.com/SendSMS.php?recipient= tel :447712345678&message=messagetext&sender=User&title=TheMessage SendSMS Method <span class=”input”> recipient

List of recipent phone numbers in the format ”tel:” followed by an international phone number

message

Content of the message.

<span class=”output”>The result is a sent SMS.

Listing 3. Example hRESTS Service Description

The hRESTS address class is used to specify the URI of the operation. Similarly, the method class specifies the HTTP method used for the operation. The final two elements used are input and output. They are used on block markup and indicate the operation’s input and output. These two elements serve as the basis for extensions given by microformats, which provide additional semantic information or details about the particular data type and schema information. Finally, user-oriented labels can be attached to the service, operation, input or output classes. The current version of SWEET directly supports the annotation only of the first, most common type of RESTful service descriptions, where all details about a service are provided within one webpage. However, the two other types of descriptions can easily by annotated as well, by making some minor manual modifications. First, one API description can have one main page and a number of separate pages, which describe each of the operations. In order not to lose the link between the separate parts of the description, the service page is modified to include rel="section" after each of the links pointing to the operation Web pages and each of the operations is modified to include rel="start",

Adapting SAWSDL for Semantic Annotations of RESTful Services

923

which points to the main service description. As a result the start and section relations link the pages together. The second requirement, that a number of operations can be grouped based on the resource, to which they apply, is implicitly solved. All of the grouped operations have the same subset of input parameters, which can additionally be emphasized by adding semantic annotations as described in Section 5.

5

Semantic Descriptions of RESTful Services

hRESTS marks the key properties of the RESTful service and provides a machine-readable description based on the available HTML documentation. The result can effectively be used as the basis for adding extensions for supplementary information and annotations. In addition, it enables the adapting of SAWSDL [3] properties for adding semantic annotations to RESTful services because the hRESTS view of services is analogous to the WSDL one. Even though, hRESTS already provides a certain level of automation by enabling the creation of machine-readable descriptions, a higher level of automation of the discovery, composition, ranking, invocation and mediation service tasks can be archived by extending service descriptions with semantic annotations of their properties. As a result, Semantic RESTful Services (SRS) can be developed following and adapting approaches from the Semantic Web Services (SWS). SAWSDL specifies how to annotate service descriptions, provided in WSDL, with semantic information by defining three XML attributes with equivalent RDF properties. The modelReference points to URIs identifying appropriate semantic concepts, while liftingSchemaMapping and loweringSchemaMapping associate messages with appropriate transformations between the level of technical descriptions (XML) and the level of semantic knowledge (RDF).We adopt these SAWSDL properties as extensions to hRESTS as part of the here described MicroWSMO microformat. Therefore, MicroWSMO represents the SAWSDL layer for RESTful services, based on top of hRESTS, instead of WSDL. Consequently, MicroWSMO has three main elements, which represent links to URIs of semantic concepts and data transformations. model indicates that the URI is a link to a model reference, while lifting and lowering point to links for lifting and lowering transformations. Since the WSMO-Lite [7] ontology is used for describing the content of SAWSDL annotations in WSDL, we also adapt it for MicroWSMO. WSMOLite specifies four aspects of service semantics including information model, functional semantics, behavioral semantics and nonfunctional descriptions, instances of which are linked to the MicroWSMO annotations. It is important to point out that since both MicroWSMO and SAWSDL can apply WSMO-Lite service semantics, RESTful services can be integrated with WSDL-based ones. Tasks such as discovery, composition and mediation can be performed based on WSMO-Lite, completely independently from the underlying Web service technology (WSDL/ SOAP or REST/HTTP). The task of associating semantic content with RESTful service properties is even more time- and effort-demanding than the insertion of hRESTS tags.

924

M. Maleshkova, J. Kopeck´ y, and C. Pedrinaci

Fig. 2. SWEET: Semantic Annotation

Therefore, SWEET supports users in searching for suitable domain ontologies and in making semantic annotations in MicroWSMO. Whenever, a user wants to add semantics to a particular service property, for example, an input parameter, he/she has to select it and click on the “magic wand” symbol, which send a request to Watson [10]. Waston is a search engine, which retrieves relevant ontologies based on keyword search. The results are presented in the service properties panel visualized in Figure 2. The searched for property is the root of the tree, populated with nodes that represent the found matches. In the example, recipient was found to be a property (“P”) in an ontology located at http://protege.stanford.edu. If the user needs additional information in order to decide whether the particular semantic annotation is suitable or not, he/she can switch to the domain ontologies panel, which provides a list of all concepts and the corresponding property matches. The user can make a semantic annotation by simply selecting the property instance and clicking on one of the semantic matches in the service properties panel. The result is a MicroWSMO annotated HTML description, which can be saved in a repository (button “Save”) or be converted into RDF (button “Export”). Listing 4 shows our example service description annotated with MicroWSMOb using SWEET. Line 4 uses the model relation to indicate that the service sends SMS, while line 12 associates the input parameter recipient with the class Recipient. The lowering schema for the recipient is also provided in line 13.

Adapting SAWSDL for Semantic Annotations of RESTful Services

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

925

Send <span class=”label”>SMS Service

This is a Short Message Service (SMS).

Example usage <span class=”address”>http://my.test.serv.com/SendSMS.php?recipient= tel :447712345678&message=messagetext&sender=User&title=TheMessage SendSMS Method <span class=”input”> recipient ( lowering)

List of recipient phone numbers in the format ”tel:” followed by an international phone number

Listing 4. Example MicroWSMO Service Description

6

Related Work

hRESTS is not the only alternative that can be used for the creation of machinereadable descriptions of RESTful services. WADL (Web Application Description Language) [9] and even WSDL 2.0 [8] can be used as description formats. They provide well-structured and detailed forms of descriptions. However, probably due to the user-centered context of Web 2.0 and of the resulting API descriptions, WADL and WSDL seem to add complexity and still the majority of the API descriptions are provided in unstructured text. We use hRESTS, which is relatively simple, easy to use, can be applied directly on the existing HTML descriptions, supports the extraction of RDF and can provide a basis, for the future adoption of dedicated formats such as WADL. Another description approach if offered by RDFa [11]. RDFa can be effectively used for embedding RDF data in HTML. However, following the simplicity and lightweight principles perused with hRESTS, it needs to be investigated to what extent and in which use cases RDFa can be used for hRESTS. A parallel approach to RDFa would be the use of GRDDL [12] on top of hRESTS. GRDDL is a mechanism for extracting RDF information from Web pages and is particularly suitable for processing microformats. In the area of tools supporting the semantic annotation of services, ASSAM [13] enables the annotations of services with WSDL-based descriptions. It provides user interface tools as well as some automatic recommendation components, however, it can only be used on WSDL-based descriptions and does not support RESTful services.

7

Conclusion and Future Work

Current RESTful services can be found, interpreted and invoked not without the extensive user involvement and a multitude of manual tasks. This situation can be alleviated through the creation of machine-readable descriptions. Based on such descriptions, crawlers and search engines can better find services, and

926

M. Maleshkova, J. Kopeck´ y, and C. Pedrinaci

developers can better use them. Moreover, extended with semantic annotations, RESTful services can even be discovered, composed and invoked automatically, following the principles of the SWS. In this paper, we have built on a lightweight RESTful service model, based on the hRESTS microformat that enables the tagging of key service properties and therefore supports the creation of machine-readable service descriptions. We complemented hRESTS by the MicroWSMO microformat, which adapts SAWSDL for the semantic annotation of RESTful services. Finally, we have shown the tool SWEET, which effectively supports users in creating semantic descriptions of RESTful services based on hRESTS and MicroWSMO. Future work will include the development of additional functionalities of SWEET, which will better support users in the creation of semantic RESTful annotations. Better visualization components, such as structure and properties highlighting are planned. In addition, some work will be devoted to the automatic recognition of service properties such as operations and input parameters, so that the amount of manual work required by the user can be reduced. The work presented here is partially supported by EU FP7 project SOA4All.

References 1. Richardson, L., Ruby, S.: RESTful Web Services. O’Reilly Media, Sebastopol (2007) 2. Fielding, R.T.: Architectural styles and the design of network-based software architectures. PhD thesis, University of California (2000) 3. Kopeck´ y, J., Vitvar, T., Bournez, C., Farrel, J.: SAWSDL: Semantic Annotations for WSDL and XML Schema. IEEE Internet Computing 11(6), 60–67 (2007) 4. Kopeck´ y, J., Gomadam, K., Vitvar, T.: hRESTS: an HTML Microformat for Describing RESTful Web Services. In: Proceedings of the 2008 IEEE/WIC/ACM International Conference on Web Intelligence, WI 2008 (2008) 5. Khare, R., Celik, T.: Microformats: a pragmatic path to the semantic web (Poster). In: Proceedings of the 15th international conference on World Wide Web (2006) 6. Kopeck´ y, J., Vitvar, T., Fensel, D., Gomadam, K.: hRESTS & MicroWSMO. Technical report (2009), http://cms-wg.sti2.org/TR/d12/ 7. Vitvar, T., Kopeck´ y, J., Viskova, J., Fensel, D.: WSMO-Lite Annotations for Web Services. In: Bechhofer, S., Hauswirth, M., Hoffmann, J., Koubarakis, M. (eds.) ESWC 2008. LNCS, vol. 5021, pp. 674–689. Springer, Heidelberg (2008) 8. Web Services Description Language (WSDL) Version 2.0. Recommendation, W3C (June 2007), http://www.w3.org/TR/wsdl20/ 9. Hadley, M.J.: Web Application Description Language (WADL). Technical report, Sun Microsystems (November 2006), https://wadl.dev.java.net 10. Watson - The Semantic Web Gateway: Ontology Editor Plugins (November 2008), http://watson.kmi.open.ac.uk 11. RDFa in XHTML: Syntax and Processing. Proposed Recommendation, W3C (September 2008), http://www.w3.org/TR/rdfa-syntax/ 12. Clarke, F., Ekeland, I.: Gleaning Resource Descriptions from Dialects of Languages. Recommendation, W3C (September 2007), http://www.w3.org/TR/grddl/ 13. Heß, A., Johnston, E., Kushmerick, N.: ASSAM: A tool for semi-automatically annotating semantic web services. In: McIlraith, S.A., Plexousakis, D., van Harmelen, F. (eds.) ISWC 2004. LNCS, vol. 3298, pp. 320–334. Springer, Heidelberg (2004)

An Evolutionary Ontology Approach for Community-Based Competency Management Peter De Baer, Robert Meersman, and Gang Zhao STARLab, Vrije Universiteit Brussel, Pleinlaan 2, 1050 Brussels, Belgium {pdebaer, meersman}@vub.ac.be, [email protected]

Abstract. In this article we describe an evolutionary ontology approach that distinguishes between major ontology changes and minor ontology changes. We divide the community in three (possibly overlapping) groups, i.e. facilitators, contributors, and users. Facilitators are a selected group of domain experts who represent the intended community. These facilitators define the intended goals of the ontology and will be responsible for major ontology and ontology platform changes. A larger group of contributors consists of all participating domain experts. The contributors will carry out minor ontology changes, like instantiation of concepts and description of concept instances. Users of the ontology may explore the ontology content via the ontology platform and/or make use of the published ontology content in XML or HTML format. The approach makes use of goal and group specific user interfaces to guide the ontology evolution process. For the minor ontology changes, the approach relies on the wisdom of crowds. Keywords: Evolutionary ontology, competence ontology, management, human resource management.

competency

1 Introduction In this article we describe an evolutionary ontology approach to support communitybased competency management across domains and organizations. During past projects, i.e. PoCeHRMOM1 and CODRIVE2, VUB STARLab developed competence ontologies [2] and community-driven ontology engineering tools to support competency-based human resource management (HRM) [9]. During the PROLIX project3 (Process Oriented Learning and Information Exchange), we further investigate the requirements of an evolutionary ontology platform for competency description and competency-based qualification description. The main goal of the intended platform is to enable the broad community of training and certification providers to publish the qualifications they offer, and describe these qualifications in function of required initial competencies and expected end competencies. The main 1

PoCeHRMOM info: http://starlab.vub.ac.be/website/PoCehrMOM CODRIVE info: http://starlab.vub.ac.be/website/codrive 3 PROLIX website: http://www.prolixproject.org/ 2

R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 927–936, 2009. © Springer-Verlag Berlin Heidelberg 2009

928

P. De Baer, R. Meersman, and G. Zhao

difference with the methodology [1] and platform [6] that was used during the CODRIVE project is that we now broaden the community across domains. The new methodology and platform should also support more dynamic changes of the concept definitions over longer periods of time. In the next sections we will describe the communities involved (2), the structure of the evolutionary ontology (3), the user roles and use case diagrams for the evolutionary ontology platform (4), the publication and use of the validated ontology content (5), and the meta-data to support tracking of ontology changes and the publication of validated content (6).

2 Community We divide the community involved in the development and management of the evolutionary ontology into three groups: facilitators, contributors, and users. The facilitators are the partners in the PROLIX project who represent organizations that: a) Provide training materials and/or training software e.g. the Social Care Institute for Excellence, Ernst Klett Verlag, Giunti Labs, imaginary srl, and IMC AG. b) Use competency-based HRM in their organizations, for example British Telecom, or (want to) support competency-based HRM via their business process management software, for example IDS Scheer and QPR Software Plc. c) Research and develop approaches and software for information, knowledge, and ontology management e.g. Forschungszentrum L3S and VUB STARLab. The facilitators analyzed the needs of the community for competency information related to qualifications. Taking the different perspectives into consideration the evolutionary ontology as described in section 3 and the evolutionary ontology platform as described in section 4 could be distilled. Note: This group is comparable to the central board in the DILIGENT methodology [11]. All training and certification providers are potential contributors to the ontology content. To make it easy for such organizations to contribute to the ontology we believe it is important to provide a set of user interfaces that guide the user when describing competences and qualifications. An example of such a user interface for semantic qualification description is illustrated in Fig. 1. Using specific ontology engineering interfaces distinguishes the proposed solution from other collaborative ontology engineering approaches, e.g. Collaborative Protégé [7] and HCOME-30 [10]. These user interfaces could be discussed, developed and tested by the facilitators before opening them to the entire community. The users of the ontology content may be organizations and individuals in search for suitable training, i.e. qualifications, based on competency information. This will be further discussed in section 5.

3 Evolutionary Ontology The goal of the ontology is that organizations should be able to describe qualifications in function of required initial competencies and expected end competencies. This

An Evolutionary Ontology Approach for Community-Based Competency Management

929

scope is more specific than related work in the CommOn framework [8], however, it allows broadening the community to different domains. The structure for the ontology now includes the following concepts: competence, competence level, competency, context, qualification, and qualification level. • •

• •

•

•

A competence is a generic competence that may be used across organizations and domains. A competence level indicates the proficiency level of a person for competences. Such competence level may be used across organizations and domains. Examples are the reference levels in the Common European Framework of Reference for Languages4. Each competence level has a minimum and maximum value between 0 and 1 to enable interorganizational comparison. If an organization uses four competence levels A, B, C, and D, competence level A might, for example, have the minimum value 0 and the maximum value 0.25, i.e. 1 / 4. A competency is a specific competence that includes a certain competence level and optionally a context. For an in-depth discussion of the difference between a competence and a competency we refer to [3]. A context is a category that may help to contextualize competences. For example the context BT would indicate that the competence should be interpreted within the context of that organization. For an in-depth discussion of context dependency management we refer to [4, 5]. A qualification is a training certificate issued by an organization that certifies a set of competencies for a person. The qualification should correspond to a set of initial competencies required to start the training, and a set of expected end competencies after the training. A qualification level is a level that indicates the difficulty level of a qualification. Examples are the European Qualification Levels5. Each qualification level has a minimum and maximum value between 0 and 1 to enable inter-organizational comparison.

Instances of the above described concepts may be added, described, and deleted by the training and certification community. English could be used as the Interlingua language on the platform; however, the platform should also allow adding multilingual terminology to describe concepts and concept instances. The addition of multilingual terminology could facilitate the adoption of the ontology content in an international setting. In the CODRIVE project, ontology templates were developed by core domain experts and further specified by domain experts [6]. The design and management of a goal-oriented core ontology and ontology platform, by the group of facilitators, is an extension to that approach. The new approach further relies on the wisdom of crowds to create, update and verify the ontology contents. This new approach to evolutionary ontology engineering will be described in the next section. 4 5

http://tinyurl.com/2k7zko http://tinyurl.com/agw657

930

P. De Baer, R. Meersman, and G. Zhao

4 Evolutionary Ontology Platform We identified five different types of actors that may interact with the ontology platform: (1) a potential user, (2) a user that only consults the platform, (3) a contributor of content on the platform, (4) a validator of content on the platform, and (5) an administrator of the platform. Each administrator is also a validator, a validator is also a contributor, and a contributor is also a user. We also identified fifteen use cases of how the actors might use the ontology platform. For these use cases we designed the following use case diagrams: Table 1. Register new user Actor Potential user Ontology platform Validator

Ontology platform User Ontology platform

Action A potential user registers on the platform. He provides his e-mail address, username, password, and optionally a comment to explain why he wants to use the platform. The list with ‘New user’ requests is available to all validators. A validator approves the new user (a) or not. a. The new user is added. The ‘New user’ request is deleted. The platform sends the potential user an e-mail that states whether the request is approved or not. If approved, the e-mail contains the username and security code to login on the platform. The user uses his username, security code, and password to login. The platform verifies username, security code, and password. If valid, the user may browse the ontology and the security code protection is removed. Table 2. Change password or e-mail address

Actor User Ontology platform User

Action The user logs in on the platform with his username and password. The platform verifies username and password. If valid, the user is logged in. The user may change his password and/or e-mail address. Table 3. Ask password or username

Actor User Ontology platform

Action The user provides his username and/or e-mail address, and asks to send his password or username. The platform verifies username or e-mail address. If valid the password or username is sent to the e-mail address of the user. Table 4. Read content

Actor User Ontology platform

Action The user logs in on the platform with his username and password. The platform verifies username and password. If valid, the user may browse the ontology.

An Evolutionary Ontology Approach for Community-Based Competency Management Table 5. New contributor Actor User Ontology platform Validator

Action A user requests to become a contributor. The list of ‘New contributor’ requests is displayed to all validators. A validator approves the new contributor (a) or not. a. The new contributor is added. The ‘New contributor’ request is deleted. Ontology platform A message is sent to the user with the result of the request. Table 6. Create content Actor Contributor 1 Ontology platform Contributor 2

Action Contributor 1 creates new content. A list of unvalidated new content is displayed to all contributors. Contributor 2 approves the new content (a) or not (b). a. The new content is validated. b. The new content is removed. Table 7. Update validated content

Actor Contributor Ontology platform Validator

Action A contributor updates validated content. A list of unvalidated updates is displayed to all validators. A validator approves the update (a) or not (b). a. The update is validated. b. The update is removed. Table 8. Delete validated content

Actor Contributor Ontology platform Validator

Action A contributor deletes validated content. A list of unvalidated deletes is displayed to all validators. A validator approves the delete (a) or not (b). a. The delete is validated. b. The delete is undone. Table 9. New validator

Actor Contributor Ontology platform Administrator

Action A contributor requests to become a validator. A list of ‘New validator’ requests is displayed to all administrators. An administrator approves the request (a) or denies the request. a. The new validator is added. The ‘New validator’ request is deleted. Ontology platform A message is sent to the contributor with the result of the request.

931

932

P. De Baer, R. Meersman, and G. Zhao Table 10. New admin

Actor Validator Ontology platform Administrator Ontology platform

Action A validator requests to become an administrator. A list of ‘New administrator’ requests is displayed to all administrators. An administrator approves the request or denies the request. Counters keep track of the number of approvals and denials. A flag will indicate whether the logged-in administrator already voted. If the number of approvals minus denials is higher than half the number of administrators, the new administrator is added and the ‘New administrator’ request is deleted. Send result. If the number of denials reaches a quarter of the number of administrators, the ‘New administrator’ request is deleted. Send result. Send result: The result of the request is sent to the validator. Table 11. Revoke admin

Actor Administrator Ontology platform Administrator Ontology platform

Action An administrator may request to revoke an administrator. A list of ‘Revoke administrator’ requests is displayed to all administrators. An administrator approves the request or denies the request. Counters keep track of the number of approvals and denials. A flag will indicate whether the logged-in administrator already voted. If the number of approvals minus denials is higher than half the number of administrators, the administrator is revoked and the ‘Revoke administrator’ request is deleted. Send result. If the number of denials reaches a quarter of the number of administrators, the ‘New administrator’ request is deleted. Send result. Send result: The result of the request is sent to both the requesting administrator and to the administrator that was the subject of the request. Table 12. Revoke validator

Actor Action Administrator An administrator may revoke a validator that is no administrator. Ontology platform A message is sent to the validator that he is now only a contributor. Table 13. Revoke contributor Actor Action Validator A validator may revoke a contributor that is no validator. Ontology platform A message is sent to the contributor that he is now only a user. Table 14. Delete user Actor User Administrator Ontology platform

Action A user may delete his user account. An administrator may delete a user that is no contributor. A message is sent to the user that his account was deleted.

An Evolutionary Ontology Approach for Community-Based Competency Management

933

Table 15. Publish validated ontology content Actor Administrator Ontology platform

Action An administrator may publish the validated ontology content in XML format. He has to specify a valid location. The validated ontology content is published in the specified location. The ontology meta-data will be updated (see section 6).

Fig. 1. A contributor may use a client application to add and describe qualifications with terminology, classification information, and properties. A qualification may have a set of initial competencies and a set of end competencies.

The goal of the different user roles and use case diagrams is to make the ontology platform scalable and sustainable over time. This could be achieved by a separation of concerns so that users are shielded from complexity and are able to specialize themselves in their roles. A set of activity and role specific user interfaces also guides the user to manage the ontology. For an example of how the platform could be used to describe a qualification see Fig. 1. Depending on the user role and user activity, the platform should limit the possible user actions. The platform should also check the consistency of the ontology changes. For example, an expected end competency of a qualification should not be lower than the required initial competencies to start the training. Notable differences between our approach and other evolutionary ontology engineering approaches, for example [7] and [10], are that we mainly rely on natural language to capture the knowledge and use specific applications to guide the user during the conceptualization.

934

P. De Baer, R. Meersman, and G. Zhao

5 Publication and Use of the Ontology Content Although the ontology platform allows a broad community to explore and maintain the ontology, we would also include the option of publishing the validated ontology content as XML pages on the web. The advantage of such static XML pages is that software systems could easily make use of the information. For the PROLIX project, organizations could, for example, extract the list of competences for internal use, or filter the qualifications that provide the required competences for their organization. The use of static XML pages is also less demanding of the ontology platform, since organizations may download the information for (offline) custom querying. We would also provide XSL Transformations6 to transform the XML pages into HTML pages. This would allow end users, for example, HRM managers and job candidates, to browse the ontology content in their web browser without even registering on the ontology platform. For an example of how the ontology content might be presented as HTML pages, see Fig. 2.

Fig. 2. Validated ontology content could be presented as static HTML pages

Publishing the ontology as static XML or HTML pages makes it easier to keep track of ontology changes (see also section 6). If a concept, that was already published, is modified, validated, and again published, a new concept version would be created. The concept list would refer to the latest concept version and the status of the latest concept version would have a link to the previous concept version. Moreover, the status of the previous concept version would change to Updated and have a link to the new concept version. Each concept version in the published ontology has a unique URL which makes it possible for end users to refer to the concept. For example, a job candidate could refer 6

http://www.w3.org/TR/xslt

An Evolutionary Ontology Approach for Community-Based Competency Management

935

(in a portfolio) to the URLs that describe his list of qualifications and competences. An HRM manager (possibly a software system) could then better evaluate this information.

6 Meta-data in the Evolutionary Ontology Content in the ontology may be divided into two major categories, i.e. ontological and terminological information. Ontological information includes the concepts, concept properties, and concept relations. Terminological information includes the terms, term properties, and term relations. Terms are the language specific character strings that denote a certain concept. To enable the above described use case diagrams and publication of the ontology it is necessary to add meta-data to the ontology so that content changes may be tracked, validated, and published. For each data element, i.e. concept, concept property, concept relation, term, term property, and term relation, the following meta-data should be recorded: • • •

Date and timestamp of creation, modification, or deletion. User ID that created, modified, deleted, or validated the data. Status that indicates the validity of the data. An overview of the different states and the possible transitions between two states is illustrated in Fig. 3. • • • • • • • •

Created: indicates that the data was newly created. Updated: indicates that the data was updated. Deleted: indicates that the data was marked for deletion. Create validated: indicates that the new data was validated. Update validated: indicates that the update was validated. Published: indicates that the validated data was published. Delete validated: indicates that the delete was validated. Delete published: indicates that the validated delete was published.

For the entire ontology the following meta-data should be recorded: • • •

Date and timestamp of publication User ID that published the validated ontology content. Location of the latest published ontology content.

Fig. 3. The different meta-data states of ontology content and the possible transitions between two states

936

7

P. De Baer, R. Meersman, and G. Zhao

Conclusion and Future Work

We described an evolutionary ontology approach that distinguishes between major ontology (platform) changes and minor ontology changes. We divide the community into facilitators, contributors, and users. Facilitators are responsible for major ontology (platform) changes. Contributors are responsible for minor ontology changes. The wisdom of crowds approach is followed to manage minor ontology changes. Users may explore the ontology via the ontology platform and/or make use of the published ontology content in XML or HTML format. Currently, this approach is being tested for community-based competency and qualification description. In the future we would like to further develop and evaluate the approach in other ontology engineering projects. Acknowledgments. The research described in this paper was sponsored in part by the EU IP 027905 Prolix project.

References 1. Christiaens, S., De Leenheer, P., de Moor, A., Meersman, R.: Business Use Case: Ontologising Competencies in an Interorganisational Setting. In: Ontology Management: Semantic Web, Semantic Web Services, and Business Applications, from Semantic Web and Beyond: Computing for Human Experience (2008) 2. Christiaens, S., De Bo, J., Verlinden, R.: Competencies in a Semantic Context: Meaningful Competencies. In: Proceedings of the OntoContent workshop, Montpellier, France (November 2006) 3. De Coi, J.L., Herder, E., Koesling, A., Lofi, C., Olmedilla, D., Papapetrou, O., Siberski, W.: A Model for Competence Gap Analysis. In: Proceedings of the First European Conference on Technology Enhanced Learning, EC-TEL (2006) 4. De Leenheer, P., de Moor, A., Meersman, R.: Context Dependency Management In Ontology Engineering: a Formal Approach. In: Spaccapietra, S., Atzeni, P., Fages, F., Hacid, M.-S., Kifer, M., Mylopoulos, J., Pernici, B., Shvaiko, P., Trujillo, J., Zaihrayeu, I. (eds.) Journal on Data Semantics VIII. LNCS, vol. 4380, pp. 26–56. Springer, Heidelberg (2007) 5. De Leenheer, P., de Moor, A.: Context-driven Disambiguation in Ontology Elicitation. In: Shvaiko, P., Euzenat, J. (eds.) Context and Ontologies: Theory, Practice and Applications, AAAI Technical Report WS-05-01, pp. 17–24. AAAI Press, Menlo Park (2005) 6. de Moor, A., De Leenheer, P., Meersman, R.: DOGMA-MESS: A Meaning Evolution Support System for Interorganizational Ontology Engineering. In: Schärfe, H., Hitzler, P., Øhrstrøm, P. (eds.) ICCS 2006. LNCS (LNAI), vol. 4068, pp. 189–202. Springer, Heidelberg (2006) 7. Noy, N., Chugh, A., Liu, W., Musen, M.: A Framework for Ontology Evolution in Collaborative Environments. In: Cruz, I., Decker, S., Allemang, D., Preist, C., Schwabe, D., Mika, P., Uschold, M., Aroyo, L.M. (eds.) ISWC 2006. LNCS, vol. 4273, pp. 544–558. Springer, Heidelberg (2006) 8. Radevski, V., Trichet, F.: Ontology-Based Systems dedicated to Human Resources Management: an application in e-recruitment. In: Meersman, R., Tari, Z., Herrero, P. (eds.) OTM 2006 Workshops. LNCS, vol. 4278, pp. 1068–1077. Springer, Heidelberg (2006) 9. Tang, Y., Christiaens, S., Kerremans, K., Meersman, R.: PROFILE COMPILER: OntologyBased, Community-Grounded, Multilingual Online Services to Support Collaborative Decision Making. In: Proc. of RCIS 2008 (2008); IEEE catalog: CFP0840D-PRT 10. Vouros, G.A., Kotis, K., Chalkiopoulos, C., Lelli, N.: The HCOME-3O Framework for Supporting the Collaborative Engineering of Evolving Ontologies. In: Proceedings of the First International Workshop on Emergent Semantics and Ontology Evolution 2007, vol. 292. CEUR-WS.org/ (2007) 11. Vrandečić, D., Pinto, S., Tempich, C., Sure, Y.: The DILIGENT knowledge processes. Journal of Knowledge Management 9(5), 85–96 (2005)

MaSiMe: A Customized Similarity Measure and Its Application for Tag Cloud Refactoring David Urdiales-Nieto, Jorge Martinez-Gil, and Jos´e F. Aldana-Montes University of M´ alaga, Department of Computer Languages and Computing Sciences Boulevard Louis Pasteur 35, 29071 M´ alaga, Spain {durdiales,jorgemar,jfam}@lcc.uma.es http://khaos.uma.es/

Abstract. Nowadays the popularity of tag clouds in websites is increased notably, but its generation is criticized because its lack of control causes it to be more likely to produce inconsistent and redundant results. It is well known that if tags are freely chosen (instead of taken from a given set of terms), synonyms (multiple tags for the same meaning), normalization of words and even, heterogeneity of users are likely to arise, lowering the efficiency of content indexing and searching contents. To solve this problem, we have designed the Maximum Similarity Measure (MaSiMe) a dynamic and flexible similarity measure that is able to take into account and optimize several considerations of the user who wishes to obtain a free-of-redundancies tag cloud. Moreover, we include an algorithm to effectively compute the measure and a parametric study to determine the best configuration for this algorithm. Keywords: social tagging systems, social network analysis, Web 2.0.

1

Introduction

Web 2.0 is a paradigm about the proliferation of interactivity and informal annotation of contents. This informal annotation is performed by using tags. Tags are personally chosen keywords assigned to resources. So instead of putting a bookmark into a folder, users might assign it tags. The main aspect is that tagging creates an annotation to the existing content. If users share these with others, everybody benefits by discovering new sites and getting better matches for their searches. Tag clouds represent a whole collection of tags as weighted lists. The more often a tag has been used, the larger it will be displayed in the list. This can be used to both characterize users, websites, as well as groups of users. To date, tag clouds have been applied to just a few kinds of focuses (links, photos, albums, blog posts are the more recognizable). In the future, expect to see specialized tag cloud implementations emerge for a tremendous variety of fields and focuses: cars, properties or homes for sale, hotels and travel destinations, products, sports teams, media of all types, political campaigns, financial markets, brands, etc [1]. R. Meersman, P. Herrero, and T. Dillon (Eds.): OTM 2009 Workshops, LNCS 5872, pp. 937–946, 2009. c Springer-Verlag Berlin Heidelberg 2009 

938

D. Urdiales-Nieto, J. Martinez-Gil, and J.F. Aldana-Montes

On the other hand, although automatic matching between tags is perhaps the most appropriate way to solve this kind of problems, it has the disadvantage but when dealing with natural language often it leads a significant error rate, so researchers try to find customized similarity functions (CSF) [2] in order to obtain the best solution for each situation. We are following this line. Therefore, the main contributions of this work are: – The introduction of a new CSF called Maximum Similarity Measure (MaSiMe) to solve the lack of terminological control in tag clouds. – An algorithm for computing the measure automatically and efficiently and a statistical study to choose the most appropriate parameters. – An empirical evaluation of the measure and discussion about the advantages of its application in real situations. The remainder of this article is organized as follows. Section 2 describes the problem statement related to the lack of terminological control in tag clouds. Section 3 describes the preliminary definitions and properties that are necessary for our proposal. Section 4 discusses our Customized Similarity Measure and a way to effectively compute it. Section 5 shows the empirical data that we have obtained from some experiments, including a comparison with other tools. Section 6 compares our work with other approaches qualitatively. And finally, in Section 7 the conclusions are discussed and future work presented.

2

Problem Statement

Tags clouds offer an easy method to organize information in the Web 2.0. This fact and their collaborative features have derived in an extensive involvement in many Social Web projects. However they present important drawbacks regarding their limited exploring and searching capabilities, in contrast with other methods as taxonomies, thesauruses and ontologies. One of these drawbacks is an effect of its flexibility for tagging, producing frequently multiple semantic variations of a same tag. As tag clouds become larger, more problems appear regarding the use of tag variations at different language levels [3]. All these problems make more and more difficult the exploration and retrieval of information decreasing the quality of tag clouds. We wish to obtain a free-of-redundancies tag cloud as Fig. 1 shows, where tags with similar means have been grouped. The most significant tag can be visible and the rest of similar tags could be hidden, for example. Only, when a user may click on a significant tag, other less important tags would be showed. On the other hand, we need a mechanism to detect similarity in tag clouds. In this way, functions for calculating relatedness among terms can be divided into similarity measures and distance measures. – A similarity measure is a function that associates a numeric value with a pair of objects, with the idea that a higher value indicates greater similarity.

MaSiMe: A Customized Similarity Measure and Its Application

939

Fig. 1. Refactored tag cloud. Tags with similar means have been grouped.

– A distance measure is a function that associates a non-negative numeric value with a pair of objects, with the idea that a short distance means greater similarity. Distance measures usually satisfy the mathematical axioms of a metric. Frequently, there are long-standing psychological objections to the axioms used to define a distance metric. For example, a metric will always give the same distance from a to b as from b to a, but in practice we are more likely to say that a child resembles their parent than to say that a parent resembles their child [4]. Similarity measures give us an idea about the probability of compared objects being the same, but without falling into the psychological objections of a metric. So from our point of view, working with similarity measures is more appropriate for detecting relatedness between different tags with a similar meaning.

3

Technical Preliminaries

In this section, we are going to explain the technical details which are necessary to follow our proposal. Definition 1 (Similarity Measure). A similarity measure sm is a function sm : µ1 × µ2 → R that associates the similarity of two input solution mappings µ1 and µ2 to a similarity score sc ∈  in the range [0, 1]. A similarity score of 0 stands for complete inequality and 1 for equality of the input solution mappings µ1 and µ2 . Definition 2 (Granularity). Given a weight vector w = (i, j, k, ..., t) we define granularity as the Maximum Common Divisor from the components of the vector. Its purpose is to reduce the infinite number of candidates in the solutions space to a finite number.

940

4

D. Urdiales-Nieto, J. Martinez-Gil, and J.F. Aldana-Montes

MaSiMe: Maximum Similarity Measure

In this section, we are going to explain MaSiMe and its associated properties. Then, we propose an efficient algorithm to compute MaSiMe and finally, we present a statistical study to determine the most appropriate configuration for the algorithm. 4.1

Maximum Similarity Measure

An initial approach for an ideal Customized Similarity Measure which would be defined in the following way: Let A be a vector of matching algorithms in the form of a similarity measure and w a weight vector then: i=n M aSiM e(c1, c2) = x ∈ [0, 1] ∈  → ∃ A, w , x = max( i=1 Ai · wi ) i=n with the following restriction i=1 wi ≤ 1 But from the point of view of engineering, this measure leads to an optimization problem for calculating the weight vector, because the number of candidates from the solution space is infinite. For this reason, we present MaSiMe, which uses the notion of granularity for setting a finite number of candidates in that solution space. This solution means that the problem of computing the similarity can be solved in a polynomial time. Definition 3. Maximum Similarity Measure (MaSiMe) Let A be a vector of matching algorithms in the form of a similarity measure, let w be a weight vector and let g the granularity then: i=n M aSiM e(c1, c2) = x ∈ [0, 1] ∈  → ∃ A, w, g , x = max( i=1 Ai · wi ) i=n ˙ with the following restrictions i=1 wi ≤ 1 ∧ ∀wi ∈ w, wi ∈ {g} ˙ denotes the set of multiples of g. where {g} Example 1. Given an arbitrary set of algorithms and a granularity of 0.05, calculate MaSiMe for the pair (author, name author). M aSiM e(author, name author) = .542 ∈ [0, 1] → i=4 ∃ A = (L, B, M, Q), w = (0.8, 0, 0, 0.2), g = 0.05 , 0.542 = max( i=1 Ai · wi )

Where L = Levhenstein [5], B = BlockDistance [6], M = MatchingCoefficient [6] , Q = QGramsDistance [7] There are several properties for this definition: Property 1 (Continuous Uniform Distribution). A priori, MaSiMe presents a continuous uniform distribution in the interval [0, 1], that is to say, its probability density function is characterized by ∀ a, b ∈ [0, 1] → f (x) =

1 f or a ≤ x ≤ b b−a

Property 2 (Maximality). If one of the algorithms belonging to the set of matching algorithms returns a similarity of 1, then the value of MaSiMe is 1.

MaSiMe: A Customized Similarity Measure and Its Application

941

∃Ai ∈ A, Ai (c1, c2) = 1 → M aSiM e(c1, c2) = 1 Moreover, the reciprocal is true M aSiM e(c1, c2) = 1 → ∃Ai ∈ A, Ai (c1, c2) = 1 Property 3 (Monotonicity). Let S be a set of matching algorithms, and let S’ be a superset of S. If MaSiMe has a specific value for S, then the value for S’ is either equal to or greater than this value. ∀S  ⊃ S, M aSiM es = x → M aSiM es ≥ x 4.2

Computing the Weight Vector

Once the problem is clear and the parameters A and g are known, it is necessary to effectively compute the weight vector. At this point, we leave the field of similarity measures to move into the field of engineering. It is possible to compute MaSiMe in several ways, for this work, we have designed a greedy mechanism that seems to be effective and efficient. In the next paragraphs, we firstly describe this mechanism and then we discuss its associated complexity. We are going to solve this using a greedy strategy, thus a strategy which consists of making the locally optimum choice at each stage with the hope of finding the global optimum. Theorem 1 (About Computing MaSiMe). Let S be the set of all the matching algorithms, let A be the subset of S, thus, the set of matching algorithms that we want to use, let g be the granularity, let Q the set of positive Rational Numbers, let i, j, k, ..., t be indexes belonging to the set of multiples for the granularity ˙ then, a set of rational vectors r exists where each element ri is re(denoted {g}) sult of the scalar product between A and the index pattern (i, j − i, k − j, ..., 1 − t). All of this subject to j ≥ i ∧ k ≥ j ∧ 1 ≥ k. Moreover, the final result, called R, is the maximum of the elements ri and is always less or equal than 1. And in mathematical form: ˙ → ∃r, ri = A · (i, j − i, k − j, ..., 1 − t) ∃A ⊂ S, ∃g ∈ [0, 1] ∈ Q+, ∀i, j, k, ..., t ∈ {g} with the followings restrictions j ≥ i ∧ k ≥ j ∧ 1 ≥ k R = max (ri ) ≤ 1

Proof 1. ri is by definition the scalar product between a vector of matching algorithms that implements similarity measures and the pattern (i, j−i, k−j, ..., 1−t). In this case, a similarity measure cannot be greater than 1 by Definition 1 and the sum of the pattern indexes cannot be greater than 1 by restriction (i, j − i, k − j, ..., 1 − t), so scalar product of such factors cannot be greater than 1. Now, we are going to show how to implement the computation of MaSiMe by using an imperative programming language. Algorithm 1 shows the pseudocode implementation for this theorem.

942

D. Urdiales-Nieto, J. Martinez-Gil, and J.F. Aldana-Montes Input: tag cloud: T C Input: algorithm vector: A Input: granularity: g Output: M aSiM e foreach pair (c1, c2) of terms in T C do foreach index i, j, k, ..., t ∈ κ × g do result = A1 (c1, c2) · i + A2 (c1, c2) · j − i + A3 (c1, c2) · k − j + A4 (c1, c2) · t − k + ... An (c1, c2) · 1 − t ; if result > M aSiM e then M aSiM e = result; end if M aSiM e = 1 then stop; end end if M aSiM e > threshold then merge (M ostW eigthedT erm(c1, c2), LightT erm(c1, c2)); end end

Algorithm 1. The greedy algorithm to compute MaSiMe The algorithm can be stopped when it obtains a partial result equal to 1, because this is the maximum value than we can hope for. Complexity. The strategy seems to be brute force, but it is not (n-1 loops are needed to obtain n parameters). Have into account that the input data size is, but the computational complexity for the algorithm according to big O notation [8] is

O(nlength

of A−1

)

In this way, the total complexity (TC) for MaSiMe is: T C(M aSiM eA) = O(max(max(O(Ai )), O(strategy))) and therefore for MaSiMe using the greedy strategy

T C(M aSiM eA ) = O(max(max(O(Ai )), O(nlength 4.3

of A−1

)))

Statistical Study to Determine the Granularity

We have designed the proposed algorithm, but in order to provide a specific value for its granularity we have performed a parametric study. In this study, we have tried to discover the value that maximizes the value for the granularity by means of an experimental study. In Fig. 2, it can be seen that for several independent experiments the most suitable value is in the range between 0.1 and 0.13.

MaSiMe: A Customized Similarity Measure and Its Application

943

Fig. 2. Statistical study which shows that the most suitable value for granularity is in the range between 0.1 and 0.13. Cases analyzed present an increasing value of MaSiMe for low values of granularity, and MaSiMe presents the highest value between 0.1 and 0.13. MaSiMe is a constant value for higher values of granularity. Table 1. The statistical study shows the most suitable value for granularity is 0.10 because it provides the best results in all cases Granularity value No-adding function Adding function 0.10 0.11 1.00 0.13 0.11 1.00 Experiment 2 0.10 0.67 0.67 0.13 0.67 0.61 Experiment 3 0.10 0.63 0.63 0.13 0.63 0.57 Experiment 4 0.10 0.67 0.67 0.13 0.67 0.61 Experiment 1

Once we have obtained the granularity range with which is obtained the best MaSiMe value, a new statistical study is made with the same concepts to obtain the best MaSiMe value between 0.1 and 0.13. The function used by Google to take similarity distances [9] is introduced in MaSiMe showing better MaSiMe values using a granularity value of 0.1. Adding this function and using a granularity of 0.13 MaSiMe values are lower than without adding this function. Then, we can

944

D. Urdiales-Nieto, J. Martinez-Gil, and J.F. Aldana-Montes

conclude that the suitable granularity value is 0.1. Table 1 shows a comparative study with and without this new function.

5

Empirical Evaluation

We have tested an implementation of MaSiMe. We have used MaSiMe in the following way: For the matching algorithms vector, we have chosen a set of well known algorithms A = {Levhenstein [5], Stoilos [10], Google [9], Q-Gram [7] } and for granularity, g = 0.1 (as we have determined in the previous section). We show an example (Table 2) of mappings that MaSiMe has been able to discover from [11] and [12]. We have compared the results with two of the most outstanding tools: FOAM [13] and RiMOM [14].

Fig. 3. Refactorized tag cloud. Similar tags have been added to the scope of their corresponding and most significant tag. As consequence, we obtain a free-of-redundancies tag cloud where new terms can be included. Table 2. Comparison of several mappings from several tools Russia1 food drink traveler health risk document approval monetary unit inhabitant adventure building flight river transfer political area

Russia2 FOAM RiMOM MaSiMe food 1.00 0.50 1.00 drink 1.00 0.71 1.00 normal traveler 0 0 0.90 disease type 0 0.17 0.17 document 1.00 0.99 1.00 certificate 0 0.21 0.24 currency 0 0 0.29 citizen of russia 0 0.11 0.12 sport 0 0.01 0.11 public building 0.80 0.60 0.53 air travel 0 ≈0 1.00 cruise 0 0.21 0.21 political region 0 0.40 0.69

MaSiMe: A Customized Similarity Measure and Its Application

945

Moreover, in Fig. 3 we show the appearance from the experiment where we have obtained a free-of-redundancies tag cloud. Moreover, the refactoring process allows us to obtain a nicer tag cloud where new terms can be included. To obtain better results in the test, it is only necessary to expand the vector A with algorithms to have into account aspects to compare among the tags.

6

Related Work

A first approach to solve the problem could consist of systems employing an optional authority control of keywords or names and resource titles, by connecting the system to established authority control databases or controlled vocabularies using some kind of techniques, but we think that it is a very restrictive technique in relation to ours. Other approach consists of the utilization of approximate string matching techniques to identify syntactic variations of tags [3]. But the weakness of this proposal is that it has been designed to work at syntactical level only. In this way, only misspelled or denormalized tags can be merged with the relevant ones. On the other hand, there are tag clustering approaches. Most significant work following this paradigm is presented in [15], where a technique for pre-filtering tags before of applying an algorithm for tag clustering is proposed. Authors try to perform a statistical analysis of the tag space in order to identify groups, or clusters, of possibly related tags. Clustering is based on the similarity among tags given by their co-occurrence when describing a resource. But the goal of this work is substantially different from ours, because it tries to find relationships within tags in order to integrate folksonomies with ontologies.

7

Conclusions

We have presented MaSiMe, a new similarity measure and its application to tag cloud refactoring as part of a novel computational approach for flexible and accurate automatic matching that generalizes and extends previous proposals for exploiting an ensemble of matchers. Using MaSiMe to compare semantic similarities between tags needs to the user for choosing the appropriate algorithms for comparing such aspects it could be corrected (i.e. misspellings or typos, plurals, synonyms, informal words and, so on). As the results show, MaSiMe seems to be an accurate, and flexible similarity measure for detecting semantic relatedness between tags in a tag cloud and its application has been satisfactory. Moreover, we should not forget that MaSiMe is easy to implement in an efficient way.

Acknowledgements This work has been funded: ICARIA: From Semantic Web to Systems Biology (TIN2008-04844) and Pilot Project for Training and Developing Applied Systems Biology (P07-TIC-02978).

946

D. Urdiales-Nieto, J. Martinez-Gil, and J.F. Aldana-Montes

References 1. Marinchev, I.: Practical Semantic Web Tagging and Tag Clouds. Cybernetics and Information Technologies 6(3), 33–39 (2006) 2. Kiefer, C., Bernstein, A., Stocker, M.: The Fundamentals of iSPARQL: A Virtual Triple Approach for Similarity-Based Semantic Web Tasks. 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., Cudr´e-Mauroux, P. (eds.) ASWC 2007 and ISWC 2007. LNCS, vol. 4825, pp. 295–309. Springer, Heidelberg (2007) 3. Echarte, F., Astrain, J.J., C´ ordoba, A., Villadangos, J.: Pattern Matching Techniques to Identify Syntactic Variations of Tags in Folksonomies. In: Lytras, M.D., Carroll, J.M., Damiani, E., Tennyson, R.D. (eds.) WSKS 2008. LNCS (LNAI), vol. 5288, pp. 557–564. Springer, Heidelberg (2008) 4. Widdows, D.: Geometry and Meaning. The University of Chicago Press (2004) 5. Levenshtein, V.: Binary Codes Capable of Correcting Deletions, Insertions and Reversals. Soviet Physics-Doklady 10, 707–710 (1966) 6. Ziegler, P., Kiefer, C., Sturm, C., Dittrich, K.R., Bernstein, A.: Detecting Similarities in Ontologies with the SOQA-SimPack Toolkit. In: Ioannidis, Y., Scholl, M.H., Schmidt, J.W., Matthes, F., Hatzopoulos, M., B¨ ohm, K., Kemper, A., Grust, T., B¨ ohm, C. (eds.) EDBT 2006. LNCS, vol. 3896, pp. 59–76. Springer, Heidelberg (2006) 7. Ukkonen, E.: Approximate String Matching with q-grams and Maximal Matches. Theor. Comput. Sci. 92(1), 191–211 (1992) 8. Knuth, D.: The Art of Computer Programming. Fundamental Algorithms, 3rd edn., vol. 1. Addison-Wesley, Reading (1997) 9. Cilibrasi, R., Vit´ anyi, P.M.B.: The Google Similarity Distance. IEEE Trans. Knowl. Data Eng. 19(3), 370–383 (2007) 10. Stoilos, G., Stamou, G.B., Kollias, S.D.: A String Metric for Ontology Alignment. In: Gil, Y., Motta, E., Benjamins, V.R., Musen, M.A. (eds.) ISWC 2005. LNCS, vol. 3729, pp. 624–637. Springer, Heidelberg (2005) 11. http://www.aifb.uni-karlsruhe.de/WBS/meh/foam/ontologies/russia1.owl (last visit: February 3, 2009) 12. http://www.aifb.uni-karlsruhe.de/WBS/meh/foam/ontologies/russia2.owl (last visit: February 3, 2009) 13. Ehrig, M., Sure, Y.: FOAM - Framework for Ontology Alignment and Mapping - Results of the Ontology Alignment Evaluation Initiative. Integrating Ontologies (2005) 14. Li, Y., Li, J., Zhang, D., Tang, J.: Result of Ontology Alignment with RiMOM at OAEI 2006. In: International Workshop on Ontology Matching collocated with the 5th International Semantic Web Conference (2006) 15. Specia, L., Motta, E.: Integrating Folksonomies with the Semantic Web. In: Franconi, E., Kifer, M., May, W. (eds.) ESWC 2007. LNCS, vol. 4519, pp. 624–639. Springer, Heidelberg (2007)

Author Index

Abgaz, Yalemisew M. 544 Acu˜ na, C´esar J. 350 Adamus, Radoslaw 15 Agostinho, Carlos 194 Aim´e, Xavier 584 Akhlaq, Monis 6 Aldana-Montes, Jos´e F. 604, 937 Alencar, Fernanda 370 Alserhani, Faeiz 6 Amador, Ricardo 789 Amghar, Youssef 9 Antoniou, Grigoris 108 Apostolopoulos, Elias 108 Armenatzoglou, Nikos 108 Askounis, Dimitris 152 Aubry, Alexis 205 Awan, Irfan U. 6 Azevedo, Sofia 411 Badir, Hassan 11 Bahsoon, Rami 304, 494 Balsters, H. 671 Balsters, Herman 659 Benaben, Fr´ed´erick 898 Benghazi, Kawtar 381 Benharkat, A¨ıcha-Nabila 9 Bernus, Peter 162 Bikakis, Antonis 108 Boissel-Dallier, Nicolas 898 Bollen, Peter 639 Buchgeher, Georg 316 Cancela, Paulo 1 Cardoso, Jo˜ ao M.P. 464 Cardoso, Jorge C.S. 118 Carrillo-Ramos, Angela 474 Casellas, N´ uria 594 Casteleyn, Sven 88 Castro, Jaelson 370 Chang, Elizabeth 848 Charalabidis, Yannis 152 Chen, David 216 Chiara Caschera, Maria 504 Christiaens, Stijn 757 Chung, Lawrence 327

Cˆımpan, Sorana 433 Coninx, Karin 610 Corchuelo, Rafael 294 Cuesta, Carlos E. 350 Cullen, Andrea J. 6 Cur´e, Olivier 49 Curland, Matthew 692 D’Andrea, Alessia 504 D’Ulizia, Arianna 504 Davoust, Alan 888 De Baer, Peter 514, 534, 816, 927 de Castro, Valeria 350 De Giorgio, Teodoro 907 De Troyer, Olga 88 Dillon, Darshan 836 Dillon, Laura K. 704 Diniz, Pedro C. 464 Dong, Hai 848 Ducasse, St´ephane 433 El Beqqali, Omar 11 Emmerich, Wolfgang 304 Esfandiari, Babak 888 Eskeli, Juho 238 Espinoza, Ad´ an-No´e 622 Fabian, Benjamin 142 Facca, Federico Michele 877 Feliot, Claude 141 Fern´ andez, Luis 360 ´ Fern´ andez L´ opez, Alvaro 423 Ferreira, Diogo R. 464 Ferri, Fernando 504 Fortier, Andr´es 78 Franco, Dario 401 Franco, Tiago 1 Frantz, Rafael Z. 294 Fuentes, Lidia 360 Furst, Fr´ed´eric 584 Garc´ıa-V´ azquez, Juan-Pablo Gi, Engyoku 4 Gionis, George 152 G´ omez Oliva, Ana 805

622, 779

948

Author Index

Gordillo, Silvia 78 Gøtze, John 162 Gregoriades, Andreas 259 Grifoni, Patrizia 504 Groß, Anika 574 Gu´edria, Wided 216 Guzzo, Tiziana 504 Haarsma, Bouke 659 Hadzic, Maja 836 Halpin, Terry 692, 723 Hartung, Michael 574 Heath, Clifford 682 Herrmann, Klaus 98 Hill, Tom 327 Hornung, Thomas 13 Hummel, Karin Anna 444 Hussain, Farookh Khadeer 848, 858 Jardim-Goncalves, Ricardo Javed, Muhammad 544 J¨ org, Brigitte 757 Jos´e, Rui 118

194

K¨ aa ¨ri¨ ainen, Jukka 238 Kampas, Dimitris 108 Kapravelos, Alexandros 108 Karduck, Achim 172 Kartsonakis, Eythimis 108 Kasisopha, Natsuda 858 Keet, C. Maria 735 Kimoto, Masahiro 866 Kirsten, Toralf 574 Kojima, Isao 866 Kolp, Manuel 564 Komazec, Srdjan 877 Kopeck´ y, Jacek 917 Koussouris, Sotiris 152 Kowalski, Tomasz M. 15 Kriara, Lito 108 Kudagba, Kunale 11 Kuliberda, Kamil 15 Kuntz, Pascale 584 Lamersdorf, Ansgar 228 Lamine, Elyes 172 Lamolle, Myriam 19 Lampathaki, Fenareti 152 Laurier, Wim 554 L  awrynowicz, Agnieszka 826 Lemmens, Inge 714, 745

Linardakis, Giorgos 108 Lincoln, Maya 184 L´ opez-Sanz, Marcos 350 Lorr´e, Jean-Pierre 898 Louvion, Carine 39 Lucas Soares, Ant´ onio 524 Lucena, Marcia 370 Luyten, Kris 610 Machado, Ricardo J. 411 Mak, Ralph 745 Maleshkova, Maria 917 Marcos, Esperanza 350 Marin D´ıaz, David 474 Markantonakis, Konstantinos 128 Marketakis, Yannis 108 Martinez-Gil, Jorge 937 May, Wolfgang 13 Mayes, Keith 128 McGill, Matthew J. 704 Meersman, Robert 514, 534, 816, 927 Mellor, John 6 Menet, Ludovic 19 Mirchandani, Pravin 6 Mishra, Alok 282, 484 Mishra, Deepti 282, 484 Molina-Jimenez, Carlos 294 Morris, Robert A. 59 M¨ uller, Cristian 142 M¨ unch, J¨ urgen 228 Muthig, Dirk 411 Naeem Akram, Raja 128 Naudet, Yannick 216 Neyem, Andr´es 401 Neysen, Nicolas 564 Nijssen, Maurice 745 Nikitaki, Sofia 108 Niwi´ nska, Magdalena 29 Noguera Garc´ıa, Manuel 381, 423 Ochoa, Sergio F. 401 Ohzeki, Kazuo 4 Ok, MinHwan 69 Onolaja, Olufunmilola

494

Pahl, Claus 544 Panetto, Herv´e 205 Pankowski, Tadeusz 29 Papadopoulou, Vicky 259

Author Index Papavasiliou, Vicky 108 Paulino, Herv´e 1 Pedrinaci, Carlos 917 Pereira, Carla 524 P´erez, Emiliano 78 Pernek, Igor 444 Piippola, Markus 238 Pimentel, Jo˜ ao 370 Pingaud, Herv´e 172 Pino, Jos´e A. 401 Pinto, M´ onica 360 Piprani, Baba 629, 649 Poels, Geert 554 Pudney, Kevin 514 Rahm, Erhard 574 Razavizadeh, Azadeh 433 Ribeiro, Hugo 411 Rico Zuluaga, Alejandro 474 Ripa, Gianluca 907 Rodrigues, Helena 810 Rodr´ıguez, Mar´ıa Luisa 381 Rodr´ıguez, Marcela D. 622, 779 Rodr´ıguez F´ ortiz, Mar´ıa Jos´e 423 Rosati, Riccardo 18 Rossi, Gustavo 78 Rothermel, Kurt 98 Rubach, Pawel 248 Ruiz-Montiel, Manuela 604 Salda˜ na-Jimenez, Diana 622 Salger, Frank 267, 391 S´ anchez Garc´ıa, Sergio 805 Santos, Andr´e C. 464 Santos, Arlindo 810 Santos, Emanuel 370 Sellami, Sana 9 Seo, Yuki 4 Sgaramella, Francesco 714 Sienou, Amadou 172 Silva, Carla 370 Sobolewski, Michael 248 Sousa, Crist´ ov˜ ao 524 Spyns, Peter 757 Stirewalt, Kurt 692 Stirewalt, R.E. Kurt 704

949

Subramanian, Nary 337 Supakkul, Sam 327 Tahmasebi, Nina 769 Tang, Yan 514, 816 Temmerman, Rita 534 Teppola, Susanna 238 Thau, David 59 Theodoropoulos, Georgios Treins, Michel 39 Trichet, Francky 584 Turner, Patrick 162 Tuuttila, Pekka 238

494

Urbansky, David 800 Urdiales-Nieto, David 937 Valenzuela, Juan A. 360 Valera, Serge 714 V¨ alim¨ aki, Antti 238 van Blommestein, F. 671 Vanderhulst, Geert 610 Van Grootel, Geert 757 Van Woensel, William 88 Vaudelin, Jacques 39 Vemulapalli, Anisha 337 Verjus, Herv´e 433 Visitaci´ on Hurtado, Mar´ıa 381 Wang, Yinglin 616 Wasser, Avi 184 Wautelet, Yves 564 Weinreich, Rainer 316 White, Sean 59 Wi´slicki, Jacek 15 Wojciechowski, Adam 454 Wolf, Hannes 98 Wongthongtham, Pornpit 858 Yahia, Esma 205 Yang, Jing 205 Zhang, Zheying 616 Zhao, Gang 514, 816, 927 Ziekow, Holger 142, 277 Zuccal` a, Maurilio 907