Complex Systems in Knowledge-based Environments: Theory, Models and Applications (Studies in Computational Intelligence)

Andreas Tolk and Lakhmi C. Jain (Eds.) Complex Systems in Knowledge-based Environments: Theory, Models and Applications...

Author: Andreas Tolk | Lakhmi C. Jain

21 downloads 1013 Views 18MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

Andreas Tolk and Lakhmi C. Jain (Eds.) Complex Systems in Knowledge-based Environments: Theory, Models and Applications

Studies in Computational Intelligence, Volume 168 Editor-in-Chief Prof. Janusz Kacprzyk Systems Research Institute Polish Academy of Sciences ul. Newelska 6 01-447 Warsaw Poland E-mail: [email protected] Further volumes of this series can be found on our homepage: springer.com Vol. 147. Oliver Kramer Self-Adaptive Heuristics for Evolutionary Computation, 2008 ISBN 978-3-540-69280-5 Vol. 148. Philipp Limbourg Dependability Modelling under Uncertainty, 2008 ISBN 978-3-540-69286-7 Vol. 149. Roger Lee (Ed.) Software Engineering, Artificial Intelligence, Networking and Parallel/Distributed Computing, 2008 ISBN 978-3-540-70559-8 Vol. 150. Roger Lee (Ed.) Software Engineering Research, Management and Applications, 2008 ISBN 978-3-540-70774-5 Vol. 151. Tomasz G. Smolinski, Mariofanna G. Milanova and Aboul-Ella Hassanien (Eds.) Computational Intelligence in Biomedicine and Bioinformatics, 2008 ISBN 978-3-540-70776-9 Vol. 152. Jaroslaw Stepaniuk Rough – Granular Computing in Knowledge Discovery and Data Mining, 2008 ISBN 978-3-540-70800-1 Vol. 153. Carlos Cotta and Jano van Hemert (Eds.) Recent Advances in Evolutionary Computation for Combinatorial Optimization, 2008 ISBN 978-3-540-70806-3 Vol. 154. Oscar Castillo, Patricia Melin, Janusz Kacprzyk and Witold Pedrycz (Eds.) Soft Computing for Hybrid Intelligent Systems, 2008 ISBN 978-3-540-70811-7 Vol. 155. Hamid R. Tizhoosh and M. Ventresca (Eds.) Oppositional Concepts in Computational Intelligence, 2008 ISBN 978-3-540-70826-1 Vol. 156. Dawn E. Holmes and Lakhmi C. Jain (Eds.) Innovations in Bayesian Networks, 2008 ISBN 978-3-540-85065-6 Vol. 157. Ying-ping Chen and Meng-Hiot Lim (Eds.) Linkage in Evolutionary Computation, 2008 ISBN 978-3-540-85067-0

Vol. 158. Marina Gavrilova (Ed.) Generalized Voronoi Diagram: A Geometry-Based Approach to Computational Intelligence, 2009 ISBN 978-3-540-85125-7 Vol. 159. Dimitri Plemenos and Georgios Miaoulis (Eds.) Artificial Intelligence Techniques for Computer Graphics, 2009 ISBN 978-3-540-85127-1 Vol. 160. P. Rajasekaran and Vasantha Kalyani David Pattern Recognition using Neural and Functional Networks, 2009 ISBN 978-3-540-85129-5 Vol. 161. Francisco Baptista Pereira and Jorge Tavares (Eds.) Bio-inspired Algorithms for the Vehicle Routing Problem, 2009 ISBN 978-3-540-85151-6 Vol. 162. Costin Badica, Giuseppe Mangioni, Vincenza Carchiolo and Dumitru Dan Burdescu (Eds.) Intelligent Distributed Computing, Systems and Applications, 2008 ISBN 978-3-540-85256-8 Vol. 163. Pawel Delimata, Mikhail Ju. Moshkov, Andrzej Skowron and Zbigniew Suraj Inhibitory Rules in Data Analysis, 2009 ISBN 978-3-540-85637-5 Vol. 164. Nadia Nedjah, Luiza de Macedo Mourelle, Janusz Kacprzyk, Felipe M.G. Fran¸ca and Alberto Ferreira de Souza (Eds.) Intelligent Text Categorization and Clustering, 2009 ISBN 978-3-540-85643-6 Vol. 165. Djamel A. Zighed, Shusaku Tsumoto, Zbigniew W. Ras and Hakim Hacid (Eds.) Mining Complex Data, 2009 ISBN 978-3-540-88066-0 Vol. 166. Constantinos Koutsojannis and Spiros Sirmakessis (Eds.) Tools and Applications with Artificial Intelligence, 2009 ISBN 978-3-540-88068-4 Vol. 167. Ngoc Thanh Nguyen and Lakhmi C. Jain (Eds.) Intelligent Agents in the Evolution of Web and Applications, 2009 ISBN 978-3-540-88070-7 Vol. 168. Andreas Tolk and Lakhmi C. Jain (Eds.) Complex Systems in Knowledge-based Environments: Theory, Models and Applications, 2009 ISBN 978-3-540-88074-5

Andreas Tolk Lakhmi C. Jain (Eds.)

Complex Systems in Knowledge-based Environments: Theory, Models and Applications

123

Professor Dr. Andreas Tolk Engineering Management & Systems Engineering 242B Kaufman Hall Old Dominion University Norfolk, VA 23529 USA Email: [email protected]

Professor Dr. Lakhmi C. Jain School of Electrical and Information Engineering University of South Australia Mawson Lakes Campus Adelaide, South Australia SA 5095 Australia Email: [email protected]

ISBN 978-3-540-88074-5

e-ISBN 978-3-540-88075-2

DOI 10.1007/978-3-540-88075-2 Studies in Computational Intelligence

ISSN 1860949X

Library of Congress Control Number: 2008935501 c 2009 Springer-Verlag Berlin Heidelberg 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, reuse of illustrations, recitation, broadcasting, reproduction on microfilm or in any other way, and storage in data banks. Duplication of this publication or parts thereof is permitted only under the provisions of the German Copyright Law of September 9, 1965, in its current version, and permission for use must always be obtained from Springer. Violations are liable to prosecution under the German Copyright Law. The use of general descriptive names, registered names, trademarks, etc. in this publication does not imply, even in the absence of a specific statement, that such names are exempt from the relevant protective laws and regulations and therefore free for general use. Typeset & Cover Design: Scientific Publishing Services Pvt. Ltd., Chennai, India. Printed in acid-free paper 987654321 springer.com

This Book Is Dedicated to Our Students

Preface

The tremendous growth in the availability of inexpensive computing power and easy availability of computers have generated tremendous interest in the design and implementation of Complex Systems. Computer-based solutions offer great support in the design of Complex Systems. Furthermore, Complex Systems are becoming increasingly complex themselves. This research book comprises a selection of state-of-the-art contributions to topics dealing with Complex Systems in a Knowledge-based Environment. Complex systems are ubiquitous. Examples comprise, but are not limited to System of Systems, Service-oriented Approaches, Agent-based Systems, and Complex Distributed Virtual Systems. These are application domains that require knowledge of engineering and management methods and are beyond the scope of traditional systems. The chapters in this book deal with a selection of topics which range from uncertainty representation, management and the use of ontological means which support and are large-scale business integration. All contributions were invited and are based on the recognition of the expertise of the contributing authors in the field. By collecting these sources together in one volume, the intention was to present a variety of tools to the reader to assist in both study and work. The second intention was to show how the different facets presented in the chapters are complementary and contribute towards this emerging discipline designed to aid in the analysis of complex systems. The common denominator of all of the chapters is the use of knowledge-based methods, and in particular ontological means. The chapters are categorized into two parts which are the Theoretical Contributions and the Practical Applications. We believe that this volume will help researchers, students, and practitioners in dealing with the challenges encountered in the integration, operation, and evaluation of Complex Systems. We are grateful to the contributors and the reviewers for their time, efforts and vision. We would like to express our sincere thanks to the editorial staff of SpringerVerlag publisher and Scientific Publishing Services Private Limited for their excellent support. Editors

Andreas Tolk Lakhmi C. Jain

Contents

1 An Introduction to Complex Systems in the Knowledge-Based Environment Andreas Tolk, Lakhmi C. Jain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

2 Uncertainty Representation and Reasoning in Complex Systems Kathryn Blackmond Laskey, Paulo Cesar G. Costa . . . . . . . . . . . . . . . . . . . .

7

3 A Layered Approach to Composition and Interoperation in Complex Systems Andreas Tolk, Saikou Y. Diallo, Robert D. King, Charles D. Turnitsa . . . .

41

4 Ontology Driven Data Integration in Heterogeneous Networks Isabel F. Cruz, Huiyong Xiao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

75

5 Complexity and Emergence in Engineering Systems Chih-Chun Chen, Sylvia B. Nagl, Christopher D. Clack . . . . . . . . . . . . . . . .

99

6 Feature Modeling: Managing Variability in Complex Systems Christer Th¨ orn, Kurt Sandkuhl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 7 Semantic Robotics: Cooperative Labyrinth Discovery Robots for Intelligent Environments Atilla El¸ci, Behnam Rahnama . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 8 Principles for Effectively Representing Heterogeneous Populations in Multi-agent Simulations Daniel T. Maxwell, Kathleen M. Carley . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

X

Contents

9 Ontology Meets Business – Applying Ontology to the Development of Business Information Systems Matthew West . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 Author Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

1 An Introduction to Complex Systems in the Knowledge-Based Environment Andreas Tolk1 and Lakhmi C. Jain2 1

Old Dominion University, Norfolk, VA 23529, USA [email protected] 2 University of South Australia Adelaide, Australia [email protected]

Abstract. This chapter gives a brief introduction to the complex systems in an intelligent environment. It presents the chapters included in the book and places them into a common context. It contains a number of resources for interested readers to pursue their particular interests.

1.1 Introduction Complex systems can be said to be ubiquitous. They exist in our daily lives among others in traffic control systems, in information technology, in world-wide interconnected services, and in mathematical applications. Engineers working in these areas face the challenge to integrate existing solutions into increasingly complex systems. The academic education of engineers and computer scientists is attempting to cope with these new demands. However, a gap between the needs of industry and the methods and the best practices developed in academia still exists. The work summarized in this book helps to close this gap and contains the theoretic efforts obtained by research and best practices developed for industrial solutions. The book results from a series of workshops and discussions that the editors participated in. During this time they realized that the approaches presented in this book all deal with the use of the knowledge-based means used with complex systems in innovative ways. Most of these systems and solutions have nothing in common at first glance. Social models using agent-based simulations, semantic robots going through a labyrinth, the integration of syntactically and schematically heterogeneous networked data sources, and mathematical models dealing with uncertainty are some examples. At second glance, examples of similarities become apparent. All of the efforts presented in this book involve various means of knowledge representation. These are used to enable typical tasks faced by engineers and scientists when confronted with complex systems. Application domains are diverse, which becomes apparent in the variety of contributions to this volume. Examples range from theoretical insight on how complexity and emergence can be understood in complex systems to reflective use cases describing practical applications. Other contributions cover how uncertainty A. Tolk, L.C. Jain (Eds.): Comp. Sys. in Knowledge-based Environments, SCI 168, pp. 1–5. © Springer-Verlag Berlin Heidelberg 2009 springerlink.com

2

A. Tolk and L.C. Jain

can be represented by allowing intelligent software solutions to draw conclusions and support decisions. Theoretical contributions and practical applications are also documented. The idea behind this book was to assemble these different experiences and gather them into a common context of knowledge-based support enabling to deal better with complex systems. The target audiences are master-level students of science and engineering and practitioners in the field. All are facing the challenge that the necessary solutions steadily increase in complexity. This is true for both real and virtual systems. Efficient methods and tools are needed to manage this complexity. In particular when new functionality needs are to be added, – and this functionality is often included in legacy systems which are by themselves already complex –, effective and efficient support for this task needs to be provided. A new way to document complex systems focusing on the two characteristic aspects - the multiple interfaces of complex systems, most of which exposing non-linear interconnections - is a first step. Intelligent agents shall be able to read these documentations in order to support the engineer. Intelligent decision and decision support technologies are applied in these domains and were successfully used in various applications. The requirement of addressing challenges of transferring explicit knowledge, information, and data in large heterogeneous organizations is known. This can include networked solutions, the federation of systems, or engineering systems mainly comprising existing systems. It may even support the merging of big businesses and their business processes. There may be a need to integrate the formerly separated solutions into a common infrastructure. Knowledge management applied in this context must be mature and lead with certainty to feasible solutions. Using these ideas means that current legacy systems must evolve from their existing state of organization specific variants to a heterogeneous, but aligned, single common architecture. These federated systems must provide consistent support of the common business processes and at the same time provide service-unique applications and services.

1.2 Chapters Included in the Book To adequately cover both aspects, the book is divided into two parts. The first four chapters are related to the theory and foundations of complex systems. The last four chapters focus on practical applications. It should be noted that all chapters contribute to the theory and are both applicable to practice. Laskey and Costa describe how to deal with uncertainty in complex systems and how to allow not only the representation but also present the reasoning in uncertain environments. The ability to deal with uncertain and incomplete data is a vital requirement for all real-world applications. Not including uncertainty will lead to wrong decisions and to failure of the solution. Bayesian probability theory and traditional knowledge representation languages provide a powerful logical basis for representing uncertainty, but they alone are not sufficient. On this account, the authors introduce Multi-Entity Bayesian Networks (MEBN) and the PR-OWL language. This enables expressing probabilistic ontologies to be expressed as an efficient support for complex system engineering. A layered approach to the composition and interoperation in complex systems is introduced by Tolk and others in the third chapter. The Levels of Conceptual Interoperability Model (LCIM) is used to identify means of knowledge representation

An Introduction to Complex Systems in the Knowledge-Based Environment

3

support. The first aspect is the composition of many systems into one system of systems. The second aspect is to understand the interoperation of the many systems that are part of a system of systems. The engineer must understand data, processes and the supported operational context provided by the business use of such cases. The chapter introduces data engineering, process engineering, and constraint engineering. These are used as methods to deal with challenges of composition and interoperation by use of the ontological spectrum. The work of Cruz and Xiao is a complementary effort and uses ontology-driven data integration in heterogeneous networks for complex system integration. They focus on building networks of data sources that are both syntactically and schematically different. To this end, they first show how to define a common vocabulary that constructs the basis of semantic integration. The common vocabulary results in an application global ontology on which the various data schemes can be mapped. The chapter introduces the necessary metadata, schema conceptualization, and it shows how to mediate solutions. Finally, Chen et al. address the challenges which must be solved to manage complexity and emerging behavior in the resulting engineering systems. Emerging properties are exposed by complex systems on higher levels than the originally engineered level. Such higher level emerging properties are typically more difficult to predict and are harder to manage. This is because the underlying functions are both more complex and are also non-linear. Even small changes on the engineering level can result in tremendous differences in the system’s behavior on the users’ level. The chapter gives an overview of the currently available key concepts for coping with the complexity and the emergence of other complications and shows how they can be applied to support the more complex system engineering using knowledge-based means. In the best practice section of this volume, Thoern and Sandkuhl contribute the first chapter introducing the principles of feature modeling. Their goal is to provide the support necessary to manage the variability in complex systems. The underlying problem is that providing users with the features offered by these complex systems often causes serious management issues for the developers. This chapter describes feature modeling as an important contribution to help solve this problem. This is done by capturing and visualizing common features and the interdependence between these features and system components that take part in the implementation. The fundamentals of feature modeling are introduced. It gives also examples from the real-world applications in the automotive industry. The use of knowledge by robots is a new discipline. It is no longer only applied in laboratories but also in real systems. An important example is the use of robots for emergency operations. Elci and Rahnama document recent developments in the field of semantic robotics and use cooperative labyrinth discovery as an example. Each agent is an autonomous complex system and acts on its sensory input. Information is retrieved from other agents. This requires agent ontologies and domain ontologies. Communication is based on semantic web services. The resulting solution is in the conceptual phase, but this chapter gives examples of the use of these robots, which includes traffic support and homeland security. An application-driven solution using the idea of a virtual environment to support and address the problems observed in real-world systems is then introduced. This is in the chapter by Maxwell and Carley. Many real-world systems can only be observed

4

A. Tolk and L.C. Jain

by engineers. Manipulation of the system is too dangerous or otherwise infeasible. Socio-cultural systems cannot be subject to manipulation. The authors use multi-agent simulations to represent heterogeneous populations with the objective to develop policy in an environment suitable for experimentation. Multi-agent simulations are stochastic, and they illuminate significant uncertainties that exist in the environment. The chapter highlights the primary development concerns. It is suitable for use in a wide range of application domains. The last chapter of this book is based on some large-scale applications in support of business information systems. West shows in this contribution that ontology is no longer an academic toy. Serious applications are not only possible, but are already in use. The chapter summarizes best practices available to support the development of business information systems. These focus on the conceptual data modeling phase by introducing an ontological framework. This framework takes spatio-temporal aspects into account, which means that four dimensions need to be captured. The reason why this is important and how it can be applied is demonstrated by real-world examples. The chapter also introduces the underlying theory which is based on data models, set theory, and the use of properties. Every chapter uses references. In addition, all authors submitted contributions to a bibliography – comprising breakthrough and milestone papers as well as good survey review articles on the selected topic – and contributions to a resource list – enumerating resources relevant to the topic, such as websites, software, organizations, etc. These contributions have been compiled into the Bibliography and Resources for Additional Studies. They will support the interested reader in the initiation of further studies on complex systems in knowledge-based environments.

1.3 Overview on Journals, Conferences, and Workshops Although there is no conference or journal on complex systems in knowledge-based environments – at least not yet –, several conferences and journals of interest exist that the interested reader may use keep track of current developments. Table 1.1 enumerates journals and conferences and workshops that may be of interest to a reader of this book. This list can be neither complete nor exclusive. It is a hub enabling further study and contributions of new solutions. Several conference proceedings have significantly contributed to books to establish an initial body of knowledge for system engineering and system of systems engineering utilizing the means of knowledge management and knowledge representation. The reader is referred to the bibliography at the end of this book for examples. As pointed out previously, these contributions are just examples and by no means complete or exclusive. In summary, the eight chapters of this book give an overview of the theory and the best practices applicable to a broad range of challenges encountered when developing or managing complex systems and systems of systems. These systems can be either real or virtual. The use of knowledge representation means, in particular ontology applications, should be paired with engineering methods. They may be required to deal with

An Introduction to Complex Systems in the Knowledge-Based Environment

5

Table 1.1. Selected Journals and Conferences and Workshops and Book Series

Journals

Conferences & Workshops

IEEE Intelligent Systems, IEEE Press, USA

AAAI Conference on Artificial Intelligence

IEEE Transactions on Systems, Man and Cybernetics, Part A, B, C, IEEE Press USA Intelligent Decision Technologies: An International Journal, IOS Press, The Netherlands International Journal of Hybrid Intelligent Systems, IOS Press, The Netherlands

KES International Conference Series

International Journal of Knowledge-Based Intelligent Engineering Systems, IOS Press, The Netherlands Journal of Systems Engineering, Wiley Inter Science

International Conference on Complex Systems (ICCS)

Book Series Advanced Intelligence and Knowledge Processing, Springer-Verlag, Germany Computational Intelligence and its Applications Series, Idea Group Publishing, USA International Series on Natural and Artificial Intelligence, AKI

International Conference on Knowledge Systems Science and Engineering (KSSE) Australian World Wide Web Conferences

Knowledge-Based Intelligent Engineering Systems Series, IOS Press, The Netherlands Advanced Information Processing, SpringerVerlag, Germany

European Conferences on Artificial Intelligence (ECAI)

The CRC Press International Series on Computational Intelligence, The CRC Press, USA

data, processes, requirements, uncertainties, and the many other concerns inherent in real-world applications. It connects all chapters providing support for the student and practitioner in the field. It provides a variety of ideas and recommends best practices. The bibliography and resource list help the interested reader to focus on particular topics.

2 Uncertainty Representation and Reasoning in Complex Systems Kathryn Blackmond Laskey1 and Paulo Cesar G. Costa2 1

Department of Systems Engineering and Operations Research MS 4A5 George Mason University Fairfax, VA 22030-4444, USA 1-703-993-1644 [email protected] 2 Center of Excellence in C4I MSN 4B5 George Mason University Fairfax, VA 22030-4444, USA 1-703-879-6687 [email protected]

Keywords: Uncertainty, probabilistic ontologies, Bayesian inference, plausible reasoning, incomplete information, artificial intelligence.

The rapid expansion of corporate computer networks, the rise of the World Wide Web (WWW), and exploding computational power are some of the most visible innovations shaping our increasingly knowledge-based society. The growing demand for interconnectivity and interoperability gives rise to systems of ever-greater complexity. These include systems of systems, whose subsystems are systems in their own right, often geographically distributed and exhibiting ownership and/or managerial independence. Along with the increasing complexity of systems comes a growing demand for systems that act intelligently and adaptively in response to their environments. There is a need for systems that can process incomplete, uncertain and ambiguous information, and can learn and adapt to environments that require interoperating with other intelligent, adaptive complex systems. The ability to cope with uncertainty is a fundamental characteristic of knowledge systems designed to address real world problems. Therefore, a principled and logically sound methodology for representing and reasoning with uncertainty is a vital requirement for complex systems. Failure to address that need dooms a system to failure, regardless of the resources devoted to its design and development. Bayesian probability theory provides a powerful logical basis for representing uncertainty in knowledge systems, for reasoning under uncertainty, and for learning better representations as new information accrues. This chapter presents methodologies based on Bayesian probability theory that can be applied in the design of complex systems. We begin with Bayesian networks (BNs), a powerful graphical language for representing probabilistic relationships among large numbers of uncertain hypotheses. A. Tolk, L.C. Jain (Eds.): Comp. Sys. in Knowledge-based Environments, SCI 168, pp. 7–39. © Springer-Verlag Berlin Heidelberg 2009 springerlink.com

8

K.B. Laskey and P.C.G. Costa

Bayesian networks have been applied to a wide variety of problems including medical diagnosis, classification systems, multi-sensor fusion, and legal analysis for trials. However, Bayesian networks are insufficiently expressive to cope with many realworld reasoning challenges. For example, a standard Bayesian network can represent the relationship between the type of an object, the object’s features, and sensor reports that provide information about the features, but cannot cope with reports from a large number of sensors reporting on an unknown number of objects, with uncertain associations of reports to objects. Traditional knowledge representation languages based on classical logic are well suited to reasoning about multiple interrelated entities of different types, but until recently have lacked support for reasoning under uncertainty. To address this issue, we introduce Multi-Entity Bayesian Networks (MEBN), which combine the simplicity and inferential power of BNs with the expressive power of First-Order Logic. The last section closes the loop on using Bayesian techniques to complex systems by presenting the concept of a probabilistic ontology and the PROWL language for expressing probabilistic ontologies. Because it is an OWL upper ontology for probabilistic knowledge, PR-OWL ontologies can draw upon other OWL ontologies, and can be processed by OWL-compliant ontology editors and reasoners. Because PR-OWL is based on MEBN, it has all the advantages of a highly expressive Bayesian language, including logical coherency, a built-in learning theory, and efficient inference. The chapter concludes with a discussion of the role of probabilistic ontologies in design of complex systems.

2.1 Bayesian Networks A Bayesian Network is a compact and computationally efficient representation for a joint probability distribution over a potentially large number of interrelated hypotheses. Probabilistic knowledge is represented in the form of a directed graph and a set of local probability distributions. Each node of the graph represents a random variable (RV), or mutually exclusive and collectively exhaustive set of hypotheses. The edges of the graph represent direct dependence relationships. With each node is associated a local distribution, which specifies probabilities for its possible values as a function of the values of its parents. There is a large and growing literature on Bayesian network theory and algorithms (e.g., Charniak 1991; Jensen 2006; Neapolitan 2003; Pearl 1988). Bayesian networks have been applied to represent uncertain knowledge in diverse fields such as medical diagnosis (Spiegelhalter, et al., 1989), image recognition (Booker and Hota 1988), search algorithms (Hansson, and Mayer, 1989), and many others. Heckerman, et al. (1995) provide a comprehensive survey of applications of Bayesian Networks ca. 1995. As a running illustration, we will use the case study presented in Costa (2005), which was based on the popular Paramount series Star Trek™. Our examples have been constructed to be accessible to anyone having some familiarity with space-based science fiction. This example has structural features that are similar to the more down-to-earth problems today’s complex systems are designed to address. A Simple BN Model. Figure 2.1 illustrates the operation of a 24th Century decision support system tasked with helping Captain Picard to assimilate reports, assess their significance, and choose an optimal response. Of course, present-day systems are

2

Uncertainty Representation and Reasoning in Complex Systems

9

Fig. 2.1. Decision Support Systems in the 24th Century

much less sophisticated than the system of Figure 2.1. We therefore begin our exposition by describing a highly simplified problem of detecting enemy starships. In this simplified problem, the main task of a decision system is to detect Romulan starships (here considered as hostile by the United Federation of Planets) and assess the level of danger they bring to our own starship, the Enterprise. Starships other than Romulans are considered either friendly or neutral. Starship detection is performed by the Enterprise’s suite of sensors, which can correctly detect and discriminate starships with an accuracy of 95%. However, Romulan starships may be in “cloak mode,” which would make them invisible to the Enterprise’s sensors. Even for the most current sensor technology, the only hint of a nearby starship in cloak mode is a slight magnetic disturbance caused by the enormous amount of energy required for cloaking. The Enterprise has a magnetic disturbance sensor, but it is very hard to distinguish background magnetic disturbance from that generated by a nearby starship in cloak mode. This simplified situation is modeled by the BN in Figure 2.2, which also considers the characteristics of the zone of space where the action takes place. Each node in our BN has a finite number of mutually exclusive, collectively exhaustive states. The node Zone Nature (Z) is a root node, and its prior probability distribution can be read directly from Figure 2.2 (e.g., 80% for deep space). The probability distribution for Magnetic Disturbance Report (M) depends on the values of its parents Z and Cloak Mode (C). The strength of this influence is quantified via the conditional probability table (CPT) for node M, shown in Table 2.1. Similarly, Operator Species (O) depends on Z, and the two report nodes depend on C and the hypothesis on which they are reporting.

10


Fig. 2.2. The Basic Starship Bayesian Network Table 2.1. Conditional Probability table for node Magnetic Disturbance Report

Zone Nature Deep Space Planetary Systems Black Hole Boundary

Cloak Mode True False True False True False

Magnetic Disturb. Rep. Low 80.0 85.0 20.0 25.0 5.0 6.9

Medium 13.0 10.0 32.0 30.0 10.0 10.6

High 7.0 5.0 48.0 45.0 85.0 82.5

A Bayesian Network provides both an elegant mathematical structure for representing relationships among random variables and a simple visualization of these relationships. For example, from the graph of Figure 2.2, we can see that M depends directly on Z and C, but only indirectly on O. The influence of O operates through C. From this Bayesian network, we can write the following expression for the joint distribution of the five random variables: P(Z,O,C,S,M) = P(Z)P(O|Z)P(C|O)P(S|O,C)P(M|Z,C)

(2.1)

This expression can be used to find the joint probability of a configuration of states of the random variables. In addition to the power of communication, BNs also exploit independence assumptions to simplify specification and inference. To illustrate, consider the BN of Figure 2.2. There are 3×3×2×3×3 = 162 possible configurations of the five existing random variables (the product of the number of states of each of the random variables). To specify a joint distribution for the five random variables, one must specify a probability for each of these configurations, or 162 probabilities in total. One of these can be obtained from the other 161 by applying the constraint that the probabilities must sum to 1. Thus, specifying a general probability distribution requires 161

2


11

independent parameters. In contrast, we can specify the Bayesian network of Figure 2.2 by specifying the local distributions for each of the nodes and combining them according to Equation (2.1). For a root node, we need to specify a single probability distribution; for non-root nodes, we specify a distribution for each configuration of the node’s parents. Each distribution requires one fewer probability than the number of states; the last probability can be obtained from the constraint that probabilities sum to 100%. Thus, the number of independent parameters is 2 for Z; 3×2 for O; 3×1 for C; 6×2 for S and 6×2 for M. Therefore, the number of independent parameters required to specify the BN of Figure 2.2 is the sum of these, or 35. Even for this small BN, this is a considerable reduction in specification burden. For larger networks, the effect is much more dramatic. In general probability models, specification scales exponentially in the number of random variables. In Bayesian networks with a bounded number of states and parents per random variable, specification scales linearly in the number of nodes. For example, consider the BN of Figure 2.5, which models a situation in which the Enterprise encounters four other starships. A general probability distribution for these random variables would require 944,783 parameters, whereas a BN of the structure of Figure 2.5 would require only 182 parameters. For a situation with 10 starships, a general probability distribution requires 3.2x1013 parameters, whereas extending the model of Figure 2.5 to 2.10 starships would require 6,356 parameters. This example demonstrates the power of Bayesian networks to enable parsimonious specification of joint probability distributions over large numbers of interrelated hypotheses. Belief Propagation in BNs. Because a Bayesian network represents a full joint distribution over the random variables it represents, it can be used to reason about how evidence about some random variables affects the probabilities of unobserved random variables. Mathematically, the impact of evidence is assessed by applying Bayes Rule. Suppose T denotes a random variable that is the target of a query – that is, we wish to assess its probability distribution. Let P(T) denote the probability distribution for T. This distribution assigns probability P(T=t) to each of the possible values t for T. Now, suppose we learn that another random variable E has value e. After receiving this evidence, Bayes rule tells us how to obtain a new probability distribution for the target random variable:

P(T = t | E = e) =

P(E = e | T = t)P(T = t) = P(E = e)

P(E = e | T = t)P(T = t) ∑ P(E = e | T = t ')P(T = t ') t'

(2.2) The left-hand side of this equation is the conditional probability that T has value t, given that E has value e. It is called the posterior probability, because it reflects our knowledge about T after receiving the evidence about E. Equation (2.2) shows how to compute the posterior probability distribution for T as a function of the prior probability distribution and the likelihood of the evidence conditional on T. We saw above that specifying a joint probability distribution over many variables is unmanageable in general, but for many interesting classes of problem, specifying a Bayesian network is quite manageable. Similarly, the general task of Bayesian updating is intractable, but efficient inference algorithms make the task tractable for a wide

12


variety of interesting and important applications. Inference algorithms for Bayesian networks exploit the independence relationships encoded in the graph for efficient computation. Some algorithms work by local message passing; others work by efficiently integrating or summing over variables other than the evidence and target variables. Despite the efficiencies achieved by the Bayesian network representation, exact computation becomes intractable for larger and more complex Bayesian networks. A variety of approximation algorithms have been developed. Common approaches include local message passing, efficient integration and/or summation, and stochastic simulation. Many inference methods require specifying in advance which variables will be observed and which will be the target of a query. In contrast, a Bayesian network represents knowledge in the form of a joint distribution, which implies that a mathematically well-defined conditional distribution exists for each random variable given evidence on any of the other random variables. Figure 2.3 shows an example in which evidence about causes is used to predict effects of those causes. In this example, evidence is received about the operator species (Romulan) and the zone nature (deep space). Given this evidence, Bayes rule has been applied to update beliefs for whether the ship is in cloak mode and the contents of the sensor and magnetic disturbance reports. Comparing these results with Figure 2.2, it can be seen that the probability that there is a starship nearby in cloak mode has increased 750% (from 12.2% to 90%), while the chances of a sensor to perceive a Romulan starship (which would be in cloak mode) remained practically unchanged. In this case, the relationships between causes and effects captured by this simple BN indicate that the proximity of a Romulan starship would not induce a major change in the magnetic disturbance report in a deep space zone.

Fig. 2.3. Predicting Observations from State of the World

Figure 2.4 illustrates that Bayesian networks can also be used to reason from evidence about effects to the likely causes of those effects. In this example, the same Bayesian network is used to infer the starship type and zone nature, given evidence about the sensor report (Romulan) and the magnetic disturbance report (high). Notice that although evidence of a high magnetic disturbance report would have increased

2


13

the chances of a Cloak Mode, its impact was easily overcome by that of a sensor report indicating the presence of a Romulan starship, which strongly corroborates the hypothesis that this starship is not in cloak mode. The combination of this conflicting evidence resulted in a decrease in the probability of a starship in cloak mode to less than half of its previous figure (i.e., from 12.2% to 5.1%), while also increasing the probability of a nearby Romulan starship from 12.8% to 65% (a 5 fold increase). This ability to capture the subtleties of even the most complex relationships is a strong point of Bayesian networks.

Fig. 2.4. Inferring State of the World from Observations

Specifying the Structure and Probabilities in BNs. As noted above, specifying a Bayesian network to represent a problem requires defining a set of random variables, a graph to represent conditional dependence relationships, and a local distribution for each random variable that defines its probability distribution as a function of the states of its parents. The task of specification can be performed by eliciting knowledge from domain experts (e.g., Mahoney and Laskey, 2000; Korb and Nicholson, 2003), learning from observations (e.g., Korb and Nicholson, 2003; Neapolitan, 2003), or some combination of expert elicitation and data analysis The problem of specifying a Bayesian network is usually broken into two components – specifying the structure and specifying the parameters. The structure of a Bayesian network consists of the random variables, their possible values, the dependence relationships, and the functional form of the local distributions. The parameters are numerical variables that determine a specific local distribution from a family of local distributions. It has been argued that specifying structure is more natural for experts than specifying parameters (e.g., Pearl, 1988). A robust literature exists on elicitation of numerical probabilities from experts (c.f., Druzdzel and van der Gaag, 2000). When data are plentiful and expertise is scarce, then learning from data is the preferred option. Standard textbook methods and widely available software exist for parameter and structure learning for unconstrained discrete local distributions (c.f., Neapolitan, 2003). However, these methods can provide very imprecise parameter estimates,

14


because when a node has many parent configurations (due to a large number of parents and/or large parent state spaces), there many be very few observations for some parent configurations. This may also result in failure of the learning algorithm to infer dependence relationships that could be found by more powerful methods. For this reason, if local distributions can be defined by specifying a functional form and a few parameters, the resulting estimates may be much more precise. However, this requires much more sophisticated parameter estimation methods, typically implemented as custom software. Limitations of BNs. Although a powerful representation formalism, BNs are not expressive enough for many real-world applications. More specifically, Bayesian Networks assume a simple attribute-value representation – that is, each problem instance involves reasoning about the same fixed number of attributes, with only the evidence values changing from problem instance to problem instance. This type of representation is inadequate for many problems of practical importance. Many domains require reasoning about varying numbers of related entities of different types, where the numbers, types and relationships among entities cannot be specified in advance and may themselves be uncertain. Stretching the expressiveness of BNs. The model depicted above is of limited use in a “real life” starship environment. After all, hostile starships cannot be expected to approach Enterprise one at a time so as to render this simple BN model usable. If four starships were closing in on the Enterprise, we would need to replace the BN of Figure 2.2 with the one shown in Figure 2.5. But even if we had a BN for each possible number of nearby starships, we still would not know which BN to use at any given time, because we cannot know in advance how many starships the Enterprise is going to encounter. In short, BNs lack the expressive power to represent entity types (e.g., starships) that can be instantiated as many times as required for the situation at hand. In spite of its naiveté, let us briefly hold on to the premise that only one starship can be approaching the Enterprise at a time, so that the model of Figure 2.2 is valid.

Fig. 2.5. The BN for Four Starships

2


15

Furthermore, suppose we are traveling in deep space, our sensor report says there is no trace of a nearby starship (i.e., the state of node Sensor Report is Nothing), and we receive a report of a strong magnetic disturbance (i.e., the state of node Magnetic Disturbance Report is High). Table 2.1 shows that the likelihood ratio for a high MDR is 7/5 = 1.4 in favor of a starship in cloak mode. Although this favors a cloaked starship in the vicinity, the evidence is not overwhelming. Repetition is a powerful way to boost the discriminatory power of weak signals. As an example from airport terminal radars, a single pulse reflected from an aircraft usually arrives back to the radar receiver very weakened, making it hard to set apart from background noise. However, a steady sequence of reflected radar pulses is easily distinguishable from background noise. Following the same logic, it is reasonable to assume that an abnormal background disturbance will show random fluctuation, whereas a disturbance caused by a starship in cloak mode would show a characteristic temporal pattern. Thus, when there is a cloaked starship nearby, the magnetic disturbance at any time depends on its previous state. A BN similar to the one in Figure 2.6 could capitalize on this for pattern recognition purposes. Dynamic Bayesian Networks (DBNs) allow nodes to be repeated over time (Murphy 1998). The model of Figure 2.6 has both static and dynamic nodes, and thus is a partially dynamic Bayesian network (PDBN), also known as a temporal Bayesian network (e.g., Takikawa et al. 2001). While DBNs and PDBNs are useful for temporal recursion, a more general recursion capability is needed, as well as a parsimonious syntax for expressing recursive relationships.

Fig. 2.6. BN for One Starship with Temporal Recursion

More expressive languages. The above represents just a glimpse of the issues that confront an engineer attempting to apply Bayesian networks to realistically complex problems. To cope with these and other challenges, a number of languages have appeared that extend the expressiveness of standard BNs in various ways. Examples include include plates (Gilks, et al., 1994; Buntine, 1994; Spiegelhalter, et al. 1996), object-oriented Bayesian networks (Koller and Pfeffer, 1997; Bangsø and Wuillemin,

16


2000; Langseth and Nielsen, 2003), probabilistic relational models (Pfeffer, 2000), relational Bayesian networks (Jaeger, 1997); Bayesian logic programs (Kersting and De Raedt, 2001; De Raedt and Kersting, 2003); and multi-entity Bayesian networks (Laskey, 2007). The expressive power of these languages varies, but all extend the expressivity of Bayesian networks beyond propositional power. As probabilistic languages became increasingly expressive, the need grew for a fuller characterization of their theoretical properties. Different communities appear to be converging around certain fundamental approaches to representing uncertain information about the attributes, behavior, and interrelationships of structured entities (cf., Heckerman et al. 2004). Systems based on first-order logic (FOL) have the ability to represent entities of different types interacting with each other in varied ways. Sowa states that first-order logic “has enough expressive power to define all of mathematics, every digital computer that has ever been built, and the semantics of every version of logic, including itself” (Sowa 2000, page 41). For this reason, FOL has become the de facto standard for logical systems from both a theoretical and practical standpoint. However, systems based on classical first-order logic lack a theoretically principled, widely accepted, logically coherent methodology for reasoning under uncertainty. In classical first-order logic, the most that can be said about a hypothesis that can be neither proven nor disproven is that its truth-value is unknown. Practical reasoning demands more. In our example, the Enterprise crew’s lives depend on the Captain’s assessment of the plausibility of many hypotheses he can neither prove nor disprove. Yet, he also needs first-order logic’s ability to express generalizations about properties of and relationships among entities. In short, he needs a probabilistic logic with first-order expressive power. Multi-Entity Bayesian Networks (MEBN) integrates first-order logic with Bayesian probability theory (Laskey, 2005). MEBN logic can assign probabilities in a logically coherent manner to any set of sentences in first-order logic, and can assign a conditional probability distribution given any consistent set of finitely many firstorder sentences. That is, anything that can be expressed in first-order logic can be assigned a probability by MEBN logic. Achieving full first-order expressive power in a Bayesian logic is non-trivial. This requires the ability to represent an unbounded or possibly infinite number of random variables, some of which may have an unbounded or possibly infinite number of possible values. We also need to be able to represent recursive definitions and random variables that may have an unbounded or possibly infinite number of parents. Random variables taking values in uncountable sets such as the real numbers present additional difficulties. The next section presents how MEBN addresses these issues and can be used as the logical underpinning of the Enterprise’s complex decision system.

2.2 MEBN Like present-day Earth, 24th Century outer space is not a politically trivial environment. Our first extension introduces different alien species with diverse profiles. Although MEBN logic can represent the full range of species inhabiting the Universe in the 24th century, for purposes of this paper we prefer to use a simpler model. We

2


17

therefore limit the explicitly modeled species to Friends1, Cardassians, Romulans, and Klingons while addressing encounters with other possible races using the general label Unknown. Cardassians are constantly at war with the Federation, so any encounter with them is considered a hostile event. Fortunately, they do not possess cloaking technology, which makes it easier to detect and discriminate them. Romulans are more ambiguous, behaving in a hostile manner in roughly half their encounters with Federation starships. Klingons, who also possess cloaking technology, have a peace agreement with the United Federation of Planets, but their treacherous and aggressive behavior makes them less reliable than friends. Finally, when facing an unknown species, the historical log of such events shows that out of every ten new encounters, only one was hostile. Apart from the species of its operators, a truly “realistic” model would consider each starship’s type, offensive power, the ability of inflict harm to the Enterprise given its range, and numerous other features pertinent to the model’s purpose. We will address these issues as we present the basic constructs of MEBN logic. Understanding MFrags. MEBN logic represents the world as comprised of entities that have attributes and are related to other entities. Random variables represent features of entities and relationships among entities. Knowledge about attributes and relationships is expressed as a collection of MEBN fragments (MFrags) organized into MEBN Theories (MTheories). An MFrag represents a conditional probability distribution for instances of its resident RVs given their parents in the fragment graph and the context nodes. An MTheory is a set of MFrags that collectively satisfies consistency constraints ensuring the existence of a unique joint probability distribution over instances of the RVs represented in each of the MFrags within the set. Like a BN, an MFrag contains nodes, which represent RVs, arranged in a directed graph whose edges represent direct dependence relationships. An isolated MFrag can be roughly compared with a standard BN with known values for its root nodes and known local distributions for its non-root nodes. For example, the MFrag of Figure 2.7 represents knowledge about the degree of danger to which our own starship is exposed. The fragment graph has seven nodes. The four nodes at the top of the figure are context nodes; the two darker nodes below the context nodes are the input nodes; and the bottom node is a resident node. A node in an MFrag may have a parenthesized list of arguments. These arguments are placeholders for entities in the domain. For example, the argument st to HarmPotential(st, t) is a placeholder for an entity that might harm us, while the argument t is a placeholder for the time step this instance represents. To refer to an actual entity in the domain, the argument is replaced with a unique identifier. By convention, unique identifiers begin with an exclamation point, and no two distinct entities can have the same unique identifier. By substituting unique identifiers for a RV’s arguments, we can make instances of the RV. For example, HarmPotential(!ST1, !T1) and HarmPotential(!ST2, !T1) are two instances of HarmPotential(st, t) that both occur in the time step !T1. 1

The interest reader can find further information on the Star Trek series in a plethora of websites dedicated to preserve or to extend the history of series, such as www.startrek.com, www.ex-astris-scientia.org, or techspecs.acalltoduty.com.

18


Fig. 2.7. The DangerToSelf MFrag

The resident nodes of an MFrag have local distributions that define how their probabilities depend on the values of their parents in the fragment graph. In a complete MTheory, each random variable has exactly one home MFrag, where its local distribution is defined.2 Input and context nodes (e.g., OpSpec(st) or IsOwnStarship(s)) influence the distribution of the resident nodes, but their distributions are defined in their own home MFrags. Context nodes represent conditions that must be satisfied for the influences and local distributions of the fragment graph to apply. Context nodes are Boolean nodes: that is, they may have value True, False, or Absurd.3 Context nodes having value True are said to be satisfied. As an example, if we substitute the unique identifier for the Enterprise (i.e., !ST0) for the variable s in IsOwnStarship(s), the resulting hypothesis will be true. If, instead, we substitute a different starship unique identifier (say, !ST1), then this hypothesis will be false. Finally, if we substitute the unique identifier of a non-starship (say, !Z1), then this statement is absurd (i.e., it is absurd to ask whether or not a zone in space is one’s own starship). To avoid cluttering the fragment graph, we do not show the states of context nodes as we do with input and resident nodes, because they are Boolean nodes whose values are relevant only for deciding whether to use a resident random variable’s local distribution or its default distribution. No probability values are shown for the states of the nodes of the fragment graph in Figure 2.7. This is because nodes in a fragment graph do not represent individual random variables with well-defined probability distributions. Instead, a node in an MFrag represents a generic class of random variables. To draw inferences or declare evidence, we must create instances of the random variable classes. 2

Although standard MEBN logic does not support polymorphism, it could be extended to a typed polymorphic version that would permit a random variable to be resident in more than one MFrag. 3 State names in this paper are alphanumeric strings beginning with a letter, including True and False. However, Laskey (2005) uses the symbols T for True, F for False, and ⊥ for Absurd, and requires other state names to begin with an exclamation point (because they are unique identifiers).

2


19

To find the probability distribution for an instance of DangerToSelf(s, t), we first identify all instances of HarmPotential(st, t) and OpSpec(st) for which the context constraints are satisfied. If there are none, we use the default distribution that assigns value Absurd with probability 1. Otherwise, to complete the definition of the MFrag of Figure 2.7, we must specify a local distribution for its lone resident node, DangerToSelf(s, t). The pseudo-code of Figure 2.7 defines a local distribution for the danger to a starship due to all starships that influence its danger level. Local distributions in standard BNs are typically represented by static tables, which limits each node to a fixed number of parents. On the other hand, an instance of a node in an MTheory might have any number of parents. Thus, MEBN implementations (i.e., languages based on MEBN logic) must provide an expressive language for defining local distributions. We use pseudo-code to convey the idea of using local expressions to specify probability distributions, while not committing to a particular syntax. Lines 3 to 5 cover the case in which there is at least one nearby starship operated by Cardassians and having the ability to harm the Enterprise. In this uncomfortable situation for our starship, the probability of an unacceptable danger to self is 0.90 plus the minimum of 0.10 and the result of multiplying 0.025 by the total number of starships that are harmful and operated by Cardassians. Also the remaining belief (i.e., the difference between 100% and the belief in state Unacceptable is divided between High (80% of the remainder) and Medium (20% of the remainder) whereas belief in Low is zero. The remaining lines use similar formulas to cover the other possible configurations in which there exist starships with potential to harm Enterprise (i.e., HarmPotential(st, t) = True). The last conditional statement of the local expression covers the case in which no nearby starships can inflict harm upon the Enterprise (i.e., all nodes HarmPotential (st, t) have value False). In this case, the value for DangerToSelf(s, t) is Low with probability 1. Figure 2.8 depicts an instantiation of the Danger To Self MFrag for which we have four starships nearby, three of them operated by Cardassians and one by the Romulans. Also, the Romulan and two of the Cardassian starships are within a range at which they can harm the Enterprise, whereas the other Cardassian starship is too far away to inflict any harm. Following the procedure described in Figure 2.7, the belief for state Unacceptable is .975 (.90 + .025*3) and the beliefs for states High, Medium, and Low are .02 ((1.975)*.8), .005 ((1-.975)*.2), and zero respectively. In short, the pseudo-code covers all possible input node configurations by linking the danger level to the number of nearby starships that have the potential to harm our own starship. The formulas state that if there are any Cardassians nearby, then the distribution for danger level given the number of Cardassians will be: 1 Cardassian ship - [0.925, 0.024, 0.006, 0]; 2 Cardassian ships - [0.99, 0.008, 0.002, 0]; 3 Cardassian ships - [0.975, 0.2, 0.05, 0]; 4 or more Cardassian ships - [1, 0, 0, 0]

20


Fig. 2.8. An Instance of the DangerToSelf MFrag

Also, if there are only Romulans with HarmPot(s) = True, then the distribution becomes: 1 Romulan ship - [.73, .162, .081, .027]; 2 Romulan ships - [.76, .144, .072, .024]; ... 10 or more Romulan ships - [1, 0, 0, 0]

,

For a situation in which only starships operated by unknown species can harm Enterprise, the probability distribution is more evenly distributed: 1 Unknown ship - [.02, .48, .48, .02]; 2 Unknown ships - [.04, .46, .46, .04]; ... , 10 or more Unknown ships - [.20, .30, .30, .20] Finally, if there are only friendly starships nearby with the ability to harm the Enterprise, then the distribution becomes [0, 0, 0.01, .99]. The last line indicates that if that no starship can harm the Enterprise, then the danger level will be Low for sure. As noted previously, a powerful representational formalism is needed to represent complex scenarios at a reasonable level of fidelity. In our example, we could have added additional detail and explored many nuances. For example, a large number of nearby Romulan ships might indicate a coordinated attack and therefore indicate greater danger than an isolated Cardassian ship. Our example was purposely kept simple in order to clarify the basic capabilities of the logic. It is clear that more complex knowledge patterns could be accommodated as needed to suit the requirements of the application. MEBN logic has built-in logical MFrags that provide the ability to express anything that can be expressed in first-order logic. Laskey (2005) proves that MEBN logic can implicitly express a probability distribution over interpretations of any consistent, finitely axiomatizable first-order theory. This provides MEBN with sufficient expressive power to represent virtually any scientific hypothesis.

2


21

Fig. 2.9. The Zone MFrag

Recursive MFrags. One of the main limitations of BNs is their lack of support for recursion. Extensions such as dynamic Bayesian networks provide the ability to define certain kinds of recursive relationships. MEBN provides theoretically grounded support for very general recursive definitions of local distributions. Figure 2.9 depicts an example of how an MFrag can represent temporal recursion. As we can see from the context nodes, in order for the local distribution to apply, z has to be a zone and st has to be a starship that has z as its current position. In addition, tprev and t must be TimeStep entities, and tprev is the step preceding t. Other varieties of recursion can also be represented in MEBN logic by means of MFrags that allow influences between instances of the same random variable. Allowable recursive definitions must ensure that no random variable instance can influence its own probability distribution. As in non-recursive MFrags, the input nodes in a recursive MFrag include nodes whose local distributions are defined in another MFrag (i.e., CloakMode(st)). In addition, the input nodes may include instances of recursively-defined nodes in the MFrag itself. For example, the input node ZoneMD(z, tprev) represents the magnetic disturbance in zone z at the previous time step, which influences the current magnetic disturbance ZoneMD(z, t). The recursion is grounded by specifying an initial distribution at time !T0 that does not depend on a previous magnetic disturbance. Figure 2.10 illustrates how recursive definitions can be applied to construct a situation-specific Bayesian Network (SSBN) to answer a query. Our query concerns the magnetic disturbance at time !T3 in zone !Z0, where !Z0 is known to contain our own uncloaked starship !ST0 and exactly one other starship !ST1, which is known to be cloaked. To build the graph shown in this picture, we begin by creating an instance of the home MFrag of the query node ZoneMD(!Z0,!T3). That is, we substitute !Z0 for z and !T3 for t, and then create all instances of the remaining random variables that meet the context constraints. Next, we build any CPTs we can already build. CPTs for ZoneMD(!Z0,!T3), ZoneNature(!Z0), ZoneEShips(!Z0), and ZoneFShips(!Z0) can be constructed because they are resident in the retrieved MFrag. Single-valued CPTs for CloakMode(!ST0), CloakMode(!ST1), and !T3=!T0 can be specified because the values of these random variables are known.

22


This leaves us with one node, ZoneMD(!Z0,!T2), for which we have no CPT. To construct its CPT, we must retrieve its home MFrag, and instantiate any random variables that meet its context constraints and have not already been instantiated. The new random variables created in this step are ZoneMD(!Z0,!T1) and !T2=!T0. We know the value of the latter, and we retrieve the home MFrag of the former. This process continues until we have added all the nodes of Figure 2.10. At this point we can construct CPTs for all random variables, and the SSBN is complete.4 The MFrag depicted in Figure 2.9 defines the local distribution that applies to all these instances, even though for brevity we only displayed the probability distributions (local and default) for node ZoneMD(z, t). Note that when there is no starship with cloak mode activated, the probability distribution for magnetic disturbance given the zone nature does not change with time. When there is at least one starship with cloak mode activated, then the magnetic disturbance tends to fluctuate regularly with time in the manner described by the local expression. For the sake of simplicity, we assumed that the local distribution depends only on whether there is a cloaked starship nearby.

Fig. 2.10. SSBN Constructed from Zone MFrag 4

For efficiency reasons, most knowledge-based model construction systems would not explicitly represent root evidence nodes such as CloakMode(!ST0) or !T1=!T0 or barren nodes such as ZoneFShips(!Z0) and ZoneFShips(!Z0). For expository purposes, we have taken the logically equivalent, although less computationally efficient, approach of including all these nodes explicitly.

2


23

We also assumed that the initial distribution for the magnetic disturbance when there are cloaked starships is equal to the stationary distribution given the zone nature and the number of cloaked starships present initially. Of course, it would be possible to write different local expressions expressing a dependence on the number of starships, their size, their distance from the Enterprise, etc. MFrags provide a flexible means to represent knowledge about specific subjects within the domain of discourse, but the true gain in expressive power is revealed when we aggregate these “knowledge patterns” to form a coherent model of the domain of discourse that can be instantiated to reason about specific situations and refined through learning. It is important to note that just collecting a set MFrags that represent specific parts of a domain is not enough to ensure a coherent representation of that domain. For example, it would be easy to specify a set of MFrags with cyclic influences, or one having multiple conflicting distributions for a random variable in different MFrags. The following section describes how to define complete and coherent domain models as collections of MFrags. Building MEBN models with MTheories. In order to build a coherent model we have to make sure that our set of MFrags collectively satisfies consistency constraints ensuring the existence of a unique joint probability distribution over instances of the random variables mentioned in the MFrags. Such a coherent collection of MFrags is called an MTheory. An MTheory represents a joint probability distribution for an unbounded, possibly infinite number of instances of its random variables. This joint distribution is specified by the local and default distributions within each MFrag together with the conditional independence relationships implied by the fragment graphs. The MFrags described above are part of a generative MTheory for the intergalactic conflict domain. A generative MTheory summarizes statistical regularities that characterize a domain. These regularities are captured and encoded in a knowledge base using some combination of expert judgment and learning from observation. To apply a generative MTheory to reason about particular scenarios, we need to provide the system with specific information about the individual entity instances involved in the scenario. On receipt of this information, we can use Bayesian inference both to answer specific questions of interest (e.g., how high is the current level of danger to the Enterprise?) and to refine the MTheory (e.g., each encounter with a new species gives us additional statistical data about the level of danger to the Enterprise from a starship operated by an unknown species). Bayesian inference is used to perform both problem-specific inference and learning in a sound, logically coherent manner. Findings are the basic mechanism for incorporating observations into MTheories. A finding is represented as a special 2-node MFrag containing a node from the generative MTheory and a node declaring one of its states to have a given value. From a logical point of view, inserting a finding into an MTheory corresponds to asserting a new axiom in a first-order theory. In other words, MEBN logic is inherently open, having the ability to incorporate new axioms as evidence and update the probabilities of all random variables in a logically consistent way. In addition to the requirement that each random variable must have a unique home MFrag, a valid MTheory must ensure that all recursive definitions terminate in finitely many steps and contain no circular influences. Finally, as we saw above, random variable instances may have a large, and possibly unbounded number of parents.

24


A valid MTheory must satisfy an additional condition to ensure that the local distributions have reasonable limiting behavior as more and more parents are added. Laskey (2005) proved that when an MTheory satisfies these conditions (as well as other technical conditions that are unimportant to our example), then there exists a joint probability distribution on the set of instances of its random variables that is consistent with the local distributions assigned within its MFrags. Furthermore, any consistent, finitely axiomatizable FOL theory can be translated to infinitely many MTheories, all having the same purely logical consequences, that assign different probabilities to statements whose truth-value is not determined by the axioms of the FOL theory. MEBN logic contains a set of built-in logical MFrags (including quantifier, indirect reference, and Boolean connective MFrags) that provide the ability to represent any sentence in first-order logic. If the MTheory satisfies additional conditions, then a conditional distribution exists given any finite sequence of findings that does not logically contradict the logical constraints of the generative MTheory. MEBN logic thus provides a logical foundation for systems that reason in an open world and incorporate observed evidence in a mathematically sound, logically coherent manner.

Fig. 2.11. The Star Trek Generative MTheory

Figure 2.11 shows an example of a generative MTheory for our Star Trek domain. For the sake of conciseness, the local distribution formulas and the default distributions are not shown here. The Entity Type, at the right side of Figure 2.11, is meant to formally declare the possible types of entity that can be found in the model. This is a generic MFrag that allows the creation of domain-oriented types (which are represented by TypeLabel entities) and forms the basis for a Typed system. In our simple model we did not address the creation or the explicit support for entity types. Standard MEBN logic as defined in Laskey (2005) is untyped, meaning that a knowledge engineer who wishes to represent types must explicitly define the necessary logical machinery. The Entity Type MFrag of Figure 2.11 defines an extremely simple kind of type structure. MEBN can be extended with MFrags to accommodate any flavor of typed system, including more complex capabilities such as sub-typing, polymorphism, multiple-inheritance, etc.

2


25

Fig. 2.12. Equivalent MFrag Representations of Knowledge

It is important to understand the power and flexibility that MEBN logic gives to knowledge base designers by allowing multiple, equivalent ways of portraying the same knowledge. Indeed, the generative MTheory of Figure 2.11 is just one of the many possible (consistent) sets of MFrags that can be used to represent a given joint distribution. There, we attempted to cluster the random variables in a way that naturally reflects the structure of the objects in that scenario (i.e., we adopted an object oriented approach to modeling), but this was only one design option among the many allowed by the logic. As an example of such flexibility, Figure 2.12 depicts the same knowledge contained in the Starship MFrag of Figure 2.11 (right side) using three different MFrags. In this case, the modeler might have opted for decomposing an MFrag in order to get the extra flexibility of smaller, more specific MFrags that can be combined in different ways. Another knowledge engineer might prefer the more concise approach of having all knowledge in just one MFrag. Ultimately, the approach to be taken when building an MTheory will depend on many factors, including the model’s purpose, the background and preferences of the model’s stakeholders, the need to interface with external systems, etc. First Order Logic (or one of its subsets) provides the theoretical foundation for the type systems used in popular object-oriented and relational languages. MEBN logic provides the basis for extending the capability of these systems by introducing a sound mathematical basis for representing and reasoning under uncertainty. Among the advantages of a MEBN-based typed system is the ability to represent type uncertainty. As an example, suppose we had two different types of space traveling entities, starships and comets, and we are not sure about the type of a given entity. In this case, the result of a query that depends on the entity type will be a weighted average of the result given that the entity is a comet and the result given that it is a starship. Further advantages of a MEBN-based type system include the ability to refine type-specific probability distributions using Bayesian learning, assign probabilities to possible

26


values of unknown attributes, reason coherently at multiple levels of resolution, and other features related to representing and reasoning with incomplete and/or uncertain information. Another powerful aspect of MEBN, the ability to support finite or countably infinite recursion, is illustrated in the Sensor Report and Zone MFrags, both of which involve temporal recursion. The Time Step MFrag includes a formal specification of the local distribution for the initial step of the time recursion (i.e., when t=!T0) and of its recursive steps (i.e., when t does not refer to the initial step). Other kinds of recursion can be represented in a similar manner. MEBN logic also has the ability to represent and reason about hypothetical entities. Uncertainty about whether a hypothesized entity actually exists is called existence uncertainty. In our example model, the random variable Exists(st) is used to reason about whether its argument is an actual starship. For example, we might be unsure whether a sensor report corresponds to one of the starships we already know about, a starship of which we were previously unaware, or a spurious sensor report. In this case, we can create a starship instance, say !ST4, and assign a probability of less than 1.0 that Exists(!ST4) has value True. Then, any queries involving !ST4 will return results weighted appropriately by our belief in the existence of !ST4. Furthermore, our belief in Exists(!ST4) is updated by Bayesian conditioning as we obtain more evidence relevant to whether !ST4 denotes a previously unknown starship. Representing existence uncertainty is particularly useful for counterfactual reasoning and reasoning about causality (Druzdzel & Simon 1993, Pearl 2000). Because the Star Trek model was designed to demonstrate the capabilities of MEBN logic, we avoided issues that can be handled by the logic but would make the model too complex. As an example, one aspect that our model does not consider is association uncertainty, a very common problem in multi-sensor data fusion systems. Association uncertainty means that we are not sure about the source of a given report (e.g., whether a given report refers to starship !ST4, !ST2 or !ST1). Many weakly discriminatory reports coming from possibly many starships produces an exponential set of combinations that require special hypothesis management methods (c.f., Stone et al. 1999). In the Star Trek model we avoided these problems by assuming our sensor suite can achieve perfect discrimination. However, the logic can represent and reason with association uncertainty, and thus provides a sound logical foundation for hypothesis management in multi-source fusion. Making Decisions with MEBN Logic. Captain Picard has more than an academic interest in the danger from nearby starships. He must make decisions with life and death consequences. Multi-Entity Decision Graphs (MEDGs, or “medges”) extend MEBN logic to support decision making under uncertainty. MEDGs are related to MEBNs in the same way influence diagrams are related to Bayesian Networks. A MEDG can be applied to any problem that involves optimal choice from a set of alternatives subject to given constraints. When a decision MFrag (i.e., one that has decision and utility nodes) is added to a generative MTheory such as the one portrayed in Figure 2.11, the result is a MEDG. As an example, Figure 2.13 depicts a decision MFrag representing Captain Picard’s choice of which defensive action to take. The decision node DefenseAction(s) represents the set of defensive actions available to the Captain (in this case, to fire the

2


27

Fig. 2.13. The Star Trek Decision MFrag

ship’s weapons, to retreat, or to do nothing). The value nodes capture Picard’s objectives, which in this case are to protect Enterprise while also avoiding harm to innocent people as a consequence of his defensive actions. Both objectives depend upon Picard’s decision, while ProtectSelf(s) is influenced by the perceived danger to Enterprise and ProtectOthers(s) is depends on the level of danger to other starships in the vicinity. The model described here is clearly an oversimplification of any “real” scenario a Captain would face. Its purpose is to convey the core idea of extending MEBN logic to support decision-making. Indeed, a more common situation is to have multiple, mutually influencing, often conflicting factors that together form a very complex decision problem, and require trading off different attributes of value. For example, a decision to attack would mean that little power would be left for the defense shields; a retreat would require aborting a very important mission. MEDGs provide the necessary foundation to address all the above issues. Readers familiar with influence diagrams will appreciate that the main concepts required for a first-order extension of decision theory are all present in Figure 2.13. In other words, MEDGs have the same core functionality and characteristics of common MFrags. Thus, the utility table in Survivability(s) refers to the entity whose unique identifier substitutes for the variable s, which according to the context nodes should be our own starship (Enterprise in this case). Likewise, the states of input node DangerToSelf(s, t) and the decision options listed in DefenseAction(s) should also refer to the same entity. Of course, this confers to MEDGs the expressive power of MEBN models, which includes the ability to use this same decision MFrag to model the decision process of the Captain of another starship. Notice that a MEDG Theory should also comply with the same consistency rules of standard MTheories, along with additional rules required for influence diagrams (e.g., value nodes are deterministic and must be leaf nodes or have only value nodes as children). In our example, adding the Star Trek Decision MFrag of Figure 2.13 to the generative MTheory of Figure 2.11 will maintain the consistency of the latter, and therefore the result will be a valid generative MEDG Theory. Our simple example can be extended to more elaborate decision constructions, providing the flexibility to model decision problems in many different applications spanning diverse domains.

28


Inference in MEBN Logic. A generative MTheory provides prior knowledge that can be updated upon receipt of evidence represented as finding MFrags. We now describe the process used to obtain posterior knowledge from a generative MTheory and a set of findings. In a BN model such as the ones shown in Figures 2.2 through 2.6, assessing the impact of new evidence involves conditioning on the values of evidence nodes and applying a belief propagation algorithm. When the algorithm terminates, beliefs of all nodes, including the node(s) of interest, reflect the impact of all evidence entered thus far. This process of entering evidence, propagating beliefs, and inspecting the posterior beliefs of one or more nodes of interest is called a query. MEBN inference works in a similar way (after all, MEBN is a Bayesian logic), but following a more complex yet more flexible process. Whereas BNs are static models that must be changed whenever the situation changes (e.g., number of starships, time recursion, etc.), an MTheory implicitly represents an infinity of possible scenarios. In other words, the MTheory represented in Figure 2.11 (as well as the MEDG obtained by aggregating the MFrag in Figure 2.13) is a model that can be used for as many starships as we want, and for as many time steps we are interested in, for as many situations as we face from the 24th Century into the future. That said, the obvious question is how to perform queries within such a model. A simple example of query processing was given above in the section on temporal recursion. Here, we describe the general algorithm for constructing a situation-specific Bayesian network (SSBN). To do so, we have to have an initial generative MTheory (or MEDG Theory), a Finding set (which conveys particular information about the situation) and a Target set (which indicates the nodes of interest to us). For comparison, let’s suppose we have a situation that is similar to the one in Figure 2.5, where four starships are within the Enterprise’s range. In that particular case, a BN was used to represent the situation at hand, which means we have a model that is “hardwired” to a known number (four) of starships, and any other number would require a different model. A standard Bayesian inference algorithm applied to that model would involve entering the available information about these four starships (i.e., the four sensor reports), propagating the beliefs, and obtaining posterior probabilities for the hypotheses of interest (e.g., the four Starship Type nodes). Similarly, MEBN inference begins when a query is posed to assess the degree of belief in a target random variable given a set of evidence random variables. We start with a generative MTheory, add a set of finding MFrags representing problemspecific information, and specify the target nodes for our query. The first step in MEBN inference is to construct the SSBN, which can be seen as an ordinary Bayesian network constructed by creating and combining instances of the MFrags in the generative MTheory. Next, a standard Bayesian network inference algorithm is applied. Finally, the answer to the query is obtained by inspecting the posterior probabilities of the target nodes. A MEBN inference algorithm is provided in Laskey (2005). The algorithm presented there does not handle decision graphs, and so we will extend it slightly for purposes of illustrating how our MEDG Theory can be used to support the Captain’s decision. In our example, the finding MFrags will convey information that we have five starships (!ST0 through !ST4) and that the first is our own starship. For the sake of illustration, let’s assume that our Finding set also includes data regarding the nature of the

2


29

space zone we are in (!Z0), its magnetic disturbance for the first time step (!T0), and sensor reports for starships !SR1 to !SR4 for the first two time steps. We assume that the Target set for our illustrative query includes an assessment of the level of danger experienced by the Enterprise and the best decision to take given this level of danger. Figure 2.14 shows a situation-specific decision graph for our query5. To construct the decision graph, we begin by creating instances of the random variables in the Target set and the random variables for which we have findings. The target random variables are DangerLevel(!ST0) and DefenseAction(!ST0). The finding random variables are the eight SRDistance nodes (2 time steps for each of four starships) and the two ZoneMD reports (one for each time step). Although each finding MFrag contains two nodes, the random variable on which we have a finding and a node indicating the value to which it is set, we include only the first of these in our situation-specific Bayesian network, and declare as evidence that its value is equal to the observed value indicated in the finding MFrag. The next step is to retrieve and instantiate the home MFrags of the finding and target random variables. When each MFrag is instantiated, instances of its random variables are created to represent known background information, observed evidence, and queries of interest to the decision maker. If there are any random variables with undefined distributions, then the algorithm proceeds by instantiating their respective home MFrags. The process of retrieving and instantiating MFrags continues until there are no remaining random variables having either undefined distributions or unknown values. The result, if this process terminates, is a SSBN or, in our case, a situationspecific decision graph (SSDG). In some cases the SSBN can be infinite, but under conditions given in Laskey (2005), the algorithm produces a sequence of approximate SSBNs for which the posterior distribution of the target nodes converges to their posterior distribution given the findings. Mahoney and Laskey (1998) define a SSBN as a minimal Bayesian network sufficient to compute the response to a query. A SSBN may contain any number of instances of each MFrag, depending on the number of entities and their interrelationships. The SSDG in Figure 2.14 is the result of applying this process to the MEDG Theory in Figures 2.11 and 2.13 with the Finding and Target set we just defined. Another important use for the SSBN algorithm is to help in the task of performing Bayesian learning, which is treated in MEBN logic as a sequence of MTheories. Learning from Data. Learning graphical models from observations is usually decomposed into two sub-problems: inferring the parameters of the local distributions when the structure is known, and inferring the structure itself. In MEBN, by structure we mean the possible values of the random variables, their organization into MFrags, the fragment graphs, and the functional forms of the local distributions. Figure 2.15 shows an example of parameter learning in MEBN logic in which we adopt the assumption that one can infer the length of a starship on the basis of the average length of all starships. This generic domain knowledge is captured by the generative MFrag, which specifies a prior distribution based on what we know about starship lengths. 5

The alert reader may notice that root evidence nodes and barren nodes that were included in the constructed network of Figure 2.10 are not included here. As noted above, explicitly representing these nodes is not necessary.

30


Fig. 2.14. SSBN for the Star Trek MTheory with Four Starships within Enterprise’s Range

One strong point about using Bayesian models in general and MEBN logic in particular is the ability to refine prior knowledge as new information becomes available. In our example, let’s suppose that we receive precise information on the length of starships !ST2, !ST3, and !ST5; but have no information regarding the incoming starship !ST8. The first step of this simple parameter learning example is to enter the available information to the model in the form of findings (see box StarshipLenghInd Findings). Then, we pose a query on the length of !ST8. The SSBN algorithm will instantiate all the random variables that are related to the query at hand until it finishes with the SSBN depicted in Figure 2.15 (box SSBN with Findings). In this example, the MFrags satisfy graph-theoretic conditions under which a re-structuring operation called finding absorption (Buntine 1994b) can be applied without changing the structure of the MFrags. Therefore, the prior distribution of the random variable GlobalAvgLength can be replaced by the posterior distribution obtained when adding evidence in the form of findings. As a result of this learning process, the probability distribution for GlobalAvgLength has been refined in light of the new information conveyed by the findings. The resulting, more precise distribution can now be used not only to predict the length of !ST8 but for future queries as well. In our specific example, the same query would retrieve the SSBN in the lower right corner of Figure 2.15 (box SSBN with Findings Absorbed). One of the major advantages of the finding absorption operation is that it greatly improves the tractability of both learning and SSBN inference. We can also apply finding absorption to modify the generative MFrags themselves, thus creating a new generative MTheory that has the same conditional distribution given its findings as our original MTheory. In this new MTheory, the distribution of GlobalAvgLength has been modified to incorporate the observations and the finding random variables are set with probability 1 to their observed values. Restructuring MTheories via finding absorption can increase the efficiency of SSBN construction and of inference.

2


31

Fig. 2.15. Parameter Learning in MEBN

Structure learning in MEBN works in a similar fashion. As an example, let’s suppose that when analyzing the data that was acquired in the parameter learning process above, a domain expert raises the hypothesis that the length of a given starship might depend on its class. To put it into a “real-life” perspective, let’s consider two classes: Explorers and Warbirds. The first usually are vessels crafted for long distance journeys with a relatively small crew and payload. Warbirds, on the other hand, are heavily armed vessels designed to be flagships of a combatant fleet, usually carrying lots of ammunition, equipped with many advanced technology systems and a large crew. Therefore, our expert thinks it likely that the average length of Warbirds may be greater than the average length of Explorers. In short, the general idea of this simple example is to mimic the more general situation in which we have a potential link between two attributes (i.e., starship length and class) but at best weak evidence to support the hypothesized correlation. This is a typical situation in which Bayesian models can use incoming data to learn both structure and parameters of a domain model. Generally speaking, the solution for this class of situations is to build two different structures and apply Bayesian inference to evaluate which structure is more consistent with the data as it becomes available. The initial setup of the structure learning process for this specific problem is depicted in Figure 2.16. Each of the two possible structures is represented by its own generative MFrag. The first MFrag is the same as before: the length of a starship depended only on a global average length that applied to starships of all classes. The upper left MFrag of Figure 2.16, StarshipLengthInd MFrag conveys this hypothesis. The second possible structure, represented by the ClassAvgLength and StarshipLengthDep MFrags, covers the case in which a starship class influences its length. The two structures are then connected by the Starship Length MFrag, which has the format of a multiplexor MFrag. The distribution of a multiplexor node such as StarshipLength(st) always has one parent selector node defining which of the other parents is influencing the distribution at a given situation. In this example, where we have only two possible structures, the selector parent will be a two-state node. Here, the selector parent is the Boolean LengthDependsOnClass(!Starship). When this node has value False then StarshipLength(cl) will be

32


Fig. 2.16. Structure Learning in MEBN

equal to StarshipLengthInd(st), the distribution of which does not depend on the starship’s class. Conversely, if the selector parent has value True then StarshipLength(cl) will be equal to StarshipLengthDep(st), which is directly influenced by ClassAvgLength(StarshipClass(st)). Figure 2.17 shows the result of applying the SSBN algorithm to the generative MFrags in Figure 2.16. The SSBN on the left doesn’t have the findings included, but only information about the existence of four starships. It can be noted that we choose our prior for the selector parent (the Boolean node on the top of the SSBN) to be the uniform distribution, which means we assumed that both structures (i.e., class affecting length or not) have the same prior probability. For the SSBN in the right side we included the known facts that !ST2 and !ST3 belong to the class of starships !Explorer, and that !ST5 and !ST8 are Warbird vessels. Further, we included the lengths of three ships for which we have length reports. The result of the inference process was not only an estimate of the length of !ST8 but a clear confirmation that the data available strongly supports the hypothesis that the class of a starship directly influences its length.

Fig. 2.17. SSBNs for the Parameter Learning Example

2


33

It may seem cumbersome to define different random variables, StarshipLengthInd and StarshipLengthDep, for each hypothesis about the influences on a starship’s length. As the number of structural hypotheses becomes large, this can become quite unwieldy. Fortunately, we can circumvent this difficulty by introducing a typed version of MEBN and allowing the distributions of random variables to depend on the type of their argument. A detailed presentation of typed MEBN is beyond the scope of this chapter, and the interested reader is directed to Laskey (2007) for further information on the logic.

2.3 Probabilistic Ontologies This section closes the cycle of Bayesian technologies that can be applied to complex systems. We explain the concept of probabilistic ontologies (POs) and introduce PR-OWL, a MEBN reasoner and GUI that can be used to design complex models and save them as a PO, improving its chances of being interoperable, reusable, and extensible. Ontologies. Since its adoption in the field of Information Systems, the term ontology has been given many different definitions. A common underlying assumption is that classical logic would provide the formal foundation for knowledge representation and reasoning. Until recently, theory and methods for representing and reasoning with uncertain and incomplete knowledge have been neglected almost entirely. However, as research on knowledge engineering and applications of ontologies matures, the ubiquity and importance of uncertainty across a wide array of application areas has generated consumer demand for ontology formalisms that can capture uncertainty. Although interest in probabilistic ontologies has been growing, there is as yet no commonly accepted formal definition of the term. Augmenting an ontology to carry numerical and/or structural information about probabilistic relationships is not enough to deem it a probabilistic ontology, as too much information is lost to the lack of a good representational scheme that captures structural constraints and dependencies among probabilities. A true probabilistic ontology must be capable of properly representing those nuances. More formally: Definition 1 (from Costa, 2005): A probabilistic ontology is an explicit, formal knowledge representation that expresses knowledge about a domain of application. This includes: • • • • • • •

Types of entities that exist in the domain; Properties of those entities; Relationships among entities; Processes and events that happen with those entities; Statistical regularities that characterize the domain; Inconclusive, ambiguous, incomplete, unreliable, and dissonant knowledge related to entities of the domain; and Uncertainty about all the above forms of knowledge;

where the term entity refers to any concept (real or fictitious, concrete or abstract) that can be described and reasoned about within the domain of application. Probabilistic Ontologies are used for the purpose of comprehensively describing

34


knowledge about a domain and the uncertainty associated with that knowledge in a principled, structured and sharable way, ideally in a format that can be read and processed by a computer. They also expand the possibilities of standard ontologies by introducing the requirement of a proper representation of the statistical regularities and the uncertain evidence about entities in a domain of application. Probabilistic OWL. PR-OWL was developed as an extension enabling OWL ontologies to represent complex Bayesian probabilistic models in a way that is flexible enough to be used by diverse Bayesian probabilistic tools (e.g., Netica, Hugin, Quiddity*Suite, JavaBayes, etc.) based on different probabilistic technologies (e.g., PRMs, BNs, etc.). More specifically, OWL is an upper ontology for probabilistic systems that can be used as a framework for developing probabilistic ontologies (as defined in above) that are expressive enough to represent even the most complex probabilistic models. DaConta et al. define an upper ontology as a set of integrated ontologies that characterizes a set of basic commonsense knowledge notions (2003, page 230). In PR-OWL, these basic commonsense notions are related to representing uncertainty in a principled way using OWL syntax (itself a specialization of XML syntax), providing a set of constructs that can be employed to build probabilistic ontologies. Figure 2.18 shows the main concepts involved in defining an MTheory in PR-OWL.

Fig. 2.18. Main Elements of PR-OWL

In the diagram, ellipses represent general classes while arrows represent the main relationships between these classes. A probabilistic ontology (PO) has to have at least one individual of class MTheory, which is basically a label linking a group of MFrags that collectively form a valid MTheory. In actual PR-OLW syntax, that link is expressed via the object property hasMFrag (which is the inverse of object property isMFragIn). Individuals of class MFrag are comprised of nodes, which can be resident, input, or context nodes (not shown in the picture). Each individual of class Node is a random variable RV and thus has a mutually comprehensive, collectively exhaustive set of possible states. In PR-OWL, the object property hasPossibleValues links each node with its possible states, which are individuals of class Entity. Finally, random variables (represented by the class Nodes in PR-OWL) have unconditional or conditional probability distributions, which are represented by class ProbabilityDistribution and linked to its respective nodes via the object property hasProbDist. Figure 2.19 depicts the main elements of the PR-OWL language, its subclasses, and the secondary elements necessary for representing an MTheory. The relations necessary to express the complex structure of MEBN probabilistic models using the OWL

2


35

Fig. 2.19. PR-OWL Elements

syntax are also depicted. In addition to (Carvalho et al., 2007) the prospective reader will find more information on the PR-OWL language at http://www.pr-owl.org. At its current stage of development, PR-OWL contains only the basic representation elements that provide a means of representing any MEBN theory. Such a representation could be used by a Bayesian tool (acting as a probabilistic ontology reasoner) to perform inferences to answer queries and/or to learn from newly incoming evidence via Bayesian learning. However, building MFrags in a probabilistic ontology is a manual, error prone, and tedious process. Avoiding errors or inconsistencies requires deep knowledge of the logic and of the data structures of PR-OWL, since the user would have to know all technical terms such as hasPossibleValues, is-NodeFrom, isResidentNodeIn, etc. In an ideal scenario, many of these terms could be omitted and filled automatic by a software application projected to enforce the consistency of a MEBN model. The development of UnBBayes-MEBN, an open source, Java-based application that is currently in alpha phase, is an important step towards this scenario, as it provides both a GUI for building probabilistic ontologies and a reasoner based on the PR-OWL/MEBN framework. UnBBayes-MEBN was designed to allow building POs in an intuitive way without having to rely on a deep knowledge of the PR-OWL specification. Figure 2.20 brings a snapshopt of the UnBBayes-MEBN user interface. In the figure, a click on the “R” icon and another click anywhere in the editing panel will create a resident node, for which a description can be inserted in the text area at the lower left part of the screen. Clicking on the arrow icon would allow one to graphically define the probabilistic relations of that resident node with other nodes, as much as it would be done in current Bayesian packages such as Hugin™. All those actions would result in the

36


software creating the respective PR-OWL tags (syntactic elements that denote particular parts of a PR-OWL ontology) in the background. Probabilistic Ontologies in UnBBayes-MEBN are saved in PR-OWL format (*.owl file), while application-specific data is stored in a text file with the *.ubf extension. UnBBayes-MEBN provides not only a graphical interface for building probabilistic ontologies, but also a probabilistic reasoner that performs plausible inference by applying Bayes theorem to combine background knowledge represented in the knowledge base (KB) with problem-specific evidence. Currently, only simple queries are available, but future releases will include the ability to perform more complex queries. When a query is submitted, the knowledge base is searched for information to answer the query. If the available information does not suffice, then the KB and the generative MTheory are used to construct a BN to answer the query. This process is called Situation Specific Bayesian.

Fig. 2.20. The UnBBayes-MEBN GUI

UnBBayes was designed to allow building POs in an intuitive way without having to rely on a deep knowledge of the PR-OWL specification. In the example, a click on the “R” icon and another click anywhere in the editing panel will create a resident node, for which a description can be inserted in the text area at the lower left part of

2


37

the screen. Clicking on the arrow icon would allow one to graphically define the probabilistic relations of that resident node with other nodes, as much as it would be done in standard Bayesian network tools. The software automatically creates the necessary PR-OWL tags (syntactic elements that denote particular parts of a PR-OWL ontology) in the background. A few performance issues had to be considered in the implementation of UnBBayes-MEBN. As an example, it is possible for the algorithm to reach a context node that cannot be immediately evaluated. This happens when all ordinary variables in the parents set of a resident random variable term do not appear in the resident term itself. In this case, there may be an arbitrary, possibly infinite number of instances of a parent for any given instance of the child. Because this may have a strong impact on the performance of the algorithm, the designed solution involves asking the user for more information. In the current implementation, if one does not provide such information, the algorithm will just halt. Nonetheless, UnBBayes-MEBN provides a convenient tool for building complex MEBN models and save them as PR-OWL probabilistic ontologies. Thus constituting an important step towards the ability to design complex systems with Bayesian technology.

2.4 Conclusion As systems designed to address real world needs are becoming to cross the boundary of complexity that renders deterministic tools less than optimal, the need for proper representation and reasoning with uncertainty is a topic of growing interest. There is a clear trend for requiring systems to be able to deal with incomplete and ambiguous knowledge, and to perform inferences over such knowledge. By providing the best inferential analysis possible with the available data (Occam’s razor), Bayesian theory is a promising approach for complex system’s design. This chapter presented a set of Bayesian tools with a great potential to become the solution of choice for this approach.

References Booker, L.B., Hota, N.: Probabilistic reasoning about ship images. In: Proceedings of the Second Annual Conference on Uncertainty in Artificial Intelligence. Elsevier, New York (1986) Buntine, W.L.: Learning with Graphical Models. Technical Report No. FIA-94-03. NASA Ames Research Center, Artificial Intelligence Research Branch (1994) De Raedt, L., Kersting, K.: Probabilistic Logic Learning. ACM-SIGKDD Explorations: Special Issue on Multi-Relational Data Mining 5(1), 31–48 (2003) Calvanese, D., De Giacomo, G.: Expressive Description Logics. In: Baader, F., Calvanese, D., McGuiness, D., Nardi, D., Patel-Schneider, P. (eds.) The Description Logics Handbook: Theory, Implementation and Applications, ch. 5, 1st edn., pp. 184–225. Cambridge University Press, Cambridge (2003) Charniak, E.: Bayesian Networks without Tears. AI Magazine 12, 50–63 (1991) Costa, P.C.G., Laskey, K.B.: PR-OWL: A Framework for Probabilistic Ontologies. In: Proceedings of the International Conference on Formal Ontology in Information Systems (FOIS 2006), Baltimore, MD, USA, November 9-11 (2006)

38


Costa, P.C.G.: Bayesian Semantics for the Semantic Web. Doctoral dissertation. In: Department of Systems Engineering and Operations Research, p. 312. George Mason University, Fairfax (2005) Druzdzel, M.J., van der Gaag, L.C.: Building Probabilistic Networks: Where do the Numbers Come From - A Guide to the Literature, Guest Editors’ Introduction. IEEE Transactions in Knowledge and Data Engineering 12, 481–486 (2000) Getoor, L., Taskar, B.: Introduction to Statistical Relational Learning. MIT Press, Cambridge (2007) Gilks, W., Thomas, A., Spiegelhalter, D.J.: A language and program for complex Bayesian modeling. The Statistician 43, 169–178 (1994) Hansson, O., Mayer, A.: Heuristic Search as Evidential Reasoning. In: Henrion, M. (ed.) Proceedings of the Fifth Workshop on Uncertainty in Artificial Intelligence (UAI 1989). Elsevier, New York (1989) Heckerman, D., Meek, C., Koller, D.: Probabilistic Models for Relational Data. MSR-TR2004-30. Microsoft Corporation, Redmond (2004) Heckerman, D., Mamdami, A., Wellman, M.P.: Real-World Applications of Bayesian Networks. Communications of the ACM 38(3), 24–30 (1995) Jaeger, M.: Relational Bayesian Networks. In: The 13th Annual Conference on Uncertainty in Artificial Intelligence (UAI 1997), Providence, RI, USA, August 1-3 (1997) Jaeger, M.: Probabilistic role models and the guarded fragment. In: Proceedings IPMU 2004, pp. 235–242 (2006); Extended version in Int. J. Uncertain. Fuzz. 14(1), 43–60 (2006) Jensen, F.V., Nielsen, T.: Bayesian Networks and Decision Graphs, 2nd edn. Springer, Heidelberg (2007) Kersting, K., De Raedt, L.: Adaptive Bayesian Logic Programs. In: Rouveirol, C., Sebag, M. (eds.) ILP 2001. LNCS (LNAI), vol. 2157, p. 104. Springer, Heidelberg (2001) Koller, D., Levy, A.Y., Pfeffer, A.: P-CLASSIC: A Tractable Probabilistic Description Logic. In: The Fourteenth National Conference on Artificial Intelligence (AAAI 1997), Providence, RI, USA, July 27-31 (1997) Koller, D., Pfeffer, A.: Object-Oriented Bayesian Networks. In: The Thirteenth Conference on Uncertainty in Artificial Intelligence (UAI 1997), San Francisco, CA, USA (1997) Kolmogorov, A.N.: Foundations of the Theory of Probability, 2nd edn. Chelsea Publishing Co., New York (1960) (Originally published in 1933) Korb, K.B., Nicholson, A.E.: Bayesian Artificial Intelligence. Chapman and Hall, Boca Raton (2003) Langseth, H., Nielsen, T.: Fusion of Domain Knowledge with Data for Structured Learning in Object-Oriented Domains. Journal of Machine Learning Research 4, 339–368 (2003) Laskey, K.B.: MEBN: A Language for First-Order Bayesian Knowledge Bases. Artificial Intelligence 172(2-3) (2007), http://ite.gmu.edu/~klaskey/papers/Laskey_MEBN_Logic.pdf Laskey, K.B., Costa, P.C.G.: Of Klingons and Starships: Bayesian Logic for the 23rd Century. In: Uncertainty in Artificial Intelligence: Proceedings of the Twenty-first Conference. AUAI Press, Edinburgh (2005) Laskey, K.B., Mahoney, S.M.: Network Fragments: Representing Knowledge for Constructing Probabilistic Models. In: Proceedings of the Thirteenth Conference on Uncertainty in Artificial Intelligence (UAI 1997), Providence, RI, USA (August 1997) Mahoney, S.M., Laskey, K.B.: Network Engineering for Agile Belief Network Models. IEEE Transactions in Knowledge and Data Engineering 12(4), 487–498 (2000) Murphy, K.: Dynamic Bayesian Networks: Representation, Inference and Learning. Computer Science Division, University of California, Berkeley (1998)

2


39

Neapolitan, R.E.: Learning Bayesian Networks. Prentice-Hall, New York (2003) Pearl, J.: Probabilistic Reasoning in Intelligent Systems: Networks of Plausible Inference. Morgan Kaufmann, San Mateo (1988) Pfeffer, A.: Probabilistic Reasoning for Complex Systems. Stanford University, Stanford (2000) Spiegelhalter, D.J., Thomas, A., Best, N.: Computation on Graphical Models. Bayesian Statistics 5, 407–425 (1996) Spiegelhalter, D.J., Franklin, R., Bull, K.: Assessment, criticism, and improvement of imprecise probabilities for a medical expert system. In: Henrion, M. (ed.) Proceedings of the Fifth Conference on Uncertainty in Artificial Intelligence (UAI 1989). Elsevier, New York (1989) Stone, L.D., Barlow, C.A., Corwin, T.L.: Bayesian multiple target tracking. Artech House, Boston (1999) Takikawa, M., d’Ambrosio, B., Wright, E.: Real-time inference with large-scale temporal Bayes nets. In: Breese, J., Koller, D. (eds.) Proceedings of the Seventeenth Conference on Uncertainty in Artificial Intelligence (UAI 2001). Morgan Kaufmann, San Mateo (2001)

3 A Layered Approach to Composition and Interoperation in Complex Systems Andreas Tolk, Saikou Y. Diallo, Robert D. King, and Charles D. Turnitsa Old Dominion University, Norfolk, VA 23529, USA [email protected], [email protected], [email protected], [email protected]

Abstract. This chapter introduces three engineering methods to support the evaluation of composition and interoperation in complex systems. Data engineering deals with conceptualization of entities and their relations. Process engineering deals with conceptualization of functions and behaviors. Constraint engineering deals with valid solution spaces for data and processes. It is shown that all three aspects must be considered and supported by a solution. The Levels of Conceptual Interoperability Model is used as the basis for the engineering methods. Several current solutions to support complex systems in knowledge-based environments are evaluated and compared.

3.1 Introduction Complex systems are defined as systems with many components and multiple nontrivial interconnections. The term system of systems is often used alternatively, in particular when pre-existent systems are composed to provide a new portfolio of functionality. Again, we have multiple systems that are connected via multiple interfaces, often using several alternative means of communications. In the information technology world, services are used to provide functionality to users through a serviceoriented architecture. In this chapter, we are evaluating such complex systems, focusing on man-made (and managed) systems. Two terms often used synonymously but actually referring to two different concepts are interoperation and composition. Interoperation deals with how a complex system works, how the composing elements work with each other, how they are orchestrated to deliver the required functionality to the user, etc. Composition focuses on what components can be integrated into systems and what functionality can be added without creating problems with other components. This chapter describes a layered approach in support of composability and interoperation in complex systems. This approach is neither complete nor exclusive. It is intended to help master students and practitioners in engineering disciplines and information technology to better use means of knowledge management to understand, describe, and manage complex systems in all life cycles. Furthermore, the approach supports evaluation, planning, and execution of integration projects. To this end, the chapter is divided into four sections. In the first section, we will introduce the levels of interoperation between complex systems. Building layered models has been proven to be very successful in order to understand the effects and importance of decisions A. Tolk, L.C. Jain (Eds.): Comp. Sys. in Knowledge-based Environments, SCI 168, pp. 41–74. © Springer-Verlag Berlin Heidelberg 2009 springerlink.com

42

A. Tolk et al.

for the system. From this model, we derive the necessity to align three disciplines in order to understand and manage complex systems: data engineering, process engineering, and constraint engineering. Each discipline will be described respectively in the remaining three sections. The approach presented in this chapter was used to support students and practitioners within several projects conducted in recent years. The applications are in the domain of defense, homeland security, and energy. In all cases, the supported task was twofold: (1) understanding how the current system interoperates, and (2) showing how legacy systems can be migrated to participate in the desired system of systems. Additional examples can be found in (Berstein et al. 2004; Parent and Spaccapietra 1998; Parent and Spaccapietra 2000; Rahm et al. 2004, Tolk and Diallo 2005). The chapter will use the example of a rental company EZ Rental, that has a system to keep track of cars and customers. EZ Rental gets its cars either indirectly from a local dealer A&C, which has a system to monitor cars, customers and parts or directly from CheapCar, a local manufacturer. The manufacturer has a system to record and monitor cars, parts and customers.

3.2 Understanding Interoperation and Composability It may be surprising to some readers that the underlying research is rooted in the discipline of Modeling and Simulation (M&S). However, M&S applications best exhibit the challenges that have to be met when evaluating and managing interoperation and composability tasks in complex systems. The reason is that M&S applications make explicit the various layers of abstraction that are often hidden in other system domains: the conceptualization layer leading to the model, the implementation layer leading to the simulation, and technical questions of the underlying network. Each layer is tightly connected with different aspects of interoperation. We are following the recommendation given by Page and colleagues (Page, Briggs, and Tufarolo 2004), who suggested defining composability as the realm of the model and interoperability as the realm of the software implementation of the model. In addition, their research introduces the notion of integratability when dealing with the hardware and configuration side of connectivity. Following this categorization, we recommend the following distinction when dealing with interoperation: • Integratability contends with the physical/ technical realms of connections between systems, which include hardware and firmware, protocols, networks, etc. • Interoperability contends with the software- and implementation details of interoperations; this includes exchange of data elements via interfaces, the use of middleware, mapping to common information exchange models, etc. • Composability contends with the alignment of issues on the modeling level. The underlying models are purposeful abstractions of reality used for the conceptualization being implemented by the resulting systems. System modeling and architecture approaches, such as summarized in (Buede 1999) and other system engineering books show that a good system architecture is based on a rigid analysis of the underlying requirements, which leads to a conceptualization of necessary actors and processes. This conceptualization drives the architectural artifacts, which are used to build the system based on the available technology. It

3 A Layered Approach to Composition and Interoperation in Complex Systems

43

is also good practice to separate business and application logic from underlying technology. These principles are supported by our approach. On the requirement side, until recently, the support of decision makers often focused on representing data, such as displaying quart charts of available resources over time, etc. However, the advent of intelligent software agents using the Internet introduced a new quality to decision support systems. While early systems were limited to simple situations, the examples given by (Phillips-Wren and Jain 2005) show that state-of-the-art decision support is based on agent-mediated environments. Today, real-time and uncertain decision problems can be supported to manage the decision making process in a highly dynamic and agile sphere. Simple data mining and presentation is no longer sufficient: based on historic data, trend analysis and possible development hypotheses must be developed and compared. This requires a purposeful abstraction of reality and the implementation of the resulting concept to make it executable on computers. These processes are better known as “modeling,” the purposeful abstraction of reality and capturing of assumptions and constraints, and “simulation,” the execution of a model on a computer. In this light, M&S becomes more and more a backbone of operational research coping with highly complex and dynamic environments and decision challenges. Technically as well as operationally, M&S is therefore an emerging discipline. While M&S systems are valuable contributors to the decision makers toolbox, the task of composing them in a meaningful way is everything but trivial. The challenge is not the exchange of data between systems: the technical side is sufficiently dealt with by interoperability standards. In particular web services and other web enabling communication means provide a solid foundation for information exchange. The problem is that the concepts of the underlying models – or the implemented world view captured in the model – need to be aligned as well. In order to be able to apply engineering methods to contribute to a composable solution, several models have been developed and applied. In addition, a machine readable and understandable implementation based on data and metadata is ultimately needed to enable agents to communicate about situations and the applicability of M&S applications. They must share a common universe of discourse in support of the decision maker, which requires a common language rooted in a formal specification of the concepts. A formal specification of a conceptualization, however, is a working definition of a common ontology. This ontology can then be applied to derive conceptually aligned and orchestrated configurations for conceptually composable, technically interoperable, and integrated solutions. The Levels of Conceptual Interoperability Model (LCIM) was developed to support this approach. The LCIM is a model, that represents a hierarchy of capability for representing the meaning (increasingly conceptual in nature, as the model layers are ascended) of information passed between systems, components, or services. It utilizes the experiences made with interoperability models used in the defense domain pointing into the direction that documentation beyond the technical aspects of interoperability are necessary to insure the interoperation of complex systems and systems of systems. The LCIM in the currently used version distinguishes between the following layers: • Level 0: Stand-alone systems have No Interoperability. • Level 1: On the level of Technical Interoperability, a communication protocol exists for exchanging data between participating systems. On this level, a

44

•

•

•

•

•

A. Tolk et al.

communication infrastructure is established allowing the exchange of bits and bytes; the underlying networks and communication protocols are unambiguously defined. Level 2: The Syntactic Interoperability level introduces a common structure to exchange information, i.e., a common data format is applied. On this level, a common protocol to structure data is used; the format of the information exchange is unambiguously defined. At the level of syntactic interoperability, the bit and bytes exchanged can be grouped to form symbols. At this level, systems share a common reference physical data model instance. Level 3: If a common information exchange reference model is used, the level of Semantic Interoperability is reached. On this level, the meaning of data is shared; the content of the information exchange requests are unambiguously defined. Level 4: Pragmatic Interoperability is reached when the interoperating systems are aware of each other’s methods and procedures. In other words, the use of the data – or the context of its application – is understood by the participating systems; the context in which the information is exchanged is unambiguously defined. At this level systems are aware of all the possible groupings of symbols and how those groupings are related. The level of Pragmatic Interoperability implies the awareness and sharing of a common reference logical model. Level 5: As a system operates on data over time, the states of that system changes along with the assumptions and constraints that affect its data interchange. At the Dynamic Interoperability level, interoperating systems are able to comprehend and take advantage of the state changes that occur in the assumptions and constraints that each other are making over time. Simply stated, the effect of the information exchange within the participating systems is unambiguously defined. Dynamic interoperability implies that systems understand how the symbols they exchange are used during run-time. Level 6: Finally, if the conceptual models – i.e. the assumptions and constraints of the “purposeful abstraction of reality” – are aligned, the highest level of interoperability is reached: Conceptual Interoperability. This requires that conceptual models be fully documented based on engineering methods enabling their interpretation and evaluation by other engineers. In other words, we need a “fully specified but implementation independent model” as requested in (Davis and Anderson 2003), and not just a text describing the conceptual idea. At this level, the underlying concepts represented by the symbols are described unambiguously. Systems share a common reference conceptual model that captures the assumptions and constraints of the corresponding real or imaginary object.

The LCIM contributes to composition and interoperation in two important ways. First, it provides a framework for organizing the information concept into distinct, separate, and manageable parts. Second, the LCIM can be used to compare selected – or alternative – protocols, languages, standards, techniques, etc. in terms of their support for each layer. In other words, it can serve as the foundation of a maturity model for both tasks described in his chapter. The last aspect that needs to be mentioned before going into the details of the layered approach to composition and interoperation is the interplay of data, processes, and constraints. Similar observations are well


45

known in the domain of knowledge-based system design, as shown among others by O’Kelly (2006) in recent discussions in expert forums for ontology. In the following section, we will use the LCIM to guide through three necessary engineering disciplines to support the tasks of interoperation and composition for complex systems in knowledge-based environments: data engineering, process engineering, and constraints engineering. In each step, we will add additional artifacts found in knowledge-based environments to gradually increase interoperation and composition in complex systems.

3.3 Applying Data Engineering The process of interoperating heterogeneous systems involves the exchange of data at the physical and logical level. The exchange of physical data or technical interoperability implies solving hardware integration problems to ensure that systems can actually communicate. However, each system has a logical representation of data which usually includes a definition of data elements and their relationships which respect to each other. This metadata needs to be exchanged as well in order to prevent misinterpretations and misrepresentations of data during interoperation. The exchange of logical information including syntax and semantics leads to syntactic and semantic interoperability respectively. This logical representation of data is internal to the system and only makes sense in its environment and internal conditions. As a result, it is important for systems to understand the context in which data exists in order to further avoid variances in representation during interoperation. The exchange of physical and logical data in context leads to pragmatic interoperability. In order to reach pragmatic interoperability an engineering method that systematically captures the interoperation process is necessary. This section introduces the Data Engineering process and discusses the challenges inherent to making systems interoperate at the pragmatic level. As an illustration, the Data Engineering process will be applied to the car businesses use case presented earlier. In the latter part of the section, the authors will introduce a refinement of the Data Engineering called Model Based Data Engineering and discuss its implication for complex systems in knowledge based engineering. 3.3.1 Data Engineering Data Engineering is based upon a simple observation that holds true regardless of the size and complexity of the systems involved. Simply stated, data has a format (structured, unstructured, or semi-structured) and a physical location (text file, relational Database etc…). In order to transition from data exchange to information exchangewhich is the stated goal of semantic interoperability, the meaning of data must also be exchanged (Spaccapietra et al 1992; Parent and Spaccapietra 1998). Since the meaning of data varies depending on the context in which it is used, the context must also be exchanged. The goal of Data Engineering is to discover the format and location of data through a Data Administration process, discover and map similar data elements through a Data Management process, assert the need for model extension and gap elimination through a Data Alignment process and resolve resolution issues through a Data Transformation process. The combination of these four processes enables not

46

A. Tolk et al.

only the transfer of bits and bytes between systems but more importantly, it leads to the transfer of knowledge between systems. The example used in this chapter is taken from a chapter exclusively dealing with model-based data engineering, which we recommend to the interested reader for further studies (Tolk and Diallo 2008). 3.3.1.1 Data Administration Data Administration identifies and manages the information exchange needs between candidate systems. This process focuses first on clearly defining the source system and the target system or the direction of data flow. This is an important step for the future since mapping functions do not always have an inverse. Mathematically speaking, for two sets S1 and S2, any mapping function f has a valid inverse if and only every element of S1 has one and only one counterpart in S2. Simply stated f must be bijective. This is clearly not the case and in fact research shows that while 1:1 mappings do exist, n: m mappings are more prevalent (Parent and Spaccapietra 2000). The issue of complex mapping is addressed in-depth during Data Management. Data Administration also aims at aligning formats and documentation, examining the context of validity of data and asserting the credibility of its sources. A special emphasis is put on format alignment. Format alignment implies that modelers should not only agree on a common format (XML, text file) for data exchange but also that semi-structured and unstructured data be enriched semantically and syntactically. Data administration is the first step to ensuring that systems communicate in a complete and meaningful manner. 3.3.1.2 Data Management The goal of Data Management is to map concepts, data elements and relationships from the source model to the target model. Data Management is the most time consuming and difficult area of Data Engineering. As the literature has shown, mapping can be done either manually or with semi-automated tools. Possible sources of conflict have been studied and classified (Spaccapietra et al. 1992; Parent and Spaccapietra 1998). The emerging consensus is that the manual approach is long and errorprone while tools are not powerful enough yet to act on large and complex systems (Berstein et al. 2004; Seligman et al. 2002; Rahm et al. 2004) To streamline the process, mapping can be decomposed into three distinct sub-processes: • Concept Mapping: This is the inevitable human-in-the-loop aspect of mapping. Experts in both domains (source and target) must agree on concept similarity. At this level, it is important to know if the models have something in common (intersect) and to extract ontologies if possible. Two models intersect if any of their subsets are identical or any of their elements can be derived from one another directly or through a transformation. Two concepts are deemed identical if they represent the same real world view. Parent and Spaccapietra (2000) assert that “if a correspondence can be defined such that it holds for every element in an identifiable set (e.g., the population of a type), the correspondence is stated at the schema level. This intensional definition of a correspondence is called an inter-database correspondence assertion (ICA).” Concept mapping is the listing of all existing ICA. • Attribute mapping: The next logical step is to identify similar attribute. At this level special attention has to be paid to synonyms, homonyms and the inherent context of attributes. Two attributes are said to be equal is they describe the same


47

real world property. It is possible to say for example that an attribute “amount” in a cash register model is the same as the attribute “quantity” in another model if they both refer to “the total number of a product sold to a customer”. As this example shows, attribute mapping cannot be done out of context. If “amount” was referring to “the amount of money given to the cashier” then the correspondence no longer holds. • Content Mapping: Most mapping efforts tend to conglomerate content mapping with attribute mapping. Two values are said to be identical if they can be derived from one another. For example “” is “ + (<state tax>*)”. This example does not say anything about the relationship between the attribute “total price” on one side and the other three attributes on the other side. At the attribute level, equivalence between real world properties is established while the content level deals with how attribute values are derived from one another. The complexity of any mapping effort is directly related to the complexity of these individual components. The amount of effort can be measured by the size of the area of intersection, the similarity in concepts and to a lesser extent the disparity in attributes and the derivability of content. 3.3.1.3 Data Alignment The goal of data alignment is to identify gaps between the source and the target. The focus at this level is to map the non-intersecting areas of the two models by either merging them or introducing a reference model that intersects with the complement. A complete Data Alignment process ensures completeness in mapping and protects the integrity of information exchange. 3.3.1.4 Data Transformation The goal of Data Transformation is to align models in terms of their level of resolution. The assumption that models are expressed at the same level of detail is not true. Furthermore, information that is deemed vital in one model might not hold the same value in another due to disparities in focus, goal and approach between the two. As a result objects need to be aggregated or disaggregated during the mapping process in order to establish correspondences. 3.3.2 Applying Data Engineering to the Example Having described the data engineering process, let’s now apply it to solve the problem described in the example provided earlier in this chapter. 3.3.2.1 Applying Data Administration to the Example In terms of the example provided earlier, Data Administration requires a clear definition of source and target; therefore the team agrees that: • From EZ Rental to A&C Dealerships: For car information the rental company is the source and the dealership is the target. • From A&C Dealership to CheapCar: For customer information, the dealer is the source and the manufacturer is the target.

48

A. Tolk et al.

• From CheapCar to A&C Dealership: For parts information the dealership is the source and the manufacturer is the target. These definitions highlight the fact that source and target identification is not a one time process. The next step during Data Administration is to agree on a common exchange format and perform semantic enrichment to eliminate assumptions embedded within the models. The modeling team decides that XML is the common format that they will use and each model should publish a XML Schema Definition (XSD) encompassing the objects that will be exchanged. The team observes that the dealership and the manufacturer expect string values for their elements while the rental does not specify a type. For the sake of simplify, they agree that any value exchanged will be of type “String”. Each model must add a conversion layer to align its internal type to the agreed type. They further observe that there is a strong possibility of error due to the occurrence of homonyms and synonyms within models and across models. A&C for example has an attribute “Name” for both the “Car” and “Part” element. The dealership refers to the make and model of a car while the rental company has an attribute manufacturer. This begs the question as to whether the manufacturer refers to the make, the model or to both. As a result the team decides to make all of the assumptions and other documentation explicit within the XSD.

Fig. 3.1. XML Schema Definition of the Car Rental Company

Figure 3.1 shows the XSD of the car rental company. It has been augmented with a definition of type, a description of elements and constraints such as unique keys. The manufacturer and the dealer have a similar schema. This XSD shows how XML can be used to better serve the mapping effort. Other models can now use this schema in the Data Management process. It is worth noting that further enhancements are


49

needed in this XSD. The documentation remains a little bit ambiguous (the car type definition does not specify what the enumeration values are for example). 3.3.2.2 Applying Data Management to the Example Data Management is the next logical step in the integration effort discussed in the example. Modelers must focus on identifying and mapping concepts, attributes and content. Let us apply the mapping steps identified earlier. Concept Mapping In this effort, it seems obvious that the concepts of car and parts are identical in both models. However, modelers must decide whether the concept of Dealership is similar to that of Customer. It might be that the manufacturer distinguishes between individual costumers that order online or have specific demands (the information about individual customers might be captured in an “Ind_Orders” object or table for example) and dealerships which are licensed vendors of their products (the “Dealership” object or table). This decision greatly affects the outcome of the integration effort because of the domino effect it has on Attribute and Content Mapping. In this case the decision is that the concepts of Dealership and Customer are related and therefore identical. It turns out that this is the closest possible match because the manufacturer does not take orders directly from individuals. All transactions are done through a dealership. We will see later how this affects the outcome. The concept of Manufacturer is represented as an attribute (Rental Company) in one model and as an object in the other; however, it is clear from the schemas that these are conceptually identical. Attribute Mapping At this level, similar attributes must be identified. Through a good Data Administration process, a close examination of the schemas yields the results presented in tables 3.1, 3.2 and 3.3. The mapping process has to be performed for each interface. Table 3.1 shows that some attributes in the source have an unknown correspondence in the target. We will see how this issue is resolved during Data Alignment. Additionally the figure does not identify how these attributes are related; this is done during content mapping. Table 3.1. Car Attribute Mapping from EZ Rental to A&C EZ Rental Car_ID Type Mileage Manufacturer Manufacturer

A&C Dealership VIN_Number Unknown Unknown Make Model

50

A. Tolk et al. Table 3.2. Customer Attribute Mapping from A&C to CheapCar A&C Dealership Name Location Customer_Type Policy_Number VIN_Number P_Num

CheapCar Manufacturer Name Location Unknown Unknown Car.VIN Parts.Serial_Number

Table 3.3. Parts Attribute Mapping from A&C to CheapCar A&C Dealership Name P_Num Part_Type Make Model

CheapCar Manufacturer Name Serial_Number Type Car_Model Car_Model

Having identified the attributes and their images, the team can now focus on deriving attributes values from the source to the target. Content Mapping The process of content mapping corresponds to generating functions that map the values of attributes to one another. Table 3.4 shows the content mapping between the attributes of a car in the rental model and its counterpart in the dealership model. The functions show that for example the contents of the attribute <Manufacturer> must be decomposed into a make component and a model component and then mapped to <Make> and <Model> respectively. Modelers have to build similar tables for each set of attributes. Table 3.4. Content Mapping of the Car Attributes before Data Alignment EZ Rental

A&C Dealership

Function

car_ID

VIN_Number

Car_ID=VIN_Number

Type

Unknown

Mileage

Unknown

Manufacturer

Make

Manufacturer.Make

Manufacturer

Model

Manufacturer.Model


51

3.3.2.3 Applying Data Alignment to the Example Data Alignment addresses the holes represented by the “Unknown” fields in tables 3.1, 3.2 and 3.4. The recommended approach here is to either extend the target model or simply leave these attributes out because they are not important to the target model. In the car example, the modelers mapping the car concept from EZ Rental to A&C recognize that “type” is an attribute proper to the rental business and therefore decide not to include it in the exchange. The Mileage attribute on the other hand is very important to the dealership because it is a trigger in their decision making process. As a result they agree to extend their model by adding a “mileage” attribute to the car object. Table 3.5 shows the resulting mapping. Table 3.5. Mapping of the Car Attribute after Data Alignment EZ Rental

A&C Dealership

Function

car_ID

VIN_Number

Car_ID = VIN_Number

Mileage

Mileage (extended)

Mileage = Mileage

Manufacturer

Make

Manufacturer.Make

Manufacturer

Model

Manufacturer.Model

3.2.4 Applying Data Transformation to the Example In order to better illustrate Data Transformation, let’s assume that EZ rental decides to add a garage to make small repairs to their cars rather than use the dealership. As a result they would like to order parts from CheapCar directly. They extend their car model by adding a “parts” attribute to it. Let’s also assume that CheapCar has a different model for the parts side of their business and decide that they want to use this model to collect parts information from the rental company. It is obvious that a process of aggregation/disaggregation has to take place between the two systems. 3.3 Model Based Data Engineering Data Engineering presents a series of processes for modelers to use during integration projects in static environments. However, in rapidly changing environments, modelers need the capability to add emerging models without having to start over from scratch. The introduction of a Common Reference Model (CRM) as an integral part of Data engineering leads to Model Based Data Engineering (MBDE). Defining a Data Engineering process is a good step towards the goal of interoperability. In general, solutions derived from a systematic application of the Data Engineering process often lack flexibility and reusability. The traditional approach when integrating heterogeneous models is to create proprietary connecting interfaces. This results in peer-to-peer (P2P) connections that are satisfactory in static environments. However, in this era of rapid communication and globalization, the need to add new models can arise at any moment. Mathematically speaking, federating N models using P2P connections will result in N *( N − 1) ÷ 2 interfaces. In past decades, flexibility and reuse have been

52

A. Tolk et al.

neglected and more effort has been rightly directed at identifying and resolving mapping issues. In order to avoid those same pitfalls, the Data Engineering process must include rules and guidelines addressing these issues. For the solution to be flexible and reusable, the argument has been made (Tolk and Diallo 2005) that implementing Data Engineering must include a CRM. A valid CRM must represent: • Property values: For any model M containing a list of independent enumerated values V1, V2…Vn susceptible of being exchanged, there must be an exhaustive set S of unique enumerated values in the reference model such that SV = { V1,V2…Vn}. SV can be extended as more models are added to the federation. • Properties: For any model M containing a list of independent attributes A1, A2,…, An susceptible of being exchanged, there must be an exhaustive set S of attributes in the reference model such that SA = { A1, A2…An}. SA can be extended as more models are added to the federation. • Propertied Concepts: For real life objects O1, O2…On susceptible of being exchanged, there must be a set S of independent objects in the reference model such that SO = {O1, O2…On}. Objects can be added as new models join the federation • Associated Concepts: For any set of Objects O, linked through a relationship R describing real world concepts C1,C2…Cn susceptible of being exchanged there must be an exhaustive set S of concepts in the reference model such that SC = { C1, C2…Cn} The main advantage of MBDE is the creation of a series of information exchange requirements with a specific input/output data set and format to which all participating models have to abide. It becomes in fact the common language spoken and understood by all members of a federation. In MBDE, models interoperate through the CRM. Each model understands the language of the CRM and can therefore exchange information with any other model. While MBDE moves us one step closer to our ultimate goal of conceptual interoperability, it is important to recognize that a reference model should facilitate the information exchange needs of participating systems and not impose its view of the world on all systems. This means that while the CRM has its structure and its business rules, it must be flexible enough to provide a way for participating systems to fulfill their informational needs. As an analogy let’s look into the computer science world. A computer language such as C++ or java allows all programmers to express themselves by providing constructs that allow one to build complex structures. However nobody is forced to think in a computer language. The computer language is just the environment in which their ideas come to life. Similarly, the CRM is the environment in which systems that wish to interoperate can present their view of the world and learn other world views. With MBDE, systems can exchange information up to the pragmatic level. Even though the context of information exchange cannot be fully specified using MBDE, due to its inability to describe processes, systems can nonetheless fully specify their world view with respect to data. MBDE provides a first step into the pragmatics of information exchange. The pragmatic level is fully attained by applying process engineering to describe the processes that make up the system.


53

3.4 Applying Process Engineering The traditional view for systems engineers to consider information systems is as a number of different states that the system progresses through internally. Within the system, a collection of data items exist and are transformed as the progress from state to state. Processes are acknowledged to exist, but they are considered to be the linkage between states. For our purposes in this chapter, we will consider a state to be a complete snapshot of the system. This is a snapshot of all the data in a temporarily frozen state; using the terms of MBDE, this means that all of the property values of the propertied concepts have a single value from a specific instant in the operational span of the system. The following section intends to show that for complex systems to be interoperable, especially interoperable in the sense that the higher levels (pragmatic and above) of the LCIM describes, then it is important to not only understand and describe the processes of the interoperating systems, but where there are significant differences, that addressing those differences is key to composition. We have seen how, by following the four principles of model based data engineering, how we can accommodate levels of interoperability between complex systems up through the semantic level, and begin to address some of the concerns of the pragmatic level. Even at the levels addressed, within the LCIM, thus far – data is not the only concern. There are also the internal processes of the systems as well as the constraints placed on the system (described further below). Finally, the overall reason for the individual systems, as well as the reason for combining them in a system-of-systems, derives from some organizational or business model. All four of these things must be considered. In figure 3.2 we see that these four elements – data (as represented by model based data engineering), processes (as represented by model based process engineering), organizational/business models, and finally constraints – all affect the level of achievable interoperability. The first three of these vary with the level of influence they exert; the fourth – constraints – remains potentially consistent for all achievable levels of interoperability. Level 6 Conceptual Interoperability

s es oc

ne gi En g

g in er ne gi En

in er

ta Da

Constraints

Pr

nd la na l io de at M o iz an ess rg O usin B

Level 5 Dynamic Interoperability Level 4 Pragmatic Interoperability Level 3 Semantic Interoperability Level 2 Syntactic Interoperability Level 1 Technical Interoperability Level 0 No Interoperability

Fig. 3.2. Incremental Influences on Interoperation

54

A. Tolk et al.

Within a complex system, especially those where the internal activities may be describable but not predictable, understanding the processes (rather than just the data) is increasingly important for the pragmatic and dynamic interoperability for the following reasons. For pragmatic interoperability, the requirement is to understand the system context that the exchanged information between interoperating systems will be placed, once it reaches the target system. Likewise the target system of the exchange must understand the system context out of which the exchanged information came from in the originating system. An additional requirement at the dynamic level of interoperability is to not only have awareness of this context, but to also have awareness of how it will change, dynamically, with the execution of the system. To see what the system context is, for information to be transmitted or received, we have to consider, for a moment, what a system is. By taking the minimalist view that a system consists of data and processes for that data, then the context that the information is in will be not only the state of the system at the moment that context is considered, but also the processes that the data making up the information are involved in at that moment. This leads to a slightly different consideration of the internal workings of the system than is typical in most traditional system representation methods. Considering the early (but effective) methods of flow-charting, state machine diagrams, ladder diagrams – all of these concern themselves with the states of the system, and the connectivity between the states just illustrates the path from one state to another. But the interesting effects on the data, especially from a contextual point of view, occur during the processes that lead the data from state to state. This is where the emphasis must be placed in first understanding context, and then (especially) in having awareness of how that context may change. 3.4.1 Introducing Processes into the Complexity Viewpoint Based on the reasons and descriptions given so far, we see that the observing of and aligning of information concerning the processes of a system is of increasing importance compared with aligning information concerning data in order to achieve levels four (Pragmatic Interoperability) and above, in the LCIM. It then follows that some method for applying engineering methods to a representation of those processes must be possible, in order to enable the interoperability. To get to the ability to apply these engineering methods, first a clear picture of the process of a system must be held, rather than the (in comparison) static states of a system. Typically, the traditional view towards modeling a system is very state oriented, where the various states within the system are highlighted, but the processes whereby the transitions between states take place are reduced to just connections (in the view) between states. In this view (where states and their connections are the emphasis), what is not shown are any details concerning the activities that are part of the transition between states. The procedure of focus on the data from state to state is shown, so that process is implied, but there exists (in this view) no attempt at defining the nature of the process. Some of the questions that a modeler of a system might immediately ask are concerning time, the transformation of data elements, and what the change between states represents. Why would focus in the system change from one state to another? How long would it take to complete this change? What functions might come to bear on the data involved? These details concerning the processes in a system are not answered in the traditional system modeling techniques.


55

By introducing a label to each relationship between states, we now have a reference point to insert attribution to the change between states. We can introduce the information about the process of change that answers some of the questions asked above. It is shown in (Sowa 2002) that a co-emphasis must be placed on considering states of data as well as the processes that transition between states. This co-emphasis (with an increasing share relying on examining and representing processes, when considering the requirements for pragmatic and dynamic interoperability) is what sets the motivation for process engineering (described in the following sections). In order to connect the results of process engineering with data engineering, it is a method of change where one or more propertied concepts have their property values changed. This method of change may have initialization requirements; it will introduce one or more effects (changes in property values) into the system; it may take some amount of time in order to complete; it may be an ongoing process that will have specific halting requirements defined; and it may introduce post-process conditions into the operational flow of the system. These are all required to be made explicit in order to fully identify and define a process. 3.4.2 Process Engineering By following this technique, or any of a number of other modern techniques for describing processes, it is possible to capture some of the attributes of a process. Knowing that this is possible (regardless of the particular technique used) is an important precursor to the next four sections, which introduce the four steps of Process Engineering, roughly corresponding to the four steps of Model Based Data Engineering. 3.4.2.1 Process Cataloging The first step necessary to follow in the engineering of processes for alignment is that of Process Administration. The important goal to achieve during this stage is the cataloging of all the processes within the systems concerned, and an understanding of where, in the operational mode of the system, these processes are to be used. In addition to an enumeration of all the processes for a system, a method for expressing relationally each process to the states between the processes is desired. This will not only give the process engineer the foundation he needs in order to move to the next step (Process Identification), but also begins to provide the context for any data that made provide information for interoperation with other systems. 3.4.2.2 Process Identification Once the Process Cataloging step is completed, the next step in Process Engineering is to provide identity for each of the processes identified in the catalog. By identity, what is meant is a clear description of what the process does, what its resource and time requirements are to successfully complete, and what data it operates on. Some of this information was already described when transitions for Petri nets were introduced, earlier, but that is hardly an exhaustion of the topic. A successful technique for this step would include 1. Process timing (not only how long the process will take, but also when in the operational span of the system the process is able to be enacted); 2. Process initialization requirements (in terms of resources – data and system state);

56

A. Tolk et al.

3. Process effects (which effects are enacted on affected system resources – if data, are attributes or relationships altered? Are new data created? Are previously existing data destroyed?); 4. Process halting requirements (when does the process end – does it continue until there are no longer any resources available? Will it halt after affecting only a certain group of resources? Are these questions answered based on the identity of the process, or are they determined by some subset of the initialization requirements?); 5. Post-process conditions (what effects on the overall system are put into place by the completion of the process? Is the ordering of other processes affected by the completion of this process? Are new states or processes created conditional on this process completed?). A complete enumeration of these five elements (timing, initialization, effects, halting, and post-process conditions) would provide the identity that a complete satisfaction of this step requires. 3.4.2.3 Process Alignment The next step Process Engineering is the alignment of processes. This is the comparison of the information provided in the preceding step for two processes that are part of the exchange of information for interoperability. The simplest level of alignment occurs when the initialization requirements of one process are met, at least partially, by the results of process effects of another process, from another system. In fact, for pragmatic interoperability this is enough – the ability for information derived from the resulting effects of one process to be considered as part of the initialization of another process. What occurs internal to the process of question is not necessarily important for pragmatic interoperability. For dynamic interoperability, it is important to understand the other identity attributes of the processes involved – especially as concerns halting conditions, timing requirements, and post-process conditions. These can all have an effect on the overall state of the operational span of the system in question, and as such, are important to be considered for dynamic interoperability to take place. Where this step in Process Engineering is unable to completely align two different processes, the result of the applying the step should be an understanding of where the two Processes differ. Again, in simplest terms, this could be a simple difference between what results from the Process Effects of the information producing process, and the Process Initialization Requirements of the target process. It is possible that such a difference can be satisfied by applying the steps of Model Based Data Engineering. Other differences can be considerably more profound and complex, and are the subject of the next, and final, step in Process Engineering. 3.4.2.4 Process Transformation In the cases where Process Alignment has identified differences between processes that cannot be handled by the steps of Model Based Data Engineering, then it may be necessary to perform some transformation between the processes in question. In this case, whatever differences are identified between processes are to be considered to see if they can be accommodated by some middle-ware process – a transformation process. In the case that this is possible (or if simpler differences are addressable via MBDE), then a composition of the processes is possible. If the differences between


57

the processes are of such a nature that they cannot be addressed by a transformation, then it is likely that composition of the processes is not possible. The transformation process, if one is both necessary and possible, will appear to connect the two states that exist, post-process in the information producing system, and preprocess in the target system. In both of these respective cases, there are already likely to be post-processes or pre-processes internal to the system, in addition to this new state that branches out to accommodate the system-to-system information exchange. 3.4.3 Process Engineering for Interoperability When systems are to be aligned, for interoperability, and we are working from the premise of defining the systems in terms of not only states, but also the processes that occur between the states, then it becomes necessary to consider the alignment of processes between systems, rather than just the state of data produced by these processes. This is the premise of both the pragmatic and dynamic levels of the LCIM. For pragmatic interoperability, not only is the information exchanged between systems of interest, but knowledge of the context that the information exists within for each system is also of interest. It is because of this requirement for context awareness that process representation begins to become as important, or more important, than data representation (fig. 3.2). In order to be aware of this context, the processes that presented the information must be identified, and also the relationship of those processes to the operational span of the system they belong to. This establishes the context of the information – the process that produced it, and the states and other processes the preceded that production process. In similar terms, the context of the target system should also be made available to the producing system. What process will first operate on the information at the target system once it receives it, and what states and processes preceded that receiving process? By having this knowledge, the system engineer can ensure pragmatic interoperability by addressing the needs of Data Alignment and Data Transformation, so that the data that is to be part of the information exchanged between systems includes any particulars that might be affected either by the context of the system of origin, or the target system. 3.4.4 Applying Process Engineering to the Example Continuing with the example of the earlier portion of the chapter, we will now apply some examples to Process Engineering, which will illustrate the four steps of Model Based Process Engineering. As a background for the examples given, consider the following business (organizational) model. An automobile manufacturer is relying on automated information received from both dedicated (dealership) repair facilities, and automobile rental companies that handle the manufacturer’s brand of product. By aligning not only the information being exchanged between the systems of these three organizations, but also the processes involved, levels of interoperability can be achieved. 3.4.4.1 Example of Process Cataloging The processes belonging to the systems to be made interoperable must be cataloged prior to the other steps being followed. In the case of the example, the process for the automobile manufacturer that sets production levels for parts manufacturing is one

58

A. Tolk et al.

such process – as the goal of this example is to show how this process can be made interoperable with other processes. Similarly, the processes of the automobile rental company dealing with reservations, and the processes of the automobile repair facility dealing with parts ordering are required. Note that even for our simple example shown in table 3.6, this list is not complete – it only exists to serve as a guide. Table 3.6. Example for a Process Catalog

Process Name Part Manufacturing Demand Rental Fulfillment Service Model Manufacturing Demand Part Order Generation

Process Catalog System of Origin Manufacturer Factory Control System Automobile Rental Reservation System Manufacturer Factory Control System Automobile Repair Inventory System

Table 3.7. Example for Process Identification Process Identification for: Part Order Generation The process begins once the database indicates that the number of particular parts on hand have fallen below an “order now” level; the time to execute the process is based on how long it takes the system to generate output, there is no other time consideration. Initialization Requirements There are four initialization requirements that must be observed for this process to begin – first, the parts inventory control process has initiated the check for parts ordering for a particular part number; second, the flag for “automated part ordering” must be set in the database (the flag may be turned off manually or by other processes for any number of operational reasons); third, the part order generation process must be aware of any “parts on hand” values that are below their associated “order now” values; fourth, the particular part whose inventory has fallen below the “order now” value cannot already have a “parts ordered” flag set. Effects of the Process There are two effects of this process having been executed successfully. The first is that a data record is created for a part order, and this data record is both stored internally and sent to the parts manufacturer. The second effect of the process is that the “parts ordered” flag for the particular part that is ordered is set. Halting Requirements The halting requirements for the process are simple, once all of the initialization requirements are satisfied, determining that the process will execute, then if all of the effects of the process are successfully satisfied, the process will halt. Post-Process Conditions Once the process has been successfully executed and halted, then the post-process conditions are this – a data record of a part order has been generated, stored locally, sent to the manufacturer, and the “parts ordered” flag is set. Timing


59

3.4.4.2 Example of Process Identification For each of the processes catalogued, the basic details that define the process must be provided to gain a proper identification of that processes attributes. As an example, we will take the process of Part Order Generation, and provide the basic details that identify the process’s attributes. Note that other processes, not considered here, would take care of checking to be sure the order record is received by the manufacturer, and that the “parts ordered” flag is reset upon the inventory increasing. This is just one example of one process. 3.4.4.3 Example of Process Alignment The step in Process Engineering of process alignment is described by two different examples, one based on a case where pragmatic interoperability is desired, and one based on a case where dynamic interoperability is desired. In the first case, we will look at what is involved in aligning two processes, namely the Rental Fulfillment Service process for an Automobile Rental Company, and the Model Manufacturing Demand Service process for an Automobile Manufacturer. The business model, for the first case, that exists for these two services being interoperable is simple – the Model Manufacturing Demand Service automatically sets the desired production levels for certain automobile models at the manufacturing plant, based on input that indicates the perception for need for those models. One of the sources for that input is the outcome that is produced by the Rental Fulfillment Service process, for an Automobile Rental Company. The assumption here is that the models that are requested more at the rental company are the models that the public has a higher demand for. For pragmatic interoperability (case one), the effects of the originating process – the Rental Fulfillment Service – are aligned so that the data elements that are produced as an effect of the process being run are then considered as data to satisfy the input requirements for the receiving process – the Model Manufacturing Demand Service. It is likely that a transformational process will have to be relied on. For our example, assume that the data that comes out of the Rental Fulfillment Service indicates quantity of each model requested during a certain period. The transformational process would take that data and then compare the data to some assumption based median value, to see if there is more or less than the anticipated demand. If more, then the transformational process would then send data representing a demand for increased manufacturing to the Model Manufacturing Demand Service, for the particular model in question. In the second case, dynamic interoperability, we can use a slight modification of the example already given. Assume that the internal workings of the process are of interest – in other words, the initialization state, the end state, the nature of data transformations, and details about the timing of the process – so that the receiving process can make better use of information it receives. This information is in context, but it also shows the dynamic nature of that context to the receiving system, because it now has specific information about the dynamic context within the originating system. In our example this could be a demand for more information by the Model Manufacturing Demand Service from the Rental Fulfillment Service, so that a specific understanding of the models requested has a deeper meaning. This could be specifics based on the timing of the data, the initialization state of the Rental Fulfillment Service (were only two different models available?), the data transformations (did one incom-

60

A. Tolk et al.

ing transaction produce a multitude of requests for one model for simplicity’s sake, rather than customer opinion?), and so on. This gives a more dynamic picture of the originating systems context for the information being produced by one process for another, and allows for a deeper understanding of the meaning of that context. 3.4.4.4 Example of Process Transformation Transformation between processes leverages what we have already seen from data engineering, and applies it to the exchange of information between processes. In the preceding example (of the Rental Fulfillment Service producing information that can be used by the Model Manufacturing Demand Service), it was shown that a transformational process was relied on to exchange the information. The effects of the originating process produced (among other things such as internal state changes, and resource depletion) information that was useful by the receiving process, but the likelihood of the information being data of the correct resolution, level of aggregation, and appropriately labeled are very low, so a transformation process would have to adjust for those things. In our example case, some modification of resolution of the data is required, to adjust for the raw (high granularity) output of the originating process, to the adjusted and normalized (low granularity) input for the receiving process. Another likely candidate, in our example, for transformation would be aggregation based on different timing issues. If, for instance, the originating process is one that runs for a 168 hour (1 week) period, yet the receiving process is one that is expecting information representing 1 month of operations, then there must be some time aggregation applied to the data. So far, we have seen how data engineering (and MBDE in particular) is key in aligning the data elements that have to be produced, and how these techniques can provide for the majority of interoperability needs for complex systems that wish to interoperate at levels up to the Semantic, and perhaps (in a few cases) the Pragmatic levels of interoperability. Based on the information in figure 3.2, it can be shown that the relationship between demand for data engineering, compared to process engineering, is a shifting paradigm, and as the higher levels of interoperability are desired, more reliance on process engineering is crucial. Even as process engineering becomes key, however, at levels such as pragmatic and dynamic interoperability, our definitions of the steps of process engineering, and the example cases given, illustrate how it relies on (in partnership) data engineering. The two are equally important, in shifting levels of responsibility, throughout the range of interoperability. In comparing process engineering to data engineering, it can be seen that by relying on some model based method for achieving the four steps identified as part of process engineering, that a move to MBDE can be achieved. Examples of some approaches that might allow for this are the Model Driven Architecture (specifically relying on the Unified Modeling Language, or UML) (Siegel 2005), or the Business Process Execution Language (Jordan and Evdemon 2007) as techniques to model the processes and apply the four steps to.

3.5 Assumption-Constraint Engineering Combining components into complex systems and into systems of systems requires processing information on several levels. At a minimum, to be integrated successfully


61

components must be described in terms of their inputs, controls, functions and outputs. Successful re-use of system components additionally depends on a capability to index, search for, retrieve, adapt and transform (if necessary) components, not only with respect to their data, but also with respect to the conceptual models that underlie them. A conceptual model always involves a particular viewpoint. This may be the viewpoint of the model developer, system integrator, federation member, verification team member, model results user, and so on. Aligning conceptual models means, ultimately, mediating between these viewpoints. The difficult part in providing conceptual alignment between models is handling assumptions and model constraints to resolve conflicts between domain views. The difficulty of doing so varies. Within a small, specialized community of practitioners, the sharing of a common viewpoint is easier than between a large, diverse group. Robinson (2007) defines conceptual model as, a non-software specific description of the computer simulation model (that will be, is or has been developed), describing the objectives, inputs, outputs, content, assumptions and simplifications of the model. Robinson argues that the conceptual model establishes a common viewpoint that is essential to developing the overall model. Conceptual modeling captures aspects of interoperability that extend beyond data and process definition, specifically addressing understanding the problem, determining the modeling and project objectives, model content (scope and level of detail), and identifying assumptions and simplifications. King and colleagues (2007) make the case that the failure to capture and communicate the details of conceptual modeling decisions is at the root of model interoperation conflicts. Often, design decisions made during implementation become undocumented changes to a conceptual model. As a result, not all aspects of the conceptual model, its specified model, and modeling artifacts of the implementation are captured. Among the reasons why this is so are: • The cost in time and effort to document every modeling decision is prohibitive. Tools to capture design decisions suffer a variety of problems. • The discipline of design decision capture is not widely taught, practiced or enforced in software development projects. • In many domains of discourse, the required ontologies for expressing and reasoning about concepts lack maturity. • Data transformations to facilitate model reuse often introduce undetected model changes. • Application of iterative development paradigms to modeling and simulation can exacerbate these problems. Iterative development paradigms vary considerably in the number and type of iterations involved. Some paradigms, such as Incremental, Spiral and Evolutionary Development, depend on conceptual model refinement. Even so, there is no guarantee that the conceptual model is faithfully updated. Thus, when it becomes time to integrate models at the very least there will be some conflicts between them—owing to the failure to capture conceptual models fully. The effects can range from very benign (and unnoticed) to catastrophic. See Pace (2000) for discussions of the consequences of failures in conceptual modeling as it relates to system architecture. Our research has shown that conceptual interoperability implies the following characteristics in the system solution:

62

A. Tolk et al.

• Unambiguous Meaning - objects, characteristics, processes and concepts require unambiguous meaning. That is, a basis in ontology is critical. Ontology captures knowledge about a domain of interest. Ontology is the model (set of concepts) for the meaning of those terms and thus, ontology thus defines the vocabulary and the meaning of that vocabulary within a domain. By encoding domain knowledge (i.e. its properties, values and concepts), ontology makes it possible to share and to reason about it. Note that unambiguous meaning does not mean that some sort of global “reality” needs to be established. What is needed is a means to describe unambiguously what we mean when we model an object or process. Because meaning comes as much from the viewpoint of the modeler as from the object itself, solving the requirement for unambiguous meaning requires a capability to mediate between different points of view. • Use of a Supportive Framework - The framework borrows heavily from developments in service-oriented architectures (SOA), where business rules are invoked using web services. Selecting among business rules is very much like selecting among model components—but there is an important difference. Current web service practice is done with only textual metadata, not based in ontology. The characteristics of the framework include use of middleware, mediator agents, or another type of ‘glue’ to assemble components within the experimental frame. The glue should be well integrated with tools for managing ontologies (i.e. managing terms, concepts, relationships and process descriptions) in URI-compatible form for web distribution and access using protocols such as RDFS and OWL-DL. The framework should generate alerts as they occur related to mismatches in conceptual models, model parameters, assumptions and constraints. The resolution of potential conflicts may involve human or agent-based decision-making and should be recorded in a URI-compatible form. Thus, framework can recall and present the results of prior resolutions to assist in adjudication. • Functional Composability of Parts – In conceptual linkage, the model parts being joined must internally be functional compositions. Functional composability was introduced by King to better explain certain limiting cases when linking models in complex systems (interaction, evolution of system, infinity of states, transformations that result in information loss, and conceptual model misalignments) (King 2007). When making a functional composition, the outputs of one model become the inputs to another without ambiguity or unintended effect. • Alignment of Modeler’s Intent – modeler’s intent is the intention of the systems developer, stated explicitly or implicitly, that objects and processes be represented in a certain way. Alignment of modeler’s intent extends and builds upon conceptual modeling—it is concerned in identifying and resolving differences between the conceptual models of system components. Alignment of intent requires addressing the constraints and assumptions that underlie the model, system, and environment. The term conceptual linkage was suggested by King (2007) to refer to the application of these four requirements to achieve conceptual interoperability. Additionally, he argued that this list of requirements was not necessarily complete. In the context of this chapter, we will focus on the roles of assumptions and constraints and recommend a collection of best practices.


63

3.5.1 The Role of Assumptions The problem of how assumptions are formulated and handled (or not handled) has received comparatively little research and must be addressed before conceptual interoperability can become a reality. Garlan and colleagues (1995) introduce architectural mismatch that stems from mismatched assumptions a reusable part makes about the structure of the system it is to be part of. They note that these assumptions often conflict with the assumptions of other parts and are almost always implicit, making them extremely difficult to analyze before building a system. They show how an architectural view of the mismatch problem exposes several fundamental challenges for software composition and suggest possible research avenues needed to solve them. They identify four main categories of architectural mismatch: • Assumptions about the nature of the components, including infrastructure, control model and data model assumptions about the way the environment will manipulate data managed by a component. • Assumptions about the nature of the connectors, including protocols and data model assumptions about the kind of data that is communicated. • Assumptions about the global architectural structure, including the topology of the system communications the presence or absence of particular components and connectors. • Assumptions about the construction process. Assumptions should be a fundamental part of every problem solution. A first (and frequently overlooked) step in problem solving is for the analyst to identify the problem’s assumptions. Many assumptions remain hidden and unrecognized until a deliberate effort is made to identify them. Often it is the unrecognized assumption that prevents a good solution. Assumptions are necessary for three reasons: • Assumptions reflect desired values that should be maintained throughout the solution. • Assumptions set limits to the problem and thus provide a framework within which to work. These limits might include constraints of possibility, economics, or some other desired narrowing. • Assumptions simplify the problem and make it more manageable by providing fewer things to consider and solve. A problem with no assumptions is usually too general to handle. 3.5.1.1 Assumptions and Constraints For our purposes, we will define: • • • •

Assumptions are statements, taken for granted, about the components, connectors, architecture or construction process of a system solution. Properties are the characteristics of system elements. Constraints specify required properties. (If something is not required then it is a consideration instead.) Considerations define desired properties. (Desire is relative—if something is desired so strongly that it is required, it is a constraint instead of a consideration.)

64

A. Tolk et al.

Assumptions can be stated explicitly or can be implicit. Assumptions can be direct statements such as a single proposition, a complex combination of propositions, or can even encompass an entire theory (e.g. classical mechanics). Additionally, assumptions can be derived from other assumptions through the application of logic. A constraint is a condition that a solution must satisfy what a data item, a component or a process must or must not be or do. The set of constraints on a system define the set of feasible and valid solutions. Often, constraints are explicitly stated. However, implicit constraints exist and can be derived by considering how the assumptions affect or shape the solution. To illustrate, consider the consequences when one part of the system uses an assumption that matches closely, but not precisely with another. For example, suppose one part-ordering model uses an assumption, “all Ford parts are made only by Ford” while another uses “Ford parts are made by Ford.” In logic, the second could validly conclude that Ford parts could also be made by manufacturers other than Ford. Now suppose that the system is trying to optimize part availability by minimizing transport time and that a third party manufacturer can deliver a generator faster because it is closer. Here is where an assumption can constrain the system. The modeler picks the first model if, perhaps, a restriction for only genuine parts is appropriate. The point is that picking the first model constrains the system to genuine Ford parts. Alternatively, if time is money and replacement parts are satisfactory, the second model is chosen. Thus, the choice of model constrains the system because of the model’s assumptions. It is a rare for an organization to set out all the important assumptions it makes. More typically, those assumptions must be identified from documentation, interviews, and observation. Even when such assumptions are written down explicitly, unstated, implicit assumptions remain to be identified and are evident only upon reflection and study. A domain of discourse can have many explicit and implicit assumptions. A domain expert is someone who understands what the implicit assumptions of the domain are, and who can apply them to constrain a system solution. Comparing assumption lists between components, environments and systems in this manner yields constraints. Hidden constraints are those derived from examination of the system’s implicit assumptions. Although hidden, they are nevertheless valid. History has shown that failure to uncover and resolve hidden constraints sometimes leads to catastrophic failures. input

output

input

f(i)

g(i) (assumed compatible) system

model

Assumption/Constraint List f

Compatible?

Assumption/Constraint List g

Fig. 3.3. Aligning assumption/constraint lists


65

Figure 3.3 is our recommended view of the process of aligning models that highlights the roles played by assumptions and constraints. As shown, the components involved in the process are a model, a description of its inputs and output, a system that the model is being integrated into, and a description of the system input. To simplify the discussion we stipulate that the model output has been syntactically and semantically aligned with system input, and that an ontology exists for both model and system. To determine compatibility, the process creates and compares lists of assumptions and constraints between model and system. This requires a formalism for representing them. 3.5.1.2 Formalism for Representing Assumptions and Constraints It has been shown in (King and Turnitsa 2008) how assumptions are defined, characterized, used – or misused – by modelers. It was also shown how assumptions can be used to identify potential conflicts between domain views. The following presents our recommended definition of assumption or constraint in terms of its component parts (use function, referent, scope, and proposition).

Assumption/Constraint

(useFN referent scope Proposition)

where: useFN describes how the assumption/constraint is used by the model or system (uses | does_not_use | requires | ignores | denies)

referent is the model or system component that the assumption/constraint is about scope is a description of which parts of the system the assumption/constraint refers to (component, system, environment, component-system, etc.)

Proposition is a statement about the referent’s existence, relations, or quality

Fig. 3.4. Assumption/Constraint composed of useFN, referent, scope, and proposition

In figure 3.4, the components are defined as follows: • Use function: The use function describes the role of the assumption/constraint in potentially modifying system behavior. Note that the latter three enumerated terms can establish an assumption’s relevance with respect to a system solution.

66

A. Tolk et al.

• Referent: The referent of an assumption/constraint is the entity to which it refers. A referent can be an object, a model, a process, a data entity, a system, or a property of one of these. When an assumption acts as a constraint, the referent is what is being limited by the assumption. • Scope: Scope is a description of the portions of the overall system to which the assumption/constraint can be applied. • Proposition: The proposition of an assumption/constraint is what it is saying – the statement that it is making. Propositions are not restricted to simple concepts—they may encompass the content expressed by theories, books, and even whole libraries. 3.5.2 A Process to Capture and Align Assumptions and Constraints Using the formalism developed above, the assumptions and constraints that define and shape each system component can be captured and compared to determine their compatibility with each other. To ensure success, the four step process should be performed in collaboration with both a domain expert and an ontology engineer. 3.5.2.1 Capturing Assumptions and Constraints The first step is to capture the assumption and constraint propositions for the model, system and environment. Each proposition begins as a natural language statement about the problem, one or more of its components, or its solution. The objective is to write down what the main concepts are, as this will form the basis of the ontology content. It is not necessary to document absolutely everything, just the things that are known to be within scope or that are important. Several factors will determine how much information is gathered in this step. In the initial stages of system development, few assumptions may have been made and “place holders” may represent model components whose characteristics are nebulous at the start. In later stages of development, and in particular when capturing the assumptions of legacy models and systems, a wide variety of data may be available in the form of design documents—sifting through these to extract only important information may prove challenging. The domain expert will need to pay attention to the difference between core and secondary concepts. Core concepts are those terms (usually nouns) that are central to the model or system—their absence would result in an incomplete description of the domain. Secondary concepts are those that are not central to the domain but that are required to complete the definition of core concepts. Obviously, core concepts should be documented thoroughly whilst secondary concepts need receive only limited detail. 3.5.2.2 Encoding Propositions The output of the first step is a list of propositions expressed in natural language statements. These must be encoded in a knowledge representation language (e.g., OWL-DL or KIF) before they can be used by a software agent such as a description logic reasoner. Each proposition will consist of its axioms and logical assertions that relate it to other concepts and propositions. Since we are building an ontology, this will require, as a minimum, use of an ontology editor or ontology-building tool (e.g., Protégé or SWOOP).


67

The second process step also consists of assigning an assumption function, referent and scope to each proposition in both the model and the system lists. This establishes the relevance and use of each proposition. We recommend a search for existing ontologies to determine if core concepts have already been defined. If an ontology is found, special care should be taken to ensure that the semantic description in the existing ontology matches that desired of the core concepts. As long as there are no conflicting statements, the ontology engineer may wish to consider reusing the existing ontology. It is possible (indeed likely) that some propositions are found that encapsulate others. For example, the use of Newton’s second law encapsulates the concepts of force, mass and acceleration (which depend on the concepts of position and velocity). At this point, the domain expert and ontology engineer have an important trade off to consider, that of complexity vs. computability. The output of this step is list of statements encoded in a knowledge representation language—our list of assumptions and constraints for the component. 3.5.2.3 Comparing Assumption/Constraint Lists The third process step is to perform a comparison of the model and system lists. The task of comparing assumption lists requires a multi-level strategy to be effective. Consider an example of ordering parts for the body shop previously discussed—the user wants to know when the part will be available. Assumptions about transportation time when ordering are presented in table 3.8 for several alternative models. Table 3.8. Assumption function alternatives for modeling transportation time useFN alternatives for model f

Interpretation

uses partOrder component (transport time ∈ availability)

The model of part ordering includes transportation time as a factor in availability

uses partOrder component (transport time ∉ availability)

Transportation time is not an element of availability in the part ordering model

does_not_use partOrder component (transport time *)

The part ordering model does not use transportation time (roughly equivalent but slightly different from that above)

Table 3.9 shows the multi-level strategy for comparing assumption statements about transportation time model f with statements about the system g. An alert indicates an abnormal condition—raising one initiates another layer of detailed processing. Note that the relevance of transportation time as a factor is taken into account. The raising of an alert during the comparison of assumption/constraint lists initiates a second level of processing to determine if a match for a particular proposition exists between the model and system. The method of analogical reasoning (Sowa and Majumdar 2003) can be used to produce a measure of the semantic distance between propositions. Analogical reasoning employs a highly efficient analogy engine that uses

68

A. Tolk et al. Table 3.9. Strategy for assumption list comparisons useFN of model f uses = 1

does_not_use = 0

ignores = i

requires = r

denies = d

Example interpretation uses partOrder * (transport time) The model of part ordering uses transportation time does_not_use partOrder * (transport time) The model of part ordering does not use transportation time ignores partOrder * (transport time) The model of part ordering doesn’t care about transportation time requires partOrder * (transport time) The model of part ordering requires consideration for transportation time denies partOrder * (transport time) The model of part ordering requires that the system not consider transportation time

Matching proposition in system g? f 0 1 0 1

g(uses) 0 – don’t care 0 – not found in g: raise alert 1 – not found in f: raise alert 1 – aligned: no alert

f i r d i r d

g(uses) 0 – don’t care 0 – not found in g: raise alert 0 – not found in g: no alert 1 – don’t care 1 – aligned: no alert 1 – found in g: raise alert

conceptual graphs as the knowledge representation to produce the measure. If the semantic distance is zero, it is said that propositions match and no further processing is needed. For other cases, there is either a partial match, a match in meta-level mappings, or possibly no match at all. Each of these requires adjudication. 3.5.2.4 Adjudication and Resolution of Conflicts The kind of adjudication depends upon the assumption function associated with each proposition and whether the assumption is load bearing (i.e. its negation would lead to significant changes in system operation) or not. The intention is that for load bearing assumptions that are relied upon, or cared about, the adjudication is performed by a human or an agent that supports a human. The results of the adjudication can be stored and recalled at future times to provide precedents to human operators. The results can also be used to train agent-based systems. Our goal in this section was to address a fundamental issue in complex system interoperability and composability, namely that a gap exists between our ability to describe models and to use them. Closing this gap requires a framework for joining models that rests on at least the unambiguous definitions, composable parts, and supportive software and that focuses on aligning modeler’s intent. In particular alignment of modeler’s intent requires comparing assumptions and constraints, which requires a conceptual model. We have presented a formalism for expressing assumptions and a strategy for comparing assumption lists that accounts for relevance. Often it is the unrecognized assumption that prevents a good solution. If the manner in which assumptions are represented and used can be standardized, then it becomes possible to formalize the reference models of entire frameworks of theory. Eventually, semi-autonomous detection of mismatches in conceptual models would become possible—at least with respect to those critical assumptions that a system relies upon.


69

3.6 Summary – The Elusiveness of Conceptual Interoperability We have introduced new artifacts of the knowledge-based environments that are needed to enable and facilitate interoperation and composition in complex systems. We started with model-based data engineering to unambiguously define the information exchange requirements and interfaces. In this section, we treated the complex system as a black box, focusing exclusively on the data exchanged as derived from the operational needs. By adding process engineering, we changed the black box into a white box: We identified processes that connect the different states of the system with each other. Finally, we added the conceptual models as a bridge between the modeled selection of reality and the systems implementation. Currently, part solutions exist and are working very well, but they do not solve the challenges of interoperation and composition, they just contribute to the solution. Only if they are conducted in an aligned and orchestrated form, the overall success becomes possible. The hierarchical nature of the LCIM facilitates the process of aligning models by organizing concepts into dependent layers. Within each layer, the interoperability concept addressed can be further broken down in terms of its definitions, subconcepts, processes and requirements. In this manner, the necessary elements for achieving a particular LCIM level can be listed. Figure 3.5 is adapted from a recent evaluation by the authors of the state of the art for the contributions of selected interoperability protocols and knowledge representation languages towards satisfying the levels of the LCIM. The first two are simulation interoperability protocols, which are of particular interest, as Modeling and Simulation explicitly expresses the ideas of conceptual models and using models as abstractions of reality as the basis for the simulation in its body of knowledge efforts. For each protocol (Distributed Interactive Simulation - DIS, High Level Architecture - HLA, Extensible Markup Language XML, Resource Description Framework/RDF for Services - RDF/RDFS, Web Ontology Language - OWL, OWL for Services - OWL-S, Rules), the density of the

HLA

RDF/RDF S

XML

OWL OWL-S Rules

DIS Conceptual Dynamic Pragmatic Semantic Syntactic Technical none

Fig. 3.5. Protocol comparison using the LCIM

MBDE PE CL

70

A. Tolk et al.

square indicates the relative degree of support for the indicated level. As can be seen, the study reported a general lack of support for achieving the highest LCIM level: Conceptual Interoperability. Using the same evaluation criteria as applied in the study, we first add evaluations of the potential contributions of model-based data engineering (MBDE) and process engineering (PE) and conceptual linkage (CL). As shown, the artifacts gradually increase the supported level of interoperation. Only if all supporting methods and tools are aligned and orchestrated – i.e. that a pair wise connection between the concepts and entities exists allowing the map the different levels and that they are executed in a harmonized manner – the full spectrum of interoperation and composition is covered. The engineering processes of data engineering, process engineering, and constraint/ assumption engineering are one example and document best practices how to make this approach work for complex systems in knowledge-based environments. In the definitions and examples given until now, we have discussed what is required to be achieved if engineering practices are to be applied to two existing systems, in order to make them achieve some level of interoperability. The definitions and requirements described in this chapter, and the descriptions of the levels of interoperability from the LCIM can serve another use as well: The definitional levels of Table 3.10. Descriptive and Prescriptive Roles of the LCIM LCIM Levels

Description of Interoperability at this Level

Prescription of Requirements to reach this Level

Technical

Systems are exchanging data with each other.

Ability to produce and consume data in exchange with systems external to self is required to be technically interoperable.

Syntactic

Data exchange is taking place within an agreed to protocol, that all systems are able to produce to, and can consume them

An agreed-to protocol that all can be supported by the technical level solution is required to achieve this level of interoperability.

Semantic

Interoperating systems are exchanging a set of terms that they can semantically parse.

Agreement between all systems on a set of terms that grammatically satisfies the syntactic level solution requirements is required for this level.

Pragmatic

Interoperating systems will be aware of the context and meaning of information being exchanged.

A method for sharing meaning of terms is required, as well as a method for anticipating context. These both should be based on what exists at the semantic level.

Dynamic

Interoperating systems are able to reorient information production and consumption based on understood changes to meaning, due to changing context.

A method for defining meaning and context is required to achieve this level. The means of producing and consuming these definitions is required for dynamic interoperability.

Conceptual

Interoperating systems at this level are completely aware of each others information, processes, contexts, and modeling assumptions.

A shared understanding of the conceptual model of a system (exposing its information, processes, states and operations) must be possible in order to operate at this level.


71

the LCIM can serve two broad functions – (a) the role of describing what level of interoperability exists within a composition of systems, and (b) the role of prescribing the methods and requirements that must be satisfied during the engineering of a system of systems in order to achieve a desired level of interoperability. The description of interoperating systems that are sharing information to a certain level of interoperability is described in the table 3.10 (Tolk et al., 2007). The prescription of the methods required to enable system-to-system interoperation at a certain level is also described. • When applied in the role of providing a description of interoperability, the LCIM is used in the cases where two or more systems are interoperating - at some level - and the richness of that interoperation is being evaluated. In this role, the levels of the LCIM are applied as a description of a capability that already exists. • When applied in the role of providing a prescription for interoperability development methods, the LCIM is used in cases where an assessment must be made of techniques to be applied in order to achieve a desired level of interoperability. In this role, the capability for systems to interoperate does not exist - the systems themselves may not even exist. The LCIM in this role is applied, as prescriptive, giving developers a measure of required effects, which must be satisfied in order to become interoperable to a certain level. As stated in the introduction to this chapter, the LCIM is already used in several communities and was successfully applied in support of interoperation and composition. Some of these examples are recorded in the special issue of the Journal for Intelligent Decision Technologies (Phillips-Wren and Jain, 2008). With the widening acceptance and use, the LCIM has the potential to become a framework for an Interoperation and Composition Maturity Model enabling the description and prescription of solutions in a standardized manner. The ultimate goal of the recommendations summarized in this chapter is to set up a framework enabling the mediation between different viewpoints. As stated before, a conceptual model allows making such viewpoints explicit. While the majority of current standardization efforts tries to support to come to a common view, the approach of this chapter recognizes that the real, physical world contains "more detail and complexity than any humanly conceivable model or theory can represent" (Sowa, 2000). As such a multitude of viewpoints resulting in a multitude of models is a good thing, as they allow evaluating a multitude of aspects of an underlying problem. The challenge for engineers is to make sure that the resulting recommendations are based on aligned views, i.e. that the viewpoints should not lead to contradicting results and recommendations. Therefore, if the viewpoints can be mediated, the resulting system of systems represents a multitude of viewpoints that are consistent and can be used to express different aspects of the same problem to be solved. Summarizing this chapter it was shown that interoperation and composition require to deal with data (concepts of entities that are modeled and are related and interact with each other), processes (concepts of functions that use the entities or are used by the entities), and constraints (defining the valid solution space for data and processes) using engineering methods. Each recommendation that only implements a subset will fall short of providing a solution. While the emphasis of research focused on data,

72

A. Tolk et al.

newer approaches are including processes as well. How to cope with assumptions and constraints is topic of current research. As a community, we are just starting to realize that diversity and heterogeneity is an advantage in the domain of system of systems. So far, however, this chapter summarizes best practices in an applicable way. In order to support a rigorous Interoperation and Composition Maturity Model, additional research work and broader application in the community is needed. As such, this chapter is just describing the first steps into this direction.

References Bernstein, P.A., Melnik, S., Petropoulos, M., Quix, C.: Industrial-strength schema matching. Special Issue in Semantic Integration, SIGMOD Rec. 33(4), 38–43 (2004) Brown, G., Jeremy, J.: Website Indexing: enhancing access to information within websites, 2nd edn. Auslib Press, Blackwood (2004) Buede, D.M.: The Engineering Design of Systems. John Wiley & Sons, Inc., Chichester (1999) Davis, P.K., Anderson, R.H.: Improving the Composability of Department of Defense Models and Simulations. RAND Corporation (2003) Dobrev, P., Kalaydjiey, O., Angelova, G.: From Conceptual Structures to Semantic Interoperability of Content. In: Conceptual Structures: Knowledge Architectures for Smart Applications, pp. 192–205. Springer, Heidelberg (2007) Garlan, D., Allen, R., Ockerbloom, J.: Architectural Mismatch: Why Reuse Is So Hard. In: Proceedings 17th International Conference on Software Enginneering, Seattle, Washington, pp. 179—185 (1995) GridWise Architecture Council Interoperability Framework Team, Interoperability ContextSetting Framework, V1.0 (July 2007) Hofmann, M.: Challenges of Model Interoperation in Military Simulations. SIMULATION 80, 659–667 (2004) Jordan, D., Evdemon, J.: Web Services Business Process Execution Language (2007), http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.pdf King, R.: Towards Conceptual Linkage of Models and Simulations. In: Proceedings of the Fall Simulation Interoperability Workshop. IEEE CS Press, Los Alamitos (2007) King, R., Turnitsa, C.: The Landscape of Assumptions. In: Spring Simulation MultiConference, Ottawa. IEEE CS Press, Los Alamitos (2008) King, R., Diallo, S., Tolk, A.: How to Play Fairly: Agents and Web Services Can Help. In: Proceedings Spring Simulation Interoperability Workshop. IEEE CS Press, Los Alamitos (2007) Morris, E., Levine, L., Meyers, C., Place, P., Plakosh, D.: System of Systems Interoperability (SOSI), Final Report. Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA (2004) O’Kelly, P.: Data Modeling is Underrated: A Bright Future Ahead in the Grand Schema Things. Burton Group, Ontolog-Forum Presentation (November 30, 2006) Pace, D.: Simulation Conceptual Model Development Issues and Implications for Reuse of Simulation Components. In: Fall Simulation Interoperability Workshop. IEEE CS Press, Los Alamitos (2006) Page, E.H., Briggs, R., Tufarolo, J.A.: Toward a Family of Maturity Models for the Simulation Interconnection Problem. In: Spring Simulation Interoperability Workshop. IEEE CS Press, Los Alamitos (2004)


73

Parent, C., Spaccapietra, S.: Issues and approaches of database integration. Communications of the ACM 41(5), 166–178 (1998) Parent, C., Spaccapietra, S.: Database Integration: The Key To Data Interoperability Advances in Object-Oriented Data Modeling. In: Papazoglou, M., Spaccapietra, S., Tari, Z. (eds.) Advances in Object-Oriented Data Modeling, pp. 221–253. MIT Press, Cambridge (2000) Phillips-Wren, G., Jain, L.: Decision Support in Agent Mediated Environments. IOS Press B.V., Amsterdam (2005) Phillips-Wren, G., Jain, L.: Ontology Driven Interoperability for Agile Applications using Information Systems: Requirements and Applications for Agent Mediated Decision Support. Journal for Intelligent Decision Technologies 2(1) (Special Issue 2008) Rahm, E., Do, H., Massmann, S.: Matching large XML schemas. SIGMOD Record. Special Issue in Semantic Integration (2004) Robinson, S.: Issues in Conceptual Modeling for Simulation: Setting a Research Agenda. OR Society 3rd Simulation Workshop, Ashorne, UK (2006) Robinson, S.: Conceptual modelling for simulation Part I: definition and requirements. Journal of the Operational Research Society 59(3), 278–290 (2007) Seligman, L.A., Rosenthal, P., Lehner, P., Smith. A.: Data integration: Where does the time go? IEEE Data Engineering Bulletin (2002) Siegel, J.: Introduction To OMG’s Unified Modeling Language (UML), Object Management Group (2005), http://www.omg.org/gettingstarted/what_is_uml.htm Sowa, J., Majumdar, A.: Analogical Reasoning. In: de Moor, L., Ganter (eds.) Conceptual Structures for Knowledge Creation and Communication, pp. 16–36. Springer, Berlin (2003) Sowa, J.F.: Knowledge Representation: Logical, Philosophical and Computational Foundations. Monterey. Brooks Cole Publishing Co. (2000) Spaccapietra, S., Parent, C., Dupont, Y.: Model Independent Assertions for Integration of Heterogeneous Schemas. Very Large Database (VLDB) Journal 1(1), 81–126 (1992) Su, H., Kuno, H., Rundensteiner, E.: Automating the transformation of XML documents. In: 3rd International Workshop on Web Information and Data Management, pp. 68–75. ACM Press, New York (2001) Tolk, A., Diallo, S.: Model-Based Data Engineering for Web Services. IEEE Internet Computing 9(4), 65–71 (2005) Tolk, A., Diallo, S.: Model-Based Data Engineering for Web Services. In: Nayak, R., et al. (eds.) Evolution of the Web in Artificial Intel. Environ, pp. 137–161. Springer, Heidelberg (2008) Tolk, A., Muguira, J.: The Levels of Conceptual Interoperability Model (LCIM). In: IEEE Fall Simulation Interoperability Workshop. IEEE CS Press, Los Alamitos (2003) Tolk, A.: Moving towards a Lingua Franca for M&S and C3I – Developments concerning the C2IEDM. In: European Simulation Interoperability Workshop, Edinburgh, Scotland (June 2004) Tolk, A., Diallo, S., Turnitsa, C.: Ontology Driven Interoperability – M&S Applications, Old Dominion University, Whitepaper in support of the I/ITSEC Tutorial, VMASC Report 2548 (2006) Tolk, A., Turnitsa, C., Diallo, S.: Implied Ontological Representation within the Levels of Conceptual Interoperability Model. Journal of Systemics, Cybernetics and Informatics 5(5), 65–74, IIIS (2007) Tolk, A., Diallo, S., Turnitsa, C., Winters, L.S.: Composable M&S Web Services for Netcentric Applications. Journal Defense Modeling and Simulation 3(1), 27–44 (2006)

74

A. Tolk et al.

Tolk, A.: Common Data Administration, Data Management, and Data Alignment as a Necessary Requirement for Coupling C4ISR Systems and M&S Systems. Information & Security: An International Journal 12(2), 164–174 (2003) Turnitsa, C.: Extending the Levels of Conceptual Interoperability Model. In: Proc. Summer Computer Simulation Conference, Philadelphia (2005) Yilmaz, L., Paspuletti, S.: Toward a Meta-Level Framework for Agent-supported Interoperation of Defense Simulations. Journal of Defense Modeling and Simulation 2(3), 161–175 (2005) Yilmaz, L.: On the Need for Contextualized Introspective Simulation Models to Improve Reuse and Composability of Defense Simulations. Journal of Defense Modeling and Simulation 1(3) (2004) Yilmaz, L., Tolk, A.: Engineering ab initio dynamic interoperability and composability via agent-mediated introspective simulation. In: IEEE Winter Simulation Conference, pp. 1075– 1182. IEEE CS Press, Los Alamitos (2006) Zeigler, B., Hammonds, P.: Modeling & Simulation-Based Data Engineering: Introducing Pragmatics into Ontologies for Net-Centric Information Exchange. Academic Press, London (2007)

4 Ontology Driven Data Integration in Heterogeneous Networks Isabel F. Cruz and Huiyong Xiao ADVIS Lab Department of Computer Science University of Illinois at Chicago, USA {ifc,hxiao}@cs.uic.edu Abstract. We propose a layered framework for the integration of syntactically, schematically, and semantically heterogeneous networked data sources. Their heterogeneity stems from different models (e.g., relational, XML, or RDF), different schemas within the same model, and different terms associated with the same meaning. We use a semantic based approach that uses a global ontology to mediate among the schemas of the data sources. In our framework, a query is expressed in terms of one of the data sources or of the global ontology and is then translated into subqueries on the other data sources using mappings based on a common vocabulary. Metadata representation, global conceptualization, declarative mediation, mapping support, and query processing are addressed in detail in our discussion of a case study.

4.1 Introduction Data integration refers to the ability to manipulate data transparently across multiple data sources, such as networked data sources on the web. The concept of data integration is part of the broader concept of interoperability among systems, services, or programs [33]. However, because of their increasing number, reference models and standards that have been developed to enable interoperability stand paradoxically in the way of their intended goals. To address this problem, common metamodels and mappings have been proposed [44]. Metamodels support abstraction and generalization that aid in identifying problems that can use the same solutions. Mappings provide bridges between those alternative solutions. A compelling parallel has been made between models and metamodels: “What metadata and mediation services enable for data, metamodels and mappings can provide for models.” [44]. The migration of solutions to new problems depends heavily on the ability to use metamodels and in particular on using a common layered metamodel to organize and map existing standards. An example of a layered model is the ISO/OSI model for networking, where layers support clearly defined functions and interfaces. It is in this structure that a solution can be devised.

This research was supported in part by the National Science Foundation under Awards ITR IIS-0326284, IIS-0513553, and IIS-0812258.

A. Tolk, L.C. Jain (Eds.): Comp. Sys. in Knowledge-based Environments, SCI 168, pp. 75–97. c Springer-Verlag Berlin Heidelberg 2009 springerlink.com

76

I.F. Cruz and H. Xiao

The Levels of Conceptual Interoperability Model (LCIM) has been devised to measure the level of interoperability between systems: Level 6 (of maximum interoperability) is labeled “Conceptual Interoperability.” The remaining levels (in decreasing order of interoperability that they support) are respectively labelled “Dynamic Interoperability,” “Pragmatic Interoperability,” “Semantic Interoperability,” “Syntactic Interoperability,” and “Technical Interoperability.” Tolk et al. recognize the need of using ontologies for defining the meaning of data and of processes in a system and propose a ontology-based approach for the different layers of LCIM [45]. In this paper, we follow an approach that follows closely the objectives, if not the methods, of the above approaches. First, we focus on data operation and therefore on interoperability. Second, we distinguish levels of interoperability, with Semantic Interoperability being the highest level obtained thus far. Third, our structure for interoperability is not only layered but also follows closely the ISO/OSI model for networking. Fourth, we consider several types of data heterogeneity and deal with all of them within the same framework. Fifth, we deal with different data representation standards and would be able to accommodate emerging standards. Finally, we use an approach where ontologies play several roles. In particular, we use a metamodel (conceptually an ontology) to bridge across the ontologies that model the different interoperating data sources. In the rest of the paper we focus on the particular problem of integrating data sources that can be heterogeneous in syntax, schema, or semantics, thus making data integration a difficult task [10]. More specifically, syntactic heterogeneity is caused by the use of different data models (e.g., relational, XML, or RDF). Within the same model, the structural differences between two schemas lead to schematic heterogeneity. Semantic heterogeneity results from different meanings or interpretations of data that may arise from various contexts. To demonstrate our approach we have adapted an example that considers legacy databases for aircraft maintenance scheduling [38] to illustrate syntactic, schematic, and semantic heterogeneities, which is shown in Figure 4.1. In this example, syntactic heterogeneity stems from data that is stored in relational and XML databases. The example also illustrates schematic heterogeneity in that the schemas of the relational databases differ substantially. For example, aircraft models are either table names, attribute names, or attribute values. Semantic heterogeneity is also apparent: “RDYF15S” (table name in System D), “F15S” (attribute name in System C), and “F15” (attribute value in System B) relate to the same kind of airplane. In this paper, we achieve integration among syntactically, schematically, and semantically heterogeneous network data using an approach that is based on the layered model proposed by Melnik and Decker [31]. Their model, which is inspired by the ISO/OSI layered networking model, consists of four layers: the syntax, object, semantic, and application layers. This paper expands on our preliminary work [16]. We follow a hybrid approach, which is embodied in the semantic layer. In particular, we associate an ontology with each networked data source, called

4 Ontology Driven Data Integration in Heterogeneous Networks

77

Fig. 4.1. Five syntactically, schematically, and semantically heterogeneous legacy databases for aircraft maintenance

henceforth local ontology, and create a global ontology to mediate across the data sources. The global ontology relies on a common vocabulary shared by all data sources [47]. Considering the fundamental role of RDF as an ontology language, we express all the data models in our approach using RDF1 and RDF Schema.2 Queries are propagated across the semantic layers of the data sources and are expressed using a RDF query language. We use the RDF Query Language, RQL [25], but any other language for RDF could have been used, including SPARQL.3 The queries are expressed using mappings established between pairs of ontologies, one called the source ontology and the other one the target ontology. The rest of the paper is organized as follows. In Section 4.2 we describe the different ways under which ontologies can be used and the different roles they play in data integration. Our layered approach is presented in Section 4.3. In this section, we describe the different layers and the overall architecture of a system that integrates data from the networked sources. To demonstrate our layered approach, in Section 4.4 we expand the legacy example we have just introduced in light of the different kinds of roles that ontologies play. Section 4.5 describes 1 2 3

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

78


in detail query processing across different data sources and lists the kinds of assumptions we have made. We discuss related work in Section 4.6 and finally draw some conclusions in Section 4.7.

4.2 Ontologies in Data Integration We call semantic data integration the process of using a conceptual representation of the data and of their relationships to eliminate heterogeneities. At the heart of this process is the concept of ontology, which is defined as an explicit specification of a shared conceptualization [21, 22]. Ontologies are developed by people or organizations to facilitate knowledge sharing and reuse [23]. For example, they can embody the semantics for particular domains, in which case they are called domain ontologies. Ontologies are semantically richer than traditional database schemas. In what follows we describe data integration architectures in terms of database schemas. Later we describe how ontologies can be used instead of database schemas. We distinguish two data integration architectures: one that is central [2, 5, 12, 18, 32, 46] and the other one that is peer-to-peer [4, 8, 9, 19, 24, 34]. A central data integration system has a global schema, which provides the user with a uniform interface to access information stored in the data sources by means of queries posed in terms of the global schema [28]. In contrast, in a peer-to-peer data integration system, any peer (a data source) can accept user queries to access information in other peers. To enable data integration in a central data integration system, mappings need to be created between the global schema and the data source schemas. In a peer-to-peer data integration system mappings are established between peers. The two main approaches to building such mappings are Global-as-View (GaV) and Local-as-View (LaV) [28, 46]. In the GaV approach, every entity in the global schema is associated with a view over the data sources. Therefore querying strategies are simple because the mappings are explicitly defined. However, every time that there is a change to the data sources, it could change the views. In contrast, the LaV approach allows for changes to the data sources that do not affect the global schema, since the local schemas are defined as views over the global schema. However, query processing is more complex. Now that we have introduced the main concepts behind data integration, we describe the different forms in which ontologies can intervene [47]: Single ontology approach. All source schemas are directly related to a shared global ontology, which provides a uniform interface to the user. However, this approach requires that all sources have similar characteristics, for example the same level of granularity. An example of a system that uses this approach is SIMS [5]. Multiple ontology approach. Each data source is described by its own local ontology. Instead of using a global ontology, local ontologies are mapped to one another. For this purpose, an additional representation formalism is


79

necessary for defining the inter-ontology mappings. The OBSERVER system is an example of this approach [32]. Hybrid ontology approach. A combination of the two preceding approaches is used. First, a local ontology is built for each source schema, which is mapped to a global ontology. New sources can be easily added with no need for modifying existing mappings. Our layered framework is an example of this approach. The single and hybrid approaches are appropriate for building central data integration systems, the former being more appropriate for GaV systems and the latter for LaV systems. A peer-to-peer system, where a global ontology exists in a “super-peer” can also use the hybrid ontology approach [19]. However, the multiple ontology approach is better suited to “pure” peer-to-peer data integration systems, where there are no super-peers. We identify the following five roles of ontologies in a data integration process [17]: Metadata representation. Each source schema can be explicitly represented by a local ontology. All ontologies use the same representation language and are therefore syntactically homogeneous. Global conceptualization. The global ontology provides a conceptual view over the schematically heterogeneous source schemas. Support for high-level queries. The global ontology provides a high-level view of the sources. Therefore, a query can be formulated without specific knowledge of the different data sources. The query is then rewritten into queries over the sources, based on the semantic mappings between the global and local ontologies. Declarative mediation. A hybrid peer-to-peer system uses the global ontology as a mediator for query rewriting across peers. Mapping support. A common thesaurus or vocabulary, which can be formalized as an ontology, can be used to facilitate the automation of the mapping process. In the following sections, we further elaborate on these five roles using our case study to exemplify them.

4.3 A Layered Data Interoperability Model 4.3.1

Overview

In this section, we present the layered approach for data interoperability proposed by Melnik and Decker [31], which we show in Figure 4.2. Of the four proposed layers, we concentrate on the semantic layer and identify three sublayers that are contained in it. Application Layer. The application layer is used to express queries. For example, a visual user interface may be provided in this layer for users to submit

80


Local Source

Remote Source

Application Layer

Application Layer

User Interface

User Interface

Semantic Layer

Semantic Layer

Language Domain Models

Language Domain Models

Conceptual Models

Conceptual Models

Object Layer (Objects / Relations between objects)

Object Layer (Objects / Relations between objects)

Syntax Layer (Serialization, Storage)

Syntax Layer (Serialization, Storage)

Fig. 4.2. The layered model

their queries. Ideally, query results are integrated and shown to the users, so as to give the appearance that the distributed databases interoperate seamlessly. Semantic Layer. This layer consists of three cooperating sublayers that accomplish different tasks: • Languages. The main purpose of this sublayer is to accept the user queries and to interpret them so that they can be understood by the other interoperating systems. The language can be highly specialized or be a general purpose language. • Domain Models. They include the ontologies for a particular application domain and can be different from one another even for the same domain [29]. Examples of domains include transportation, manufacturing, e-business, digital libraries, and aircraft maintenance. • Conceptual Models. They model concepts, relationships and constraints using constructs such as generalization, aggregation, or cardinality constraints. RDF Schema and UML Foundation/Core are two examples. Object Layer. The purpose of the object layer is to give an object-oriented view of the data to the application. This layer enables manipulations of objects and binary relationships between them. Every object in a data schema is mapped to a particular class. The object layer also forwards all the information that it receives from the syntax layer to the semantic layer. Syntax Layer. The main purpose of the syntax layer is to provide a way of specifying both the semantic and object layer information using a common representation. XML has been used to represent RDF and RDF Schema. This layer is also responsible for data serialization and for mapping the queries


81

from the object layer to the XML representation of the data schemas. The information that is extracted by the queries is returned to the object layer. 4.3.2

Architecture

Based on the layered approach discussed above, we concentrate now on the semantic layer. The semantic layer accepts user queries from the application layer and processes them. We use a hybrid ontology approach and RDF Schema both for the conceptual model of the data sources and for the domain model, as expressed by means of a global ontology. Given our choice of RDF and RDF Schema, a query language for RDF is appropriate. We chose RQL (RDF Query Language) [25] for the language sublayer. The application layer can either support RQL or an application specific user interface. As for the implementation of the object layer and of the syntax layer, we use RSSDB (RDF Schema Specific Database), which is an RDF Store that uses schema knowledge to automatically generate an Object-Relational (SQL3) representation of RDF metadata and to load resource descriptions [1]. Figure 2 shows the architecture that is used to build applications based on our layered approach. The whole process can be further divided into three subprocesses as follows: Constructing local ontologies. A component called Schema Integrator is used to transform source schemas and source data automatically into a single conceptual schema, expressed using a local ontology. We consider relational, XML, and RDF databases. Mapping. We use a global ontology (using RDF Schema) to serve as the mediator between different local ontologies, each of which is mapped to the global ontology. We utilize a common vocabulary (which also uses RDF Schema) to facilitate this mapping process. This process is usually semi-automatic in that it may require input from users. Query processing. When the user submits a query to the local ontology, the query will be executed directly over the local RSSDB. This process is called local query processing. Queries are transformed from one local ontology to all the other local ontologies by a query rewriting algorithm. This process, which is based on the mappings between the global ontology and the local ontologies, is called remote query processing; it can be performed automatically under some simplifying assumptions. The answers to both local query processing and remote query processing are assembled and returned to the user.

4.4 Case Study In this section, we describe in detail the process for semantic data integration as illustrated by the case study already introduced in Section 4.1 and displayed in Figure 4.1. We also discuss the various ontology roles of Section 4.2 in the context of the case study.

82


Result Display

System B (Local) Relational DB XML Files RDF Files

Schema Integrator

System E (Remote)

Query Submission Integrated Local Schema (Local and Remote Results are returned to the user) Query Execution

Integrated Local Schema (Results are integrated and returned to System B) Query Execution

RSSDB

Mapping

Common Vocabulary

RSSDB

Relational DB Schema Integrator

XML Files RDF Files

Mapping

Global Ontology

Ontology and Mapping Maintenance

Fig. 4.3. Architecture of the semantic layer

4.4.1

Construction of Local Ontologies

The construction of a local ontology includes two phases. In the first phase, we integrate all source schemas into a single local ontology, which is represented in RDF Schema and stored in RSSDB. In the second phase, we transform data from the original relational or XML databases into RDF files, which are then also stored in RSSDB. When integrating RDF databases, this step is not needed. When the underlying schema is relational, we analyze the attributes of each table and the dependency relationships between every pair of tables through their foreign keys. In particular, if two tables are connected using a foreign key, we create a schema tree for each table. The root of each tree represents one table with type rdfs:Class and its children represent the attributes of the table with type rdf:Property. Therefore, the arcs connecting the root and its children are rdfs:domain arcs. Then we connect two trees using an rdfs:range edge from the node corresponding to the foreign key to the root of the other tree. Hence, we obtain the local ontology that can be used by the system for data interoperation. An example is shown for System B where STAFF ID is a foreign key, and the local ontology is shown in Figure 4.4(a). In the case of System D, where there is no foreign key between two tables, we also create a schema for each table. We then build a new root with type rdfs:Class and two new nodes of type rdf:Property, one for each table as children of this new root. Then we connect each of these nodes to one of the nodes representing the tables using an arc of type rdfs:range.


83

RDYACFT

MODEL

AVAILTIME

QTY

AIRBASE

STAFF_ID

STAFF TITLE

TEAM_LEADER STAFF_NUM

(a) Local ontology of SYSTEM B Class

AIRCRAFT

rdfs:domain Property rdfs:range

NAME

RDYTIME

NUMBER

AIRBASE

(b) Local ontology of SYSTEM E

MTSTAFF

Class Legend

Fig. 4.4. Local ontology for legacy source schemas

If a system uses XML files, we analyze the DTD file corresponding to each XML file and find all the element and attribute tags and their hierarchy, which we use to construct the local ontology for the system. Figure 4.4(b) shows the schema tree for System E. In this way, each of the participating systems have their local schemas expressed as a single RDF Schema local ontology and data stored using RSSDB. Figure 4.5 gives a fragment of the underlying RDF Schema representation of the local ontology of System E.

Fig. 4.5. RDF Schema for the local ontology of system E

84


Fig. 4.6. SQL query for data transformation in System B

Based on the local ontology, we consider two cases when transforming the data from a source schema into a local ontology. Relational database. We use the left outer join operation to unite the data from multiple tables that are connected through foreign keys. The table containing the foreign key acts as the left part of the left outer join operation. Figure 4.6 gives the example of a SQL query that expresses this transformation in System B. In the case where there is no foreign key relationship, we use a Cartesian product to realize the data transformation. XML data. The data model uses XML Schema or a DTD. In both situations we use XSLT expressions to transform data from an XML file into an RDF file. After the data is saved into an RDF file, we can use RQL (or any of the APIs for RSSDB), to access the data. 4.4.2

Mapping Process

The global ontology is used for mediating among distributed schemas [29]. For this purpose, we set up the relationships between the global ontology and the local ontologies based on a common vocabulary. Figure 4.7 shows a fragment of the global ontology for the domain of aircraft maintenance and its partial RDF Schema representation. We focus on the class and properties that are contained in the box. We use rdfs:isDefinedBy, which is an RDF property, to make the connection between a class or a property and the associated vocabulary. An important component of our approach is that all local ontologies share the common dictionary with the global ontology (see Figure 4.8). This dictionary stores the common vocabulary of all the concepts and the relationships between the global ontology and each local ontology. When presented with a new local ontology that needs to be mapped to the global ontology, the system checks every concept name against the dictionary to obtain an appropriate matching for that concept and chooses the optimal one according to a score function. The construction of a dictionary and the determination of an appropriate matching is an important area of research [37]. In this paper, we consider that the dictionary has a simplified structure, in that it only supports one-to-one total mappings. The components that participate in the mapping process (namely the local ontologies, the common vocabulary, and the global ontology) are all represented using RDF Schema. The mapping between the global ontology and a local ontology is realized according to the common vocabulary. Figure 4.9 shows the local


FLYING-OBJECT

AIRCRAFT

COMBAT-AIRCRAFT

MEASURE

STAFF

MAINTENANCE

NAME

TIME

85

TITLE

NUMBER

AIRBASE

LOCATION

"F15" Class

rdfs:subClassOf Class

rdf:type

rdfs:domain Property

Instance

rdfs:subPropertyOf Property Legend

Fig. 4.7. The global ontology and its RDF Schema description

ontologies of the five legacy systems of Figure 4.1, the relationships among the local ontologies, the global ontology, and the common vocabulary. Similarly to the global ontology, each local ontology has its properties mapped to the properties in the common vocabulary through rdfs:isDefinedBy. When the local ontology becomes related to the common vocabulary, the RDF representation of the local ontology also needs to be updated by inserting rdfs:isDefinedBy into any rdfs:Class or rdfs:Property being mapped. We use System E as an example (refer to Figure 4.4 for the previous RDF description of its local ontology). Figure 4.10 shows a fragment of the new RDF representation.

Class rdfs:domain Property rdfs:range Class Legend

VOCABULARY

AIRCRAFT

READYTIME

NUMBER

ADDRESS

MACHINIST

VOCABULARY _AIRCRAFT

VOCABULARY _READYTIME

VOCABULARY _NUMBER

VOCABULARY _ADDRESS

VOCABULARY _MACHINIST

SYNONYMS

Fig. 4.8. The common vocabulary

86


MAINTENANCE

NAME

TIME

AIRCRAFT

READYTIME

NUMBER

AIRBASE

TITLE

Global Ontology

ADDRESS

MACHINIST

Common Vocabulary

STATE

MECHANIC

SYSTEM A

VOCABULARY

NUMBER

ACMAINT

ACTYPE

RDYWHEN

NUM

RDYACFT

BASENAME

SYSTEM B MODEL

AVAILTIME

QTY

AIRBASE

a T_1 AIRCRAFT

AIRCFT

RDYTIME

F15S

STAFF

STAFF_NUM

T_2

SYSTEM C

STAFF_ID TITLE

MAINTSCHED

F16S

TEAM_LEADER

MECH_GROUP

SYSTEM C

T1

RDYF15S

Class

Property

SYSTEM D T2

RDYF15S

SYSTEM D

rdfs:domain rdfs:isDefinedBy

Property WHEN

QUANTITY rdfs:range Class

AIRCRAFT

SYSTEM E NAME

RDYTIME

NUMBER

AIRBASE

MTSTAFF

Legend

Fig. 4.9. Mapping between the global ontology and the local ontologies

Fig. 4.10. RDF Schema for the mapping information of System E

4.4.3

Discussion

The case study illustrates the following three roles played by ontologies in data integration: Metadata representation. To uniformly represent the metadata, which are source schemas in our case, a local ontology is constructed by means of a straightforward schema transformation process. Although a uniform syntax has been achieved, this process may seem too simplistic to encode rich and interpretable semantics. For example, names that do not correspond to words in a dictionary, such as ACTYPE in System A, may cause difficulties in the mapping process if not replaced by an English word or phrase, for example Aircraft Type. It remains an open issue how to generate an ontology that


87

represents the metadata of a data source in a conceptual but semantically lossless way [30, 43]. Global conceptualization. In our architecture, the global ontology, which is mapped to the local ontologies using an LAV approach, provides the user with a conceptual high-level view of all the source schemas. We recall that our architecture uses an hybrid ontology approach where we associate an ontology with each networked data source and create a single ontology, the global ontology, whose properties are mapped to the properties in the common vocabulary. Mapping support. The support provided by the common vocabulary for the mapping process corresponds to one of the roles played by ontologies, as the vocabulary can be represented using an ontology, and play the role of a meta-ontology. It describes the semantic relations between the vocabularies of the global ontology and of the local ontologies, thus serving as the basis for the mappings.

4.5 Query Processing Across Data Sources In our layered approach, as in any data integration system, query processing plays a critical role. Query processing is performed by rewriting a query posed on one data source to all the other sources that are connected to it using established mappings. 4.5.1

RQL

RQL is a typed functional language and relies on a formal model for directed labeled graphs [25]. In Figure 4.11, we show the example of an RQL query on the local ontology of System B. In the local query processing phase the system executes the RQL query on the local ontology and on the resources that are stored in the local RSSDB; the answer to the query, shown in Figure 4.12, is expressed in RDF and returned to the user (a visual user interface can display the results in other formats). In the remote query processing phase, the query gets rewritten on the schemas of the other networked data sources. 4.5.2

Query Rewriting Algorithm

Our algorithm makes the following simplifying assumptions about the schemas, mappings, and queries: (1) We assume that the local ontology is either a hierarchy or can be converted into a hierarchy without losing important schematic or semantic information (see Figure 4.4). (2) We assume that the mappings between the global ontology and local ontologies are total mappings, that is, all the concepts (classes or properties) occurring in the query are mapped. (3) We consider only one-to-one mappings, that is, a concept in one schema maps to a single concept in the other schema. (4) To keep the current discussion simple, we

RQL


QTY

TITLE

AVAILTIME MODEL

RDYACFT

STAFF_ID

MODEL

AV

0800

STAFF_ID aircraft1

E TI M A IL

STAFF

12

STAFF_NUM

TEAM_LEADER staff1

AI R

BA SE

CA, Anaheim

T IT LE

F15

TEAM_LEADER

AIRBASE

QTY

R DF r esou rce descr ip tio n of System B

RD F Schema of System B

88

Johnson ST AF F_

NU

M

6

F15_team

Select a1, a2, a3, a4, a5 From {a} MODEL {a1}, {b} AVAILTIME {a2}, {c} QTY {a3}, {d} STAFF_ID {a4}, {g} AIRBASE {a5} Where a=b and b=c and c=d and e=f and d=g and a1= 15 ”

{e}, {f} TITLE

rdfs:domain rdfs: range rdf:type correspondence between RQL and resources

Fig. 4.11. A typical RQL query on System B

Fig. 4.12. Query results of executing an RQL query on local System B

assume that the variables in the query only refer to “pure” classes or properties, that is, no functions such as subClassOf, subPropertyOf, domain, and range are applied to them; we consider queries with syntax {class1}property{class2} as shown in Figure 4.11. (5) We consider only schema or ontology mappings, not value mappings (which is our focus elsewhere [15]). The rewriting algorithm uses the established mapping information between any pair of local ontologies, having the global ontology as mediator. Before the algorithm starts, we initialize the source ontology and the target ontology as schema trees using the following rules. For every pair of concepts (classes or


89

(a) Schema Tree of SYSTEM B RDYACFT

MODEL

AVAILTIME

QTY

AIRBASE

STAFF_ID

STAFF_NUM

TEAM_LEADER TITLE

AIRCRAFT

NAME

RDYTIME

NUMBER

AIRBASE

MTSTAFF

(b) Schema Tree of SYSTEM E

Fig. 4.13. Local ontologies of System B and System E and their mappings

properties), say S and O, if S rdfs:domain O, or S rdfs:subClassOf O, or S rdfs:subPropertyOf O, we make S a child of O; if S rdfs:range O or S rdf:type O, we incorporate S and O into a single node. In addition, we establish mappings between the source ontology and the target ontology according to their respective mappings to the global ontology. Figure 4.13 shows the schema trees of System B and System E and their mappings (refer also to Figure 4.9). In System B, for instance, the properties MODEL, AVAILTIME, and QTY are made children of the class RDYACFT. The property STAFF ID and the class STAFF are incorporated into a single node. In the following illustration of the query rewriting algorithm, Q is the source query and Q is the target (rewritten) query, and we use the RDF terms subject, object, and statement [25]. As an example, we consider query Q on the local ontology of System B, which is shown in Figure 4.11. Q is the target query on the local ontology of System E. The following steps will be executed: Step 1. Get all the statements in the from clause that correspond to the objects in the select clause. In our example, we obtain (MODEL, AVAILTIME, QTY, AIRBASE, TITLE ). Each of these statements corresponds to a class or property in the source ontology. Step 2. Use the mapping information between the source ontology and the target ontology to find all the concepts (classes or properties) that correspond to the statements found in Step 1 and make these concepts statements in Q , as follows: select from

, ..., {<subject1>} <statement1> {}, ..., {<subjectn>} <statementn> {}

In our particular example of Figure 4.13 we have: select from

o1 , o2 , o3 , o4 , o5 {s1 }NAME {o1 }, {s2 }RDYTIME {o2 }, {s3 }NUMBER{o3 }, {s4 }AIRBASE {o4 }, {s5 }MTSTAFF {o5 }

Step 3. Consider each pair of nodes, Ei and Ej , corresponding to each pair of consecutive statements in Q , in the following cases:

90

I.F. Cruz and H. Xiao E0' E1'

Ei E1'

E1''

Ek'

Ek'

Ek''

En'

En'

En'' Ej

Ei (a)

Ej (b)

Fig. 4.14. Relationships between Ei and Ej

1) If Ei and Ej are siblings (have the same parent), meaning that this pair of statements share a common subject, then we append the condition <subjecti >=<subjectj > to the where clause of Q using and. For example, in System E (see Figure 4.13), NAME and RDYTIME are siblings, therefore, s1 = s2 is to be appended to the where clause. 2) If Ei and Ej share a common ancestor E0 that is not their parent, as shown in Figure 4.14(a), then we append all the intermediate nodes (statementk ), between E0 and Ei and between E0 and Ej , to the from clause in the form {<subjectk >} statementk {}. In addition, we append new conditions to the where clause in the following way: • =<subject2>, ..., =<subjectk+1 >, ..., =<subjectn>, and =<subjecti >, which correspond to the path E0 , E1 , ..., En , Ei . • =<subject2 >, ..., =<subjectk+1 >, ..., =<subjectn>, and = <subjectj >, which correspond to the path E0 , E1 , ..., En , Ej . • <subject1> = <subject1 >, as E1 and E1 share a common subject. 3) If Ei is an ancestor of Ej as shown in Figure 4.14(b), then we append all the intermediate nodes (statementk ) between Ei and Ej to the from clause in the form {<subjectk >}statementk {}. In addition, we append = <subject1>, = <subject2> ..., = <subjectk+1 >, ..., =<subjectn>, and =<subjecti> to the where clause. In our example, we only have the first case. Therefore, after Step 3 we get Q as follows: o1 , o2 , o3 , o4 , o5 {s1 }NAME {o1 }, {s2 }RDYTIME {o2 }, {s3 }NUMBER{o3 }, {s4 }AIRBASE {o4 }, {s5 }MTSTAFF {o5 } where s1 = s2 and s2 = s3 and s3 = s4 and s4 = s5

select from

Step 4. For each query condition oi =<string-value> in Q, we append the condition oi =<string-value> to the where clause of Q , where oi in Q is mapped to oi in Q . In our example, we obtain the following Q : o1 , o2 , o3 , o4 , o5 {s1 }NAME {o1 }, {s2 }RDYTIME {o2 }, {s3 }NUMBER{o3 }, {s4 }AIRBASE {o4 }, {s5 }MTSTAFF {o5 } where s1 = s2 and s2 = s3 and s3 = s4 and s4 = s5 and o1 =“F15”

select from


91

Fig. 4.15. Query results of executing Q on System E3

Step 5. Finally, Q is executed on RSSDB in System E. For our running example, we obtain the answer that is shown in Figure 4.15, where rdf:Seq is a tuple. This answer, which is returned by the remote query processing phase associated with System E, will be assembled by unioning all the tuples with the local query processing results that were shown in Figure 4.12. 4.5.3

Discussion

In our layered approach, the semantic layer enables the use of the above described algorithm for query rewriting in two ways—central and peer-to-peer—which correspond to two of the ontology roles described in Section 4.2: Support for high-level queries. This role dependents on the Global Conceptualization role, which was discussed in Section 4.4. Given that the global ontology acts as a single query interface to the data sources, the user is then able to formulate queries by referring to the global ontology, which serves as a “super-peer”. Both central and peer-to-peer queries are supported, based on the mappings between the global ontology and the local ontologies. Queries on the global ontology are automatically rewritten to a local query over each local ontology. A query on a peer is automatically rewritten to a query on another peer. Declarative mediation. As shown in the above example illustrating the query rewriting algorithm, the rewriting of Q over System B to Q over System E makes use of the global ontology as a mediator. In particular, the mapping information between System B and System E is derived by composing the mappings from System B to the global ontology and those from the global ontology to System E. It is possible that the composition of two mappings involves some semantic reasoning that may be supported by the global ontology. For example, suppose that System B has a concept Transportation mapped to Concept Vehicle in the global ontology, and that Aircraft (a child of Vehicle) is mapped to a concept Plane in System E. Then, the concept Transportation can be made a parent of Plane.

92


4.6 Related Work The subject of interoperability and the related subject of data integration have been long-standing in database research. In the nineties, several system architectures and systems have been proposed, including TSIMMIS [13] and InfoHarness [39]. In the field of data integration there are a number of noteworthy proposals. For example, the MOMIS (Mediator Environment for Multiple Information Sources) system consists of a set of tools for the integration of information in heterogeneous sources ranging from traditional databases to XML databases [6, 7]. The integration process relies heavily on a common thesaurus derived from the WordNet lexical database. The inter-schema knowledge is expressed using the thesaurus in the form of relationships such as synonymy and hyponymy. One tool is the SI-Designer (Source Integrator Designer) [6], a designer support tool for E-commerce applications, which uses a semi-automatic (requiring some user intervention) approach for the integration of heterogeneous data sources. Another tool is the MIKS (Mediator agent for Integration of Knowledge Sources) system [7], an agent based middleware system that integrates data belonging to heterogeneous sources into a global virtual view and offers support for the execution of queries over the global virtual schema [11]. The Clio project creates mappings between two data representations semiautomatically for the purpose of managing and facilitating heterogeneous data transformation and integration [36]. Given the two schemas and the set of correspondences between them, Clio can generate queries (e.g., SQL, XSLT, XQuery) that drive the translation of data conforming to the source schema to data conforming to the target schema. However, with the exception of mapping queries, Clio does not provide a mechanism for users to associate semantic information with the data—the only semantics are those “embedded” in the queries. There are a number of approaches addressing the problem of data integration among XML sources. In what follows we look at some of the main features found in existing approaches and describe those approaches. 4.6.1

Semantic Integration

High-level mediator. Amann et al. propose an ontology-based approach to the integration of heterogeneous XML Web resources in the C-Web project [2, 3]. The proposed approach is very similar to our approach except for the following differences. For example, they use the local-as-view (LaV) approach with a hypothetical global ontology that may be incomplete. Direct translation. Klein proposes a procedure to transform XML data directly into RDF data by annotating the XML documents using external RDFS specifications [26]. Encoding semantics. The Yin/Yang Web [35] proposed by Patel-Schneider and Siméon address the problem of incorporating the XML and RDF paradigms. They develop an integrated model for XML and RDF by integrating the semantics and inferencing rules of RDF into XML, so that


93

XML querying can benefit from their RDF reasoner. But the Yin/Yang Web does not solve the essential problem of query answering across heterogeneous sources, that is, sources with different syntax or data models. Lakshmanan and Sadri also propose an infrastructure for interoperating over XML data sources by semantically marking up the information contents of data sources using application-specific common vocabularies [27]. However, the proposed approach relies on the availability of an application-specific standard ontology that serves as the global schema. This global schema contains information necessary for interoperability, such as key and cardinality information for predicates. 4.6.2

Query Languages

CXQuery [14] is an XML query language proposed by Chen and Revesz, which borrows features from both SQL and other XML query languages. It overcomes the limitations of the XQuery language by allowing the user to define views, specify explicitly the schema of the answers, and query multiple XML documents. However, CXQuery does not solve the issue of structural heterogeneities among XML sources. The user has to be familiar with the document structure of each XML source to formulate queries. Heuser et al. present the CXPath language based on XPath for querying XML sources at the conceptual level [12]. CXPath is used to write queries over a conceptual schema that abstracts the semantic content of several XML sources. However, they do not consider query rewriting from the XML sources to the global schema. 4.6.3

Query Rewriting

Query rewriting or query translation is the key issue for both mediator-based integration systems and peer-to-peer systems. As an example of the first case, the Clio approach [36] addresses the issue of schema mapping and data transformation between nested schemas and/or relational databases. It focuses on how to take advantage of schema semantics to generate the consistent translations from source to target by considering the constraints and structure of the target schema. The approach uses queries to express the mapping so as to transform the data into the target schema. The Piazza system [24] is a peer-to-peer system for interoperating between XML and RDF. The system achieves its interoperability in a low-level (syntactic) way using the interoperability of XML and the XML serialization of RDF.

4.7 Conclusions and Future Work The work on data integration that we presented in this paper fits in the overall perspective of metamodels and mappings that address the problem of interoperability in the presence of multiple standards [44]. In particular, we presented an approach to the syntactic, schematic, and semantic integration of

94


data sources using a layered model. Our layered model consists of four layers, of which the main component is the semantic layer. This layer uses a hybrid ontology-based approach to the integration problem that enables both central and peer-to-peer query processing. Our contribution involves the representation of metadata, global conceptualization, declarative mediation, mapping support, and query processing. Future work will focus on the following topics: • We will lift some of the restrictions we imposed on the query rewriting algorithm. An interesting extension, which will further use the conceptual modeling capabilities of RDF Schema, will consider the mapping of concepts related by subclassing. • We will further explore the creation of joint local schemas to make it more general. • We will consider the case where the answers to the queries may be expressed in the native schema of the legacy databases. For example, by using RDF, the nesting structure associated with XML is lost in the mapping from XML data to RDF data. We will look at which properties can be encoded using RDF Schema, and how they can be encoded. For example, RDF can be extended to encode the XML nesting structure using the property rdfx:contained [48]. • We will consider the problem of building vocabularies and of automatically matching ontologies that represent different vocabularies so as to align similar terms [40]. There have been significant advances in automatic ontology matching and in the evaluation of algorithms that implement those matchings [20], including of algorithms that consider the structure of the ontology graph (e.g., [41, 42]).

References [1] Alexaki, S., Christophides, V., Karvounarakis, G., Plexousakis, D., Tolle, K.: The ICS-FORTH RDFSuite: Managing Voluminous RDF Description Bases. In: International Workshop on the Semantic Web (SemWeb), Hongkong, China (2001) [2] Amann, B., Beeri, C., Fundulaki, I., Scholl, M.: Ontology-Based Integration of XML Web Resources. In: International Semantic Web Conference (ISWC), pp. 117–131 (2002) [3] Amann, B., Fundulaki, I., Scholl, M., Beeri, C., Vercoustre, A.-M.: Mapping XML Fragments to Community Web Ontologies. In: International Workshop on the Web and Databases (WebDB), pp. 97–102 (2001) [4] Arenas, M., Kantere, V., Kementsietsidis, A., Kiringa, I., Miller, R.J., Mylopoulos, J.: The Hyperion Project: From Data Integration to Data Coordination. SIGMOD Record 32(3), 38–53 (2003) [5] Arens, Y., Knoblock, C.A., Hsu, C.: Query Processing in the SIMS Information Mediator. In: Tate, A. (ed.) Advanced Planning Technology. AAAI Press, Menlo Park (1996) [6] Benetti, I., Beneventano, D., Bergamaschi, S., Guerra, F., Vincini, M.: SIDesigner: an Integration Framework for E-commerce. In: IJCAI Workshop on E-Business and the Intelligent Web, Seattle, WA (2001)


95

[7] Beneventano, D., Bergamaschi, S., Gelati, G., Guerra, F., Vincini, M.: M IKS: An Agent Framework Supporting Information Access and Integration. In: Klusch, M., Bergamaschi, S., Edwards, P., Petta, P. (eds.) Intelligent Information Agents. LNCS (LNAI), vol. 2586, pp. 22–49. Springer, Heidelberg (2003) [8] Bergamaschi, S., Guerra, F., Vincini, M.: A Peer-to-Peer Information System for the Semantic Web. In: International Workshop on Agents and Peer-to-Peer Computing (AP2PC), pp. 113–122 (2003) [9] Bernstein, P.A., Giunchiglia, F., Kementsietsidis, A., Mylopoulos, J., Serafini, L., Zaihrayeu, I.: Data Management for Peer-to-Peer Computing: A Vision. In: International Workshop on the Web and Databases (WebDB), pp. 89–94 (2002) [10] Bishr, Y.A.: Overcoming the Semantic and Other Barriers to GIS Interoperability. International Journal of Geographical Information Science 12(4), 229–314 (1998) [11] Cabri, G., Guerra, F., Vincini, M., Bergamaschi, S., Leonardi, L., Zambonelli, F.: MOMIS: Exploiting Agents to Support Information Integration. International Journal of Cooperative Information Systems 11(3), 293–314 (2002) [12] Camillo, S.D., Heuser, C.A., dos Santos Mello, R.: Querying Heterogeneous XML Sources through a Conceptual Schema. In: International Conference on Conceptual Modeling (ER), pp. 186–199 (2003) [13] Chawathe, S.S., Garcia-Molina, H., Hammer, J., Ireland, K., Papakonstantinou, Y., Ullman, J.D., Widom, J.: The TSIMMIS Project: Integration of Heterogeneous Information Sources. In: Meeting of the Information Processing Society of Japan (IPSJ), Tokyo, Japan, pp. 7–18 (1994) [14] Chen, Y., Revesz, P.: CXQuery: A Novel XML Query Language. In: International Conference on Advances in Infrastructure for Electronic Business, Science, and Medicine on the Internet (SSGRR 2002w) (2002) [15] Cruz, I.F., Rajendran, A., Sunna, W., Wiegand, N.: Handling Semantic Heterogeneities Using Declarative Agreements. In: International Symposium on Advances in Geographic Information Systems (ACM GIS), McLean, VA, pp. 168–174 (2002) [16] Cruz, I.F., Xiao, H.: Using a Layered Approach for Interoperability on the Semantic Web. In: International Conference on Web Information Systems Engineering (WISE), pp. 221–232 (December 2003) [17] Cruz, I.F., Xiao, H.: The Role of Ontologies in Data Integration. Journal of Engineering Intelligent Systems 13(4), 245–252 (2005) [18] Cruz, I.F., Xiao, H., Hsu, F.: An Ontology-based Framework for Semantic Interoperability between XML Sources. In: International Database Engineering and Applications Symposium (IDEAS), pp. 217–226 (2004) [19] Cruz, I.F., Xiao, H., Hsu, F.: Peer-to-Peer Semantic Integration of XML and RDF Data Sources. In: Moro, G., Bergamaschi, S., Aberer, K. (eds.) AP2PC 2004. LNCS (LNAI), vol. 3601, pp. 108–119. Springer, Heidelberg (2005) ˘ ab, O., [20] Euzenat, J., Isaac, A., Meilicke, C., Shvaiko, P., Stuckenschmidt, H., Sv´ Sv´ atek, V., van Hage, W.R., Yatskevich, M.: First Results of the Ontology Evaluation Initiative 2007. In: Second ISWC International Workshop on Ontology Matching. CEUR-WS (2007) [21] Gruber, T.R.: A Translation Approach to Portable Ontology Specifications. Knowledge Acquisition 5(2), 199–220 (1993) [22] Gruber, T.R., Olsen, G.R.: An Ontology for Engineering Mathematics. In: International Conference on Principles of Knowledge Representation and Reasoning (KR), pp. 258–269 (1994) [23] Guarino, N.: Formal Ontology and Information Systems. In: International Conference on Formal Ontologies in Information Systems (FOIS 1998), pp. 3–15 (1998)

96


[24] Halevy, A.Y., Ives, Z.G., Mork, P., Tatarinov, I.: Piazza: Data Management Infrastructure for Semantic Web Applications. In: International World Wide Web Conference (WWW), pp. 556–567 (2003) [25] Karvounarakis, G., Alexaki, S., Christophides, V., Plexousakis, D., Scholl, M.: RQL: A Declarative Query Language for RDF. In: International World Wide Web Conference (WWW), pp. 592–603 (2002) [26] Klein, M.C.A.: Interpreting XML Documents via an RDF Schema Ontology. In: International Conference on Database and Expert Systems Applications (DEXA), pp. 889–894 (2002) [27] Lakshmanan, L.V., Sadri, F.: Interoperability on XML Data. In: International Semantic Web Conference (ISWC), pp. 146–163 (2003) [28] Lenzerini, M.: Data Integration: A Theoretical Perspective. In: ACM SIGMODSIGACT-SIGART Symposium on Principles of Database Systems (PODS), Madison, WI, pp. 233–246 (2002) [29] Lud¨ acher, B., Gupta, A., Martone, M.E.: Model-Based Mediation with Domain Maps. In: IEEE International Conference on Data Engineering (ICDE), pp. 81–90 (2001) [30] Maedche, A., Volz, R.: The Text-To-Onto Ontology Extraction and Maintenance System. In: Workshop on Integrating Data Mining and Knowledge Management co-located with the 1st International Conference on Data Mining (2001) [31] Melnik, S., Decker, S.: A Layered Approach to Information Modeling and Interoperability on the Web. In: ECDL Workshop on the Semantic Web, Lisbon, Portugal (2000) [32] Mena, E., Kashyap, V., Sheth, A.P., Illarramendi, A.: OBSERVER: An Approach for Query Processing in Global Information Systems Based on Interoperation Across Pre-existing Ontologies. In: IFCIS International Conference on Cooperative Information Systems (CoopIS), pp. 14–25 (1996) [33] Morris, E., Levine, L., Meyers, C., Place, P., Plakosh, D.: System of Systems Interoperability (SOSI): Final Report. Technical Report CMU/SEI-2004-TR-004, ESC-TR-2004-004, Carnegie Mellon Software Engineering Institute, Pittsburgh, PA (April 2004) [34] Ng, W.S., Ooi, B.C., Tan, K.L., Zhou, A.: PeerDB: A P2P-based System for Distributed Data Sharing. In: IEEE International Conference on Data Engineering (ICDE), pp. 633–644 (2003) [35] Patel-Schneider, P.F., Siméon, J.: The Yin/Yang Web: XML Syntax and RDF Semantics. In: International World Wide Web Conference (WWW), pp. 443–453 (2002) [36] Popa, L., Velegrakis, Y., Miller, R.J., Hern´ andez, M.A., Fagin, R.: Translating Web Data. In: International Conference on Very Large Databases (VLDB), pp. 598–609 (2002) [37] Rahm, E., Bernstein, P.A.: A Survey of Approaches to Automatic Schema Matching. VLDB Journal 10(4), 334–350 (2001) [38] Renner, S.A., Rosenthal, A.S., Scarano, J.G.: Data Interoperability: Standardization or Mediation. In: IEEE Metadata Conference (1996) [39] Shklar, L.A., Sheth, A.P., Kashyap, V., Shah, K.: InfoHarness: Use of Automatically Generated Metadata for Search and Retrieval of Heterogeneous Information. In: International Conference on Advanced Information Systems Engineering (CAiSE), pp. 217–230 (1995) [40] Shvaiko, P., Euzenat, J.: A survey of schema-based matching approaches. In: Spaccapietra, S. (ed.) Journal on Data Semantics IV. LNCS, vol. 3730, pp. 146–171. Springer, Heidelberg (2005)


97

[41] Sunna, W., Cruz, I.F.: Structure-Based Methods to Enhance Geospatial Ontology Alignment. In: Fonseca, F., Rodr´ıguez, M.A., Levashkin, S. (eds.) GeoS 2007. LNCS, vol. 4853, pp. 82–97. Springer, Heidelberg (2007) [42] Sunna, W., Cruz, I.F.: Using the AgreementMaker to Align Ontologies for the OAEI Campaign 2007. In: Second ISWC International Workshop on Ontology Matching. CEUR-WS (2007) [43] Tijerino, Y.A., Embley, D.W., Lonsdale, D.W., Nagy, G.: Ontology Generation from Tables. In: International Conference on Web Information Systems Engineering (WISE), Rome, Italy, pp. 242–252(2003) [44] Tolk, A.: Metamodels and Mappings–Ending the Interoperability War. In: Fall Simulation Interoperability Workshop, pp. 748–761. IEEE CS Press, Los Alamitos (2004) [45] Tolk, A., Turnitsa, C., Diallo, S.: Implied Ontological Representation Within the Levels of Conceptual Interoperability Model. Intelligent Decision Technologies 2(1), 3–20 (2008) [46] Ullman, J.D.: Information Integration Using Logical Views. In: International Conference on Database Theory (ICDT), pp. 19–40 (1997) [47] Wache, H., V¨ ogele, T., Visser, U., Stuckenschmidt, H., Schuster, G., Neumann, H., H¨ ubner, S.: Ontology-Based Integration of Information–A Survey of Existing Approaches. In: IJCAI Workshop on Ontologies and Information Sharing (2001) [48] Xiao, H., Cruz, I.F.: Integrating and Exchanging XML Data Using Ontologies. In: Spaccapietra, S., Aberer, K., Cudré-Mauroux, P. (eds.) Journal on Data Semantics VI. LNCS, vol. 4090, pp. 67–89. Springer, Heidelberg (2006)

5 Complexity and Emergence in Engineering Systems Chih-Chun Chen1 , Sylvia B. Nagl2 , and Christopher D. Clack1 1 2

Department of Computer Science, University College London Department of Oncology and Biochemistry, University College London [email protected]

Abstract. The purpose of this chapter is to introduce the reader to the key concepts of complexity and emergence, and to give an overview of the state of the art techniques used to study and engineer systems to exhibit particular emergent properties. We include theories both from complex systems engineering and from the physical sciences. Unlike most reviews, which usually focus solely on one of these, we wish to analyse the ways in which they relate to one another, as well as how they differ, since there is often a lack of clarity on this.

5.1 Introduction and Chapter Outline The world economy, human body, financial markets and world wide web are just a few examples of complex systems with emergent properties. Such systems are composed of a set of constituents that together, through their interactions, give rise to one or more higher level properties or behaviours. These properties are often difficult to predict because interactions between the constituents are nonlinear (small differences at the local level can lead to very different outcomes at the global level) and the structure of their interactions tends to change dynamically. Scientists seeking to understand such systems therefore require special analytical methods and tools. At the same time, designers and engineers of information and communication systems have sought to exploit and control emergent properties arising from interactions between system components. Figure 5.1 shows a map of Complex Systems research. The two major disciplines are Complexity Science and Complex Systems design & engineering. Complexity Science can be further subdivided into generic concerns, where the goal is to develop special methods and tools for understanding complex systems in general, and domain-specific disciplines, which study a particular real-world complex system using these special methods. There is significant dialogue and exchange between these two branches since the development of methods can be driven by domain-specific needs. Complex systems design and engineering is concerned with developing systems that exploit emergent properties. These can be situated multi-component A. Tolk, L.C. Jain (Eds.): Comp. Sys. in Knowledge-based Environments, SCI 168, pp. 99–127. c Springer-Verlag Berlin Heidelberg 2009 springerlink.com

100

C.-C. Chen, S.B. Nagl, and C.D. Clack

Fig. 5.1. Map of Complex Systems research. There is currently a lack of much-needed dialogue between Complexity Science and Complex systems design & engineering.

systems, which satisfy some function through the collective action of the components, or algorithms, where a solution to a computational problem is arrived at in a distributed fashion. Complex systems design and engineering is also concerned with controlling emergent system behaviours so the system’s behaviour remains within an acceptable range. Although Complexity Science and Complex Systems engineering have many common concerns, dialogue between them is lacking. This chapter introduces the fundamental complex systems concepts and constructs from both the complex systems engineering and complexity science perspective. By considering the work of both these groups within a common framework, we seek to open up the possibility for dialogue by clarifying the main commonalities and differences. 5.1.1

Chapter Outline

The chapter will be structured as follows: – Section 5.2 introduces the key concepts of complexity, emergence and selforganisation, reviewing the different positions taken in the field. – Section 5.3 compares the main theories of emergence, focusing especially on those for distributed and multi-agent systems. – Section 5.4 will critically review techniques that have been used to specify and engineer specific emergent behaviours. – Section 5.5 concludes the chapter and outlines important challenges remaining in the field. – Section 5.6 suggests readings and resources for readers wishing to further pursue the topics described in this chapter.

5 Complexity and Emergence in Engineering Systems

5.1.2

101

Introductory Concepts and Terminology

Since this chapter assumes familiarity with certain terminology, and because terms are often used ambiguously, we first define the main terms used in the chapter. Systems, Subsystems and System Components. A system is a set of units, called its components or constituents, that are related to one another in some way. Any subset of the system’s components is a subsystem. Since much of the work in this area is in relation to multi-agent systems and simulations, we will also refer to agents, which are the components of multi-agent systems. Properties, Behaviours and Functions. A property of a component or system is anything about the component or system that can be detected. For example, a component in a particular state X can be said to have the property of being in state X i.e. state X is a property of the component. On this definition, structures, patterns and behaviours are all properties. When a system is in operation, the states of its components are changing through time. The collective effect of these changes in state during the course of the system’s lifetime can then be said to be its behaviour. Similarly, the behaviour of a component can be defined as the sequence of state changes it undergoes during a specified period of time. A designed system exists to serve some purpose, which is defined by the stakeholders and users of the system. The properties that the system must possess to realise this purpose are its functions. Similarly, the functions of a system component are the properties it must possess to contribute to the system realising its purpose. Relationships and Interactions. Components in a system can be related to each other in various ways. For example, one components might contain another or be coupled with another. A relationship can be said to exist between two or more components when the state of one component is in some way related to the state(s) of another component(s). The same applies to systems and subsystems. Interactions are a special type of relationship. To say that one component interacts with another is to say that its state plays some causal role in determining the state of another component. For example, in a rule-based system where rules are fired when a condition is fulfilled, an interaction between components A and B can be defined as the case where the firing of one of A’s rules is the consequence (either full or partial) of B being in a particular state. In contrast, non-interactive relationships are non-causal and can usually be reduced to a question of definition. For example, in a nested system where a component A contains another component B, we might define states such that A is in state qA1 when B is in qB1 .

102


5.2 Complexity, Emergence and Self-organisation Complexity, emergence and self-organisation are terms that are often found together. The relationship between them can be summarised as follows: Emergence occurs in a system when the system’s complexity increases by self-organisation i.e. without external intervention. Given the relationship between emergence and complexity, it is clear that any definition of emergence must assume some measure of complexity. However, to capture the various intuitions as to how the measure should change with particular system features, the measure adopted often depends on the particular domains and/or application. 5.2.1

Complexity Measures

The diversity of complexity measures described below and summarised in Table5.1 reflects the fact the lack of consensus in this area. Because different measures behave differently with repsect to certain system features (e.g. number of components, number of modules), they serve different purposes more effectively and therefore have different applications (also given in Table 5.1). For example, for systems with hierarchical structures, measures relating to modularity may be more useful than those that only consider algorithmic or statistical complexity. It is important to distinguish between the complexity of a system and the complexity of the design of the system. The design of a system is the set of rules or the program that generates it. Algorithmic complexity, statistical complexity and connectivity are measures that apply to the system itself since they try to determine how comlplex the design would have to be to generate the system1 . On the other hand, design size, logical depth and sophistication directly address the design of the object or the program used to generate it. Structure and organisation can apply to both the design of the system and the system itself. Measures can also be characterised according to how they behave when presented with different systems. For example, algorithmic and statistical complexity behave similarly for systems exhibiting regularity but differently for systems with random patterns of behaviour. The algorithmic complexity of a completely random system would be maximum (since each randomly generated event would have to be stored), but such a system would have a low statistical complexity since the system would be one of many (with which it would have no statistically significant similarities) that could be generated by the random source [49], [9]. Recently, complexity measures that do not take into account the hierarchical structure of the object/system, such as algorithmic complexity and connectivity 1

However, for designed systems, the number of symbols in the design program is often used as an approximation for the algorithmic complexity e.g. [54]. This is based on the assumption that the design program is also the minimal program, but it is not possible to show this conclusively i.e. that a shorter program could not have generated the system.


103

Table 5.1. System and design complexity measures Complexity measure

Definition

Main application

Alogrithmic plexity

Com-

Number of symbols of the shortest program that produces an object. The value for algorithmic complexity is always an approximation, since it is not possible to determine with certainty what the minimal program would be.) E.g. [17], [61].

Data generated by a program.

Statistical Complexity

Number of symbols of the shortest program that produces the statistically significant features of an object. E.g. [90], [91].

Data (usually time series) generated by a program.

Connectivity

The number of edges that can be removed before the graph representing the object is split into two separate graphs. E.g. [97], [35].

Objects with highly connected interacting components.

System structure and organisation

Function of the degree of connectivity between and within subsets of components. E.g. [97].

Objects with sophisticated hierarchical structures.

Design size

The length in symbols of the assembly procedure for an object. E.g. [54]

Logical depth

Computational complexity of the assembly procedure for an object i.e. the times it takes to compute the assembly procedure. E.g. [8]

Sophistication

The number of control symbols in the program that generates the object. E.g. [62].

Grammar size

The number of production rules in the program required to produce an object. E.g. [35].

Design structure and organisation

Function of the number of modules, the reuse of these modules and the degree of nesting. E.g. [54].

(alone), have been criticised for being counter-intuitive [97], [54]. It is argued that the complexity measure should be such that complexity increases both with increasing numbers of modules and with the degree of intergration between

104


these modules. The results of tests with different types of systems to see how different complexity measures behave are given in [54]. System Complexity. Here, we consider four measures of complexity addressing a system directly: (i) Algorithmic complexity; (ii) Statistical complexity (see Figure 5.2); (iii) Connectivity and (iv) Structure and organisation.

Fig. 5.2. Algorithmic complexity is the length of the minimal program that is able to generate the actual system/object whereas statistical complexity is the length of the minimal program that is able to generate the statistically significant aspects of the system

Algorithmic complexity [17], [61]. The algorithmic complexity of a system is the length of the smallest program that is able to generate the system. The shortest program can also be thought of as the most efficient design for the system. More formally, if we were to characterise the system as a string, the algorithmic complexity would be the number of symbols in the smallest set of grammar rules that could generate that string. (See Figure 5.2) Statistical complexity [90], [91]. The assumption underlying statistical complexity is that the system is one a set of possible systems that can be generated by a common source. The statistical complexity of the system is the length of the smallest program that is able to generate the statistically significant aspects of the system. These are the aspects that the system shares with the other systems that can be generated by the source.2 (See Figure 5.2) 2

Algorithmic and statistical complexity have in common the fact that they try to infer something about the complexity of the generating source or design of the system while connectivity and structure relate directly to the system itself.


105

Connectivity. The connectivity of a system refers to the extent to which its components are interconnected. It is easy to see this as a network or graph structure, where each of the nodes are the components [35]. Connectivity can then be determined by counting the maximum number of connections that can be removed before the system is split into two separate networks. Connectivity does not have to be static. In fact, one of the key features of complex systems is the fact that connectivity is dynamic, with changes in which components interact with one another i.e. the graph topology changes over time [44]. Sophisticated measures of connectivity are used in Neuroscience, which take into account selfconnectedness or re-entry and the fact that connections between components are often dynamic in a system and change with time [97]. (See also Figure 5.3) Structure and organisation. An especially high degree of connectivity between a subset of components can be interpreted as a module. These subsets can also show a relatively high degree of connectivity with each other, resulting in a hierarchical structure. One measure of system complexity is therefore its modularity and hierarchy, where a system with a high degree of modularity and hierarchy has a higher degree of complexity (e.g. [97]). Design Complexity. Measures of design complexity are those that relate to the design of the system components and the way they should relate to one another in a system. With traditional Systems design and engineering techniques, the distinction is more difficult to draw, since the system complexity is often a straightforward function the design complexity. However, if a system’s properties or behaviours can not be derived from the design because the interactions and connections between the components are dynamic, the relationship may not be as straightforward (see Figure 5.3). Here, we consider five design complexity measures: (i) Design size; (ii) Logical depth; (iii) Sophistication; (iv) Grammar size and (v) Structure and organisation. Design size. Design size is the number of symbols in the design program. Logical depth. Logical depth is the computational complexity of the system’s design program. Unlike design size, this would also take into account the number of times a particular procedure is executed to produce the system. Sophistication. Sophistication is the number of control symbols (e.g. selection statements, loops) in the program that generates the system. Grammar size. Grammar size is the number of rules in the design program that produces the system. Structure and organisation. In [54], structure and organisation includes measures of modularity, hierarchy and reuse. Modularity refers to the number of encapsulated group of elements in the design program that can be manipulated as a unit (in [54], this includes procedures). Hierarchy refers to the number of nested

106


Fig. 5.3. Design and system complexity. (a) In traditional design and engineering paradigms, the system complexity can be established analytically from the design complexity. (b) Paradigms that exploit emergent properties and behaviours are those where the relationship between design complexity and system complexity can not be established analytically simply from the design (even if they are discovered empirically to be related in some way). This is because in the system, the relationships and interactions between the components tend to be dynamic and constantly changing in ways that are not explicitly defined in the design.

layers of modules. Reuse is a measure of the average number of times elements of the design program are used to create the resulting design. Several measures are possible, depending on which elements are counted (e.g. reuse of build symbols vs. reuse of modules; see [54] for more details). 5.2.2

Self-organisation

Self-organisation is the process whereby some system property occurs solely from the behaviours and interactions between the system’s components. Theories of self-organisation tend to fall into one of three categories: 1. Complexity-based theories, which emphasise the description of the process of itself and characterise it as a shift in complexity. 2. Design-oriented theories, which emphasise the discrepency between the design of the system components and the functions the system is able to perform as a whole (without these being explicitly specified in the componenents’ deisgns). Self-organisation is the mechanism by which this discrepency is able to exist. 3. Environment-oriented theories, which focus on the ability of the system to adapt to its environment and tend to be interested in the occurrence of different system properties in response to different environments through self-organisation.


107

Fig. 5.4. Lower level properties give rise to a higher level emergent property, which in turn constrains the set of lower level properties that can be realised.

If a property or behaviour arising through self-organisation tends to promote itself, we say it is exhibiting autopeoisis [99]. Autopeoitic systems are those where the system components, through their interactions with one another and their individual behaviours, regenerate a set of interaction relationships (an interaction network). In the way, the interaction network reinforces and perpetuates itself. This idea is also closely linked with ‘downward causation’, where an emergent property constrains the properties that can be realised at lower levels; due to these constraints, the set of higher level properties that are able to emerge is also constrained (since these are dependent on the lower level properties). This is illustrated in Figure 5.4. In the Artificial Intelligence and Artificial Life literature, other ‘self-*’ terminology [31] is also used (e.g. self-managing, self-optimising, self-protecting). In the current discussion, we subsume these under self-organisation, since they are essentially special categories of self-organisation. However, we also believe that distinguishing between different sub-categories of self-organising properties when studying them is likely to lead to more detailed insight into the mechanisms unique to each category. Dynamic Shifts in Complexity. On one interpretation, self-organisation is the dynamic process that occurs when a system shifts from one level of complexity to another without any external input or guiding force (see Section 5.2.2). This interpretation relates to the complexity measures for the actual system (see Section 5.2.1 above) rather than to those for its design. The shifting of complexity is called emergence (see Figure 5.5).

108


Fig. 5.5. Shifts in complexity. A higher (a) or lower (b) complexity description of a system may emerge as the result of self-organisation.

A shift in complexity means a change in the description of the system. If we consider again the four measures of system complexity introduced above, we can interpret complexity shifts as follows: Algorithmic Complexity. A decrease in algorithmic complexity indicates that there is another algorithm or design that can generate the system’s behaviour more efficiently so that the current algorithm is no longer the shortest while an increase indicates that the current algoroithm is no longer sufficient to generate the system’s behaviour. Statistical Complexity. Similarly, a decrease in statistical complexity indicates that there is a shorter algorithm that can generate the statistically significant aspects of the system’s behaviour while an increase indicates that the current algorithm is no longer sufficient to generate the statistically significant features of the system’s behaviour. Connectivity. A change in connectivity means that a different number of components in the system are connected to one another. This implies that a higher or lower number of the components are involved in driving the system forward in its evolution i.e. a different number of components are required for the system to behave in a particular way. Structure and organisation. A change in structure and organisation is reflected in changes in connectivity between subsets of components. For example, highly connected components that initially functioned as modules might show a


109

reduction in connectivity so that the modularity and complexity of the system decreases. Design/Observation Discrepency in Multi-component Systems. With a more design-oriented interpretation, we might also say that a self-organised system is one where the behaviour exhibited by the system is not explicitly given in the design of any of its components. Instead, the interactions between the components together give rise to some property or behaviour of the system with no controlling component. System properties and behaviours that occur in this way (with no top-down control) are said to be emergent and the components of the system are often said to exhibit cooperative or coordinated behaviour (see Section 5.2.2). In systems which are intended to perform a particular function, self-organisation can be seen as the system’s ability to perform this function without this being explictly incorporated in the design. This means there is no one component or set of components whose purpose in the system is to ensure that the other components’ behaviours are coordinated in such a way that the function is performed. Instead, the components collectively give rise to an overall system behaviour that performs the function. Adaptivity to the Environment. Finally, a more environment-oriented and functional view of self-organisation focuses on the ability of the system to adapt to its environment in ways that have not been considered in the design ‘without explicit external command..’ [87]. 5.2.3

Emergence

Fundamental to the concept of emergence is the idea that there is a change in the way system components interact and relate to one another. Depending on the complexity measure chosen to characterise the descriptions of the system and/or its design, emergence can be seen to result in an increase or decrease in complexity. For example, in [10], emergence is defined as an unexpected complexity drop in the description of the system by a certain observer. When an observer observes a system at work, he has a theory about the rules governing the system. If the observer understands very little about the system, the set of rules he associates with the system’s behaviour will be very large, since every component of the system will have to be described independently. When the observer understands more about the system, he might be able to characterise its behaviour using a smaller set of rules. This smaller set of rules represents the lower complexity description and can be said to emerge from the larger set of rules representing the higher complexity description. 5.2.4

Summary and Analysis

The relationship between the different theories of complexity, self-organisation and emergence can be described by the following logical chain:

110


Fig. 5.6. Lower level properties give rise to an emergent property, which in turn constrains the set of lower level properties that can be realised.

Interactions between components → Self-organisation → Complexity → Emergent property → Constraints on interactions between components An important point to note is that the chain is not supposed to represent a temporal or causal sequence. Interactions between components both give rise to and constitute the emergent property, which in turn constrains the interactions between the components. The phenomenon of autopeoisis results when the constraints on the interactions perpetuate those same interactions. This is illustrated in Figure 5.6. Systems usually operate in a dynamic (as opposed to static) environment so that interactions between the system and the environment can influence the system’s operation (see Figure 5.7), giving the following logical chain (adapted from [22]): Environmental Change → Change in interaction graph3 → Shift in complexity → Self-organisation → Emergence of new property Again, no member of the chain is temporally or causally prior to any of the others. Unlike traditional design and engineering paradigms, designs that exploit emergent properties and behaviours are those where the resulting system has features that are not explicitly specified in the design. For this reason, their 3

An interaction graph represents the interaction relationships between a system’s components. Each node in the graph represents a component and the edges represent the interactions.


111

Fig. 5.7. The environment and the system together give rise to an emergent property, which in turn constrains the properties and interactions between the system constituents. If the system is also able to influence its environment, then the emergent property would also constrain system-environment interactions via the constraints on the system itself.

complexity can not be established analytically from the design alone (see Figurefig:TraditionalNew). More formally, if Cdesign stands for the design complexity, Csystem stands for the system complexity, and Csystem = f (Cdesign ), for traditional design and engineering paradigms, we can establish what the function f is from the design whereas for paradigms exploiting emergence, we can not.

5.3 Theories of Emergence Emergence has been a much-discussed subject in both the physical sciences and in engineering. Unfortunately, it is often seen as an area where there is little consensus and much confusion. However, we shall try to show that many of the apparent differences between definitions are not fundamental but simply due to different aspects of the phenomenon being emphasised. 5.3.1

Formalising the Micro-macro Relationship

The idea that a system can be observed and described at different levels of abstraction is central to most definitions of emergence e.g. [23], [25], [10], [26], [83], [86], [89], [5], [63]. In the Design and Engineering domain, this has tended to be formalised uing language-oriented definitions based on multi-agent systems (e.g. [26], [83], [63]), while those inspired by statistical mechanics used to study real systems (both

112


physical and social) tend to focus on relating the different scopes and resolutions of properties (e.g. [23], [89], [55], [56], [85]). Language-oriented Definitions. Language-oriented definitions (e.g. [26], [63]) require that the macro-level description is in some way ‘greater than’ the microlevel description i.e. the macro-level language has elements that can not be found in the micro-level language. A grammar can be seen as a formal computational device with a particular generative power i.e. it is able to generate a particular language or set of languages. In Kubik’s formalisation of emergence [63], the micro-level grammar LP ART S is determined by the sum of conditions that agents can bring about in the environment if they act individually in the environment. If the multiagent system can generate a language LP ART S that can not be generated by the summation of individual agents’ languages, it is said to have an emergent property. Similarly, Demazeau’s definition [26] refers to the discrepancy between the language represented by the whole system and the langauge represented by summing the parts. A description of the whole system consists of agents (A) in their environment (E) using interactions (I) to form an organisation (O). However, if we simply summed these different elements (A + E + I + O), we would not get the same result as if we considered the system as a whole. Since the micro-macro discrepancy on these definitions is inextricably linked to the design/observation discrepancy on these definitions, there is no reference to shifts in system complexity. Hierarchies, Scope and Resolution. In [55] and [56], two categories of hierarchy are described (see Figure 5.8): 1. Compositional hierarchy, where lower level properties are constituents of higher level properties. This can be seen to correspond to α-aggregation, the AN D relationship, or part-whole; 2. Specificity or type hierarchy where higher level properties are defined at a lower resolution than lower level properties. This can be seen to correspond to β-aggregation [55, 56], or the OR relationship. We can relate these two categories of hierarchy to the account of micro-macroproperty relationships given in [85], which defines a property P1 to be a macroproperty of another property P2 if: – P2 has a greater scope than P1 ; – P2 has a lower resolution than P1 ; or – both. The scope of a property is the set of constituents required for the property to exist; for example, the property of being a flock requires a minimum number of birds. On the other hand, the resolution is the set of distinctions that have to be made to distinguish the property; for example, to identify a colour, one


113

Fig. 5.8. Two categories of hierarchy. (a) Compositional hierarchy/α-aggregation: P2 , P3 and P4 are constituents of P1 . (b) Type hierarchy/β-aggregation: P6 , P7 and P8 fall in the set defined by P5 .

needs to be able to distinguish between a ranges of wavelengths. Informationtheoretic interpretations of emergence in dynamic systems are based on the idea that often, when we are considering a greater scope, we are willing to accept some loss of accuracy or a lower resolution when predicting future behaviour (see, for example [10], [88]). 5.3.2

Formalising the Design-Observation Discrepancy: Definitions of Emergence for Designed Multi-agent Systems

In the context of designed multi-agent systems, a defining characteristic of emergent properties and behaviours is that they arise ‘spontaneously’ without being explicitly specifed in the design. In other words, it is not possible to predict their occurrence simply from looking at the design program. For example, Ronald et. al. [83] suggest that a property can be said to be emergent if (i) the system has been constructed from a design describing the interactions between components in a language L1 , (ii) the observer is fully aware of the design but describes the behaviour of the system using langauge L2 , (iii) L1 and L2 are disinct and (iv) The causal link between the interactions described in L1 and the system behaviour described in L2 is non-obvious. This is somewhat controversial since it seems to make the

114


Fig. 5.9. A ‘law’ emerges when an emergent property P 1 constrains the properties and/or interactions of its constituents I1 so they give rise to another emergent property P 2 made up of interacting constituents I2

emergence classification of a property dependent on the observer’s knowledge i.e. whether or not the observer thinks the causal link between the L1 property and L2 property is non-obvious. A more objective criterion is given by Darley [25], who defines an emergent property as one ‘for which the optimal means of prediction is simulation’. In other words, given the design, it can only be deduced by stepping the evolution of the system, that the property will be present. 5.3.3

Top-Down ‘Causation’ and Emergent ‘Laws’

An important feature of emergent properties is that they can constrain or influence the properties of their components. Some even hold the position that this feature is mandatory for a property to be called ‘emergent’ (e.g. [92], [86]). The phenomenon of ‘autopeoisis’ described in Sections 5.2.2 and 5.2.4 is an example of this, since an emergent property sustains itself by constraining the interactions between system components so they perpetuate themselves (see Figure 5.10). More generally though, top-down constraints mean that a particular property P 1 that emerges from a set of component properties and/or interactions I1 make the appearance of a second set of interactions I2 more likely or certain (e.g. [6]). If I2 is also associated with an emergent property P 2, then a higher level ‘law’ will emerge that relates P 1 and P 2 (this might be deterministic or probabilistic). This is illustrated in Figure 5.9. Computational statistics techniques grounded in information-theoretic interpretations of emergence (see Section 5.3.1) can be used to identify statistical regularities or ‘laws’ that emerge e.g. [88], [89], [24], [91]. 5.3.4


Although there are several definitions of emergence in the literature, definitions tend to address one or more of the following:


115

1. the micro/macro relationship; 2. the design/observation discrepancy; 3. top-down ‘causation’ effects. In the context of designing and engineering systems with emergent properties, these characteristics present us with particular challenges. In particular, the design/observation discrepancy means that it is difficult to specify components to guarantee that their interactions give rise to the desired system behaviour.

5.4 Designing and Engineering Emergent Behaviours in Complex Decentralised Systems Recently, there has been significant interest in designing systems in such a way that the system’s successful operation depends on properties and behaviours that are not explicitly specified in the design i.e. the systems are decentralised and self-organising. For example, multi-agent systems are used in distributed planning and reasoning (e.g. [11], [46], [2]), and swarm algorithms (e.g. [60], [32], [67]) and other nature-inspired techniques such as genetic algorithms [48] and artificial neural networks [66], [64], [76] have been used to solve problems, including those that fall into the NP-complete class [51]. These systems are believed to be more robust and adaptive (see also Section 5.2.2) to their environment [52], [53] than traditionally designed systems with centralised control. In the case of problem-solving algorithms, distributed knowledge and information can be exploited to arrive at a solution. To exploit the emergent properties of a system, traditional methods for designing, engineering and analysing systems need to be replaced with new paradigms that take into account the discrepency between the design of the individual components and their collective behaviour in a system. Whereas traditional

Fig. 5.10. Autopeoisis. An emergent property P 1 constrains the properties and interactions between its constituents I1 so that I1 (and hence P 1 itself) is sustained or perpetuated.

116


engineering aims to ensure that components’ interactions with one another are predictable and controlled for successful system operation, emergence-based engineeering seeks to exploit the dynamic aspect of components’ interactions. When a traditionally engineered system fails to deliver its functionality, it is either because one or more of the components has failed or because a control has failed to operate. When an emergence-exploiting system fails to deliver its functionality however, it is usually because the components have interacted in such a way as to give some other, undesired, emergent behaviour. Importantly, the difference between traditional methods and emergence-based methods lies in the different relationship between the system’s design and the system’s functionality, not necessarily in any intrinsic feature(s) of the systems themselves. Emergence-based methods exploit the emergent features of the system and design the system in such a way as to promote the appearance of these emergent features whereas traditional methods do not exploit the emergent features (even though these may still appear4 ). This is expressed succinctly in [15], [43] and [45] by the following conditions that emergent-based designs satisfy: 1. The goal of a computational system is to realise an adequate function, judged by a relevant user. This function might be a behaviour, a pattern, or some other property that has to emerge. 2. This function is emergent if the coding of the system does not depend on the knowledge of this function. This coding has to contain the mechanisms facilitating the adaptation of the system during its coupling with the environment, so as to tend toward a coherent and relevant function. 3. The mechanisms which allow the changes are specified by self-organisation rules, providing autonomous guidance to the components’ behaviour without any explicit knowledge about the collective functin nor how to reach it. The methods and techniques reviewed in this section come mainly from the field of multi-agent systems. As with traditional Systems Engineering, the process of designing and then implementing the system is usually an iterative one that cycles (often several times) through the phases of: 1. 2. 3. 4.

Requirements gathering and analysis; Design; Construction (in software systems, this would include coding); Testing.

By definition, if we are exploiting the emergent properties of a system, it is not possible to predict with certainty that we will be able to from the design of its components alone. However, it may be possible to establish with a particular margin of error, how likely or with what frequency the property/behaviour will emerge, given a particular design. Choosing an appropriate and efficient method for doing this is itself difficult and can depend on the application. Gleizes et. al. [45] cite three main challenges in relation to engineering systems so they have the appropriate emergent behaviours for desired functionalities: 4

In fact, in come cases, the unexpected appearance of these features contributes to system malfunction and is a sign of bad design.


117

1. Controlling system behaviour at the macro level by focusing on the design of agents at the micro level. 2. Providing designers and engineers with the tools, models and guides to develop such systems. 3. Validating these systems. Correspondingly, the methods and techniques used in emergent systems design and engineering can be seen to fall into one or more of the following categories: 1. Design methods and methodology that allow designers and engineers to specify a system that exploits emergent behaviours. 2. Validation techniques. 3. Techniques for controlling interactions so that the appearance of desired emergent properties and behaviours is facilitated, and occurrence of undesirable behaviours is prevented. The first two of these are considered in Section 5.4.1, while the latter is considered in Section 5.4.2. 5.4.1

Design and Validation Methods

Design methods and validation techniques tend to be closely related. In the design phase, specifications for the system’s components are drawn up based on an understanding of how these components will interact when the system is in operation. These specifications themselves have to be validated to ensure they correctly reflect the requirements. Formal methods provide the strongest form of validation for this purpose (Section 5.4.1). However, the big challenge in engineering systems with emergent properties is in validating system behaviour as it would be in operation. For this purpose, empirical techniques are required (Section 5.4.1) Formal Methods to Validate Design Specifications. Formal reasoning frameworks can be used to validate design specifications by proving that the specifications entail the occurence or non-occurrence of certain interactions between components. Strong statements can therefore be made about the way the system should behave when implemented. Formal methods can be seen to fall into the following categories (although some methods cut across categories) [84]: 1. Model-oriented approaches, which involve the derivation of an explicit model of the system’s desired behaviour in terms abstract mathematical objects amalgamating the behaviour of the components. These can be further subclassified as: – Process algebras e.g. Calculus of communicating systems (CCS) [71], πcalculus [72], [36], ambient calculus [16]. These can be used to describe the interactions between components and prove that certain conditions are satisfied with respect to them.

118


–

Concurrency automata e.g. Petri nets [75], Statecharts [50], X-machines [57], [58], which include the details of components’ operational behaviour (X-machines have the additional feature of representing the internal states of components [57]). – Set-theoretic methods e.g. abstract state machines (ASM) [13], the BMethod [65], Z notation [93]. 2. Property-oriented approaches, which allow minimal constraints to be specified. These tend to be algebraic methods, which use axiomatic semantics based on multi-sorted algebras and relate system properties to equations over the system components e.g. BDI logic properties can be mapped down to linear temporal logic (LTL) [12] or branching time logic (CTL) [7]. Most of these frameworks also come have tools for model-checking [20]. Empirical Methods for Validating and Developing Decentralised Systems. Formal methods are unable to address the problem of implementing or (in the case of software systems) programming the components of systems to guarantee that the system will satisfy the design specifications [34], [33]. (This follows from Godel’s Incompleteness Theorem [47] and the fact that the ‘halting problem’ is an undecidable [98].) Although this is also true of non-emergencebased design, designers seeking to exploit emergent properties have the additional challenge of understanding how non-obvious behaviours can arise from a multitude of interactions. Empirical methods are therefore required to validate the system’s behaviour. The premise on which these are based is that “The behaviour of a system is only a hypothesis about the system’s behaviour - it must be checked by experimentation” [34]. One approach is global validation, which establishes that the system as a whole performs the desired function. Simulation and numerical analysis of the results can also be used to check whether the system’s performance falls within an acceptable range. Often, agent-based models and simulations have been used for this purpose. A related approach is to study certain coordination mechanisms such as those described in Section 5.4.2 and reuse them as design patterns [28], [27], [68], [42]. Analysis of these mechanisms using formalisms such as causal loop diagrams [81] can help us to understand the causal structures underlying them (e.g. positive and negative feedback loops) [96]. This more analytical understanding is important as it allows us to reliably synthesise different coordination mechanisms so they interact appropriately [94]. A formalism for relating behavioural motifs at different levels of abstraction has been introduced in [18] and its application in multi-level hypothesis testing is described in [19]. 5.4.2

Regulating Interactions

A significant amount of work has been done to try and understand which component interactions tend to lead to desirable emergent properties and behaviours (and which do not). Once this has been established (either through rigorous


119

proof or empirical studies; see Section 5.4.1), it is the task of the designer to put in place certain mechanisms to ensure these interactions take place (or, in the case of undesirable properties, do not take place). Mechanisms for regulating interactions between components in a decentralised distributed system fall into two main categories: – Protocols and rules, which act as a means of ensuring that the behaviour of every component in the system results in interactions that satisfy a set of constraints. These might require specific agent architectures and/or capabilities; and – Environmental artifacts and architectures, which allow components to communicate with one another through shared data spaces so that their interactions satisfy a set of constraints constraints. Here, there is only space to briefly refer to the more commonly cited examples, but the interested reader is advised to follow up on the references. For more details on coordination protocols, the reader should refer to the ‘Coordination, Organization, Institutions and Norms in Agent Systems (COIN)’ workshop series (http://www.pcs.usp.br/∼coin/). For more details on environmental artifacts and architectures, the ‘Environments for Multiagent Systems (E4MAS)’ workshop series (http://www.cs.kuleuven.be/∼distrinet/events/e4mas/) is a good place to start. Coordination Protocols and Local Regulation. Coordination protocols are rules that determine the set of permissible interactions between agents. While the precise set of protocols adopted for a particular system tends to be appli cation-specific, various models of interaction inspired by natural and social systems are often involved. Also, environmental architectures and artifacts (see below) often require specific coordination protocols and/or agent architectures to work e.g. the Influence-Reaction model [40] requires both that agents have a ‘physical’ aspect and that the environment is active. Examples of coordination protocols include: – Cooperation [38] and the detection of cooperation failure [77], where agents can coordinate their actions and share resources to achieve a goal; – Trust [79], [74] and reputation [80], where agents can evaluate the trustworthiness of their peers and find select suitable partners to interact with to achieve their goals; – Organisational metaphors such as roles and groups [39], [14], [21], [70], where roles provide context constraints for agents’ behaviours; – Norms obligations and institutions [4], [29], [100] where certain constraints govern agents’ interactions with one another in particular situations; – Gossip, where agents select peers to receive information from [59], [1]. Taxonomies of such protocols can be found in [30], [95] and [68].

120


Environmental Artifacts and Architectures. Environmental artifacts and architectures are used to mediate agent interactions, providing a means for agents to interact with each other reliably [78]. Examples include: – Interaction channels, where agents share and filter data by publishing and subscribing to repositories, which is responsible for sending (and blocking) messages to the appropriate agents. Examples include multicast interactions [3], shared memory and tuple-based approaches [41], and event-based interaction [37]. – Sychncronisation mechanisms, which can be centralised or decentralised. These hold the resulting effects of simultaneous actions until it is safe to execute them in the system. In centralised synchronisation (e.g. the InfluenceReaction model [40]), the data structures are accessible to all agents in the system whereas in decentralised synchronisation, the system is split into regions which each hold a group of agents that can act simulateously and independently from other agents in the system [101]. – Overlay networks, which restrict the set of agents that can interact with one another. Usually there are protocols that allow new agents to join and leave a network. Examples include distributed hash tables [82] and ‘ObjectPlaces’, which has view and role abstractions [102]. – Stigmergic mechanisms, such as pheremones [73] and fields [69], which allow agents to interact and share data indirectly. As agents move around in their enviornment, they can store data in their current location and this can be accesed by other agents (sometimes only within a given time frame). With fields, the data can themselves propogate according to certain rules that prescribe how they spread. 5.4.3


Designing and engineering complex systems with emergent properties is challenging because by definition, the appearance of these properties can not be established analytically from the design of system’s components. However, formal and empirical methods have been proposed to better inform designs: – Formal methods allow designers of these systems to express their design specifications unambiguously and prove that certain conditions and properties hold for specifications. – Empirical methods allow certain interaction patterns to be identified and reused in the form of protocols and environmental artifacts. Perhaps the most important criticism of emergence-based design principles is that although they are “compatible with the good average-case performance... they often conflict with a design’s predictability”. On the other hand, such systems may provide the only means of solving computational problems that would otherwise be too time-consuming to solve. Furthermore, by applying empirical methods and studying such systems, it is possible that we are able to achieve sufficient predictability (and reliability) for a particular purpose.


121

5.5 Conclusions This chapter has introduced the main concepts of complexity, self-organisation and emergence. As well as theories from the design and engineering of complex systems, we have also reviewed theories from the physical and complex systems sciences. Complex systems, whether designed or natural, are difficult to analyse because system properties and behaviours are driven by the collective properties and/or relationships between the system’s components. Designing and engineering such systems to exploit their emergent properties and behaviours is therefore inherently difficult; formal specification techniques need to be supplemented with empirical methods and analytical techniques. At the same time, scientists studying complex systems, either in the abstract or in specific domains such as Finance, Systems Biology, Earth Science, Ecology and Economics, face similar challenges. There therefore needs to be more mutual engagement between complexity scientists and complex systems engineers so that methods and techiques can be shared. One of the reasons such engagement has been slow to come about is the confusion surrounding terminology. This chapter has taken the first step to addressing this by clarifying the main distinctions and commonalities between different theories of emergence and complexity.

5.6 Resources and Suggested Readings Complexity Science is the umbrella term used to describe disciplines that study complex systems with emergent properties. It includes the development of methods for analysing and modelling such systems (e.g. network theory, dynamical systems analysis, statistical mechanics) as well as more domain-specific concerns (e.g. why do stock markets crash?). The reader wishing to learn more about these should refer to the Bibliography and Resource List. 5.6.1

Bibliography

– Axelrod, R., Cohen, M. D. (2001) Harnessing complexity: Organisational implications of a scientific frontier. Basic Books. – Bar-Yam, Y (1999) The Dynamics of Complex Systems (Studies in nonlinearity). Perseus Books. – Flake, G. W. (2000) The computational beauty of nature: Computer explorations of fractals, chaos, complex systems and adaptation. MIT Press. – Holland, J. (2000) Emergence: From chaos to order. Oxford University Press. – Resnick, M. (1997) Turtles, termites and traffic jams: Explorations in massively parallel microworlds. MIT Press. – Waldorp, M. (1992) Complexity: The emerging science at the edge of order and chaos. Simon and Schuster.

122


Acknowledgements The work presented in this paper is the result of a multi-disciplinary collaboration between the authors: Chih-Chun Chen (Computer Science: complexity science and multi-agent systems), Sylvia Nagl (Oncology: complexity science, systems biology and philosophy of science), and Christopher Clack (Computer Science: type systems, logics, rule-based and adaptive systems).

References 1. Allavena, A., Demers, A., Hopcroft, J.: Correctness of gossip-based membership protocol. In: Proceedings of the 24th ACM Symposium on the Principle of Distributed Computing (2005) 2. Atkins, E.M., Abdelzhar, T.F., Shin, K.G., Durfee, E.H.: Planning and resource allocation for hard real-time, fault-tolerant plan execution. Autonomous Agents and Multi-Agent Systems Journal (Best of Agents 1999 special issue) (1–2), 57–78 (March/June 1999) 3. Balbo, F., Pinson, S.: Toward a multi-agent modelling approach for urban public transportation systems. In: Engineering societies in the agents world II. Springer, Heidelberg (2001) 4. Barbuceanu, M., Gray, T., Mankovski, S.: Coordinating with obligations. In: Proceedings of the second international conference on autonomous agents, pp. 62–69 (1998) 5. Bedau, M.A.: Downward causation and the autonomy of weak emergence. Principia 3, 5–50 (2003) 6. Beer, R.D.: Autopoiesis and cognition in the game of life. Artificial Life 10, 309– 326 (2004) 7. Benerecetti, M., Cimatti, A.: Symbolic model checking for multi-agent systems. In: Proceedings of the model checking and artificial intelligence workshop (MoChArt 2002), held with 15th ECAI, Lyon, France, pp. 1–8 (July 21–26, 2002) 8. Bennett, C.H.: On the nature and origin of complexity in discrete, homogenou, locally-ineracting systems. Found. Phys. 16, 585–592 (1986) 9. Boffetta, G., Cencini, M., Falcioni, M., Vulpiani, A.: Predictability: a way to characterise complexity. Physics Reports 356, 367–474 (2002) 10. Bonabeau, E., Dessalles, J.L.: Detection and emergence. Intellectica 2(25), 85–94 (1997) 11. Bonabeau, E., Dorigo, M., Theraulaz, G.: Swarm Intelligence: From Natural to Artificial Systems. Oxford University Press, Oxford (1999) 12. Bordini, R., Fisher, M., Visser, W., Wooldridge, M.: Verifying multi-agent programs by model-checking. Autonomous agents and multi-agent systems 12, 239– 256 (2006) 13. Borger, E., Stark, R.: Abatrsct State Machines: A method for high-level system design and analysis. Springer, Heidelberg (2003) 14. Cannata, N., Corradini, F., Merelli, E., Omicini, A., Ricci, A.: An agent-oriented conceptual framework for systems biology. Trans. On Comput. Syst. Biol. 3, 105– 122 (2005) 15. Capera, D., George, J.P., Glize, M.P.: The amas theory for complex problem solving based on self-organising cooperative agents. In: The First International TAPOCS Workshop at IEEE 12th WETICE, pp. 383–388 (2003)


123

16. Cardelli, L., Gordon, A.D.: Mobile ambients. In: Foundations of Software Science and Computation Structures: First Interational Conference FOSSACS 1998. Springer, Berlin (1998) 17. Chaitin, G.J.: On the length of programs for computing finite binary sequences. J. Assoc. Comput. Mach. 13, 547–569 (1966) 18. Chen, C.-C., Nagl, S.B., Clack, C.D.: A calculus for multi-level emergent behaviours in component-based systems and simulations. In: Aziz-Alaoui, M.A., Bertelle, C., Cosaftis, M., Duchamp, G.H. (eds.) Proceedings of the satellite conference on Emergent Properties in Artificial and Natural Systems (EPNACS) (October 2007) 19. Chen, C.-C., Nagl, S.B., Clack, C.D.: A method for validating and discovering associations between multi-level emergent behaviours in agent-based simulations. In: Nguyen, N.T., Jo, G.S., Howlett, R.J., Jain, L.C. (eds.) KES-AMSTA 2008. LNCS (LNAI), vol. 4953. Springer, Heidelberg (2008) 20. Clarke, E.M., Grumberg, E.M., Peled, D.A.: Model Checking. MIT Press, Cambridge (2000) 21. Corradini, F., Merelli, E., Vita, M.: A multi-agent system for modelling carbohydrate oxidation in cell. In: Computational Science and Its Applications (ICCSA 2005: International Conference, Part II), Singapore, May 9-12, 2005, Proceedings, pp. 1264–1273 (May 2005) 22. Cotsaftis, M.: In: Aziz-Alaoui, M.A., Bertelle, C., Cotsaftis, M., Duchamp, G.H.E. (eds.) Proceedings of EPNACS 2007, Emergent Properties in Natural and Artificial Systems, Dresden, Germany, October 1–5, pp. 9–33 (2007) 23. Crutchfield, J.P.: The calculi of emergence: Computation, dynamics, and induction. Physica D 75, 11–54 (1994) 24. Crutchfield, J.P., Feldman, D.P.: Regularities unseen, randomness observed: Levels of entropy convergence. Chaos 13(1), 25–54 (2003) 25. Darley, V.: Emergent phenomena and complexity. Arificial Life 4, 411–416 (1994) 26. Demazeau, Y.: Steps towards multi-agent oriented programming. In: First International Workshop on Multi Agent Systems, Boston, Mass. (1997) 27. DeWolf, T., Holvoet, T.: A catalogue of decentralised coordination mechanisms for designing self-organising emergent applications. Technical Report CW 458, Department of Computer Science, K. U. Leuven (2006) 28. DeWolf, T., Holvoet, T.: Decentralised coordination mechanisms as design patterns for self-organising emergent applications. In: Proceedings of the Fourth International Workshop on Engineering Self-Organising Applications, pp. 40–61 (2006) 29. Dignum, F., Morley, D., Sonenberg, L., Cavedon, L.: Towards socially sophisticated bdi agents. In: Proceedings of ICMAS 2000 (2000) 30. d’Inverno, M., Luck, M.: Understanding agent systems, ch. 3, pp. 39–66. Springer, Heidelberg (2001) 31. Dowling, J., Cunningham, R., Curran, E., Cahill, V.: Component and system-wide self-* properties in decentralized distributed systems. In: Self-Star: Internatinal Workshop on Self*- Properties in Complex Information Systems (2004) 32. Eberhart, R.C., Shi, Y.: Particle swarm optimization: developments, applications and resources. In: Proceedings of the IEEE Congress on Evolutionary Computation, pp. 27–30 (2001) 33. Edmonds, B.: Engineering self-organising systems, methodologies and applications. In: Brueckner, S.A., Di Marzo Serugendo, G., Karageorgos, A., Nagpal, R. (eds.) ESOA 2005. LNCS (LNAI), vol. 3464. Springer, Heidelberg (2005)

124


34. Edmonds, B., Bryson, J.: The insufficiency of formal design methods - the necessity of an experimental approach - for the understanding and control of complex multi-agent systems. In: Proceedings of AAMAS, pp. 938–945 (2004) 35. Edmunds, B.: Syntactic measures of complexity. PhD thesis, University of Manchester (1999) 36. Esterline, A., Rorie, T.: Using the π-calculus to model multi-agent systems. In: Greenbelt, M.D. (ed.) Proceedings of the First International Workshop on Formal APproaches to Agent-Based Systems, vol. 1871. Springer, Heidelberg (2001) 37. Eugster, P., Felber, P., Guerraoui, P., Kermarrec, A.: The many faces of publish/subscribe. ACM Computing Surveys 35(2), 114–131 (2003) 38. Ferber, J.: Multi-Agents Systems: An Introduction to Distributed Artificial Intelligence. Addison-Wesley, Reading (1999) 39. Ferber, J., Gutknecht, O.: A meta-model for the analysis and design of organisations in multi-agent systems. In: Proceedings of the Third International Conference on Multi-Agent Systems (ICMAS 1998), pp. 128–135. IEEE Computer Society Press, Los Alamitos (1998) 40. Ferber, J., Muller, J.-P.: Influences and reaction: A model of situated multiagent systems. In: Second international conference on multi-agent systems, AAAI (1996) 41. Freeman, E., Hupfer, S., Arnold, K.: JavaSpaces principles, patterns, and practice. Addison-Wesley, Reading (1999) 42. Gardelli, L., Viroli, M., Omicini, A.: Design patterns for self-organising multiagent systems. In: Proceedings of EEDAS 2007 (2007) 43. George, J.P., Gleizes, M.P.: Experiments in emergent programming using selforganising multi-agent systems. In: Pˇechouˇcek, M., Petta, P., Varga, L.Z. (eds.) CEEMAS 2005. LNCS (LNAI), vol. 3690, pp. 450–459. Springer, Heidelberg (2005) 44. Giavitto, J.-L., Michel, O.: Mgs - a rule-based programming language for complex objects and collections. Electronic Notes in Theoretical Computer Science, 59 (2001) 45. Gleizes, M.-P., Camps, V., George, J.-P., Capera, D.: Engineering systems which generate emergent functionalities. In: Engineering Environment-Mediated Multiagent Systems (EEMMAS 2007). LNCS. Springer, Heidelberg (2007) 46. Gmytrasiewicz, P.L., Durfee, E.H.: Rational coordination in multi-agent systems. Autonomous Agents and Multi-Agent Systems Journal 3(4), 319–350 (2000) 47. Godel, K.: Uber formal unentscheidbare satze der principia mathematica und verwandter system i. Monatschefte Math. Phys. 38, 173–198 48. Goldberg, D.: Genetic Algorithms in Search Optimisation and Machine Learning. Addison-Wesley, Reading (1989) 49. Grassberger, P.: Toward a quantitative theory of self-generated complexity. International Journal of Theoretical Physics 25, 907–938 (1986) 50. Harel, D.: Statecharts - a visual formalism for complex systems. SCP 8, 231–274 (1987) 51. Harel, D.: Algorithmics - The Spirit of Computing, 3rd edn. Addison-Wesley, Reading (2004) 52. Holland, J.: Adaptation in Natural and Artificial Systems. MIT Press, Cambridge (1992) 53. Holland, J.: Emergence - from chaos to order. Oxford University Press, Oxford (2000) 54. Hornby, G.S.: Modularity, reuse, and hierarchy: Measuring complexity by measuring structure and organisation. Complexity 13(2), 50–61 (2007)


125

55. Johnson, J.: Hypernetworks for reconstructing the dynamics of multilevel systems. In: Proceedings of European Conference on Complex Systems (November 2006) 56. Johnson, J.: Multidimensional Events in Multilevel Systems, pp. 311–334. Physica-Verlag HD (2007) 57. Kefalas, P., Eleftherakis, G., Kehris, E.: Communicating x-machines: A practical approach for formal and modular specification of large systems. Journal of Information and Software Technology 45, 269–280 (2003) 58. Kefalas, P., Halcombe, M., Eleftherakis, G., Gheorghe, M.: formal method for the development of agent-based systems. In: Plekhanova, V. (ed.) Intelligent Agent Software Engineering. Idea Group Publishing, UK (2003) 59. Kempe, D., Dobra, A., Gehrke, J.: Gossip-based computation of aggregate information. In: Proceedings of the 44th IEEE Symposium on Foundations of Computer Science (2003) 60. Kennedy, J., Eberhart, R.C.: Particle swarm optimisation. In: Proceedings of the IEEE International Conference on Evolutionary computation, pp. 1942–1948 (1995) 61. Kolmogorov, A.N.: On the length of programs for computing finite binary sequences. Prob. Info. Transm. 1, 1–17 (1965) 62. Koppel, M.: Complexity, depth and sophistication. Complex Systems 1, 1087– 1091 (1987) 63. Kubik, A.: Toward a formalization of emergence. Artificial Life 9, 41–66 (2003) 64. Kung, S.Y.: Digital Neural Networks. PTR Prentice Hall, Englewood Cliffs (1993) 65. Lano, K.: The B Language and Method: A Guide to Practical Formal Development. In: FACIT. Springer, Heidelberg (1996) 66. Lau, C.: Neural networks, theoretical foundations and analysis. IEEE Press, Los Alamitos (1991) 67. Lovbjerg, M., Rasmussen, T.K., Krink, T.: Hybrid particle swarm optimiser with breeding and subpopulations. In: Proceedings of the third Genetic and Evolutionary Computation Conference (2001) 68. Mamei, M., Menezes, R., Tolksdorf, R., Zambonelli, F.: Case studies for selforganisation in computer science. Journal of System Architecture 52, 160–443 (2006) 69. Mamei, M., Zambonelli, F.: Field-based coordination for pervasive multiagent systems. Springer, Heidelberg (2006) 70. Messie, D., Oh, J.C.: Environment organisation of roles using polymorphism. In: Weyns, D., Van Dyke Parunak, H., Michel, F. (eds.) E4MAS 2005. LNCS (LNAI), vol. 3830, pp. 251–269. Springer, Heidelberg (2006) 71. Milner, R.: A Calculus of Communicating Systems. LNCS, vol. 92. Springer, Heidelberg (1980) 72. Milner, R., Parrow, J., Walker, D.: A calculus of mobile processes (i and ii). Inform. and Comput. 100(1), 1–77 (1992) 73. Van Dyke Parunak, H., Brueckner, S.A., Sauter, J.: Digital pheromones for coordination of unmanned vehicles. In: Weyns, D., Van Dyke Parunak, H., Michel, F. (eds.) E4MAS 2004. LNCS (LNAI), vol. 3374. Springer, Heidelberg (2005) 74. Patel, J., Teacy, W.T.L., Jennings, N.R., Luck, M.: A probabilistic trust model for handling inaccurate reputation sources. In: Herrmann, P., Issarny, V., Shiu, S.C.K. (eds.) iTrust 2005. LNCS, vol. 3477, pp. 193–209. Springer, Heidelberg (2005) 75. Petri, C.A.: Kommunikation mit Automaten. PhD thesis, Institut fuer Instrumentelle Mathematik, Bonn (1962)

126


76. Philippides, A., Smith, T., Husbands, P., O’Shea, M.: Diffusible neuromodulation in real and artificial neural networks. In: AI Symposium, Second International Conference on Cybernetics, Applied Mathematics and Physics: CIMAF 1999. Editorial Academia (1999) 77. Picard, G., Gleizes, M.P.: Cooperative self-organisation to design robust and adaptive collectives. In: Second International Conference on Informatics in Control, Automation and Robotics (ICINCO 2005), Barcelona, Spain, September 14– 17, pp. 236–241. INSTICC Press (2005) 78. Platon, E., Mamei, M., Sabouret, N., Honiden, S., Parunak, H.V.D.: Mechanisms for environmenrts in multi-agent systems: Survey and applications. Auton. Agent Multi-Agent Syst. 14, 31–47 (2007) 79. Ramchurn, S., Huynh, D., Jennings, N.R.: Trust in multiagent systems. The Knowledge Engineering Review 19(1), 1–25 (2004) 80. Ramchurn, S.D., Jennings, N.R., Sierra, C., Godo, L.: Devising a trust model for multi-agent interactions using confidence and reputation. Applied Artificial Intelligence, pp. 833–852 (2004) 81. Randers, J.: Elements of the System Dynamics Method. MIT Press, Cambridge (1980) 82. Ratnasamy, S., Karp, B.: Ght: A geographic hash table for data-centric storage. In: Proceedings of the international workshop on wireless sensor networks and applications, Atlanta. ACM Press, New York (2002) 83. Ronald, E., Sipper, M.: Design, observation, surprise! a test of emergence. Artifcial Life 5, 225–239 (1999) 84. Rouff, C., Hinchey, M., Rash, J., Truszkowski, W., Gordon-Spears, D.: Formal Methods and Agent-based Systems. Springer, Heidelberg (2006) 85. Ryan, A.: Emergence is coupled to scope, not level. Nonlinear Sciences (2007) 86. Sawyer, R.K.: Simulating emergence and downward causation in small groups. In: Proceedings of the Second International Workshop on Multi-Agent Based Simulation, pp. 49–67. Springer, Berlin (2001) 87. Di Marzo Serugendo, G., Gleizes, G., Glize, P.: Self-organisation and emergence in multi-agent systems. The Knowledge Engineering Review 20, 165–189 88. Shalizi, C.: Causal Architecture, Complexity and Self-Organization in Time Series and Cellular Automata. PhD thesis, University of Michigan (2001) 89. Shalizi, C.R., Crutchfield, J.P.: Computational mechanics - pattern and prediction, structure and simplicity. Journal of Statictical Physics 104, 819–881 (2001) 90. Shalizi, C.R., Shalizi, K.L.: Optimal non-linear prediction of random fields on networks. Discrete Mathematics and Theoretical Computer Science, 11–30 (2003) 91. Shalizi, C.R., Shalizi, K.L.: Blind construction of optimal nonlinear recursive predictors for discrete sequences. In: Chickering, M., Halpern, J.J. (eds.) Uncertainty in Artificial Intelligence: Proceedings of the Twentieth Conference. AUAI Press (2004) 92. Silberstein, M., McGeever, J.: The search for ontological emergence. The Philosophical Quarterly 49(195), 201–214 (1999) 93. Spivey, J.M.: The Z notation: a reference manual. Prentice-Hall, Englewood Cliffs (1989) 94. Sudeikat, J., Renz, W.: Toward requirements engineering for self-organising multiagent systems. In: Proceedings of the First IEEE International Conference on self-adaptive and self-organising systems (SASO 2007), pp. 299–302 (2006) 95. Sudeikat, J., Renz, W.: Building complex adaptive systems: On engineering selforganising multi-agent systems. In: Application of complex adaptive systems. IDEA (2007)


127

96. Sudeikat, J., Renz, W.: Toward systemic mas development: Enforcing decentralised self-organisation by composition and refinement of archetype dynamics. In: Engineering Environment-Mediated Multiagent Systems (EEMAS 2007). LNCS. Springer, Heidelberg (2007) 97. Tononi, G., Sporns, O., Edelman, G.M.: A measure for brain complexity: Relating functional seggregation and integration in the nervous system. PNAS 91, 5033– 5037 (1994) 98. Turing, A.M.: On computable numbers, with an application to the entscheidungsproblem. Proc. Lond. Math. Soc. 42, 230–265 99. Varela, F.: Principles of Biological Autonomy. Elsevier, New York (1979) 100. Vigano, F., Fornara, N., Colombetti, M.: An event driven approach to norms in artificial institutions. In: Boissier, O., Padget, J., Dignum, V., Lindemann, G., Matson, E., Ossowski, S., Sichman, J.S., V´ azquez-Salceda, J. (eds.) ANIREM 2005 and OOOP 2005. LNCS (LNAI), vol. 3913, pp. 142–154. Springer, Heidelberg (2006) 101. Weyns, D., Holvoet, T.: A formal model for situated multi-agent systems. Fundamenta Informaticae 63(2–3), 125–158 (2004) 102. Weyns, D., Vizzari, G., Holvoet, T.: Environments for situated multi-agent systems: Beyond infrastructure. In: Weyns, D., Van Dyke Parunak, H., Michel, F. (eds.) E4MAS 2005. LNCS (LNAI), vol. 3830. Springer, Heidelberg (2006)

6 Feature Modeling: Managing Variability in Complex Systems Christer Th¨ orn and Kurt Sandkuhl School of Engineering, J¨ onk¨ oping University P.O. Box 1026, SE-55111 J¨ onk¨ oping, Sweden {christer.thorn,kurt.sandkuhl}@jth.hj.se

Abstract. Complex systems offering a rich set of features to their users often cause a serious challenge to their developers: how to provide high flexibility with many possible variants for different application contexts and at the same time restrict the systems’ configurability in order to achieve maintainability and controlled evolution? Feature modeling offers an important contribution to solving this problem by capturing and visualizing commonalities and dependencies between features and between the components providing feature implementations. Since more than a decade, feature models have frequently been used in the area of technical systems and as an element of software product line implementations. This chapter introduces feature model fundamentals, an approach to feature model development and ways of integration into the system development process. Application examples are taken from the field of automotive systems. Keywords: Feature modeling, variability modeling.

6.1 Introduction Complex systems offering a rich set of features to their users often cause a serious challenge to their developers: how to provide high flexibility with many possible variants for different application contexts and at the same time restrict the systems’ complexity in order to achieve maintainability? An example from automotive industry illustrates this challenge: during the last 20 years, the number of electric and electronic sub-systems in a normal car has at least tripled. Most of these sub-systems are available in many different variants, for example in order to meet regulatory requirements from different countries or to fit to different models of a car manufacturer. At the same time, there is a clear tendency to customizing a car based on the customer wishes, which increases the need for adjustments of the sub-systems to customer-specific requirements even more. The German car maker BMW indicated in 2004 that only 2 out of 2 million cars produced at its plants have exactly the same configuration of sub-systems, special equipment or optional parts1 . Both from a supplier’s and a manufacturer’s point of view, it is of high importance to limit the variety of 1

Source: G¨ unter Reichart: Trends in der Automobilelektronik. Presentation at 2. ISST-Forum, Berlin, 28.-29. April 2004; Fraunhofer ISST.

A. Tolk, L.C. Jain (Eds.): Comp. Sys. in Knowledge-based Environments, SCI 168, pp. 129–161. c Springer-Verlag Berlin Heidelberg 2009 springerlink.com

130

C. Th¨ orn and K. Sandkuhl

Fig. 6.1. Examples for electric/electronic sub-systems in cars

the variants of single sub-system in order to achieve a reasonable efficiency in development and manufacturing processes. Figure 6.1 illustrates the increasing number of sub-systems in cars by showing examples from 1970 to 2000. The curve illustrates the exponential growth of efforts needed to integrate all these sub-systems in a car. Feature modeling offers an important contribution to solving this problem by capturing and visualizing commonalities and dependencies between features and between the components providing feature implementations. Over the past decade, feature models have frequently been used in the area of technical systems and as an element of software product line implementations. This chapter introduces feature model fundamentals (including a brief history, definitions of the term feature, feature classifications, constraints and relations, feature diagram notations), an approach to feature model development (including feature finding process and selected feature modeling tools) and ways of integration into the system development process. 6.1.1

System Complexity

The concept of complexity has been subject to numerous research activities in various application domains. In the context of this paper, project complexity and product complexity are of particular interest. A review regarding the concept of project complexity performed by Baccarini [1] proposes to define complexity as “consisting of many varied interrelated parts”, in order to distinguish between organisational and technological complexity, and to operationalise this in terms of “differentiation and interdependence”.

6 Feature Modeling: Managing Variability in Complex Systems

131

Differentiation refers to the number of varied elements, e.g. tasks or components; interdependence characterises the interrelatedness between these elements. Regarding organisational complexity, Baccarini identifies among other indicators the number of organisational units involved and the division of labour. For technological complexity, the diversity of inputs and output and the number of specialities (e.g. subcontractors) are considered. In the area of product complexity, Hobday defines complex products and systems as “any high-cost, engineering-intensive product, sub-system or construct supplied by a unit of production” [2]. Hobday’s work also investigates distinctive features of complex products and systems and identifies dimensions defining the nature of a product and its complexity. For example, list of critical product dimensions provided by Hobday includes: – – – – – –

quantity of sub-systems and components quantity of alternative component design paths complexity and choice of system architectures degree of customisation of products and variety of skills and engineering input intensity of supplier involvement.

The feature modeling approach in this chapter mainly addresses product complexity. However, a controlled complexity of the product will also contribute to the complexity of projects applying or tailoring complex systems. In the following, the term complexity will be defined as consisting of many varying inter-related parts offering a rich set of features and being combinable in many different ways. 6.1.2

When to Use Feature Models?

A generally accepted model for deciding when to use feature modeling still has to be developed. This is partly based on the many potential application purposes of feature models, which will be discussed in the next chapters. However, some characteristics of complex products and systems can be used to support decision making, like traditional industrial categories, physical nature of the system or product, and dependability and variety in the system. The traditional industrial categories of Woodward [3] include: – Continuous process (e.g. chemicals, fuel, cosmetics) – Mass products manufactured in line production (e.g. cars, household electronics, phones) – Large batch (e.g. metal cutting products, casting, plastic moulds) – Small batch products (e.g. industrial robots or ship engines) – Unit production (e.g. airports, traffic control systems, bridges) Within these categories, mass products and large batch products can be considered the core area for feature modeling. Continuous process, unit production and small batch usually are not suitable for feature modeling. Of course there is a grey zone between small batch and large batch products.

132


Fig. 6.2. Feature Modeling core application area

Within mass products and large batch products, the physical nature of the product also is of interest. Hughes [4] proposes to distinguish between assembly, component, system and system of systems. Assembly is, according to Hughes, stand-alone, mass produced and performing a single function. Component is a product performing a defined role in a larger system. A system has components, a network structure and a mechanism of control in order to perform a common goal. A system of systems is a collection of inter-related systems organized to perform a certain goal with the systems performing independent tasks. Within Hughes’ categorization, components and systems are the most interesting candidates for feature modeling. Furthermore, the number of variants and the degree of dependences between parts of the components and systems are interesting characteristics when deciding about using feature modeling. A high number of variants typically is caused by many different component or system architectures, alternative design paths or different implementation technologies. Indicators for high dependence between components and systems are wide technical interfaces between parts or an intense use of shared resources. Figure 6.2 illustrates the candidate area for feature modeling in this dependence – variant space. The most promising area is components or systems with a high number of variants and a high degree of dependence. A low degree of dependence or a low number of variants usually are not the perfect areas for using feature models, but there might be exceptions. If both characteristics are considered as low, feature modeling should not be considered.

6.2 Feature Modeling Fundamentals The purpose of a feature model is to extract, structure and visualize the commonality and variability of a domain or set of products. Commonality represents the properties of products that are shared among all the products in a set, placing


133

the products in the same category or family. Variability represents the elements of the products that differentiate and show the configuration options, choices and variation points that are possible between variants of the product, aimed to satisfy different customer needs and requirements. The variability and commonality is modeled as features and organized into a hierarchy of features and sub features, sometimes called feature tree, in the feature model. The hierarchy and other properties of the feature model are visualized in a feature diagram, see Fig. 6.3 for a simple example. The exact syntax of feature diagrams is explained further ahead in this chapter.

!

Fig. 6.3. An example of a partial feature model describing a car

6.2.1

History of Feature Modeling

The subject of feature modeling is tightly connected to domain engineering. Domain engineering aims at facilitating organized software reuse by modeling the accumulated knowledge and capabilities within the business area of an organization, commonly referred to as the business domain. Domain engineering is tightly connected with the concepts of software reuse. The term domain encompasses a limited and scoped part of the world and the concepts contained within that domain. The intention of modeling a domain is that as an organization constructs systems and conducts its business, it gathers experience and know-how.

134


As most systems constructed in the organization are likely to share technical characteristics and are designed to meet similar requirements, it is likely that the organization can benefit from the acquired knowledge as subsequent systems are constructed. The domain model is an understanding of the domain, organized to take advantage of the experience and working with resources proven to be of importance. Domain engineering is a systematic approach to reach a state where it is possible to utilize these resources and assets. The idea of domain analysis was introduced in the work conducted on software families in the mid 1970’s. The term domain analysis was coined in 1980 by Neighbors [5] and described as “the activity of identifying the objects and operations of a class of similar systems in a particular problem domain”. Over time several methods and ways to perform domain analysis were developed, with the more notable being Feature-Oriented Domain Analysis [6] and Organization Domain Modeling (ODM) [7]. A lot of work in the field of domain engineering and domain-based reuse of software was conducted in the research programs sponsored by the US Department of Defense, called Software Technology for Adaptable Reliable Systems (STARS) [8] and subprojects such as Central Archive for Reusable Defense Software (CARDS) [9]. These research programs spawned several variations and directions, among them the Software Engineering Institute’s (SEI) Software Product Lines (SPL) [10], ODM and several other methodologies and guidelines for domain analysis. Neighbors expresses the key idea of domain oriented reuse as “it seems that the key to reusable software is to reuse analysis and design; not code.” The original idea of what to be captured in the domain model resulting from the domain analysis was refined and revised with the methodologies developed. Where the basic idea of “objects and operations” from Neighbors remain, the advent of more advanced modeling tools, object-oriented modeling and other modeling methodologies meant that the domain model could be equipped with more advanced constructs, such as use-cases, feature models and concept models like class diagrams etc. [11] Software Product Lines (SPL), originating in the domain analysis and software reuse projects of the early 1990s, have taken a somewhat separate path than other projects and their descendants. Based on industrial experiences gathered by researchers at the Software Engineering Institute at Carnegie-Mellon University, SPL is a methodology that utilizes domain engineering and software reuse principles [10]. While SPL involve the same steps as the other domain engineering methodologies, SPL put a lot of effort into the aspect of management of the activities and the coordination and supervision of the phases involved in domain-based reuse. SPL-methodology also emphasizes the iterative nature of the execution of the activities, as well as the strong interactions between them. It is also understood that the activities do not necessarily follow a straight flow of events, but can occur in any order. This view is illustrated by the process diagram seen in Fig. 6.4.


135

Fig. 6.4. The overview of core activities in Software Product Lines. Adapted from [10].

The SPL workflow consists of three activities that are run independently of, but interacting with, each other. Core asset development together with management constitute domain engineering, whereas product development and management constitute application engineering. The concept of feature models was originally introduced in 1990 by Kang et al with the FODA (Feature-Oriented Domain Analysis) technical report [6]. The original use for feature models was to facilitate domain analysis, but has since been used in other domains. The original definitions, notations and concepts used by FODA have been extended and modified as various other uses for feature models have become apparent. Many examples of requirement abstraction, architecture specification, etc. have been put forward over the years [12, 13]. FODA was followed by the successor FORM (Feature-Oriented Reuse Method) [14]. A significant leap towards formalizing feature models was taken by Czarnecki and Eisenecker in Generative Programming [15], and further refinement of the feature model notation was published by Riebisch et al [16, 17]. Using features as a way to describe software and system functionality is considerably older than FODA, although it was FODA that introduced structured modeling of features. The idea was incorporated in many of the techniques for domain modeling and domain analysis which appeared during the 1990s, some of which briefly flashed into existence and went away, while others became successful and are used to this day. Today, feature modeling is an established and widely used technique which has been incorporated in many development methodologies and is the subject for interesting research. The original use for feature models as a means and aid to perform domain analysis was over time complemented with other uses, as the structuring of properties of a domain or product set into features turned out to be an efficient and communicative representation. Apart from domain analysis, there are two principal categories of uses, which most efforts can be sorted under. The first is to support the requirements management process for lines or families of products. By letting the capabilities of a product line be represented by features, requirements posed on the product by customers as well as internal

136


requirements can be abstracted into features. By letting a set of common requirements on a product be represented by a feature, one can achieve higher degrees of reuse. Using this approach, feature models can be used as a means of communicating information about the product to customers during requirements negotiation or sales, conveying implementation requirements to developers or a means to exchange information between other stakeholders. The second is to use feature models for configuration and automated construction of an instantiation from the product line described by the model. Ideally, this would mean that each feature would principally represent one or more components or source-level packages used to add functionality to the instance. The selection of features from the feature model would thus guide automated scripts, which would build the product with the requested functionality. [18] 6.2.2

The Feature Concept

The main concept of feature models is of course features. There are several definitions of the term feature used in conjunction with feature models. Some of them are more formal, while others are more intuitive. Features are intended to be concepts described by a single word or short line of text. These are some definitions found in literature: – From FODA by Kang et al: “A prominent or distinctive and user-visible aspect, quality, or characteristic of a software system or systems.” [6] – From Generative Programming by Czarnecki and Eisenecker: “Property of a domain concept, which is relevant to some domain stakeholder and is used to discriminate between concept instances.” [15] – From IEEE: “A software characteristic specified or implied by requirements documentation (for example, functionality, performance, attributes, or design constraints). [19] – From Riebisch et al: “A feature represents an aspect valuable to the customer.” [17] – From Bosch: “a logical unit of behaviour that is specified by a set of functional and quality requirements.” [20] The characteristic of user-visibility is interesting, as it places constraints on what should be considered features. One can argue that the definitions that consider user-visibility and the ones that do not are equally valid, if viewed from different perspectives. From an applied, practical and user-oriented view it is meaningless to include features in a model that would not add to the users perception of the product [21, 22]. The view of domain engineering would on the other hand want to include as much as possible of the domain information in a model, and would thus like to include all information relevant to any stakeholder. When discussing products that are part of larger systems in general and perhaps embedded systems in particular, the latter perspective serves better. While the original semantics of feature models was not very well-defined to begin with, further extensions and modifications of the feature models have


137

resulted in more and more semantic meanings being imposed on the relations, without really clarifying much. As the original tree structure is pushed back in favour of more general directed graphs with equivalent types of edges, the matter of clearing up the semantics is an interesting research question. 6.2.3

Feature Diagrams

The feature diagram is an essential part of a feature model. The feature diagram is the visualization of the feature model. It is a hierarchical decomposition of the features in the model, indicating dependencies and constraints for the commonality and variability of the product that is represented by the feature model. It usually has the form of a tree structure with the root node of the tree representing the concept that is described by the rest of the tree. The nodes and edges of the tree are usually decorated in a particular notation in order to indicate the dependencies and constraints placed on the features. It is not necessary to have the feature model organized into a tree structure, as there is nothing in the semantics of the relations that can be made between the features that restrict the constructions. It is possible to let the model take on a more general graph structure, but a tree is usually seen as more useful as it indicates more clearly the distinction between the different partitions of features in the model, as well as further levels of detail that are added when model users decide to choose the features. The information that is visualized in the feature diagram could easily and conveniently be contained in some other format for processing and storage, however one of the very points of models is the visualization aspect. We will therefore use the feature diagrams to introduce some of the semantics that has been introduced in feature models. There is substantial amount of information available concerning the notation of feature diagrams, as well as information suitable to be supplemented in a feature model, (for a more detailed comparison of notations, see [23]). The usefulness and necessity of the extensions made to the feature diagrams is debatable. While in some cases it certainly adds clarity and brevity to the notation, it is argued in [24] that they do not add any more expressiveness to the diagrams. This is of course not the case if the extension adds brand new notations and semantics that did not exist in the first place, such as the hint stereotype. 6.2.4

Feature Types

FODA listed three types of features: Mandatory. This type represents the common parts of a product, meaning that they are included in every configuration of a product where the parent of the feature is included. Mandatory features that are connected to the root concept, and the mandatory features of those features, form a core or stem in the feature model, which represent functionality that is always included in all configurations of the modeled product.

138


Optional. It represents the variability of a product. Depending on the functionality needed in the configured product, a feature of this type may or may not be included, if the parent of the feature is included. Alternative features. Out of a set of alternative features, only one can be included in a product configuration, provided the parent of the alternative set is selected. Each feature can either be a concrete feature that represents a concept that can be implemented and included in the product as a real function, or the feature could be an abstract feature. Abstract features, or pseudo-features, represent logical concepts that provide an abstraction or connection-point for a group of features, which in turn implement the abstraction and make it concrete. Generative Programming [15] adds the type OR-features, which is similar to the alternative features type, except that any non-empty set of the features can be included in the configuration, provided that the parent feature is included. This can then be combined with the other semantic types of features into a variety of different groupings like optional alternative features, optional OR-features and optional alternative OR-features, in order to allow for more variation in the minimum and maximum number of features selectable for inclusion in the configuration. There is also the concept of parameterized features which - if included - are assigned or assume a value of some type. An example would be the sampling interval of a sensor, or the fuel consumption of an engine. Assigning a type/valuepair could be extended to several type/value-pairs. There have been many different suggestions for classifications and categories of features. The original FODA proposes four feature categories: – Operating environments in which applications are used and operated. – Capabilities of applications from an end-users perspective. – Domain technology common to applications in a particular domain, exemplified by navigation algorithms from avionics. – Implementation techniques based on design decisions. No further motivation is given for this choice of feature classifications, other than that they make sense in many common cases. Based on taxonomies from user interface design, the capabilities class is further refined into functional features, operational features, and presentation features [6]. Yet another set of categories, referenced in [15], proposed by Bailin, speaks of operational, interface, functional, performance, development methodology, design and implementation features. Riebisch et al suggest a distinction of functional features expressing the way users interact with the product, interface features expressing the conformance to a standard or sub-system, and parameter features expressing enumerable, listable environmental or non-functional properties. The ground of this classification is that the feature model should serve as a customer view and that all other information should be captured in other models during design and implementation. The proposed classification therefore


139

reflects the customers’ view on a product and in what terms a customer considers a product’s functions and capabilities. While one could argue about what classification is the most useful, it is the domain of investigation and the application of the modeling technique that should guide which classification that is most suitable. There is no reason to use a classification scheme that does not make sense in the current context, and one could thus imagine many other ways of categorizing features in order to assist in the production and use of the feature model. All methodologies for feature and domain analysis recognize this very fact, and suggest that the categorization should be done based on the experiences in the domain and according to the intended use and context of the feature model. Interestingly, no author makes a clear-cut argument for the usefulness and purpose of classifying features, or makes any statements about the benefits that would come from using a classification scheme. There seems to be a general agreement among the authors mentioned above that the classification should serve as some sort of view on the system from the perspective of some stakeholder. This idea on classification does not seem very well thought through though, since classifications often do not appear particularly striking for any well-defined set of stakeholders. In other words, the classification schemes seem to be a relic from a requirements engineering work pattern. 6.2.5

Supplementary Information

Czarnecki also elaborates considerably on the use of supplementary information for each feature in the model, among others semantic description, rationale explaining why the feature is included and when the feature should be selected, stakeholders that have an interest in the feature, exemplar systems, constraints and priority. To include all this information in a feature diagram is not appropriate, which is instead maintained in a separate document accompanying the feature diagram. These attributes provide means for storing information in the model in order to widen the field of application for the feature models. While the purpose of modeling commonality and variability is still the focus, additional information makes it possible for more stakeholders to use the model in more contexts, where variability of the product is a useful abstraction. We list some of the more common and probably useful entries here, mainly as mentioned in [15]. Semantic description. Each feature should have a short description of its semantics. Rationale. An explanation of why the feature is included in the model and annotation of when the feature should be selected and when it should not be selected. Stakeholders. Each feature should have an annotation, which users, developers, software components, customers, client programs etc. have an interest in the feature. Exemplar systems. If possible, a feature could have a note on existing systems that implement this feature.

140


Constraints. Constraints are hard dependencies between variable features that dictate which features are necessary in order to ensure functionality. A description can also contain recommendations or hints on features required, given the inclusion of a particular feature. Availability and binding sites/mode. An availability site describes when, where and to whom a feature is available. An available variable feature has to be bound before it can be used. A binding site is the site where a variable feature may be bound. A site model could consist of predefined times, user actions, contexts, etc. The binding mode describes if the binding of the feature is static, changeable or dynamic. Binding site can serve as yet another way of classifying features in a model. Priority. A feature can have a priority assigned to it in order to reflect its relevance to the project or software line. There are several other entries that have been suggested. One is to allow a feature to be associated to a particular type such as integer or string which would allow the feature to assume a value. This is also referred to as attributes and allows a type/value-pair to be associated with each feature as mentioned previously. Fey et al. [25] talk of properties that are associated with features and that let the feature take on values in the same way. They go one step further though and discuss the possibility of dependencies and interactions between properties as well as between features. The interactions of the feature properties are described as some form of information flow between the features and the setting of one property in feature to a particular value would affect another feature through a “modify” relation. Some of the entries in the supplementary information are visible in the feature diagram, such as the constraints information and dependencies. The reason to include it also in written or non-pictorial form is to make it possible to add complex interdependencies that do not lend themselves to the graphical format. 6.2.6

Relations and Constraints

The organization of the features into a hierarchy often seems intuitive at first glance, but at closer examination the semantics of the hierarchical structure can be a bit confusing. The general idea of the hierarchy is to structure the features in such a way that when moving down the tree, higher degrees of detail are achieved and more detailed decisions on design are made. FODA hints that the semantics of the hierarchy is “consist-of”, and in FORM there are three different kinds of semantics, namely “composed-of”, “generalization/specialization” and “implemented-by”. Generative Programming states that the semantics of the hierarchy can not be interpreted without considering the features related and their types. The lack of semantics in the feature model is deliberate and the authors say that structural semantics should be placed in another more suitable model such as ER-models. Apart from the relations that arise as a consequence of the use of mandatory and optional features in a feature hierarchy, features in a model can also have


141

other interdependencies to one another that are not part of the hierarchy structure. FODA originally described two types of feature interdependencies, namely “requires” and “mutually-exclusive-with”. These hard constraints are used, for instance, to indicate that a manual transmission in an automobile is mutually exclusive with an automatic transmission. Whereas these constraints are sufficient for most purposes, they do not offer much flexibility and there could be modeling constructs that can not be accommodated using these basic relation stereotypes [17]. In [25], the authors construe the “provided-by” relation used to realize an abstract feature into a regular implementable feature. They also rename the “consists-of” relation to “refine”, and also loosen the boundaries between hard and soft constraints. Riebisch notes that the semantic difference between the relation that make up the hierarchy and the “require” relation is quite small. Also, the “mutex-with” and the alternative relations are similar in semantics and constitute different ways of achieving similar constructions in the feature model. See Fig. 6.5 for an example of a transition. Riebisch groups “is-a”/“partof” along with “requires” into the hierarchy, based on the features that exist at the endpoints of the relation. Generative Programming introduces so the called weak constraints, which can be used to indicate default dependencies for features, but can be overridden if necessary. Riebisch calls this particular type of relation for hint relation. Riebisch also adds the refinement stereotype, which is used to point to features that are significantly effected by the inclusion of a certain feature. Several other authors have added other kinds of constraints, relations and tracing mechanisms to feature models. [15, 17, 26, 27] In theory, one could adorn feature models with any amount of information concerning dependencies and tracing between features, but in practice the models tend to expand quite rapidly for anything but the simplest systems, even

Fig. 6.5. The equivalent constructions of the mutex and requires relations. Adapted from [17].

142


using the basic stereotypes. Using stereotypes is however a powerful means of expanding the semantics and abilities of the feature model. As previously mentioned, one use for feature models is to configure instances of product families, using reusable assets, components and packages. In order to create an instance, there must be relations between the features selected and the corresponding assets and building blocks. Different approaches to feature modeling manage the connection between features and artefacts in different ways. In FORM the artefacts corresponding to the features can consist of pre-coded modules, skeletons or templates that are parameterized. Generative Programming brings up generic programming, template-based C++, aspect-oriented programming and generators among other techniques.

6.3 Feature Model Development This section describes the notations, methodologies and tool support that can be used for developing feature models. We discuss the quality considerations that should be taken into account when developing the models and also relate an example of feature model development from the automotive domain. 6.3.1

Notations of Feature Diagrams

Development of notations for feature diagrams has been a quite lively research topic, along with developing meta-models for feature models. Various authors have developed, extended or modified the notations and semantics of feature models in order to cater for different needs that have occurred through the application of feature models in practice. We will not bring up feature modeling meta-models to any greater extent, as the notations for feature diagrams generally fully reflect the constructs in the underlying meta-model. The original notation for feature diagrams comes from [6] and contains the basic building blocks of feature models, such as mandatory, optional and alternative features and some composition rules such as dependency and mutual exclusivity. Figure 6.6 illustrates the notation for mandatory, optional and alternative features, as well as some composition rules. As the constructs in this first version of feature models are quite simple and fundamental, the notation and appearance of the feature diagrams is also un-elaborative and easy to understand intuitively. Figure 6.6 also illustrates how supplementary information about composition rules and rationale is included as textual information alongside the feature diagram, rather than as edges in the diagram with stereotypes added, as seen in later revisions of feature diagrams. Optional features are in this notation denoted by an empty circle, and groups of alternative features are denoted by an empty arc connecting the edges to the group features. The changes made in the successor of FODA, called FORM, introduce four layers in the feature model denoted capability layer, operating environment layer, domain technology layer and implementation technique layer. As seen in Fig. 6.7,


143

FORM uses the interdependency types generalization/specialization, composition and implementation, tracing these interdependencies across layers in the model. The resulting diagrams very quickly become hard to overview, but the problem is to some extent mitigated by not including the composition rules in the diagram. The decorations of the features are the same as those in FODA. FORM represents a substantial expansion of FODA, not so much in notation as in the application of the feature model, and the target of the model. By layering the information, the features are grouped in a way that illustrates decisions on design and implementation issues on different abstraction levels.

Fig. 6.6. The FODA-notation of feature diagrams. Adapted from [6].

In Generative Programming by Czarnecki and Eisenecker [15], the FODAnotation of feature diagrams is slightly modified and also extended to include OR-features. OR-features are features that are non-exclusive to each other, and one can thus include several of the features denoted to be OR-features rather than merely including one of the alternative features. Figure 6.8 illustrates the notation used by Czarnecki and Eisenecker. Mandatory features are here decorated with a filled circle, while optional features have an empty circle. OR-features are indicated using a filled arc between the edges of the group of alternative features. In [17], Riebisch makes further extensions to feature models by adding more stereotypes to relations between features such as hints and refinement. He also suggested changes in [16], with the use of multiplicities to denote the choices of features. Figure 6.9 illustrates some of the changes and additions made by Riebisch. Previous notations use the composition rule of feature/sub feature and alternative features to implicitly indicate the relations requires and excludes, and complement this with the use of textual information describing composition rules. In Riebisch notation, stereotypes are added to additional edges between features to indicate these types of dependencies. This makes it possible to model the features a bit more freely in the decomposition hierarchy, while not sacrificing the possibility to denote hard and soft constraints in the diagram. The choice

144


,

"#

!

$

-#&

& '

( ) '

"#

%

$

*$! ' $ ' ( '

, ! &,

$$ '

&

$ '

*&& '

"' ! &,

%

$ ' '&

$ '

!+ %

&) ' $ '

( )

' $ '

)

#)

. / . && ,

,! &,$$ '$ ' 0 ( ) '*$!' 0

Fig. 6.7. The FORM-notation of feature diagrams. Adapted from [22].

of whether to include such constraints as objects in the diagram or whether to use information in textual or other formats apart from the diagram, is up to the user and the tools that are available to facilitate, not only the construction of the model, but also the use and understandability of it.

Fig. 6.8. The Eisenecker-notation of feature diagrams. Adapted from [28].


145

%(()

$

% '

$

!"#

&

.. ,

,

-(()

*

" + ' * $ "

Fig. 6.9. The Riebisch-notation of feature diagrams. Adapted from [16].

A notation for parameterized features is also introduced in this variant of the feature diagram notation. By using multiplicities in the arcs of optional groups, the notation is cleaned up, and the need for OR-features and alternative feature groups is eliminated. The use of multiplicities is similar for instance to UML, where a range on the form 2..* indicates that at least two features have to be selected, and the maximum number of features allowed to be selected is unbound up to the total number of features in the group. 6.3.2

Feature Modeling Methodologies

FODA and its successor FORM share most characteristics with each other and most subsequent methodologies for feature analysis are heavily based on FODA, which makes understanding of the FODA-process a prerequisite to understand most methodologies on the subject. The general feature analysis process consists of: 1. 2. 3. 4. 5.

collecting information sources identifying features abstracting and classifying features into a model defining the features validating the model.

146


Documentation is one of the information sources used for finding features, such as user manuals, requirement documents, design specifications, implementation documentation and source code. Apart from product documents, one can also use standards, textbook material and also domain experts. When processing the sources for potential features one should take care to resolve ambiguity in the meaning of concepts. Understanding the language of a domain is generally regarded as an effective way of finding possibilities for features. Once features are identified, they should be classified and structured into a hierarchical model using the consists-of relationship. During the modeling, each feature should be indicated as being mandatory, optional, alternative, etc. Each feature should also have resolved dependencies, and should be supplied with additional information. In order to ensure that the feature model is made as complete and useful as possible, it should contain features from both high levels of abstraction such as functional and operational features, as well as more technical features representing implementation details. The structure of the feature hierarchy could be quite varied. For instance, one should consider whether two features in different parts of the feature model, which are mutually exclusive should instead be organized as neighbouring alternative features. Once the model has been completed, it should be validated against existing applications and by domain experts. Preferably the validation should be made by domain experts not part of the construction of the model, since they are less likely biased. It could also be useful to validate the model against at least one application that was not part of the material analyzed for the model. Further details on the methodology are found in [6, 14]. Czarnecki and Eisenecker provide a feature modeling process in [15], which identifies sources for features, discusses strategies for finding features, and the general steps taken in feature modeling. As sources of features, the authors mention not only existing, but also potential stakeholders, domain information available from domain literature and domain experts, existing systems, and existing models. The existing models could be available object models, use-case models and other models created during design and implementation phases of the software development. For identifying features, it is important to remember that anything that a user might want to control about a concept could be a feature. Czarnecki and Eisenecker therefore consider implementation techniques and other implementation issues as features to be considered. The book suggests looking for features at all points of development and investigate more features than what are intended to be initially implemented in order to give room for some growth in the future. At some point in the process, there should be a scoping activity where the features to be implemented are agreed on. At this point the use of priorities for the features is important. The book describes a “micro-cycle” of feature modeling, which follows the standard workflow of identifying similarities between all instances of the products, record the differences between instances, that is variable features, and then organize them into diagrams. After this the feature interaction analysis ensues,


147

during which contradicting dependencies are resolved. This could lead to the discovery of feature interactions and combinations that were not discovered initially. This workflow is similar to that of requirements engineering. FeatuRSEB [29] is a methodology that integrates features and the RSEBmethod, where feature models complement other models by showing which functionality can be selected when engineering new systems. The feature model is used as the connecting model among several others that are constructed as part of the work. The feature model is developed in conjunction with the other models and is step by step extended and refined with more information. Construction of feature models in FeatuRSEB starts from use-case models, where individual use-case models are merged into a common domain use-case model using variation points to model the variability in use-cases. After this an initial feature model is developed with functional features derived from the domain use-case model. Using the RSEB analysis model, the feature model is extended with architectural features relating to system structure and configuration. The final model to be developed alongside the feature model is the design model. The feature model is augmented with implementation features as a result of this modeling effort. 6.3.3

Feature Model Quality

As previously mentioned in this chapter, the application fields for feature models have expanded over time and there are now many usage scenarios that could make an organization consider developing a feature model. In order to make the most of the feature modeling efforts, it is important to do proper scoping of the domain covered by the model. But it is also important to consider the scenarios in which the model will be used and the restrictions and constraints that the model is subject to. To ensure that proper attention and effort is given to the crucial parts of the feature model under development, given a stated goal and purpose of the model, the effects of properties of the feature model on various qualities such as usability, formality, complexity etc. need to be explored. Certain properties of the feature model would affect the potential for successfully using it in context, and depending on how the organization developing the model intends to use it, there are properties and attributes of the feature model that deserve special attention and priority. The business domain in which the feature model is to be used also leads to factors that influence the best practice for developing the feature model. There are methods developed for evaluation of software reference architectures, that use scenario-based approaches to determine if early design decisions made for the system in question meet the critical quality constraints formulated. The constraints are based on quality attributes of the architecture that have been prioritized as the most important for the scenario considered. It is recommendable to have the stakeholders of a model to be developed decide early on which

148


qualities of the feature model are essential, and which qualities can be traded for others. For example, having a model with high accuracy and correspondence to the product family can be expected to have a positive influence on usability and make the model easier to communicate and learn. However, a model with plenty of details and information could also be harder to modify and evolve. Depending on how the feature model will be used, decisions on what quality attributes have precedence should be made. 6.3.4

Tool Support for Feature Modeling

Although feature models are employed in quite large operations and organizations, tool support is somewhat scarce. While major tool vendors provide a variety of tools for almost every step in software development, feature modeling is mainly treated in tool suites for development of software product lines and software families, and those tools are generally made by smaller vendors. The first tools for feature modeling were developed by researchers and research groups as prototypes to illustrate some aspects of feature modeling. Most of those tools were made to demonstrate proof of concepts rather than to support practical use and are insufficient for most modern applications of feature models. Tool support and visualisation for feature model development continues to receive attention from researchers with most of the efforts being made under the development of tools for software product lines, e.g. [30]. For commercial systems there are some systems that were based on research work and then grew into commercial systems, as well as some tools designed from the ground up into tool suites that can be used for feature modeling. Pure::Variants is a commercial tool developed by pure-systems, a spin-off of Otto-von-Guericke-University Magdeburg (Germany) and the FraunhoferInstitute Rechnerarchitektur und Softwaretechnik. Pure::Variants is based on the CONSUL-approach [31] to variation and product line management, and the methodology makes extensive use of feature models. The workflow is centred around feature models used for describing the capabilities of the product line in a problem space and the components, parts and sources of the product line in a family model. The instances of the product line are configured using selections from the feature model. The tool is a plug-in for Eclipse and is also available in a community version with some limitations. Pure::Variants is the tool that was used in the project described in the next section. 6.3.5

Practical Feature Modeling

This section describes parts of a research project by the authors in which feature models were developed. The feature model described here was developed as part of the research project in cooperation with a leading automotive supplier of safety equipment. It is an initial model describing the structure of the safety equipment manufactured by the supplier from a customer/end-user


149

Fig. 6.10. An example of a feature model in graph format

perspective. It was developed using documentation from a number of use cases and abstracting the commonality and variability accordingly. The documentation consisted of the requirements specifications and definitions from a number of projects carried out by the supplier. Each use case provided a customer specification, detailing the needs and demands posed by the customer on the product line described in the feature model. For each use case there is also a system and software specification of the requirements, describing the actual implementation fulfilling the customer needs. Thus, both the problem domain and the solution domain was covered. The model was developed using Pure::Variants. The feature model is depicted in Fig. 6.10 as a graph. In Pure::Variants notation mandatory features are decorated with an exclamation mark (!), optional features are shown with a question mark (?) and feature groups are shown with a double arrow.

150


The model contains relatively few feature groups and restrictions while having a significant number of optional features, which is consistent with the results reported from the development of other industrial feature-models for software intensive systems. Using the information in the source materials, the feature model was developed from the perspective of the customer. The features seen in the model are features that are important to the customer stakeholders of the model. The features focus on the sensors and actuators in a safety system for automotives and have a granularity that makes it suitable for configuring the different options of the products that are needed by car manufacturers as they produce various series and configurations of their products. As Pure::Variants offers the facilities for developing family models of the solution space for the feature models, two such models were also developed. The first family (solution) model, on the left of Fig. 6.11, is focused towards the hardware aspects of the solution space, while the second family model, on the right of Fig. 6.11, describes a software (runtime) perspective. The runtime system does not describe the current software system for the product line at the automotive supplier, but rather an envisioned modularity which would encourage reuse. The family models are developed for the perspective of developers and configuration management staff. They are thus not intended to portray end-user visible aspects of the system and product line. The hardware family model was developed with a component perspective in mind and focuses mainly on the sensors and actuators found in the system. The runtime family model focuses on the algorithms in the system that transform data between sensors and actuators, such as gyros or accelerometers and firing squibs of airbags and seat belt tensioners. In between the feature model and the family models there are relations that are used for configuring the system in various ways. The relations between the features and the family model principally follow the same types of relations as those found between features, such as inclusion and exclusion. By selecting a feature combination that is validated using the relations in the feature model, parts and components from the family models are included in the system. Depending on how the tools are set up, one can create a build environment, specification, documentation or configured software system from the feature selection. The models constructed are just a subset of what would be required for a complete set, capable of supporting a domain engineering oriented workflow. One major part of the workflow used in this project is to connect the requirements and solution space to actual artefacts, i.e. creating the relations necessary between the feature model and the family models. This work represent the largest share of the modeling efforts needed to introduce domain engineering in an organization, and requires a lot of domain expertise. It is also important to include the strategic perspective in order to ensure that the results cater to future needs and can accommodate any predictable extensions or modifications to the product family.


Fig. 6.11. The family models of the hardware and runtime systems

151

152


6.4 Feature Models in System Development Process The development of feature models can create numerous benefits for the organization or the system under consideration. To capture and express all existing features and their dependencies helps for example spreading the knowledge about the product and could be used in many different activities from preparing customer offers and requirement analysis to configuration management and competence development. However, the full potential of feature models will only be reached in most organizations, if the system development process is taking advantage of the knowledge captured in feature models and if at the same time the feature model is kept accurate and up-to-date. The integration of feature modeling in systems development processes can be addressed in different ways. We will in the following sections present and discuss two approaches illustrating the bandwidth of possibilities: – The first approach is among many scholars in the field of software engineering and systems engineering considered as the most sophisticated and desirable way. The core element here is the implementation of domain engineering principles. – The second approach is starting from the established system development process and using feature modeling for the support of selected activities. We will use SPICE for illustrating this way. 6.4.1

Domain Engineering

While conventional systems engineering aims at satisfying the requirements for single systems, domain engineering produces assets usable to satisfy the requirements of a family of systems. [15] refers to areas organized around particular classes of systems as vertical domains, and parts of systems organized by functionality are referred to as horizontal domains. For software systems, domain engineering along a horizontal domain would result in reusable software components for user interfaces, communications etc., that are shared across several products in the software family. Domain engineering along a vertical domain would result in frameworks that could be instantiated to produce any system in the domain. The modeling of vertical domains should be done using several horizontal domains. Figure 6.12 illustrates the connection between system engineering and domain engineering. System engineering consists of several phases as described below and illustrated in boxes 1 to 6. The artefacts developed during system engineering are subject of reverse engineering activities in order to derive contributions to the domain model. Domain engineering aims at developing and maintaining artefacts that can be the basis for system engineering projects. This is illustrated in boxes A to F and described in the following section. Supportive functions for both, system and domain engineering, are shown in the middle of the figure and include change management and configuration management.


System & Application Testing

Systems Engineering 1 System Definition

153

2 System Economical Analysis

3 System Analysis/ Design

4 Application Analysis

5 Application Design

6 Application Implementation

Derivation activities

Traceability System Engineering

Configuration Management

Change Management

Reverse Engineering

Core Assets

Reverse Engineering activities

A Scoping Domain Engineering

B Economical Analysis

C Domain System Analysis/ Design

D Domain Analysis

E Domain Design

F Domain Implementation

Domain Testing

Fig. 6.12. Overview to Systems and Domain Engineering (adopted from [32])

The Domain Engineering workflow. The domain engineering workflow consists of three major phases, domain analysis, domain design and domain implementation, each described below. The domain analysis is the fundamental activity in domain-based software reuse and is typically the activity that initiates the whole process of adapting an organization to domain-based reuse. It is also the activity that has received most attention from researchers over the years. The domain analysis corresponds to the activities that would be carried out for any single system or software, but broadening the focus to a family of systems instead. The first part of domain analysis is domain scoping. During this activity, the focus, boundaries and limits of the domain to be modeled are defined appropriately. While not making the scope too wide, which would reduce the chances of the organization being viable and able to successfully conduct their business, the scope does have to accommodate the potential of the domain in the future. It is important to use a scope that allows for sufficient flexibility in the products that are to result from the development, but not let the scope of the domain stray so that the core assets can not accommodate the products. This would lead to a return to the classical development of one product at a time and one would loose the benefits that one hopes to achieve through software reuse. The scope should also identify the stakeholders and their interests that influence the domain. The stakeholders of the domain include managers, developers, investors, customers, end-users and so forth. It is argued that the delimitation of the domain is in fact the range of interests that the stakeholders have. The scope evolves as changes in market, organization and environment comes about.

154


Scope is determined on the grounds of marketing reasons and on technical basis. While a set of products might together satisfy a particular market segment, there could as well be a sensible set of products sharing technical characteristics that would make for a good software family. The term product family traditionally refers to a group of products that can be built from a common set of assets, based on technical similarity, whereas the term product line refers to a group of products sharing a common set of features that satisfy a need, based on marketing strategy. The distinction between product lines and product families is quite blurred and the terms are sometimes used interchangeably in the literature. The second part of domain analysis is the domain modeling, in which the domain model(s) are produced. The domain model is the explicit representation of the properties, semantics and dependencies of the concepts in the domain. It would typically be a set of different components and models, each describing one or more aspects of the system from a domain modeling perspective. Rather than all domain knowledge be contained in one single model using a particular modeling language and notation, the strengths of a variety of modeling languages models can be utilized. The following components of a domain model are listed by Generative Programming [15]: Domain definition. Defines the scope of the domain in order to determine which systems are encompassed by the domain and the rationale for inclusion and exclusion of systems for the domain. Domain lexicon. A taxonomy defining the domain vocabulary as it is understood by the practitioners in the domain. Concept models. Various models used to describe the concepts in the domain formally. This means models such as class diagrams, interaction diagrams, etc. Apart from formal models, this could also include informal textual descriptions. Feature models. Generative Programming puts emphasis on feature models as an important contribution to domain modeling and places feature models outside the other concept models. Feature models describe the meaningful combinations of features and functions of the products in the domain, hence the commonality and variability of the software family. Domain design is the subsequent activity of domain analysis that takes the domain model, and develops an architecture and production plan for the family of systems to be built from the assets in the domain. The architectural design resulting from this activity prescribes how the components and assets are to be assembled to satisfy the requirements that can be posed on the family. The architecture has to be constructed in order to accommodate all the variability possible in the family. Since the architecture is a description of the components available in the system family and the composition constraints placed on their interactions, one can see a close connection to the descriptions in the feature model. The architecture should not only consider functional descriptions, but also non-functional requirements, such as performance, compatibility and so on.


155

The production plan describes the process of how to assemble the components, how to handle change requests, custom development and adoption of the assets to special requirements and the evolution of the measurements and processes used in the development of incarnations of the family. Once the domain design has been completed, it is followed by the domain implementation phase which involves implementing the components, languages, development processes and other assets designed. It also involves building the infrastructure used to realize the reuse of the assets in the domain model. That is, the interfaces and storages to find, access and assemble the components to instantiations of the product family. The System Engineering workflow. The system engineering work builds products and configurations of the software family using the reusable assets that result from the domain engineering phases. The system engineering workflow is intended to be carried out in parallel with the domain engineering activities, but while there is one instance of the domain engineering workflow for each product family, the system engineering workflow exists in several instances, one for each product to be produced in the software family. Figure 6.12 should thus not be interpreted as if the system engineering and domain engineering activities are running synchronously with each other, but rather illustrates the flow of assets, results and information between the phases involved. The domain engineering workflow is iterative and constantly updates the assets and expands the capabilities of the organization with regard to what sort of products the organization can provide. The process of developing systems based on the reusable assets is iterative as well, not only in that the product is released in new and updated versions, i.e. maintenance, but also in the application of iterative software development processes to the development of the systems. For instance, the system might be developed using prototyping, where new versions of the prototype system are produced as assets are implemented in the domain implementation phase. The phases in system engineering correspond well to the ones that we find in most single system and software development methodologies [33]. The initial requirements analysis takes the customer requirements and matches them to the set of capabilities that the software family can fulfill using the domain model. The requirements that can not be fulfilled using the resources in the domain model and domain assets are fed to the domain analysis phase in order to determine whether those requirements should be accommodated in the software family. If that is the case, the domain engineering activities create the reusable assets to satisfy the requirements and store them to be used for future system engineering activities. While the domain engineering approach to reuse of software intends to use the assets to the greatest extent possible, the software family assets can not possibly accommodate every configurability option. There will inevitably be concrete customer requirements that can not be fulfilled using the resources from the family domain engineering, and which will not be suitable for inclusion in the domain model or the reusable assets, being specific to the

156


particular product. These requirements will require and trigger custom design and development specific for the current product. The result of the system design phase is the software architecture that will be used to accommodate the reusable assets that fulfill the customer and system requirements. At the last leg of system engineering, the actual product is configured and instantiated using the reusable assets. The assembly of the assets can be manual, automated or semi-automated. Depending on how suitable the software components are and how developed the organization is, the instantiation of the assets could be done using generators, code configurators or other advanced techniques. 6.4.2

SPICE

SPICE (ISO -15504) is an abbreviation for Software process improvement and capability determination [34]. The SPICE standard, released as a technical report in 1998, is built upon ISO-12207 (Software Life Cycle Definition), but it is substantially larger. The main subjects addressed in SPICE are process improvement, capability determination and process assessment. For the purposes of this chapter, the process improvement is of interest, as it includes a process reference model (PRM), which defines a set of processes, characterized by statements of process purpose and process outcomes. The PRM shall be used to illustrate potential integration points for feature modeling. The PRM includes five process categories, each of them divided into various sub-categories. These categories are [35]: – Customer - Supplier (CUS): processes that directly impact the customer, support development and transition of the software to the customer, and provide for its correct operation and use. – Engineering (ENG): includes processes that specify, implement, or maintain a system and software product and its user documentation. – Support (SUP): processes which may be employed by any of the other processes (including other supporting processes) at various points in the software life cycle. – Management (MAN): processes which contain practices of a generic nature which may be used while managing any sort of project or process within a software life cycle. – Organization (ORG): processes which establish the business goals of the organization and develop process, product, and resource assets which, when used by the projects in the organization, will help the organization achieve its business goals. All above process categories offer potential integration points with feature modeling. ORG processes could for example use feature models for strategic planning of new features of a product according to the business objectives; CUS processes could apply feature models for visualizing the product variants and impacts on pricing during the contract negotiations. Exploiting all integration


157

points would lead to an organization model similar to the domain engineering approach described in the previous section. A light-weight approach is to limit feature modeling to specific parts of the ENG processes. ENG is, according to SPICE, divided into the sub-categories system requirements analysis and design, software requirement analysis, software design, software construction, software integration, software testing, and system integration and testing. The sub-category “ENG.2 develop software requirements” offers possibilities for feature model use easy to implement. The purpose of this process is to establish, analyze and refine the software requirements, which includes – ENG.2.1: Determine software requirements and document in a software requirements specification. – ENG.2.2: Analyze the software requirements for correctness, e.g. completeness; understandability; testability; feasibility; etc, – ENG.2.3: Determine the impact of the software requirements on the operating environment. – ENG.2.4: Evaluate requirements with customer. – ENG.2.5: Update requirements for next iteration based on the feedback obtained from use When developing a new feature model, requirement documents from earlier system development projects are considered as potential information sources used within the feature identification process (see section 6.3). In a similar way, customer requirement specifications for new projects can be analyzed in ENG.2.1 in order to identify those features of an established feature model, which are addressed by the requirement specification or which are addressed by descriptions in the requirement specification. In this context, the different feature types (mandatory, optional, alternative, etc.) and their attributes contribute to categorizing the features requested by the customer into three initial groups: – Features required in the customer requirement specification, which are present in the feature model. For these features, an implementation exists in previously developed systems. – Features required with a similar feature present in the feature model or where the available feature shows a mismatch in some of the attributes defined. For these features, further investigations are required, whether the development of a new feature is necessary or the creation of a new variant of an existing feature (combination) is more adequate – Features not available at all, which have to be newly developed. When deciding on development of these features and designing them, the feature model can be used as planning instrument. Such a use of an established feature model when analyzing a requirement document can speed up the requirement analysis process and contribute to a more efficient system development process.

158


6.5 Summary This chapter introduces and discusses the use of feature models in development and maintenance of complex systems. The main intention is to allow for high flexibility with many possible variants in different application contexts and at the same time restrict the systems’ complexity in order to achieve maintainability. The term feature used in conjunction with feature models can be defined as “a prominent or distinctive and user-visible aspect, quality, or characteristic of a software system or systems.” [6] Features are intended to be concepts described by a single word or short line of text. The purpose of a feature model is to extract, structure and visualize the commonality and variability of a domain or set of products. Commonality represents the properties of products that are shared among all the products in a set, placing the products in the same category or family. Variability represents the elements of the products that differentiate and show the configuration options, choices and variation points that are possible between variants of the product, aimed to satisfy different customer needs and requirements. The variability and commonality is modeled as features and organized into a hierarchy of features and sub features, sometimes called feature tree, in the feature model. A generally accepted model for deciding when to use feature modeling still has to be developed. Components and systems manufactured as mass products and large batch products can be considered the core area for feature modeling, if a high number of variants and high degree of dependence exists. A low degree of dependence or a low number of variants usually are not the perfect areas for using feature models, but there might be exceptions. If both characteristics are considered as low, feature modeling should not be considered. The feature diagram is an essential part of a feature model, as it visualizes features and their relations. It is a hierarchical decomposition of the features in the model, indicating dependencies and constraints for the commonality and variability of the product that is represented by the feature model. At least three types of features should be considered: (1) Mandatory features representing the common parts included in every configuration of a product, (2) optional features representing the variability of a product, i.e. a feature of this type may or may not be included, and (3) one single feature out of a set of alternative features that can only be included in a product configuration. The semantics of a hierarchical relation between two features usually can be described as “consist-of”; other notations distinguish in this context between “composed-of”, “generalization/specialization” and “implemented-by” relations. Apart from the relations that arise as a consequence of the use of mandatory and optional features in a feature hierarchy, features in a model can also have other interdependencies. FODA originally described two types of feature interdependencies, namely “requires” and “mutually-exclusive-with”. The general feature analysis process consists of collecting information sources, identifying features, abstracting and classifying features into a model, defining the features, and validating the model. Although feature models are employed in quite large operations and organizations, tool support is somewhat scarce. While


159

major tool vendors provide a variety of tools for almost every step in software development, feature modeling is mainly treated in tool suites for development of software product lines and software families, and those tools are generally made by smaller vendors. The full potential of feature models will only be reached in most organizations, if the system development process is taking advantage of the knowledge captured in feature models and if at the same time the feature model is kept accurate and up-to-date. The integration of feature modeling in systems development processes can be addressed in different ways. This chapter discussed two approaches illustrating the bandwidth of possibilities: (a) the implementation of domain engineering principles, which is considered among many scholars in the field of systems engineering considered as the most sophisticated and desirable way, and (b) starting from the established system development processes like SPICE and using feature modeling for the support of selected activities.

References 1. Baccarini, D.: The concept of project complexity - a review. International Journal of Project Management 14(4), 201–204 (1996) 2. Hobday, M.: Product Complexity, Innovation and Industrial Organisation. Research Policy 26(6), 689–710 (1998) 3. Woodward, J.: Management and Technology. H. M. Stationary Office (1958) 4. Hughes, T.: Networks of Power: Electrification in Western Society, pp. 1880–1930. John Hopkins University Press, Baltimore (1983) 5. Neighbors, J.: Software Construction Using Components. PhD thesis, University of California (1980) 6. Kang, K., Cohen, S.G., Hess, J.A., Novak, W.E., Peterson, S.A.: Feature-Oriented Domain Analysis (FODA) - Feasibility Study. Technical Report CMU/SEI-90-TR21, Carnegie-Mellon University (1990) 7. Simos, M., Creps, D., Klingler, C., Levine, L., Allemang, D.: Software Technology for Adaptable Reliable Systems (STARS) Organization Domain Modeling (ODM) Guidebook Version 2.0. Technical Report STARS-VC-A025/001/00, Lockheed Martin Tactical Defense Systems (1996) 8. Creps, R.E., Simos, M.A., Prieto-D´ıaz, R.: The STARS Conceptual Framework for Reuse Processes. Technical report (1992) 9. Technical Report STARS-AC-04110/001/00, Paramax Systems Corporation (1992) 10. Clements, P., Northrop, L.: Software Product Lines: Practices and patterns. Addison-Wesley, Reading (2002) 11. Czarnecki, K.: Domain Engineering. Technical Report DOI: 10.1002/0471028959. sof095, Encyclopedia of Software Engineering (2002) 12. Hein, A., MacGregor, J., Thiel, S.: Configuring Software Product Line Features. In: Proceedings of ECOOP 2001 Workshop on Feature Interaction in Composed Systems (2001) 13. Liu, D., Mei, H.: Mapping Requirements to Software Architecture by FeatureOrientation. In: Proceedings of STRAW 2003 (2003) 14. Kang, K.C., Kim, S., Lee, J., Kim, K., Shin, E., Huh, M.: FORM: A FeatureOriented Reuse Method with Domain-Specific Reference Architectures. Annals of Software Engineering 5, 143–168 (1998)

160


15. Czarnecki, K., Eisenecker, U.: Generative Programming. Addison-Wesley, Reading (2000) 16. Riebisch, M., B¨ ollert, K., Streitferdt, D., Philippow, I.: Extending Feature Diagrams with UML Multiplicities. In: Proceedings of 6th Conference on Integrated Design & Process Technology (2002) 17. Riebisch, M.: Towards a More Precise Definition of Feature Models. In: Riebisch, M., Coplien, J.O., Streitferdt, D. (eds.) Modelling Variability for Object-Oriented Product Lines, Norderstedt (2003) 18. van Deursen, A., de Jonge, M., Kuipers, T.: Feature-Based Product Line Instantiation using Source-Level Packages. In: Proceedings of SPLC2 (2002) 19. IEEE Standards Board: IEEE Standard Glossary of Software Engineering Terminology. Technical Report lEEE Std 610.121990, IEEE (1990) 20. Bosch, J.: Design and Use of Software Architectures. Addison-Wesley, Reading (2000) 21. Chastek, G., Donohoe, P., Kang, K.C., Thiel, S.: Product Line Analysis: A Practical Introduction. Technical Report CMU/SEI-2001-TR-001, Carnegie-Mellon University (2001) 22. Lee, K., Kang, K.C., Lee, J.: Concepts and Guidelines of Feature Modeling for Product Line Software Engineering. In: Proceedings of The Seventh Reuse Conference (2002) 23. Trigaux, J., Heymans, P.: Modelling Variability Requirements in Software Product Lines: A comparative survey. Technical report, Institut d’Informatique FUNDP (2003) 24. Bontemps, Y., Heymans, P., Schobbens, P., Trigaux, J.: Semantics of FODA Feature Diagrams. In: Proceedings of SPLC3 (2004) 25. Fey, D., Fajta, R., Boros, A.: Feature Modeling: A Meta-Model to Enhance Usability and Usefulness. In: Proceedings of SPLC2 (2002) 26. Ferber, S., Haag, J., Savolainen, J.: Feature Interaction and Dependencies: Modeling Features for Reengineering a Legacy Product Line. In: Proceedings of SPLC2 (2002) 27. Sochos, P., Philippow, I., Riebisch, M.: Feature-Oriented Development of Software Product Lines: Mapping Feature Models to the Architecture. In: Proceedings of Object-Oriented and Internet-Based Technologies (2004) 28. Czarnecki, K., Eisenecker, U.: Synthesizing Objects. In: Proceedings of ECOOP 1999 (1999) 29. Griss, M.L., Favaro, J., d’Alessandro, M.: Integrated Feature Modeling with the RSEB. In: Proceedings of International Conference on Software Reuse (1998) 30. K¨ astner, C.: CIDE: Decomposing Legacy Applications into Features. In: Proceedings of SLPC11 (2007) 31. Beuche, D., Papajewski, H., Schroder-Preikschat, W.: Variability Management with Feature Models; Software Variability Management. Science of Computer Programming 53(3) (2004) 32. Families. Main, http://www.esi.es/families 33. Pfleeger, S.L.: Software Engineering: theory and practice, 2nd edn. Prentice-Hall, Englewood Cliffs (2001) 34. ISO SPICE, http://www.isospice.typepad.com/isospice is15504/ 35. Software Process Improvement and Capability dEtermination: http://www.sqi.gu.edu.au/spice/


161

Resource List Papers and articles K.Kang, S.G.Cohen, J.A.Hess, W.E.Novak, S.A.Peterson: Feature-Oriented Domain Analysis (FODA) - Feasibility Study. Technical Report CMU/SEI-90-TR21, Carnegie-Mellon University (1990) Lee, K., Kang, K.C., Lee, J.: Concepts and Guidelines of Feature Modeling for Product Line Software Engineering. In: Proceedings of The Seventh Reuse Conference. (2002) Trigaux, J., Heymans, P.: Modelling Variability Requirements in Software Product Lines: A comparative survey. Technical report, Institut d’Informatique FUNDP (2003) Pierre America, Steffen Thiel, Stefan Ferber, and Martin Mergel. Introduction to domain analysis. Technical report, ESAPS, 2001. Coplien, J.; Hoffman, D.; Weiss, D., “Commonality and variability in software engineering,” Software, IEEE , vol.15, no.6, pp.37-45, Nov/Dec 1998. Conferences and workshops Software Product Line Conferences. http://www.splc.net/, March 2008. Variability Modelling of Software-Intensive Systems. http://www.vamos-workshop.net/, March 2008. Books Czarnecki, K., Eisenecker, U.: Generative Programming. Addison Wesley (2000). Rubn Prieto-Daz and Guillermo Arango: Domain analysis and software systems modeling. IEEE Computer Society Press (1991). Paul Clements and Linda Northrop. Software product lines: Practices and patterns. Addison-Wesley (2002). Software Pure Systems GmbH, http://www.pure-systems.com. Big Lever, www.biglever.com. Captain Feature, https://sourceforge.net/projects/captainfeature. Websites ´ From Concepts to Application in System-Family Engineering. CAFE. http://www.esi.es/Cafe/, March 2008. Software Product Lines. http://www.sei.cmu.edu/productlines/, March 2008.

7 Semantic Robotics: Cooperative Labyrinth Discovery Robots for Intelligent Environments Atilla Elçi and Behnam Rahnama Department of Computer Engineering, and Internet Technologies Research Center, Eastern Mediterranean University, Gazimagusa, Mersin 10, TRNC, Turkey {atilla.elci,behnam.rahnama}@emu.edu.tr

Abstract. This chapter focuses on design, implementation, and utilization of semantic robots dealing with cooperative problem solving in a natural setting such as discovery of exit from a labyrinth. In our approach to realize this goal, a new modular architecture for designing and implementation of cooperative labyrinth discovery robots (CLDRs) is devised. Both hardware and software aspects are considered in detail. Robot and agent ontology aspects are treated in detail with examples. Likewise, labyrinth data structure (Maze Set) is represented in Notation 3 and OWL standard formats useful for purposes of semantic logic data processing in scientific software environments such as Prolog, Protégé, and MATLAB. Concepts of Semantic Web technology are introduced leading to a working understanding of semantic Web services (SWS). A CLDR acts as an agent offering SWS. Each agent is an autonomous complex system, which acts based on its sensory input, information retrieved from other agents, and ontology files for agent and domain. CLDR decision making was introduced based on either of the principles of open/closed World assumptions. Messaging and coordination aspects are addressed. The approach is to create semantic robotic agents based on SWS to implement autonomous semantic agents (ASAs). Several applications can be built based on ASA architecture, where semantic robotics can play a vital part: traffic management, interactive traffic information dissemination, creating intelligent environment through intelligent intersections, dispatching vehicular services, and homeland security. Keywords: Cooperative Labyrinth Discovery, Multi-Agents, Robotics, Semantic Robotics, Semantic Web, Ontology, Traffic Management and Information System, Intelligent transport System, Dispatching Vehicular Services, Homeland Security.

7.1 Background and Literature Review Semantic Web Services provide a new approach to communication, situation-, context-awareness, and knowledge representation for reasoning by multiple agents. Collaborative working among multiple robots acting autonomously requires a universal platform to merge data processed by each agent for perception and map building on a mesh of possible answers to a query. Semantic Web technologies (SWTs) are utilized in research and real-life applications as a tool to represent meaningful and inferable data. Researchers are working to standardize usage of SWTs to be able to apply it in various fields such as robotics. Current implementations are very specialized to task A. Tolk, L.C. Jain (Eds.): Comp. Sys. in Knowledge-based Environments, SCI 168, pp. 163–198. © Springer-Verlag Berlin Heidelberg 2009 springerlink.com

164

A. Elçi and B. Rahnama

and are not flexible for re-tooling to different usecases. Having a standard framework to express what is required in robotics and embedded computing, especially reasoning, in terms of semantics would help robots to utilize essential services in providing much closer understanding of required results for human daily lives. In the foundation of semantic Web reasoning engines and communication platforms relies on Open World Assumption (OWA). This is due to ‘openness’ of web where absence of entities being searched should not entail negative response rather simply treated as a fact “not available at the moment.” While, that sets the base in anticipation of future enhancements of the fact base, it is not preferred in situations where a definitive answer is needed. Closed World Assumption (CWA) alternatively returns definitive yes/no answers even in situations where future enhancements are inevitable [1]. Robots currently apply CWA for decision making and learning. They could also utilize the huge mass of information available on semantic web in order to deduct new knowledge using standard or extended OWA. Consequently, robots cannot only cooperate and communicate using semantic Web platform but also be able to retrieve much more realistic and acceptable answers to queries. This is even more so where unsupervised learning plays a main role where our knowledge about task is incomplete; and that is true for most of real life situations. Systems with distributed processing and control require distributed coordination in order to achieve a shared goal. Such systems may be realized using self-actuated agents donning semantics capability such as that of an autonomous semantic agent (ASA). Implementation of an ASA [2] as a semantic Web service offered by a robot provides required features. In a multi-agent system, one of the ASAs may indeed assume as well the duty of a common site acting as the central registry of web services in the field. This chapter explores ASA-based multiple agents (MASAs) approach to labyrinth discovery by cooperating robots. This is done in three work breakdown phases, namely, robot development, building ASA features, and finally MASA system creation. The following introduces these phases; subsequent sections take each in turn in detail. Several sample usecases of such semantic MASAs are taken up in the following in order to introduce terms. For simplicity in referring to these robots, and in order to convey their capability better, we will call them as the Cooperative Labyrinth Discovery Robots (CLDRs). 7.1.1 ASA Semantic Web Architecture We devised new software architecture for distributed environments using autonomous semantic agents (ASAs) [3]. Distributed processing environments, such as that of a traffic network management system (TMS), can be implemented easier, faster, securer, and perform better through use of ASAs. In this point of view, traffic system consists of an intersection network. For an ASA may be realized as a semantic web service, a whole TMS is readily implementable through a collection of semantic web services agents arranged according to the topology of the traffic network. It would suffice to develop a generic ASA web service class, instantiate individual ASAs from it in numbers as required one per intersection, and supply specific intersection data to

7 Semantic Robotics: Cooperative Labyrinth Discovery Robots

165

each in semantically enriched representation. One of the ASAs may be configured slightly differently in that it acts as the operational overseer and repository for aggregated data and ASA class code. Once created, this “Facilitator ASA” knows the topology of the whole traffic network, identifies each intersection (and its associated ASA), can interrogate and may instruct individual ASAs case by case. Aspects of ASA design, operation, and application development using ASAs are taken into consideration. Simulations indicate high performance and the benefits of load distribution using ASAs. 7.1.2 Robotic Applications An exemplary application domain where CLDRs can be put to use is a complex system such as “Traffic Management and Information Systems” (TMIS) whereby interactive information support is provided to all entities in the traffic. ASAs implementing multi-agents operate intersections and links in this augmented TMS. This setup caters for managing the traffic, and interacting with its occupants and the near environment in the periphery. Furthermore, other value-added services can be easily incorporated. Facilitating for dispatch of ambulance, fire fighters, and police vehicles come to mind. They are given right of way, and that they would travel the shortest possible path in the network. We look into this application domain in general considering its software architecture, intersection design, operation, and communication load in the network. Detailed usecases in intelligent environment and urban emergency services are considered below. Likewise, numerous complex problem domains are likely application areas for multiple ASAs (MASAs), such as systems for distributed control, decision support, financial market estimation, homeland security, etc. The test case application area used here is “Cooperative Labyrinth Discovery” where MASA robots are to inspect cooperatively an uncharted maze to discover its exits. Hence, context awareness, semantic understanding, near area communication, and friend/foe distinction make up upper value sets loaded upon ‘automaton’ nature of a robotic ASA. Furthermore, we aim at effecting coordination and cooperation among MASAs towards realizing intelligent behavior in order to achieve a shared goal through processes benefiting from semantic web technologies [4, 17]. Recent research on traffic and transport systems has been concentrated on vehicle and driver safety through fitting vehicles with onboard IT systems. Placing the focus on vehicle may be understandable in thinly populated rural areas, whereas it is wiser to mind the intersections in city center as well as in suburbs. An intersection may be likened to a processing node in a traffic grid where vehicles flow and flows intersect. Then, digital inclusion of vehicles, their drivers and passengers as well as pedestrians may be best realized through intersections that implement intelligent environments. An intersection network can then serve to improve the quality of life in mobile urban communities [5, 6]. This chapter also highlights a security scenario in terms of a TMIS through tracking of missing vehicles and routing. TMIS and its nodal architecture Intelligent Junction (IJ) are introduced in recent work. Their design employs autonomous semantic agent-based software, sensor networks, and wire/wireless integrated communication infrastructure. Especially described are their essential functions crucial to aid security applications. A security scenario concerning tracing and tracking of missing vehicles

166


is considered and shown how to implement it over TMIS network. Simulation results show promising outcomes. Further research involving similar development base is suggested [7]. Cooperatively responding to a query by intelligent intersections in TMIS is similar to a multi-agent robotic system discovering a way out of a maze. Communicationwise, each robot should talk to its neighbors and share its information. In this respect, optimization of neighbor selection algorithms and control structures are important. Researchers have worked in various categories of cooperatively solving problems by robots. For instance, H. Takahashi et al. [6] studied autonomous decentralized control for formation of multiple mobile robots. They covered formulations for forming a group of robots following the same goal. Chia-How Lin et al. [8] represented an agent-based robot control design for multi-robot cooperation in real time control. Their system is suitable for cooperative tasks with capability of controlling heterogeneous robots. Finally, Xie Yun et al. [9] have prepared a communication protocol for their soccer robots.

7.2 Cooperative Labyrinth Discovery Robots A CLDR has advanced design and development features rendering it the small footprint, mobile, intelligent, semantic robot. We take up all relevant issues of system software, semantic software, and hardware in this section. 7.2.1 CLDR Software Architecture Modularity has been taken into account in designing software of the robot. Also a modular hardware has been designed and developed to ease finding solutions for the requirements of labyrinth competitions. The modular software architecture is multilayered; Fig. 7.1 displays a summary. Each layer is taken up further in the following.

Web Services SOAP, USDL, UDDI Embedded Computing Decision Making Engine, SWTech HTTP, XML Feedback Control System Error Detection and Correction

TCP/IP

Low Level Control Modules Sensors, Motors, Communication

Fig. 7.1. Modular Software Architecture of CLD Robots


167

7.2.1.1 Low-Level Control Modules CLDR should be able to read the walls around in labyrinth; and, it should be able to detect the edges of blocks on the floor and obstacles in distances. CLDR uses different kinds of sensors to provide such abilities. Corresponding functions to each individual sensor based on their properties and connections have been written. These functions are called via microcontroller based on the decision maker. In low-level control layer, some predefinitions such as size of each block and proper distance to a wall are set. Decision maker prefers to deal with data such as “forward closed” rather than an output value of a sensor showing the distance to the reflecting object. Therefore, these translations should be done in low-level layer as an interface between decision maker and sensors. The same is done for controlling a pair of servomotors, which is used to move the robot. Decision maker commands “go forward” while the low-level layer translate it to proper value pulse-width modulation (PWM) signals which is fed to the wheel motor(s). In parallel the wheel encoder sensors read and forward number of notches the wheel turned in order for the decision maker to compare against the desired distance. In addition, other control modules such as battery management system (i.e. Microchip Lithium Battery Management Chipset MCP73864), LCD and fast on-chip programming interface (In-System Programming: ISP) have been included. The battery saving and management are very important factors in mobile robots. Nowadays lithium-ion/polymer cells are the best choice due to their smallness and amount of power they supply. Moreover, chipsets in tiny sizes are available with the ability of over voltage/current/temperature protection. Consequently, controller unit and sensors should support battery saving mode. To this end, the low-level layer includes modules to read the amount of charge, and control the battery management chipset. In addition, they provide sleep and standby signals based on the watchdog timer. CLDR should be able to program the low-level layer onboard. Therefore, the microcontroller should support on-chip programming. Corresponding Parallel I/O modules are used to communicate with the board using standard parallel I/O port for programming the microcontroller. The information such as initialization values and commands are transferred through standard RS232 port. Therefore, the port should be initialized first in programs loaded onto the microcontroller. 7.2.1.2 Feedback Control Mechanism After receiving the calculated PWM signal, motors might not perform as required due to slippage of a wheel or for other reasons. Therefore a feedback control mechanism should be in place in order to measure the amount of movement and issue the respective amount of pulses for correction. In addition, the deviation of the robot from the desired path causes localization problem. The localization problem is when the robot is aimed to be in the center of a labyrinth cell but due to bad motor/wheel performance, it has been deviated. Therefore, after passing a few blocks the robot may not be able to rotate properly (without touching walls) or read the walls accurately. To overcome this problem, in addition to wheel encoder sensors and analog distance measurement, an array of floor detection sensors are horizontally placed at bottom of the robot. For instance, if the robot is deviated to left, the right sensor in the sensor array

168


reaches the next block a little bit earlier than the left one. Then the feedback control mechanism speeds up the left motor as it rotates the robot to the correct stage. 7.2.1.3 Embedded Computing We aimed to run the decision-making engine on a multi threaded, multi processing operating system concurrently while also running on it web services supporting .Net framework. Windows XP Embedded is the preferred choice. It is run on the robot’s Pentium embedded board. The decision maker commands robot to read walls through microcontroller layer interface to see if they are closed (that is, there is a wall) or not (no wall); communicates with other agents and finally decides where to send the robot in the next step. 7.2.1.3.1 Finding Dead Ends and Blocking Them Virtually. While leaving a block having three walls, the robot virtually avoids later entry by blocking the fourth wall in memory not to let this or other robots go to trap in the future. 7.2.1.3.2 Finding Loops and Traps in Labyrinth. While the sequence of traced path is kept in memory, if all right (or left) walls are connected and we reach to a node previously listed in the queue, it means that that part of traced path is a loop. Therefore the point to the first touched place will be blocked in the memory in order to avoid reentry in the future. 7.2.1.3.3 MinMax Algorithm for Selecting the Direction in Crossing. At an intersection of the current and previous paths with more than two possible directions to follow, the system gives priority to the path that has been traced (travelled) less number of times. It accords higher priority to tracing unknown cells in a labyrinth. 7.2.1.4 Built-In SWTech Architecture Semantic Web aims to create a universal medium for information exchange by attaching meaning (semantics) to the content of documents on the Web, in a manner understandable by software agents. Currently under the direction of the Web's creator, Tim Berners-Lee of the World Wide Web Consortium, the Semantic Web extends the World Wide Web through new standards, markup languages and related processing tools. The essence of our approach in building the last layer of architecture for an autonomous robot is to solve problems and to act as a semantic web service. The following figure, illustrates components of the last layer; they are introduced below. 7.2.1.4.1 Semantic Labyrinth Discovery Application (SLDA). SLDA has capability of discovering labyrinth search space, labyrinth ontology, cooperating and communicating with other agents. In addition, Web services (WS) discovery, execution, composition and interpolation (goal setting and next step planning) are other capabilities of SLDA [32]. 7.2.1.4.2 Semantic Robotic Agent Application. Autonomous Semantic Agent Robots are implemented as a Semantic Web Service (SWS) and run a copy of the Semantic Robotic Agent Application which supports the following features: agent system, SWS container, knowledge acquisition, and representation.


Management Console App.

169

Apps Server: Semantic Web, UDDI, WSDL,

Semantic Labyrinth Discovery Application

SOAP, …

Inference Engine

TCP/IP Ontology DB Ontologies are replicated at applications

Autonomous Semantic Agent Robots

Fig. 7.2. Semantic Web Service layer architecture

7.2.1.4.3 Inference Engine. Supporting the agent and main applications, the inference engine will have the following features: labyrinth state space search, labyrinth discovery ontology (labyrinth discovery rules & resource description, labyrinth description rules and data), and labyrinth discovery heuristic. 7.2.1.4.4 Management Console Application. This is a web-based application to manage robotic hardware and software remotely. It has the following features: software maintenance and installation, software incremental change management, and hardware status monitoring. 7.2.2 CLDR Hardware Modular Architecture An autonomous robot is being aimed at which utilizes semantics and connectivity through semantic web services. Architectural features of a CLDR are considered in terms of its electronic and mechanical components, processors, sensors, interfaces, OS, battery, and communication. Some of the elegant mechatronics features of CLDRs are enhanced electronic design using integrated circuits and chipsets, simple but trouble-free mechanical style, a hardware control platform parallelized using different controllers for movement, error detection/correction, and problem solving. The robot has numerous crucial features which are taken up below. Size of the robot can be minimized using small sensors and controllers. In addition arranging sensors to best serve the task is a very essential. For instance, having line tracker sensors in front and rear of the robot helps sensing (thus avoiding) zigzag movement on a straight line. Lithium ion/polymer battery management system protects cells against over voltage/current/temperature. These features are very essential in mobile robots. It also allows possibility of charging batteries online while robot is operating.

170


On-chip programming ability of the microcontroller gives possibility of online upgrading the firmware. Hardware parallelization in microcontroller such as processing results of sensors while servo motors are being moved increases the performance and precision achievable by the robot. It’s known that infra-red sensors have difficulty of performing properly under fluorescent light. Therefore the emitting diode should be modulated through 38~40 KHz pulse. Use of RS232 standard to communicate with the microcontroller through the embedded Pentium board makes the robot portable and OS independent. The robot decides whether to use RS232 through cable or a wireless transceiver module working on 945 MHz depending on the task. Basically the embedded Pentium board carried on the robot is communicating through RS232 with Atmel AVR AtMega16L microcontroller. Therefore, the main brain is running on the embedded board and microcontroller executes commands so that ‘go forward’ means a calculated amount of PWM pulses applied on a specific pin. The microcontroller also has duties to correct moving errors using feedback from shaft encoder sensors in order not to let the robot deviate from its designated path. Use of real-time operating system on RISC microcontroller, built-in PWM and A/D, and availability of C compilers are also important points that should be taken into account. Moreover, embedded Pentium boards and PC104 compatible controllers such as Vortex86 with ability of supporting Linux or Windows XP Embedded are valuable assets to squeeze into a small size. This feature lets the robot to communicate with other robots or with a management console through wireless 802.11 LAN. The robot agent exchanges data about its position, context, and discovered parts of the field based on concurrently designed protocol over wireless medium [20]. Finally, modularity in software and hardware of the robot allows better management for maintenance and programming. All these features are included in a miniature size cylindrical mobile robot with 215mm height, 130mm diameter, and only 1120 grams [2]. The block structure of the CLD Robot was designed as shown in the following figure. This architecture provides modularity and supports the requirements of labyrinth, intelligent mice, and line following international competitions. The above is summarized in the following block diagram of the CLDR (Fig. 7.3); its modules are taken up below. The low level layers block diagram of the CLDR as well can be found in [2]. User can easily develop programs using .Net environment and compile it to be run on Windows XP Embedded. This provides ability of applying Semantic Web technology on a mobile robot. Ontology processing rather than creating substandard communication protocols gives opportunity to get heterogeneous robots inter-working [19]. Due to the requirements of labyrinth competitions, the mechanics of the robot is designed in the minimum possible size. The hardware fulfills the essential support requirements for software such as parallelism and interfacing the required sensors by having SPI bus, MSIO and analog ports. The modular hardware architecture of the CLD Robot is depicted in Fig. 7.4.


USB

Vision Module CCD Camera

USB

IDE

Disk Memory MDM 512MB

PCI

Vortex86-6082 Embedded Board Serial

Positioning Optical Mouse

171

Audio Module Mic/Speaker

Min PCI Ad. ICOP 6083

WiFi 802.11 b/g Serial

PSU Lithium Charge Management

Microcontroller Atmel AVR162

Motor Control L6219DS

Sensors TTL Level I/O: Line Following, Wall Detection, Distance Measurement, and Wheel Rotation

Fig. 7.3. Block diagram of the CLDR

Wireless 802.11 b/g 54Mbps Embedded Pentium System RS232

Parallel I/O Motherboard

AVR Microcontroller Layer Sensors

Motors

PSU

Fig. 7.4. Modular hardware architecture of CLD Robot

Important facets of the CLDR hardware architecture are further discussed in the following subsections. 7.2.2.1 Motors and Sensors The robot moves, turns around and rotates 360º on its circular center using two independent motors. The simple but error-free mechanical design provides clean development, light and powerful traction by use of interconnected gears inside DC Servo motors’ cover (i.e. HiTech HS-422 Servo Motor). In matching the requirements of labyrinth competitions the mechanics of the robot is designed in the minimum possible size. Distance of wheels from each other has been calibrated in such a way that an integer number of pulses generated by wheel encoder sensors, such as Hamamatsu quadrature optical wheel shaft encoder disk

172


P5587, will fit on 90° rotations. This value is calculated using circumference of the tire connected to the deduction gears. The derivation and calculation of this figure are given in a subsection below. Fast stop system, pulse width modulation and speed management are handled in microcontroller using built-in hardware PWM in the microcontroller layer. Infrared sensors, such as Sharp IR distance Measurement Sensors GP2D120 and Lynxmotion Infrared Proximity Sensors TRA-V5, are used in order to check if there is a wall or to calibrate itself of excess deviation by use of the floor color crossings. As the floor color detectors respond concurrently, the robot can detect and correct rotation errors due to wheel slippage if it receives different values from those sensors as mentioned above. Shaft encoders are employed with the aim of sending a feedback of covered distance. Normally combination of a simple infrared LED and a light sensitive transistor could make a good optical-counter. A wide usage area of these optical-counters is X/Y movement feedback of an electromechanical computer mouse. Infrared or ultra sonic sensors, such as Devantech Ultrasonic Range Finder SRF10, need to be fed by a generated pulse at a fixed frequency for noise elimination. Other issues are reading them and writing the results at each trigger pulse into a packet for forwarding to the upper layer. 7.2.2.2 Microcontroller Layer Detecting and correcting motion errors in hardware layers, computing distances and mostly basic I/O system control are done via an AVR Atmega16L Microcontroller. Up to this layer, an agent can be controlled using any compatible processing element via our designed communication protocol. This protocol is implemented as a device driver for the low level hardware layers. The driver is installed on the embedded system and allows the installed decision making engine to transmit commands to the hardware and accordingly receive feedback data from it. Commands in device driver and microcontroller should match. Fig. 7.5 illustrates the motherboard as an interface card between microcontroller, sensors, motors and the embedded system. Command sets consist of movement, obstacle detection, and velocity. Distance computing is done and controlled through this layer. Beyond this point, a more powerful processor is needed to solve the labyrinth problem and control the robot based on the feedbacks coming from this layer. 7.2.2.3 RS232 and Parallel I/O In order to interface the analog and power circuits with microcontroller and software layers, an interface layer is needed to translate and forward each side’s command and feedback to the other. For this purpose, some chipsets and extra hardware are used. MAX232 is one of good examples of interfacing RS-232 port for interfacing the data into TTL level signals. Whereas more powerful processor has to communicate with the microcontroller attached to this layer, they have to send and receive their signals and commands or feedbacks at a specific speed, usually as low as the microcontroller could support at its highest communication bandwidth.


173

RS232 Parallel I/O LCD

Wireless Transceiver

AVR Microcontroller

Ultrasonic Sensor

Servo Motor Interface

Ports for IR Sensors

Shaft Encoders

Line Following Sensors

Regulated Voltage for Motors

Interface to AVR Microcontroller

Lithium Cell Battery Management

Regulated Voltage for Digital Layer

Regulated Voltage for Embedded Board

Fig. 7.5. Motherboard, PSU and their components (top view)

7.2.2.4 Embedded Pentium System The selected embedded system is one of VORTEX86-6082LV. Fig. 7.6 shows the first example.

174


Fig. 7.6. VORTEX86-6082LV, ICOP Technologies (http://icop.com.tw)

Other electronic layers such as microcontroller and power supply boards have been designed by us and fabricated in same size with the embedded board to maintain design consistency. 7.2.2.5 Wireless 802.11 Without this layer the autonomous robot cannot act properly. The next step as the most essential one is to solve a problem cooperatively. Therefore, a TCP/IP based communication system is required for communication. Due to the mobility requirement, the Wireless LAN has been selected. The decision maker communicates with other robots using the hardware driver of the mini PCI wireless adapter installed on embedded Pentium system like Vortex86-6083. The .Net framework facilitates coding for communication requirements for mobile robots. The overall system has been built as shown in Fig. 7.7.

Fig. 7.7. Cooperative Labyrinth Discovery Robot. Height: 215mm, diameter: 130mm.


175

7.2.3 CLDR Mechanics: Traction Overall size, traction, and agility matter much for CLDR due to tight work area, sharp corners to take, and in-place maneuvers such as turning to any direction without touching walls. Miniaturizing the electronics and vertical layering of boards helped in keeping the footprint small. In order to leave sufficient gap on either side to maneuver safely once in a labyrinth cell, the robot is designed to fit into a 60.5mm radius footprint (roughly same size as a CD ROM disk). In order to achieve precise movements, the placement of the two traction wheels and their two servo motors must be precisely computed, which is taken up below. Besides the two traction wheels, CLDR also has two ball casters for balancing and weight carrying purposes located on an axis perpendicular to the wheel axis. 7.2.3.1 Mechanical Calculation of Wheel Placement Reference Fig. 7.9 displaying robot dimensions, the wheel diameter is indicated by

DW = 65.2mm

(7.1)

Circumference of a wheel gives the distance it travels per one complete rotation which may be denoted by

CW = 2 ⋅ π ⋅ r = π ⋅ DW = 204.8mm

(7.2)

Angular time elapsed in HiTec Servo motor HS-422 is as follows

T4.8V = 0.21s / T6.0V = 0.16s /

π 6

π 6

(7.3)

(7.4)

In order to calculate the linear velocity, the time spent for one complete rotation is required. Using the circumference of the wheel, we can calculate the elapsed time per rotation as follows

TC4.8V = T4.8V × 6 = 1.26s

(7.5)

TC6.0V = T6.0V × 6 = 0.96s

(7.6)

And, the minimum delay between two pulses at no-load speed is

Delay4.8V =

TC4.8V 44

= 0.02863s

(7.7)

176


Delay6.0V =

TC6.0V 44

= 0.02181s

(7.8)

Therefore, based on (7.2, 7.5, and 7.6) the velocity is denoted by

V4.8V =

0.2048m = 0.1625m / s 1.26s

(7.9)

V6V =

0.2048m = 0.2133m / s 0.96 s

(7.10)

Note that all values are based on no-load situation. The load as weight of the system carried by motors reduces the speed. The number of spokes used for wheel encoder module is equal to 44 per wheel or in other words 44 pulses / 204.8mm . Thus, we can measure the number of pulses per millimeter traveled as Pm

Pm =

44 = 0.2148 pulses / mm 204.8

(7.11)

And, based on (7.2) the length travelled on each pulse is LP as follows

LP =

204.8 = 4.654mm 44

(7.12)

In order to obtain the value of required number of pulses for crossing a (180 mm rectangular) block, we can use either (7.11) or (7.12):

PB =

180 = 180 × Pm = 38.66 LP

(7.13)

The number of pulses per degree on motor shaft is obtained from total number of pulses per rotation:

Pdm =

44 = 0.1222 pulses / deg 360

(7.14)

For calculating the number of pulses per degree on rotation of robot itself, we have to measure the minimum possible width of the robot between centers of two wheels. This amount is considered as the minimum possible radius in such a way that the number of pulses coming from wheel encoder sensor is an integer value. Let’s assume for the time being that the rotational error due to friction on wheels is not considered. This friction is caused because of difference of distances traversed by each side of the wheel d1 ,d 2 reference Fig. 7.8.


θ = 1°

d1

177

d2

r

Fig. 7.8. Estimation of Radius of the Robot

Whereas d1 < d 2 and they are calculated as follows (where 3.3mm is the half width of the wheel):

d1 =

2 ⋅ π ⋅ (r − 3.3) 360

(7.15)

d2 =

2 ⋅ π ⋅ (r + 3.3) 360

(7.16)

Therefore, for each r the lost energy could be estimated based on the integral on domain

d1 ,d 2 as follows where power to heat conversion function is f (x ) : E=∫

d2

d1

f ( x )dx

The minimum value for radius denoted by

r ≥ LA LA =

(7.17)

LA is as follows:

LW + LM = 3.3 + 43.9 = 47.2mm 2

Whereas LW symbol is denoted for wheel thickness; and

LM is the

(7.18) motor length

including encoder width. The upper limit depends on the size of a cell in a maze set as 168mm. Thus, range of r is as follows:

168 − (LW + 1.5) = 75.9mm 2

(7.19)

As the minimum value for radius is thus based on (7.19) r

= LA = 47.2mm , the

LA ≤ r
1), 4 n 2 > 2 n 2 + 2 n > n 2 + 2 n + 1

(7.30)


4 1

5 1

2

1

2

1 6

2

2

5

4 3

6

5

4

3

6 3

3

5

4

Fig. 7.10. Representation of

181

6

n × n maze as 2n × (n + 1) matrix

Proof

(

4n 2 − 2n 2 + 2n

)

2n + 2n − 2n − 2n 2

2

2

(7.31)

⇒ ∀(n > 1),2n − 2n > 0 2

(

)

2 n 2 + 2n − n 2 + 2n + 1

n + n + 2n − n − 2n − 1 2

2

2

(7.32)

⇒ ∀(n > 1), n − 1 > 0 2

However, this representation of the maze does not allow keeping an arbitrary size matrix where number of rows and columns are not equal. Therefore, a better solution is to keep horizontal walls and vertical walls in separate matrices. We define two matrices separately: For m × n size matrix, matrices V and H are defined as V ≡ m × ( n + 1) and H ≡ (m + 1) × n .

⎧(left ) ⇒ (i, j ) ⎫ V⎨ ⎬ ⎩(right ) ⇒ (i, j + 1)⎭ ⎧(up ) ⇒ ( j , i ) ⎫ H⎨ ⎬ ⎩(down ) ⇒ ( j , i + 1)⎭

(7.33)

7.3.2 Ontology Representation of Matrices Horizontal and vertical walls matrices presented above can be expressed in OWL ontology files while also observing the following constraints: • •

A matrix may consist of more than two dimensions. The engine should dynamically allocate proper space for such matrix. Additionally, nested loops for filling the values to proper places of matrix (access function) should be developed in run-time.

182


• • • •

Therefore, we designed an algorithm to provide nested loops for any n dimensional matrix in O(n log n) instead of O(2n). Row and column operations should be easily applied. In addition, it should be recognized that each two individual elements of a matrix are independent of each other. Due to the structure of the implemented output files, there is no dependent tag. Hence, the above requirements are satisfied.

We developed application software in order to embed a matrix in OWL ontology file. The program was implemented in J Builder 2006 with JDK 1.6.0 environment. The reason of selecting Java as implementation language was its compatibility with other semantic web software and issues such as platform independence. The sample program asks user the name of the matrix, its type, number of dimensions, and also the value for each dimension. Then, it generates a dynamic data structure for input values of matrix cells. Then it converts the user input data in terms of OWL ontology file. Fig. 7.11 represents an interaction with our implemented software.

Fig. 7.11. Interface of the program and library for embedding matrices in OWL ontology file [18]

The order of cell representation (storage) is based on the order of indices: first index, then second index, and so on, so that first rows then columns, and then depths. We implemented a general class for matrix representation in OWL including name, data type, indices elements etc. each matrix in OWL file is an instance of that defined class. 7.3.3 Embedding the Matrix Ontology in Math Software Math software generally support matrices represented as C data structures. Moreover, other keywords can be represented with the convertor module to be suitable for specific math software. At this step the same matrix which already is in terms of OWL ontology file will be converted to programming language syntax to be useful for math software. As an example, a portion of the OWL file for representing two matrices is given below:


183

… <Matrix rdf:ID="DoubleMaze"> <MatrixDimensions rdf:datatype="http://www.w3.org/2001/XMLSchema#string"> 3 <MatrixType rdf:datatype="http://www.w3.org/2001/XMLSchema#string"> double <MatrixName rdf:datatype="http://www.w3.org/2001/XMLSchema#string"> DoubleMaze <MatrixDim rdf:datatype="http://www.w3.org/2001/XMLSchema#string"> <MatrixSerialization rdf:datatype="http://www.w3.org/2001/XMLSchema#string"> [0,0,0],1;[0,0,1],2;[0,0,2],-3.7;[1,0,0],-4.87; … At this part a simple and tiny program converts the above OWL file into .m file for MATLAB. The following output is generated using the given OWL file for MATLAB. Note that in MATLAB the indices start from 1 by default.

DoubleMaze=zeros(5,1,3); DoubleMaze(0,0,0)=1; DoubleMaze(0,0,1)=2; DoubleMaze(0,0,2)=-3.7; DoubleMaze(1,0,0)=-4.87; DoubleMaze(1,0,1)=-858.2345; DoubleMaze(1,0,2)=6; DoubleMaze(2,0,0)=7; DoubleMaze(2,0,1)=8; This section introduced representing a robots knowledgebase in OWL file and sharing part of that data with a math engine for further processing. Architectural design issues of ASAs and ASA-based systems are taken up in the next section.

184


7.4 Autonomous Semantic Agent Based Software Architecture Systems with distributed control such as a traffic management system (TMS) and factory floor production line can be implemented easier, faster, and secure and yet perform better through use of autonomous semantic agents (ASAs). Let us first consider a scenario in which this is realized; and, then work out bases on how that all could become true. In the distributed processing environment of a TMS, let us assume that management of each traffic intersection is taken over by an agent with semantic intelligence. An ASA executes its business logic while operating on its policy store, maintains intersection parameters, and interacts only with its neighboring nodes in the network topology. In all its endeavors, an ASA benefits from an understanding of its immediate vicinity gained through semantic technology and business domain ontology. Its functioning is for the most part semantic, autonomous, and guided by globally imposed business policies. For an ASA can be realized as an intelligent agent, a TMS is easily implemented through a collection of semantic Web service agents arranged according to the traffic network topology. In preparing a TMS application system, it would suffice to develop a generic ASA Web service class, instantiate ASAs from it in numbers as required one per intersection, and supply each with specific intersection data in semantic representation. One of the ASAs is configured slightly differently so that it acts as the operational overseer and repository for aggregated data. This central ASA knows the whole traffic network, identifies each intersection (and its associated ASA), can interrogate and instruct individual ASAs. TMS is a hot topic in artificial intelligence, mathematics, and graph theory in computing departments currently. Such systems are typically implemented to control traffic lights and balance the traffic in city roads. However, people in the traffic are interested in finding factual info such as the best path to their destination in near realtime. Current TMSs are able to meet that requirement only through dedicated add-on traffic information systems, which is quite costly. Modality and utilization of ASAs for information provisioning in a TMS is taken elsewhere [24, 25]; nor TMS taxonomy / ontology will be considered here. An ASA would be capable of intelligent interaction with neighbors and people in the traffic, thus both gathering operational data and responding to information requests. Let’s suppose that a service request is received by an ASA. That ASA considers the request, either responding to the requester with the required information, or, not-having sufficient data to compose a response, forwarding the request to its (connected) neighbors. An ASA receiving the forwarded request behaves as the forwarding requester did: responding or forwarding. Finally, the ASA at the source node, which originated the request, collates all responses received, composes an answer, and provides it to the requester-user. This is pictorially displayed in Fig. 7.12. How effective would such a message - passing modus operandi be? An ASA forwards an unanswerable request to all of its neighbors. Additionally, responses to a request would have to be broadcast back similarly. Could this cause an avalanche of messages, consequently bugging down the network through excessive message traffic? We will look in to that and other aspects of ASA network in the following sections.


185

Results from neighbors

Responder ASA Business / Policy Rules Processor

∧

∨

…

Local policies Role Base

Request

Response

Results from neighbors

Requester ASA Business / Policy Rules Processor

∧

∨

…

Local policies Role Base

Fig. 7.12. Request propagation and response collation in ASAs [17]

7.4.1 Introduction to Theory and Practice of ASA An ASA is an intelligent agent, which essentially operates as a semantic Web service [27]. It functions by employing Web services protocols and carries out its built-in business logic. ASA description, registration, and discovery are same as for a Web Service represented in W3, Web Services Activity and Semantic Web Activity. An ASA is additionally made context-aware through semantic Web technology. It uses the full range of semantic Web protocol stack. Consequently, it is capable of network and neighbor discovery, ontology matching, employs ontology- and rulebased reasoning as described above [35]. It may have interfaces with passengers, drivers, and vehicles in the network to display information for and possibly to receive queries from; NLP capability may be required depending on the application. 7.4.1.1 ASA as a Physical Entity An ASA is an intelligent agent disguised as a Web service. As Web services go, an ASA could be practically executing on any platform. Depending on processing requirements of the job at hand, it may be implemented at any level of complexity from a hosted Web service sharing same platform with many others, to a mobile robotic

186


agent, to a self standing processing node with own server and storage, and up to a server farm performing as one of the nodes in a semantic grid network. 7.4.1.2 ASA-Based Paradigm to System Development Implementing a system based on ASAs may be carried out in the following steps: i Prepare a generic class definition of ASA having the required business functions and also fitted with capability to carry out site management, inter-node communication, and interaction with external actors; ii Instantiate one ASA for each node (such as, for each intersection in TMS, manufacturing stop at production line, and processing joint in a semantic grid system); iii Initialize each ASA with its node configuration, general and site-specific business policy directives, processing rules in terms of semantic representation, and their relevant ontologies; iv Prepare a Facilitator ASA object with supervisory capability; v Initialize the Facilitator ASA with network topology, business logic, overall system and node policies, administrator interface, and all concerned ontologies. Should it be required to instantiate ASAs during system execution, such as adding new intersections to an already operating TMS, the Facilitator would also include generic class definition of ASA. Then, the system can be started rolling. 7.4.1.3 ASA Interaction and Communication ASAs establish a virtual network of open, cooperative, and multi-agent system. Developing interaction rules and protocols among agents is one of the central research topics in multi-agent systems. For cooperative agents, protocols are required so that agents can achieve a common goal if they followed the protocol. Similarly, in the case of competitive or selfish agents, we need to design protocols so that a socially desirable outcome can be achieved, even if agents act selfishly [34]. However, in the case of ASAs, as they are built to satisfy the specific business function, agreeing on a common goal and cooperation towards that end is a given. On the other hand, means of carrying out the interaction requires further development. It is thought that collaboration & interaction could be facilitated through a standard agent communication language [12] devised according to social commitment and asynchronous collaboration views [13, 14]. Whereas above treatise is suitable for inter-agent collaboration, ASAs may as well be setup in situations where collaboration & interaction with people is required (such as in TMIS which is a TMS with traffic query and information dissemination features). In such systems, where robots, agents, and people will be coordinated to achieve shared goals, distributed collaboration and interaction [11] and proxy-based integration architectures [10] may prove helpful. On the other hand, server-side management of intelligent agent-based Web services [15] such as that provided by ASAs was not favored in this study. ASAs in this study interact only with their “neighbors”, Facilitator, and people as explained above. According to a recent study, the fact that ASAs are designed as semantic agents is quite helpful in improving system interoperability [30].


187

7.4.1.4 Safety and Security Features of ASA The fact that ASAs and the Facilitator are generated through secure means may not suffice to protect them against malicious attempts from environment. Security in an ASA-based multi-agent system [29] should cater for unaffected operation of both the agents and the platforms supporting them. For this purpose we propose to use an agent shielding type of an encapsulation approach where an agent executes in an isolated thread. This approach also caters for secure messaging among agents. Furthermore, an ASA carries security policies to avoid unauthorized access. Semantic nature of an ASA in its internal operation and in carrying out relations with outside world appears to be its best protection. For an attacker to entice an ASA to respond, the former had to have obtained relevant ontologies to be able to mimic a “neighboring” ASA. 7.4.2 Facilitator ASA A network of ASAs is capable of self management and community service by consensus in the sense of agent-based peer-to-peer service networks and of common-goal cooperative-agents systems [33, 34]. Therefore, a central authority to control and command is not required for the most part. For example, a recent study was conducted utilizing adaptive traffic lights at intersections with no central coordination or connections to others [28]. The method works well when traffic is light, but in heavy traffic it fails as the lights change constantly due to threshold being exceeded on all directions. Lack of global strategy and adaptive coordination among intersections at real time are likely prime reasons for the failure. Once initialized, an ASA would survive on its own. An ASA then has two distinct parts: (a) Robot ASA for self-sustenance and business logic implementation; (b) Context discovery and awareness. As ASAs would behave autonomous yet obedient, there is no reason to monitor them except for perhaps to track system performance. Even for that, ASAs could be fitted with pre-installed rule base commanding them to report significant performance factors. A central capability is conceivable in order to administer global goals and oversee compliance and performance. Such is possible through creation and infusion in to the network a special purpose ASA which may be called as the Facilitator ASA for reasons given below. The Facilitator is capable of performing as a regular ASA for all related service requests. Additionally, it has central registry, overseeing, and administrative interface responsibility. These are taken up below. Facilitator carries the ASA generic code and knows how to instantiate one. It initializes the newly created ASA with global and node-specific goals, policies and rules base; delegates it with node function and records it at the registry. The registry is a central repository of SWSs for name resolution, description, service reclamation, and discovery. What is aimed by that is for all aspects nearly dynamic discovery of agentbased semantic Web services [26]. The registry may be hosted with the Facilitator. Facilitator oversees the system operation. It knows the whole of the network, nodes and associated ASAs, policy and rule body. It listens to the network activity, can interrogate ASAs, and monitors performance. It could take corrective move by changing policies and node parameters, creating new nodes and phasing out existing ones.

188


In performing overseeing function, Facilitator interacts with the administrative user as the prime interface, executes requests, and returns feedback. If a system has to have a facilitator, then probably measures should also be in place to recover from the loss of it. This would involve re-discovery of the network, and reconstruction of the registry, rules base, and policy set. It may be possible for the system to recover by first deciding on which ASA could take over through a distributed leader election exercise. 7.4.3 Multi-agent Systems Using ASAs The novel idea of treating ASAs as web services and the adaptability of an ASAbased system was described above using a facilitator, as an example. Certain distributed control environments readily lend themselves to implementation through use of a system with multiple intelligent agents such as ASAs [14, 16]. TMIS scenario is mentioned above; similarly, factory floor production line, and grid processing systems [31] can be taken up. In all such cases, client-server solution is possible, yet that creates a bottleneck at the central site by centralizing control. The resultant application mode tends to become “command & control driven”. On the contrary, the ASA-based approach distributes load to network by delegating capability to processing nodes to decide on own considered motion. Using a distributed infrastructure without strict central control accords us the possibility of enlarging the system at will and the flexibility of network topology modification. For agents are operating in concurrent and cooperating manner, exploiting parallelism in solving complex distributed problems is another virtue of this new software architecture. Taking advantage of semantic Web technology in representing network topology, node configuration, business policy, and performing objective functions, accords an ASA with power to reconcile with its environment. Furthermore, ASAs can cooperate in resolving their share of information request problems through taking advantage of other agents’ semantic data. An application of the ASA-based architecture to a multi-nodal TMIS is interesting and shows the benefits of load distribution using ASAs. This aspect we take up below. 7.4.4 Message Passing Performance While composing a reply to a user query, ASAs cooperate in broadcasting the query to the network and responses back to the requester. It was feared that the message broadcasting modus operandi might cause excessive load on the network thus invalidating any advantages gained. In order to determine exact behavior and if possible work out an upper bound on the number of messages, simulation experiments were carried out. Simulations of network models showed close to linear incremental load on the communication network. For example, for a typical network representative of real traffic intersection system, message load increases linearly with the number of intersections. Simulation of network models of sizes one up to ten ASAs for traffic network was conducted using Message Passing Interface [21] on VMware v.4.5.1 Parallel Virtual Machine. MPI is a message-passing middleware library facilitating communication


Linear

0 4

189

2

1

3 0

Intermediate 0 1

2

2

1 4

3

Fully-Meshed 4

3

Fig. 7.13. The Three traffic network models considered: Linear, Intermediate, and FullyConnected Mesh

for exchanging data and synchronization of tasks among processors in a distributedmemory parallel processing environment [22, 23]. Three different traffic network models were considered based on topology: linear, intermediate, and mesh. Linear network is akin to a railroad track where essentially there are no intersections. The linear model is the simplest of the three; although unrealistic, it is included here as a boundary / best case. The mesh model is the most complicated traffic network consisting of fully-connected intersections; that is, all intersections connect to all others, definitely quite unrealistic as traffic networks come. The mesh model is included here as the worst-case topology. On the other hand, it is clear that the intermediate model is quite realistic. All three models are being displayed in Fig. 7.14 depicts the maximum total number of messages passed due to propagation of a single message from an originator node. Obviously these are worst-case scenarios. The numbers are given for all three models. The growth trend is clearly linear for linear and intermediate models. In the case of the mesh model, it grows similar to Fibonacci series, such as, maximum number of messages for size n is the sum of n-1 and that of size n-1 where base cases are 1 and 0. In reality, results would be more favorable, because a node having received a message would not send it to the links it received it from. Also, if the node can respond to the message there is no reason to forward it further. These shortcuts will likely reduce message propagation traffic drastically. In this study we looked into a new general class of software architecture using semantic web technologies in implementing distributed systems. Specifically, we drew

190


50

Number of Messages

45

45

Fully Connected Mesh

40 36

35 30

28

25 21Intermediate Model 17 15 13 11 9 8 7 6

20 15

15 10 7 4

10 5 0 1

3 2

1

0 2

6 5 3

3

4

5

9 5 6

Linear Model

7

8

9

10

Number of Nodes

Fig. 7.14. Maximum number of messages due to propagation of one message for all models for up to 10 ASAs

examples from a set of distributed systems having replicated processing-cum-control nodes with or without central control such as TMIS, semantic grids, and factory floor production line operation. The ASA-based software architecture discussed here distributes processing load to network by delegating capability to individual nodes. Taking advantage of semantic Web technology, nodes can behave autonomously yet remain committed to local and global goals. Using a distributed infrastructure without strict central control allows ease in enlarging the system at will and flexibility of network topology modification. For agents are operating in concurrent and cooperating manner, exploiting parallelism in problem solving is another aspect of this new architecture.

7.5 Autonomous Cooperative Semantic Agents in the Labyrinth Matrix In order to solve a given maze with more than one entry to achieve a single exit gate, we can use more than one agent. Each agent discovers a part of the labyrinth area and behaves in concordance with its terms and priorities. For instance, while the agent in the first quarter of the matrix has a first-forward priority, it may be that another elsewhere has first-left priority. Agents share their discovery and this facilitates faster solution of the maze. For example once an agent reaches the exit, all others will have learned where it is, thus heading straight there (Fig. 7.15). We take up this and other intelligence issues in this section. Following section covers the algorithms used in the existing solitary robots. Experimental results and screen shots of our simulation program are given. Next we introduce intelligent cooperative behavior of ASAs in solving labyrinth collectively.


191

Exit

Fig. 7.15. Schema of cooperation of robots to share the results

7.5.1 Naïve Discovery Algorithms In the labyrinth robotic competitions, robots are guided by an algorithm that makes decision in moving from a block to the next depending on the surrounding walls. For instance, the agent programmed for “Forward, Right, Left, Backward” priorities checks the possibility of going forward at first, if a wall closes the forward direction or the target block was previously visited, the agent selects a lower priority. In Fig. 7.16, sample configuration of a simulated game is depicted. Here, the big dot stands for an agent, numbers in cells (1 and 0 in this case) show the number of

Fig. 7.16. Single robot tries to find a way out of labyrinth

192


times the agent has passed through a block. While an agent goes through the maze, the server only informs it about the walls around the current block. The agent rotates left (third priority) in position (4, 2) because the forward step is blocked by the wall between blocks (4, 2) and (5, 2); similarly, right turn is not possible due to the wall between blocks (4, 2) and (4, 1). After that, the agent goes forward up to (4, 5) where forward block is not reachable and the agent selects the second priority (right turn), etc. In such naïve approaches, as the maze entrance and exit gates are known, the policy designer can adjust the sequence of priorities. 7.5.2 Novel Discovery Algorithms The decision can be made much more intelligently if we apply binding and predicting algorithms such as reading the walls of farther blocks using a range detector sensor arranged in a scheme to read side walls of the forward step in addition to the walls of the current block.

Fig. 7.17. Multiple robots try to find a way out of labyrinth cooperatively

Moreover, robot should recognize a loop and avoid re-visiting it. This is done at the time of reaching a previously visited block, by noting that all blocks visited in the reverse path to the same cell has right walls (or, all left walls) on. The robot raises the wall at the beginning of the loop ‘virtually’ in the memory in order to prevent re-entry in the future. A case is illustrated in Fig. 7.17 where two robots solve the labyrinth collaboratively. Problem spaces having fixed size, such as knowing all instances in a maze, vertices and edges in a graph etc. are better served through Closed World Assumption (CWA). We know that the domain knowledge is complete; therefore, CWA assumes that all instances and facts are defined. On the other hand, problems with uncertainty of


193

answer sets, having incomplete results for queries are better served through Open World Assumption (OWA). We come across many examples of that, such as in finding a way out of an uncharted maze or routing through traffic network in a city, and, in problems where estimation of probability is the cardinal rule for decision-making, etc. This is due to openness feature of problem set stemming from unknown state variables. In a way of exemplifying this, let us study the case of solving labyrinth discovery problem by cooperative mobile semantic robots. 7.5.3 Discovery by Cooperative Semantic Robots In order to solve a maze with more than one entry to reach an exit gate, we may use more than one agent (or a physical robot with ability to understand the semantics of the context, i.e., a Semantic Robot). Each agent discovers a part of the labyrinth and shares its discovered knowledge. Agents behave in concordance with their terms and priorities helping each other to find exit. Additionally, intelligence maze solver ASA focus on reshaping its priority also based on the information obtained from previously visited neighboring blocks. Other decision-making algorithms such as Blind-Man, Virtual-Agent, and Deadlock-Finder are also used in ASAs to rearrange the action priority. In the following, we introduce how agents cooperate. Once at a block with more than one possible next-block moves, in order to decide to move to which side, an agent runs Min/Max Algorithm on the number of visits of each side. It selects the one with minimum number of visits or by running shortest path algorithm. What if all visit counts are the same or none of the cells have been discovered yet? Based on theoretical implication of our research, we have developed software to solve the CLD problem using cooperating agents (robots) based on CWA restrictions. On the other hand, we have also developed an OWA version of decision making to provide a framework for testing and comparing these two approaches. Results are presented next. Agent only can see walls around the current cell. In CWA version of the example, a shared memory is updated by all robots while in OWA version, knowledge of paths are shared but each robot has own local counter of visited cells. Therefore, in both cases, the knowledge on labyrinth is incomplete. However in OWA, decision is initially based on knowledge of agent itself. If a proper decision is not reachable then the agent tries to communicate with neighbor agents in order to use their data in obtaining a solution. Let us consider the case represented in Fig. 7.18 for the robot at (7, 4). Notice that, in this case of solving the problem using two robots, left hand side number at each cell represents the local counter of the first robot, and the right value that of the second robot. Counter values of the shared memory will be summation of those two numbers. For instance, shared memory counter value of cell (7, 5) is equal to two. The query usually is: is there a path from current cell to the exit. CWA decision maker returns false as the exit has not been found yet; consequently, some paths cannot be retrieved by shortest path algorithm. The decision maker using min/max algorithm is split between selecting (6, 4) and (7, 5) as both have shared memory value equal to 2. Switching to OWA strategy, decision maker returns (7, 5) immediately as answer for next move where minimum local counter is equal to 1 among all neighbor cells of

194


Fig. 7.18. Local counters in OWA decision maker in a portion of labyrinth platform

(7, 4). Let’s note that, as move to corner neighbors is not possible, only the remaining four neighbors are considered. Where OWA decision maker returns “not available now” in more complicated cases, local counters of robots are queried one by one until a solid answer is reached. In the worst case of all local counters being equal, decision is made by simple priorities as with CWA. In Fig. 7.19, the left-hand side labyrinth is the representation of shared memory that robots are updating and the right hand side is the complete maze. As introduced at the beginning of this section, due to fixed size of problem set and knowing entrance and exit positions in labyrinth, CWA may be used to obtain a better answer set here. However, in an uncharted labyrinth, probability and estimation should be used to select one path among a set of the possible but yet undiscovered ones. For this reason in the OWA version, we provide separate memory for the counter of number of visits of each cell by a robot.


195

Fig. 7.19. Implementing CLDR based on CWA: sample game instance

The cooperative labyrinth solver program applies the following sequence of steps in the case of each robot: 1.

2.

3. 4.

Has the current cell been visited before? 1.1. Read walls of the current cell if not visited. 1.2. Update local counter and shared counter 1.3. Update shared memory of paths Run Decision-Maker based on CWA 2.1. Has the next-move-to cell been visited before? 2.1.1. If yes, run shortest path algorithm 2.1.2. Otherwise run min/max algorithm based on shared counter of visited cells 2.1.2.1. if min/max algorithm returns more than one minimum, run OWA based on local counters 2.1.2.2. if OWA results in an unknown answer, then choose one of the results of CWA randomly or based on a priority Move the robot to the next-move-to cell Check if the selected cell is an exit cell. 4.1. If not, repeat from Step 1.

The experience on our algorithm proved that there are some cases that CWA alone cannot answer the query so OWA returns a better estimation of possible answers. Therefore, we argue that a strategy to draw and utilize benefits of both world assumptions is necessary side-by-side. This strategy is following local constraints of problem definition. We cannot avoid one of the world assumptions but having them together leads to better answer sets to queries in robotic platforms. This empowers the robot with better estimations and answers while CWA alone results false as answer to unknown problems.

196


7.6 Conclusions and Future Studies In this chapter, new architecture for designing and implementation of cooperative labyrinth discovery robots (CLDRs) was introduced. With CLDRs we aim to establish intelligent collective behavior in solving problems cooperatively, such as finding a way out of an uncharted labyrinth. CLDRs use semantic technology in order to represent and retrieve labyrinth information such as block visits, crossings and walls. Such data representation avails more flexibility and portability for robots. A modular architecture was developed in the design and implementation of software and hardware of CLDRs. Autonomous semantic agent (ASA) was introduced as generic description of CLDR class agents. Semantic Web services technology was introduced and shown how to apply to agents for semantic information processing. Decision making based on a strategy choosing one or the other of open/closed world assumptions was applied to CLDR operation. Similarly covered is the approach to developing distributed processing applications as multi-agent system (MAS) using ASAs. Currently, implementation issues relating to central control, security, and fault tolerance are being investigated. Further study may be required to detail ontology processing and matching. Additional development is pending in multi-threaded programming for the microcontroller in availing concurrent reading of sensors while the embedded board communicates with the microcontroller for various other tasks.

Acknowledgements The work reported here is part of the Cooperative Labyrinth Discovery Project MEKB05-01 supported through the Fund for Enhancing Research in Higher Education by the Ministry of Education and Culture of the Turkish Republic of Northern Cyprus. We hereby also thank Internet Technologies Research Center, and the parallel computing setup of the Department of Computer Engineering, Eastern Mediterranean University for their support in this project. The design of the CLDR won an ad hoc award, “A Special Prize for Technical Merit”, in the Student Poster Competition of the Symposium at RO-MAN 06: The 15th IEEE International Symposium on Robot and Human Interactive Communication, 6-8 September 2006, University of Hertfordshire, Hatfield, United Kingdom. The main theme of the competition was "Getting to Know Socially Intelligent Robots". The CLDR later on won the prestigious “First Prize” in the Free Style Robot Category among 46 contenders at the METU National Robotics Competition that was held on 3rd & 4th of March 2007 at Middle East Technical University (METU), Ankara, Turkey.

References [1] Elçi, A., Rahnama, B., Kamran, S.: Defining a Strategy to Select Either of Closed/Open World Assumptions on Semantic Robots. In: Proc. COMPSAC 2008, Turku, Finland, July 28 - August 1, 2008, pp. 417–423. IEEE CPS, Los Alamitos (2008) [2] Elçi, A., Rahnama, B.: Theory and Practice of Autonomous Semantic Agents. MEKB-0501 Project Final Report. Department of Computer Engineering, and Internet Technologies Research Center, Eastern Mediterranean University, North Cyprus (December 2006)


197

[3] Elçi, A., Rahnama, B.: Considerations on a New Software Architecture for Distributed Environments Using Autonomous Semantic Agents. In: Proc. 2nd International Workshop on Software Cybernetics IWSC 2005, 29th IEEE COMPSAC 2005, pp. 133–138. IEEE publications, Los Alamitos (2005) [4] Elçi, A., Rahnama, B.: Human-Robot Interactive Communication Using Semantic Web Technologies in Design and Implementation of Collaboratively Working Robots. In: Proc. Robotics 2007 (ROMAN 2007), Jeju Island, Korea, August 26-29 (2007) [5] Elçi, A., Rahnama, B.: Intelligent Junction: Improving the Quality of Life for Mobile Citizens through better Traffic Management. In: Proc. YvKB, TBD Publications (in Turkish), Ankara, Turkey, June 8-9, pp. 67–74 (2006) [6] Takahashi, H., Nishi, H., Ohnishi, K.: Autonomous decentralized control for formation of multiple mobile robots considering ability of robot. IEEE Transactions on Industrial Electronics 51(6), 1272–1279 (2004) [7] Elçi, A., Rahnama, B., Amintabar, A.: Security through Traffic Network: Tracking of Missing Vehicles and Routing in TMIS using Semantic Web Services. In: Proc. The Second IEEE International Conference on Technologies for Homeland Security and Safety (TEHOSS 2006), Istanbul, Turkey, October 9-13, pp: 337–349 (2006) [8] Lin, C.-H., Song, K.-T., Anderson, G.T.: Agent-based robot control design for multirobot cooperation. In: Proc. IEEE International Conference on Systems, Man and Cybernetics 2005, vol. 1(10-12), pp. 542–547 ( October 2005) [9] Yun, X., Yiming, Y., Zeming, D., Bingru, L., Bo, Y.: Design and realization of communication mechanism of autonomous robot soccer based on multi-agent system. In: Proc. IEEE International Conference on Systems, Man and Cybernetics 2003, October 5-8, vol. 1, pp. 66–71 (2003) [10] Scerri, P., Pynadath, D., Johnson, L., Rosenbloom, P., Si, M., Schurr, N., Tambe, M.: Teamwork: A Prototype Infrastructure for Distributed Robot-Agent-Person Teams. In: Proc. Second International Joint Conference on Autonomous Agents and Multiagent Systems AAMAS 2003. ACM, New York (2003) [11] Martin, C., Schreckenghost, D., Bonasso, P., Kortenkamp, D., Milam, T., Thronesbery, C.: An Environment for Distributed Collaboration among Humans and Software Agents. ibid [12] Verdicchio, M., Colombetti, M.: Semantics and Pragmatics of Interaction: A Logical Model of Social Commitment for Agent Communication. ibid [13] Fornara, N., Colombetti, M.: Semantics and Pragmatics of Interaction: Defining Interaction Protocols using a Commitment-Based Agent Communication Language. ibid [14] Weyns, D., Holvoet, T.: Synchronous versus Asynchronous Collaboration in Situated Multi-Agent Systems. ibid [15] Ardissono, L., Cardinio, D., Petrone, G., Segnan, M.: Business Processes and Conversations: A Framework for the Server-Side Management of Conversations with Web Services. In: Proc. 13th International World Wide Web Conference on Alternate Track Papers & Poster. ACM, New York (2004) [16] Payne, T.R., Paolucci, M., Singh, R., Sycara, K.: Facilitating Message Exchange though Middle Agents. In: Proc. of AAMAS 2002, Part 2. ACM, New York (2002) [17] Elçi, A., Rahnama, B.: Applying Semantic Web in Engineering a Modular Architecture for Design and Implementation of a Cooperative Labyrinth Discovery Robot. In: Proc. 4th FAE International Symposium on Computer Science and Engineering, European University of Lefke, Gemikonağı, Northern Cyprus, pp. 447–452 [18] Elçi, A., Rahnama, B., Kiavash, B.: Embedding Matrices Ontology into Math Software Engines to Support Reasoning and Mission Oriented Calculation in Developing Semantic Agents. In: The International Conference on Semantic Web and Web Services (SWWS 2008), Monte Carlo Resort, Las Vegas, Nevada, USA, July 14-17 (2008)

198


[19] Erdur, R.C., ve Seylan, I.: A Framework of Cooperative Agents with Implicit Support for Ontologies. In: Klusch, M., Rovatsos, M., Payne, T.R. (eds.) CIA 2006. LNCS (LNAI), vol. 4149, pp. 416–430. Springer, Heidelberg (2006) [20] Elçi, A., Rahnama, B.: Upon human-robot inter communication, RO-MAN 06 Robot Companion Design Contest. In: Proc. the 15th IEEE International Symposium on Robot and Human Interactive Communication, University of Hertfordshire, Hatfield, UK, September 6-8 (2006) [21] Rahnama, B., Kostin, A.: MPI: A Message Passing Interface Standard. Technical Report, Dept. Computer Engineering, EMU, TRNC (December 2004) [22] Gropp, W., Lusk, E., Skjellum, A.: Using MPI: Portable Parallel Programming with the Message-Passing Interface, 2nd edn. MIT Press, Cambridge (1999) [23] Snir, M., Otto, S., Huss-Lederman, S., Walker, D., Dongarra, J.: MPI: The Complete Reference, 2nd edn., vol. I. MIT Press, Cambridge (1998) [24] Elçi, A., Rahnama, B.: Traffic Control using Autonomous Semantic Robots., Technical Report, Dept. Computer Engineering, EMU, TRNC (January 2005) [25] Elçi, A., Rahnama, B.: Traffic Info Gathering and Dissemination Using Interconnected Autonomous Semantic Robots as Junction Managers. In: Proc. TMT 2005- 9th International Research / Expert Conference “Trends in the Development of Machinery and Associated Technology, Univ.s of Zenica, Politecnica de Catalunya, and Bahcesehir, September 26-30, Antalya, Turkey (2005) [26] Sycara, K., Paolucci, M., Soudry, J., Srinivasan, N.: Dynamic Discovery and Coordination of Agent-Based Semantic Web Services. IEEE Internet Computing 8(3), 66–73 (2004) [27] Dogac, A., et al.: Artemis Deliverable D3.1.1.2: Review of the State-of-the-Art- Semantic Web and Web Service Semantics, EU FP6 Artemis Project (IST-2103 STP Artemis), METU-SRDC, Ankara, Turkey (April 7, 2004) [28] Patch, K.: Adaptive Lights Organize Traffic, Technology Research News, January 26 / February 2 (2005), http://www.trnmag.com/Stories/2005/012605/ Adaptive_lights_organize_traffic_012605.html. See C. Gershenson’s, http://homepages.vub.ac.be/~cgershen/sos/SOTL/SOTL.html [29] Varadharan, V., Foster, D.: A Security Architecture for Mobile Agent Based Applications. World Wide Web: Internet and Web Information System 6, 93–122 (2003) [30] Su, X., Hakkarainen, S., Brasethvik, T.: Semantic Enrichment for Improving System Interoperability. In: Proc. of 19th ACM Symposium on Applied Computing (SAC 2004), Nicosia, Cyprus. ACM press, New York (2004) [31] Foster, I., Kesselman, C.: The Grid: Blueprint for a New Computing Infrastructure, 2nd edn. Elsevier, Amsterdam (2004) [32] Çelik, D., Elçi, A.: Discovery and Scoring of Semantic Web Services Based on Client Requirement(s) through a Semantic Search Agent. In: Proc 30th COMPSAC Annual International Computer Software & Applications Conference. Proc. IEEE International Workshop on Engineering Semantic Agent Systems (ESAS 2006), Chicago, Illinois, USA, vol. 2, pp. 273–278. IEEE Computer Society Press, Los Alamitos (2006) [33] Udupi, Y.B., Yolum, P., Singh, M.P.: Agent-Based Peer-to-Peer Service Networks: A Study of Effectiveness and Structure Evolution. In: Proc. Third International Joint Conference on Autonomous Agents and Multiagent Systems AAMAS 2004, vol. 3. ACM, New York (2004) [34] Yokoo, M.: Protocol / Mechanism Design for Cooperation / Competition. In: ibid, vol. 1 [35] Olgu, G., Elçi, A.: Integrating Ontologies by Means of Semantic Partitioning. In: Koné, M.T., Lemire, D. (eds.) Canadian Semantic Web, Semantic Web and Beyond Series, vol. 2, 232p., 20illus., Hardcover, pp. 121–134. Springer, Heidelberg (2006)

8 Principles for Effectively Representing Heterogeneous Populations in Multi-agent Simulations Daniel T. Maxwell1 and Kathleen M. Carley2 1

1595 Old Gallows Road, Suite 207 Vienna, VA [email protected] 2 Carnegie Mellon University, 5000 Forbes Ave, Pittsburgh, PA [email protected]

Abstract. Multi-agent dynamic-networks simulations are emerging as a powerful technique for reasoning about complex socio-cultural systems at sufficient fidelity that they can support policy development. Within these models the way in which the agents are modeled and the fidelity of the system are critical. Basic principles guiding the development and use of these models to support policy development are described.

8.1 Introduction Understanding and predicting human behavior, particularly group behavior, requires understanding and reasoning about complex systems. Examples of such systems are nation state stability, belief formation and change within societies, and the spread of infectious diseases. There are many reasons why socio-cultural systems and the behaviors that emerge from them are complex; e.g., heterogeneous populations, multiple networks connecting the members of these populations, and learning and adaptation at both the individual level and the network level. Historically, the types of models have been applied to these complex systems have not been adequate to capture and so reason about the core sources of complexity. For example, large heterogeneous populations have been represented using deterministic macroscopic models or very simple agent based simulations with sparse representations of their information state and correspondingly simple decision logics for the agents. Information diffusion in these types of models tends to be represented using epidemiological kinds of models and either random or very simple social structures. While these models have served the community well in the preceding decade or so, recent improvements in both the social and the simulation sciences provide the ability to meaningfully improve the fidelity of information diffusion and decision making behavior in simulated populations. Complex systems, particularly socio-cultural systems, can be most usefully understood through modeling. Multi-agent (or agent based) simulations are rapidly emerging as an extremely popular tool in this area. Applications range from simulations of colonies of ants, to networks of computers, to abstract and relatively high fidelity human populations. The types of human populations that are often represented in multi-agent simulations include commercial and social organizations, geographic A. Tolk, L.C. Jain (Eds.): Comp. Sys. in Knowledge-based Environments, SCI 168, pp. 199–227. © Springer-Verlag Berlin Heidelberg 2009 springerlink.com

200

D.T. Maxwell and K.M. Carley

neighborhoods, cities and regions of countries (Batty, 2005). Now even large geographically dispersed virtual groups or organizations that stay connected using modern communications and computing capabilities are important to consider and can be simulated. The rapidly growing popularity of agent-based simulation is due, in part, to advances in the computer and computational sciences that make simulating large numbers of agents possible, the development of simulation scenarios easier, and visualization of simulation results more intuitive (Samuelson & Macal, 2006). Additionally, the “fit” these simulations have with the social and organizational science theories that are also being modeled are contributing to the growing popularity (Carley, 2001). While the technical advances make this type of simulation more accessible and salable, they do not necessarily consider adequately the underlying social, psychological, and analytical sciences that are essential to producing truly credible and defensible results. This knowledge gap presents a risk for some customers of the results of these simulations because the results, while either intuitive or able to be explained by some plausible story, are not well grounded theoretically. In the case of policy analyses these plausible stories could lead decision makers to choose ill-advised courses of action with potentially catastrophic consequences in terms of life and national or organizational treasure. As a very simple example of how this can occur consider an Army analysis supported by one of the authors that was trying to identify the number of trucks that the U.S. Army needed to buy. Some simulations were applied that represented a set of trucks moving supplies around a virtual theater of operations. The cargo on each of the trucks was limited by weight. Later it was learned that most truck cargo fills out the cargo space long before it reaches the weight limit. Consequently, using only one variable (weight) instead of two (weight and cube) the analysts underestimated the number of trucks required by a few hundred. Fortunately, the discrepancy was identified and the estimates were redone before the Army experienced a real truck shortage. One type of agent-based model that is very usable for policy development is a multi-agent dynamic-network model. Multi-agent models enable group, social and cultural behavior to emerge as a result of the morass of actions by social agents. Dynamic network models embedded in the simulations enable the pattern of interactions among social agents to influence and be influenced by the actions of these social agents. Together, in a multi-agent dynamic-network model the social agents act, interact, and learn. This is accomplished in a world where their behavior is constrained and enabled not just by their physical position, but by their social and cultural position in the set of networks. These networks connect individuals and groups and through which information, resources, and disease spread. In contrast to earlier models, in the new multi-agent dynamic-network simulations not only are agents and their logic more realistic, these agents act within a social and geographical landscape that bears a higher correspondence to the real world. Information and beliefs diffuse through social networks embedded in demographic, geographical, and technical realities and these social networks change and evolve as the diffusion of information and beliefs results in changes in agent behavior. Consequently, this new class of model, the multi-agent dynamic-network model, can be used to make more accurate predictions about the range of possible futures and consequently to study a wider range of policy issues and social activities.

8 Principles for Effectively Representing Heterogeneous Populations

201

Our goal in this paper is to lay out a set of principles that are grounded in the underlying social and modeling sciences that will help analysts and simulation developers to implement simulations of predominantly human populations that are well suited to their intended purpose. First, we present a set of observations from recent research by the authors in multi-agent and multi-agent dynamic-network simulation, followed by a set of principles that should be considered when designing agents to represent a large heterogeneous population in these simulations. How these agents are designed is of critical importance because agent design impacts a variety of factors including: the tradeoff between model fidelity and run time, the level and type of validation possible, and the type of virtual experiments needed to assess model outputs. In particular we will be emphasizing the representation of knowledge and beliefs in the agents, how the population of agents is described, how they interact, how information flows, and how they make decisions. To accomplish our goals we will first discuss some of the reasons we model populations and why simulation is important to understanding their behavior. We will then explore the sources of complexity in populations, followed by some examples of the current state-of-the practice in agent based simulation. We will then present a set of considerations that analysts and simulation builders can use when designing multi-agent simulations or conducting analyses that apply these simulations. And, finally, we will offer a set of conclusions and some recommendations for continued research.

8.2 Why Use Computer Simulation Human populations are “complex adaptive systems” (CAS). Some key characteristics of Complex Adaptive Systems that have been identified in the literature are (Dooley, 1997; Morel et al, 1998):

• • • • •

Order is emergent as opposed to predetermined. System history is irreversible. System futures are often unpredictable. Large number of interacting parts Nonlinear behavior (Individually and collectively)

Human populations clearly possess all five of the characteristics identified above. This becomes even clearer when one considers how dynamic the environment in which we live has become. Complex adaptive systems cannot be understood by “just thinking about it.” Rather, formal modeling techniques are needed, particularly, computer simulation models. There are many reasons to simulate populations. Three reasons we will discuss in this paper are training, scientific inquiry, and policy support. Each of these reasons has some special purpose for investing the energy necessary to build a simulation. For example, a policy development simulation is built and applied to gain insight into some set of questions we have about how a population is likely to behave or change over time for the purpose of evaluating some set of possible interventions to identify the best course of action. Computer based simulation is an appropriate, ethical, and cost effective way of understanding the space of possibilities that are likely to emerge when various critical events occur or policies are enacted. For example, imagine that

202


we wanted to understand whether school closures would be effective in inhibiting the spread of a pandemic influenza. Simulation actually let’s us examine, in a virtual world, the probable response of populations and the spread of the influenza to interventions like school closures given flu’s with different mortality and infectivity characteristics. The overall reason that it is important to understand the underlying reasons for developing a simulation is that this knowledge is absolutely critical to identifying the fidelity that is required for achieving the desired goals. (Maxwell & Loerch, 2007) For example, in the case of a training application of a simulation the goal is to improve the proficiency of the training subjects. In most cases where multi-agent simulations are applied the target audience is a staff or response team and the specific goal is to help them work more effectively as a team. Consequently, a reasonably realistic set of results that provide a context for their interaction are sufficient for their purposes. In the case of social science research multi-agent models can be used generate hypotheses and extend social science theory (Carley & Newell, 1994; Davis, J., et al., 2007). In some instances, very simple models can be used effectively to explore a hypothesis. For example, Schelling (1971) used a simple grid model with green and red agents and just the concept of tolerance to explore how segregation occurs. Even without a concrete connection to time on the calendar, or explicit representation of agent interactions Schelling was able to explore how segregation occurs in cities. Social science research that emphasizes the diffusion of information and innovation as a central issue has been shown to require additional fidelity in the representation of peoples’ (agents’) knowledge to achieve meaningful results. Carley (1999) demonstrates that the social network (who talks to whom) is intertwined with the individuals cognitive picture (what they know and how they think) as well as an individuals transactive memory (perception about who knows what). This complexity implies that in order to meaningfully develop and explore hypotheses relating to information diffusion all of these concepts must be represented explicitly to gain insight into the friction those inconsistencies in these different pictures and ground truth might cause. But why use multi-agent dynamic network simulations? Historically, the representation of population changes was accomplished using deterministic equation based computational models. For example Helbig (1992) applies an equation based fluid dynamics model to represent the movement of pedestrians around a city. Systems Dynamics models, such as Forrester’s (1971) WorldII model representing global economic activity and population change, use differential equations to effect the changes in model variables over time. Mathematical models have been used by epidemiologists for decades to help researchers understand how diseases spread around populations (Bailey, 1975). These epidemiological models have even been extended and applied represent to other phenomenon like the spread of computer viruses (Kephart & White, 2001). All of these models have two properties that limit their usefulness for understanding information dependent complex adaptive systems. First, they assert a top down structure that is either static or changes using a set of centrally identified and controlled rules. Population changes occur within the constraints of the specified structure, completely limiting the ability of lower level organizations and individual entities to adapt and evolve. Consequently, the emergent responses of diverse agents resulting from adaptations in their behavior do not occur. And second, these historical approaches either lack or have a very limited representation of individual agents, the


203

information flows among members of the population, and the effects the information has on agent behavior. This limitation relates especially to the effects multiple sources of conflicting information can have on the population. Because of this, it is difficult, if not impossible, to investigate the impact of diverse technologies and message content on the diffusion of information and the consequent change in knowledge and beliefs around the population. These characteristics limit the model’s ability to sufficiently represent and explore more complex phenomenon that are based on the diffusion of knowledge and beliefs. Policy analysis and decision support applications present perhaps the most demanding requirements for simulation fidelity and validity. (Harrison, J., et al., 2007) One reason for this is that the consumers of simulation results are often neither scientists nor analysts. Rather the consumers are operational staff and decision makers who want to know what the simulations’ results tell them about their operational challenges and what they should do about them. So, there is a need for interpretability of the simulation results and a need to provide simple causal explanations of the results. This is not transparency in the sense that the exact workings and all nuances of the model need to be explained; rather what is needed are simplified explanations that get the core concepts right and communicate them clearly. Additionally, policy analysis and decision support are accomplished to support real dynamic situations. Concepts like geographic position, time, and agent behavior need to be connected to a real map, a real calendar, and real behaviors by the people implementing the policy decision. Moreover, accountability for results often occurs along very tightly constrained timelines as well as from multiple sets of stakeholders with different perspectives on the situation under study. Multi-agent dynamic-network models afford yet another level of realism. The key limitation of standard multi-agent models is that the agent’s behavior is constrained by their physical position in a grid and/or ability to move in this grid. The agents are acting in a pseudo physical space. In contrast, in a dynamic-network model the agents are positioned in a socio-cultural space that evolves as they learn and interact. Multi-agent simulation systems make three key contributions to scientists, analysts, and decision makers. First, the development of the model helps the participants understand the relationships which come together to effect complex behavior. The disciplined process that simply building the model requires often lays bare relationships that may not have been evident before. (Sterman, 2000). Second, the model itself supports detailed analysis and enables more systematic evaluation of effects in a way that supports both explanation and forecasting. Because the patterns of behavior that emerge as a result of second and higher order interactions are grounded in a well specified set of first order relationships and behaviors it is often much easier to see and understand causal chains of reasoning that one might not have otherwise been visible. Epstein and Axtell’s (1996) work using the very simple model Sugarscape stimulated a whole collection of more detailed experiments. And, the United States Marine Corps Project Albert simulations (Horne, 2001) provided simple insights that were the genesis for more detailed that the Marine Corps used to develop military doctrine. Third, because multi-agent simulations can be used to conduct virtual experiments, it is easier to examine a broad range of interventions under diverse sociodemographic conditions. Gilbert (2008) points out that when one experiments on social systems “isolation is generally impossible, and treating one system while not treating

204


the control is often ethically undesirable”. Simulation allows researchers to virtually experiment on the social system without facing these design and ethical issues. Policy analyses also have the same types of issues. We have already identified that complex systems are history dependent. This means that there are no “do-overs”. Once one intervenes into a social population; a multi-agent simulation can be used to engage in a series of virtual experiments for the purpose of exploring hypotheses or to conduct “what-if” analysis across a series of possible interventions that are being considered and thereby support planning.

8.3 The Sources of Complexity Every journalist, and every author, is taught to describe a scenario using who, what, where, why, and how and when elements (Figure 8.1). Each of these factors is a source of complexity. But from a systems perspective, it is not just these entities, but also the networks of relations within and among each of these areas that contributes to complexity. Complex socio-cultural systems can be usefully represented as the set of specific nodes that populate the who, what, how, where why, the relations among them, and Fig. 8.1. The Sources of Complexity the changes in these relationships over time (the when). This representation scheme is known as the meta-network (Carley, 1999). At a practical level the ideas underlying meta networks are seen elsewhere. For example a similar concept, under the rubric “Generalized Network model” (Clark, 2006), appears in the intelligence analysis literature. All behavior can be described in terms of this meta-network. People interact with each other and their environment every day to work, play, and socialize. These interactions can be thought of as a combination of decisions that are based on information, beliefs, and behaviors that require and use resources. These interactions may be done to accomplish some task or take part in some event that requires certain resources or knowledge. A systematic look at people, their knowledge, beliefs, access to resources, tasks and events in which they engage, the locations at which those interactions take place, and the relationships with other agents in the environment, and the networks that form as a result of their interactions begins to reveal the true complexity of the system and consequently the modeling and analysis challenge. In designing and building a simulation model, each of the who, how, what, where, why and when elements need to be addressed. The level of specificity in each of these dimensions affects the fidelity of the model. The key is to be specific enough to “To Do” “To Do”

“To Do” “To Do”

“To Do” “To Do”


205

address the question of concern and NO MORE so as to avoid unwarranted computation, storage and analysis costs. As Einstein said, “Everything should be made as simple as possible, but not one bit simpler.” 3.1 First Source of Complexity: The Who! Answering the “who” question begins to develop insight into people and their behavior. It is known that the decision-making behavior of individual humans is relatively simple. Simon (1998) points out that “Human beings viewed as behaving systems, are quite simple”. In fact humans make decisions using heuristics, moral and social norms, specified protocols, and conventions. Even though individual humans are relatively simple, human populations are complex. Simon goes on to say that “the apparent complexity of our behavior is largely a reflection of the environment.” There are many centuries of descriptive data, and libraries full of studies verbally describing this complexity. Unfortunately, this verbal information is neither complete enough, nor consistent enough to provide the detail needed for constructing a computer simulation. Given that our goal is to help practitioners build simulations, we will discuss this complexity with an eye toward identifying a set of variables that can provide a sufficient foundation for a credible simulation. People are social animals. They are embedded in all different types of social networks: they belong to families, live in neighborhoods, have jobs, and are members of organizations. These networks affect who a person interacts with, how they interact, what they discuss and exchange, and how an interaction affects the knowledge, beliefs, and behavior of the person. It is well known that people tend to interact more frequently with similar people. In fact, McPherson, Smith-Lovin and Cook (2001) cite over one hundred studies that have observed homophily in some form or another. These factors include age, gender, class, organizational membership and role, family ties, and so forth. Consequently, a large source of complexity is that interactions among people are neither smoothly nor randomly distributed across the population. The interactions and the networks change over time, just based on who they are and how they were influenced by prior interactions. Further complicating this issue is that it is known that people will extend their social networks when they require expertise they do not possess; this is especially true if that expertise is needed to achieve some goal. In such cases, people will most often seek out the person possessing the knowledge (or resource) who is most similar to them. In addition to people, formal and informal organizations also serve as a form of a “who” in a social system. This is because organizations have a unique identity that is more than just the sum of the interactions of its members. Organizations make decisions, have behaviors, communicate information, and have resources that are often only loosely coupled to their members. This means that there will be often be differences between the behavior, knowledge and beliefs of an organization and its members. Membership in a political party is an excellent example of how these differences emerge. (Axelrod, 1984) A political party may endorse a specific position on an issue. The party communications machinery will advertise that position widely. A member of the party may not agree with that position but choose to remain a member of the party because of agreement on other issues.

206


The key from a modeling perspective is when developing a model it is critical to define who the “whos” in the model will be. Are they people, organizations, mediasources, animals, or other? Each class of who and the information-processing, cognitive and emotional capabilities they are given will impact the model results (Carley-Newell,1984).

8.3.2 Second Source of Complexity: The How! A second source of complexity is how things get done in this network of networks. Most behaviors require resources and knowledge to be executed successfully. Resources are typically physical objects such as money, vehicles, or computers. Whereas knowledge includes specialties, expertise, ideas, key concerns, and skills. Sometimes behaviors or tasks are more complicated and may require multiple types of resources and knowledge from multiple sources to accomplish. These (often complicated) dependencies influence the likelihood which tasks will be accomplished, what communications will occur, and ultimately how the system will behave and evolve over time. (Moon and Carley, 2006) As an example, consider the knowledge and resources required to conduct insurgent bombing activities. There is a list of possible parts. There are skills necessary to assemble, place, and detonate the device. Countering these devices also requires resources for detecting activities, interdicting supply chains, and responding to immediate threats. Depending on ones analysis goal, it could be necessary to represent explicitly most of these resources on both “sides” of the model. One special type of resource that is especially relevant in multi-agent simulations that are concerned with information flows and decision making is information and communication technology; i.e., the set of technical resources that allows people to obtain and share information without face to face contact. This is critical because people have differential access to information and communication technology based on a host of demographic characteristics like age, location, and socio economic status. We also know that this technology is changing all of the time. These technology based networks evolve very quickly, and in fact are not “engineered”. Rather their structure evolves and their effect on the population emerges based on what segments of the population have access to and adopt the technology and for what purpose. The use of cellular telephones and text messaging in particular are wonderful examples of how this pattern plays out. Over the past few years the use of text messaging has become prevalent in younger age groups; much more so than older segments of the population. This technology effect is extremely important as we do research and policy analysis. The key from a modeling perspective is that when developing a model it is critical to define the how. In a sense this is populating the agent with knowledge and providing access to resources. At another level, this means creating processes in the model for controlling the creation, maintenance, and depreciation of knowledge and resources, tradeoffs among resources and rules for transferring these among the agents. This includes the creation of interaction and communication protocols.


207

8.3.3 Third Source of Complexity: The What! The next source of complexity is the “what”; i.e., the activities, tasks, and events in which people engage. People and other actors in the environment engage in all sorts of behaviors. In some cases the behavior involves the receipt or communication of information. In others it is the execution of a specific task to achieve some specified goal. Some tasks are simple, like making a telephone call, or paying one’s tax bill. Others are significantly more complicated and may require the execution of multiple tasks that have complicated dependencies among them. For example, successfully conducting a bombing involves procuring the required materials, assembling the device, transporting it to the target’s location, finally detonating the device. A failure on any of the tasks will result in a failure to achieve the overall task goal (Moon and Carley, 2006).

In agent based models these “whats” appear in many forms. In some models these appear as the set of actions that agents can take such as passing information, filing tax returns, going to the doctor’s office. Other agent based models take a more event based approach and define whats as a series of external interventions or events such as a speech by a local opinion leader or the closure of schools. 8.3.4 Fourth Source of Complexity: The Where! “Where” things occur also introduces complexity into a multi-agent simulation. People, resources, and events are not randomly spread around the environment. Neither are they uniformly distributed around the environment. Spatial orientation is both influenced by and influences social networks, resource networks, and task networks. People with cars and money can and do travel much further than groups without those resources. Certain kinds of activities occur in urban areas and others are more likely in rural areas. (Diseases spread faster in crowded environments.) Ponds, lakes, rivers and other geo-spatial features impact where homes and businesses are built. Location also impacts the formation and dissolution of relations. For example, two people in the same location are more likely to interact or start interacting; whereas, the tendency to interact may atrophy as they move far apart or at least the communication technology used for interaction may change. In agent based models the “where” can appear in many forms: In many models, the where is a location on a grid and movement is dictated by this grid. In other models, locations may be defined in terms of a set of places such as home, office, or school that may or may not have specific latitude-longitude coordinates. Agent actions and use of resources may depend on location. For example, a student-agent may not be able to get information from a teacher-agent unless both are at a school. Agents may move to locations based on their beliefs, knowledge, resources or tasks. For example, agents who are ill may go to a hospital. 8.3.5 Fifth Source of Complexity: The Why! Another factor that influences the complexity of the social landscape is “why” things occur. The why can be thought of as beliefs, attitudes, goals, or motives. What beliefs agents hold may depend on the beliefs held by others they interact with, or their

208


knowledge or task experience. The agent’s goals may impact where the go, whom they interact with, what information they share, what tasks they engage in, and so on. In agent based models, the why can be implemented in many ways. Some models take a very goal oriented optimization approach. The problem here is that in many situations people can not articulate their goals (e.g., as in the case of traumatic life events), or the stated goals are not the true underlying goals (e.g., as when modeling tax compliance), or there is no way of knowing the goals of the agents modeled (e.g., as in the case of terrorists). In other models, beliefs are represented using social influence models and knowledge assessment. In this case, beliefs, like knowledge and resources can flow through the social networks and transform those networks. 8.3.6 Sixth Source of Complexity: The When! The final source of complexity is time. The order in which things occur, lags in information flows, dictated times at which key events must occur, the length of time actions take, and so on influence the behavior of the model over time. Complex behavior in populations is very real and has many sources. We can see that one very useful way to organize our thinking about that complexity is to look at the world as is we were a journalist. Answering the key questions of who, what, when, where, why, and how go a long way toward helping us shape our thinking about complex systems. And, we will see a little later also can help us think through the design of a simulation.

8.4 Illustrative Agent Based Simulation Applications There is a growing body of multi-agent simulation work. These examples highlight what the state of the art can support, what the limits of different simulations are, and provide examples of issues practitioners should consider when undertaking a simulation development project. We will describe four different simulations, each with different characteristics. Specifically, we will look at two different simulations that address the spread of an epidemic, we will look at one simulation that supports the analysis of political and military scenarios, and the fourth describes the behavior of US taxpayers in response to different interventions by the US Government’s Internal Revenue Service (IRS). All of these simulations are flexible enough to be used for representing scenarios other than the ones discussed in the paper. The specific scenarios help flesh out the discussion of why one is simulating as well as the specifics of implementation. 8.4.1 BioWar (Spread of Infectious Disease) A multi-university team of researchers applied a Carnegie Mellon University developed simulation called BioWar (Carley, et al. 2006) to examine the impact of life threatening events on populations at the city level. For this model, 62 diseases, including all biological warfare agents and a chemical attack for diverse cities have been modeled. This model has been used to examine the spread of anthrax, smallpox, and influenza. For example, it was used to understand the relative effectiveness of different intervention strategies, given an influenza epidemic in Norfolk (Lee, et al 2008).


209

The simulation scenario was Norfolk Virginia and contained approximately 1.6 million agents, representing explicitly the population of that metropolitan region. The virtual environment represented homes, schools, places for entertainment, and health care facilities. Agents located themselves at one of these facilities for one or more time steps, making a decision to either change location or stay with every time step. Facilities have operational schedules and the agents have behavioral rules that preclude agents from going to closed facilities. Each time step represents four hours of real time and the scenario ran for a one year period. This particular scenario and level of fidelity required a Cray XD1 super computer to execute. Each replication of the simulation took fourteen hours to complete. The “who” in this simulation are the people that make up the population of the Norfolk metropolitan region. Each agent was given a set of socio demographic characteristics such that the demography the virtual population was consistent with the 2000 census data. Then based on socio-demographics including occupation social networks were built among the agents to reflect human networks. Additionally, 200 agents were “infected” and spread randomly around the city. This was a proxy for a planeload of people infected with influenza arriving at the airport and disbursing. The “what” consists of a set of actions that the agents can take. Agents relocate (or stay) every four hours and choose to interact (or not) with others while they are at that location. Also, depending on the location they may engage in other activities such as buy over-the-counter medication, get diagnosed by a doctor, become infected, spread the disease, die or become well. The choice of interaction partner is probabilistically determined, based on an agent’s demographic characteristics; the more characteristics two agents share, the greater the likelihood they will interact if they are in a position to do so. When the agents interact if one of them is infected and contagious there is a chance that the influenza will be passed from one to the other. The likelihood of this occurring is based on the transmission rate of the virus. At the same time that influenza is spreading, other diseases may as well. And, though not used in this study, the simulation also allows for airborne, waterborne, and food borne infection. Only some of the obvious “how’s” are represented explicitly. Agent’s do have a set of knowledge, including knowledge about their visible symptoms and they use that knowledge to make decisions. Agents do get drugs, over-the-counter and prescription, and those may impact symptoms and diseases. Other general resources such as transportation vehicles are not modeled as the four hour time tick was of greater granularity than travel time. There is even a facility in the program whereby the agents know that a medical alert has been called, or the schools are closed and the agents change their behavior based on that knowledge. The “where” in the simulated city consisted of a number of specific locations found in Norfolk including homes, workplaces, schools, pharmacies, doctor’s offices, emergency rooms, stadiums, theaters, stores, restaurants, universities, and military facilities. Locations could be open or closed, depending on the day, time of day, and weather. Additionally, inclement weather or interventions could lead to school closures. The geographic, location, and weather data came from U.S. Census Bureau reports on cartographic boundaries for schools, Metropolitan Statistical Area (MSA) boundaries and business patterns, and National Oceanic and Atmospheric Administration (NOAA) Climate Data. (Carley, et al., 2004)

210


As indicated earlier, “why” people interact is influenced most heavily by homophily, their visible medical symptoms, and their location, and the “when” is every four hours, giving agents six possible opportunities to interact in a 24 hour period. 8.4.2 EpiSims (Smallpox Diffusion) Episims was originally developed at Los Alamos National Laboratory, and is now from Virginia Polytechnica Institute, for the purpose of exploring the diffusion of disease around a city or other geographical region. In the application discussed here the specific interest is the spread of smallpox around a virtual Portland Oregon. Similar to the Norfolk example researchers are interested in evaluating the differential effects of different intervention strategies and scenario assumptions, given an outbreak of Smallpox in the region. (Eubank, et al., 2004) The virtual Portland was represented using approximately 1.5 million agents and 180,000 specific locations and used the minute by minute movement around an underlying transportation network for a simulated period of 100 days to stimulate the contact that caused diffusion of the disease. The underlying simulation engine called TransSim runs on a bank of 128 networked personal computer class machines. (Los Alamos, 2008). The “who” in this scenario consists of approximately 1.5 million agents living, working, or transiting the city of Portland Oregon. Each agent possesses a set of socio-demographic characteristics derived from the census that are used to provide the agents with differential location and mobility. The networks of connections among these people are very stylized and canonical “small world” networks. The “how” people interact is based on the underlying transportation simulation. An agent’s underlying socio-demographic characteristics are assumed to provide them with differential mobility on the network. Additionally, some agents have randomly assigned characteristics that give them even greater mobility on the network to simulate those people whose employment or lifestyle cause them to move around more broadly. The “where” are 180,000 specific locations. The locations do not have their purpose represented explicitly. But they do have a maximum capacity which is distributed in a “scale free” fashion across all possible locations, causing agents to gravitate toward high capacity locations, like shopping malls. The belief is that this distribution is similar to how people actually behave, moving from home to public locations and back. The “what” in this simulation is largely movement, with possible contact and infection based on co-location for periods of time. If people are at the same location for more than one hour of simulated time with an infected and contagious person, then there is some probability that the agent will contract the virus. In the scenarios aerosolized smallpox was introduced at indoors busy locations over several hours, infecting approximately 1,000 people to seed the epidemic. The “why” for interaction is implicit in this gravitation to dense locations. The when is very highly resolved (second by second) movement data, with possible contacts occurring when two agents are in the same location for more than one hour.


211

8.4.3 Construct (Taxpayer Behavior) This simulation effort applies a Carnegie Mellon University developed multi-agent simulation called CONSTRUCT (Carley, 1991; Schrieber & Carley, 2004) to the challenge of helping the US Internal Revenue Service (IRS) identify cost effective portfolios of services, advertisements, and interventions that will encourage the US population to voluntarily meet their tax obligations. To accomplish this, the research team developed agent populations of a few thousand agents that are representative samples of the population demographics in multiple US cities. Additionally, the team developed explicit representations of tax filing knowledge, tax payer beliefs, and IRS communications programs that are designed to educate and assist the tax paying population. Simulated scenarios were run for a virtual year (sometimes two) with each time step on the simulation representing one week of calendar time. The simulation was run on a 64 bit multi-processor machine, requiring approximately three hours to complete. The “who” in this simulation consists of approximately 3,000 or more agents representing taxpayers in a US city? These agents are imbued with a set of sociodemographic characteristics, including income and their income tax filing status. Additionally, there are “Smart Agents” (Carley& Newell, 1994) that provide taxpayers information (or misinformation) serving as proxies for newspapers, radio and TV, IRS Tax Assistance Centers, and internet access points. All of the agents have some level of knowledge about taxpaying behavior, as well as, general knowledge and some transactive memory about where to go for additional knowledge on tax related topics. Additionally, taxpaying agents have beliefs about how they feel about their obligation to pay taxes and a level of risk tolerance that is independent of their beliefs. The “how” consists of an ability (or inability) of a taxpaying agent to engage in some taxpaying related behavior both legal and illegal. This ability is determined by the degree that the tax payer matches the target audience for the behavior. For example, the US Earned Income Tax Credit (EITC) targets lower income taxpayers to provide them with a measure of tax relief. If an individual is in the qualifying income range, they have the resources in the simulation to take the credit. Other tax related behaviors may involve other factors, like number of children or geographic location. These are also thought of resources in the simulation. The “what” consists of two behaviors. The first is a decision to interact with another agent at every time step. The decision to exchange information and beliefs with another agent is eighty percent homophily based and twenty percent based on differential expertise. When two agents interact, they exchange a subset of their knowledge and beliefs with the other agent. In some cases the knowledge is accurate, in other cases it could be misinformation. The second behavior is an annual decision to file (or not) income taxes and if the agent chooses to file an accompanying set of decisions concerning what deductions and credits to take. This decision is based on a vector of factors, including the knowledge that the agent has acquired through interaction with other agents. The “where” in the taxpayer simulation is only treated explicitly when it is relevant for a tax related factor. For example one study, (National Taxpayer Advocate, 2007) represented explicitly the residents of the city of Hartford in an effort to replicate an experience the IRS had with taxpayers and the local government in 2004.

212


The “why” agents do things in this simulation is based on an explicit representation of their beliefs about tax compliance. This set of beliefs has two components. First, the agent can believe that what they’re doing is either right or wrong, or some shade in between. This is important because in many cases taxpayers engage in noncompliant behavior but have been advised either unintentionally or intentionally that the behavior is legal. The other belief is that it is either OK, or not, to cheat on one’s taxes. An agent will engage in a non compliant activity if and only if one of these two beliefs is consistent with noncompliance. 8.4.4 SEAS – (Military Operations) Another application of agent based simulation is in support of the US Military’s effort to migrate to a new operational concept called “Effects Based Operations (EBO)”. In this concept the military hopes to represent and consider explicitly the broader possible set of implications of a military operation. To do this they are describing operational inputs along four dimensions Diplomatic, Information, Military, and Economic (DIME) and outcomes along six key dimensions; Political, Military, Economic, Social, Information, and Infrastructure (PMESII). Purdue’s Synthetic Environment for Analysis Simulation (SEAS) which was originally designed as an agent simulation in support of market forecasting was adapted in three ways to analyze EBO. First, it was adapted to allow for human in the loop interaction during a simulation run, second it was federated with a simulation of military operations called the Joint Warfare System (JWARS), and finally functionality was added that was more focused on DIME and PMESII concepts. (Chaturvedi, et al., 2004)

The “who” in the simulation consists of over 100,000 simulated agents that operate in the SEAS simulation environment. The agents are given properties such that the differences among agents are consistent with the areas demographics and culture. The analysis environment also includes exogenous inputs from human players representing key government leadership roles, key neutral parties (like unbiased press), and enemy organizations. There are also data exchanged with the JWARS simulation that informs SEAS about the status of military entities that are perceived to be relevant to the PMESII variables. The “what” in the simulation is an abstract representation of ports being opened and closed, diplomatic activities at varying levels, movement of the military and population around the environment. Agents choose to interact with each other and move about in the simulation consistent with a rule set that is based on over 15 attributes consisting of features like culture, religion, and education. Human decision makers in the key roles make higher level policy decisions and then the agents interact with each other in response the changing environment. The “when”, is relatively close to a near real-time environment, allowing for visualization of agent movement in the SEAS environment, with user selectable ability to run forward in time. This keeps the simulation timing consistent with the other simulation and allows for human interaction with the simulation. A consequence of this is normally scenarios represent days, to months of simulated time from end to end. The “where” is normally in a geographic region of variable size and resolution. In the case of the scenario described the literature it was the city Jakarta. (Chaturvedi,


213

et al., 2004) The environmental representation includes roads, structures, ports, and traffic loads on the infrastructure. The “how” is based on differential resources provided to the different classes of agents, and human players. Types of resources include budgets, information, humanitarian assistance and supplies. The “why” is based on a combination of attributes of the simulated agents, including religion, Culture, and an attribute called motivation. All of these attributes are considered as part of a rule based decision engine for determining agent behavior.

8.5 Multi-agent Simulation Principles The technical foundations of Multi-agent simulation and more generally multi-agent systems are largely based on the achievements of the computational organization theory, artificial intelligence and object oriented programming communities. Volumes have been written that describe good overall technical design and programming practices for multi-agent systems (Woolridge, 2002; Gilbert & Trisch, 2005), and simulation more generally (Law and Kelton, 2000). These practices are extremely important for good overall system design, implementation, and analysis but addressing them sufficiently is beyond our scope. Rather, we are focusing on the principle considerations that are relatively unique to development and applications of simulations to complex socio-technical systems. We highlight important considerations for six parts of the development and application process for such systems. These six parts are organized in roughly a sequential order, but practitioners should be prepared to iterate as activity in one area indicates a need for adjustments in another. 8.5.1 Use Good Modeling Practices All simulation (and software) development projects have a common set of decisions that must be made at the outset of the project. What language to use? How to structure the development team? What development process to follow? These are extremely important initial considerations that are discussed for the interested reader in more detail in Hoover & Perry (1990) and Maxwell & Loerch (2007). One general consideration that warrants explicit treatment for our purposes is the need to refine the research or analysis question at the beginning of the effort. We have previously discussed the need to understand the underlying reasons for developing the simulation. That addresses the first part of this challenge. The second general consideration is to identify the key sources of uncertainty and the planned procedures for dealing with that uncertainty. Multi-agent systems are often unpredictable due to the complexity of the system. This implies a critical need for dealing with uncertainty throughout development and application. Uncertainty in modeling exists at two levels. The first is the uncertainty associated with a model variable being in a specific state. These uncertainties are often addressed using probability distributions over the state space. The second kind of uncertainty, often called deep uncertainty, addresses uncertainty about the structure of the model itself. (Laskey & Lehner, 1993) One way to address effectively these uncertainties is to as exhaustively as possible describe low level behaviors, and use this knowledge as means to

214


guide further development, experimental designs, and analysis of outcomes from the simulation. Another way to address these uncertainties is to scope the model’s use to the areas where there is greater certainty. A third way is to do a series of sensitivity analyses of the critical uncertainties. 8.5.2 Key Simulation Design Tradeoffs Once the decision to build or use a simulation is made, there is a series of decisions that need to be made that provide context for the rest of the model development effort. In general there are two top level design decisions. • Understand the tradeoffs First is the level of real• Clearly define simulation purpose ism, or fidelity, the agents and the environment o If you change the purpose revisit should possess. And secthe assumptions ond, is the number of agents that will be in the o Decide whether the model will be simulated population. validated Depending on the reason • Use good modeling practices for developing a model o Refine the research or analysis and the data that is question available to support the o If the model is to be validated then development, the practiidentify the mapping between tioner can vary these two measurable data and simulated dimensions. variables In general, the higher o Clearly specify desired output the fidelity of the simulameasures tion system the wider the o Think explicitly about uncertainty range of policy issues and o Clearly document assumptions social activities that can o Clearly document modeling risks be addressed by the • Clearly specify the variables simulation and the more o Agents detailed the policy reco Environment ommendations. However, • Clearly specify agent behaviors the higher the fidelity of o Use Network thinking the simulation system the o Understand how change occurs longer it takes to develop, • Conduct sufficient verification and validaset up, and run. The tion testing higher the fidelity the • Conduct well structured virtual experiments greater the input data o Good design requirements, and the o Rigorous analysis more types and quantities • Clearly present results of data that will be genero Consider the audience ated. Thus the tradeoff is, improved fidelity (realism) can lead to improved support for the policy analyst and decision makers. There are costs associated with this increased fidelity. The


215

simulation will cost more and take longer to develop. The simulation will require more powerful and more expensive computational resources. In general the higher the fidelity of the simulation system the more data that can be used to validate it and the more reasonable it is to engage in validation. That said, the higher the fidelity of the simulation, the more resources that are required to do validate the model. Time, people, and money are needed to run representative scenarios, collect data and to engage in validation relevant analyses. As these costs increase, the less likely it is that the entire system will ever be validated. In general, the higher the fidelity of the simulation system the more types of virtual experiments that can be done to explore diverse issues and the more sensitivity analyses need to be done. What this means is the higher the fidelity the more analytically relevant data of different types that is generated. This output requires more computer storage space, advanced designs of experiments, and more statistical analysis to harvest the meaningful analytic insights. In fact, the emerging high fidelity simulation systems generally generate so much output data that standard statistical packages cannot be used to analyze the results. To meet this challenge specialized search tools and data farming environments are being developed and applied. (Horne, 2001) In general, similar to higher fidelity representations, the greater the number of agents in the virtual population, the slower the simulation will run, and the more computing power that will be required. Matching the number of agents in the virtual population with the real population significantly increases the “realism” of the simulated scenario and simplifies many issues in the design of the virtual experiments. There are, however, sampling and experimental design techniques that allow one to conduct analyses with a smaller population of agents. 8.5.3 Why Is the Model Being Built? In trying to decide on the appropriate level of fidelity the practitioner needs to consider not just these tradeoffs, but also the purpose for which the model is being built. Because these are descriptive models that can not and should not represent the entirety of reality one must ensure that the explicitly represented behaviors of the agents are consistent with the key parts of the system of interest and that simulated results inform the relevant research, analysis, or policy questions. The second part is to take a small step back and do some disciplined thinking about the essential reasons one cares about developing the simulation or doing the analysis in the first place. Too often, we have seen this step in the process either overlooked because everyone on a development team “knows” the goals or timelines are too short to allow for this luxury; only to find out later this shortcut was a very costly mistake. Keeney (1992) and Edwards, et al. (2007) provide some very useful thoughts on the details of how this is accomplished effectively. Developing a clear understanding of the overall goals of the process naturally leads to an improved understanding of one’s specific objectives. These objectives need to be quantified and then identified as desired outputs of the simulation. That is, from the beginning, simulation design (or simulation selection if there are existing choices) should consider explicitly output measures. Again accomplishing this exercise early brings clarity to the development process that increases the likelihood of project success.

216


As we stated earlier, in some cases the purpose of the model may be to explain and predict social behavior with the intention of advancing sociological theory (Carley, 2001). In other cases the simulation may be informing policy level decisions in a national government or other large organization. For example, the United States Government’s Internal Revenue Service (IRS) is conducting research using multi-agent simulation in an attempt to better understand the behavior of US taxpayers so they can identify a mix of messages, services, and interventions that will help US Taxpayers to comply with their legitimate taxpaying obligations (Carley & Maxwell, 2006; National Taxpayer Advocate, 2007). Other examples of policy decision support applications are the use of multi-agent simulation to inform planning processes in support of military operations, counterterrorism operations or strategic communication efforts around the world (See Chaturverdi, et.al. (2000) and Carley, et. al. (2003) for detailed examples). Additionally, multi-agent simulations are being used in support of training activities, particularly to generate crowd behavior emergency personnel can then interact with to practice their response to different kinds of crises. (Chiva, E & Delorme, J. 2004). 8.5.4 Clearly Specify the Variables There are two overall types of variables that require specification in our virtual world: those relating to the agents and those relating to the environment in which they will function. At the very top level there are two goals for these variables. First, they must be clearly defined. That is there should be no ambiguity about what the variable represents (or doesn’t). And second, they must exhaustively describe the space of entities and behaviors that are critical to the topic being studied. These concepts must be defined at a level of representational resolution that is semantically consistent both internally, and with the relevant research and study questions. (Davis & Tolk, 2007) In general, if the model is to be validated, each variable in the simulation should have a real world analog and be “measurable” in the real world. Use of variables that are impossible to measure in the real world is generally a sign that the model is to be used only for illustrative purposes. 8.5.4.1 Specifying Agents The fundamental building block of an agent based simulation is an agent. Agents are most often thought of as representing people. But as we saw in the example applications, such as Construct, agents can also represent organizations, companies, nation states, computer programs, news articles and other intelligent or information processing actors. Formally, an agent is a discrete entity in the simulation that has the following characteristics: • Autonomy – It possesses the ability to function without someone or something else having direct and complete control over its behavior. These behaviors include the ability to interact with other agents, make decisions, and to accomplish some task. This does not mean that the agent can initiate interaction merely that it can engage in some information processing operation on its own. • Knowledge – It has information. This information may be about itself, the environment, and/or other agents. In some cases this information is both accurate and sufficient to enough to enable constructive behavior. In other cases, the knowledge is incomplete, inaccurately perceived, or incorrectly processed. This knowledge may include historical, current, or mythical information. For knowledge, the agent


•

•

• •

• •

217

either knows it or does not, and for some class of knowledge may have some level of expertise. Beliefs – In some cases agents, especially human and organizational ones, posses a special type of knowledge called beliefs. These beliefs are usually stable and focus on fundamental concepts like right and wrong, religious conceptions, etc. Agents can hold opposing beliefs and these beliefs can be held with some degree of intensity. Resources – An agent can possess or have access to resources that empower them to execute some behavior or set of behaviors. Examples of resources might be money or raw materials. Agents can hold multiple instances of resources or levels of the same resource. Information processing capabilities – Agents may have some ability to initiate interaction, locate information, acquire, perceive, give, process, forget information. This includes sensory ability, social skills, and adaptivity based on learning. Sensory ability – An agent possesses the ability to collect and perceive facts about its environment. In some cases this may be the result of direct observation, in others it could be the result of communication that is received from another agent. Social skill – Agents have the ability to communicate with other agents. In this communication they can either initiate or reciprocate and share and receive knowledge the other agent(s) in the interaction. Adaptivity – Some agents have the ability to learn and modify their behavior based on what they learn or think they learn. Physical capability – Agents may have some ability to move themselves or objects and so put themselves in positions to acquire or provide resources, information or beliefs, or to engage in particular actions. Decision criteria – Agent may have some ability to make decisions. This may be the result of clearly articulated goals and plans or simple stochastic reactions as constrained by their environment, knowledge, beliefs, and capabilities.

Not all agents possess the same level of capability along any or all of these attributes. In fact these differences among these properties are a key part of what causes the population in the simulation to be heterogeneous. Systematically mapping these properties to be aligned with the task at hand is an important early task in model development. For example, when describing an agent for use in a simulation of taxpaying behavior it is unlikely that religious affiliation and beliefs are directly relevant to the analysis, so they can be set aside. On the other hand, if the simulation is trying to explore the behavior of a population as part of a counterinsurgency analysis effort, religious belief is likely a very relevant belief. The simulation design goal is to identify a minimally sufficient set of different dimensions for describing the population. 8.5.4.2 Representing the Environment Finding a suitable level of fidelity for the representation of the environment is another critical part of the simulation design. In modeling the principle of Occam’s Razor applies. (Jefferys, W. & Berger, J., 1992). We want to use the simplest abstraction with the fewest number of variables possible. That said, the number of variables need to be sufficient to capture the characteristics of the environment that might have major influences on the simulation’s outcome. A wonderful example of this is found in the extensions of Helbig’s work. The initial simulation environment consisted of a simple

218


grid around which agents could move. Later work demonstrated that even the introduction of simple obstacles (perhaps proxies for geographical constraints or affordability constraints) significantly changed the reults (Miyao, 1978). These differences in results caused by such a small change in the environment have stimulated significant discussion about the generalizability of Helbig’s results. 5.4.3 Specifying Behavior The next task in building a multiagent simulation is to specify the set of actions or behaviors that the agent can engage in, conditions for the behavior and response to that behavior both by that agent, the environment, and other agents. We have previously discussed the sources of complexity that make this a challenging task using a journalist’s perspective. We can use these dimensions to help us organize our thinking about behavior. Figure 8.2 organizes those same concepts into a multidimensional network that Fig. 8.2. The meta-network as it evolves through time specifies the set of possible factors that might influence agent behavior and subsequently simulation results. Combining an inspection of this network with what we have learned previously about multi-agent simulations, we can see that the “who”, “how”, and “why” make up the set of agents and the attributes those agent possess that influence their behavior in the environment. The “what” are the things the agents do in the simulation. And the “where” is the (physical and/or virtual) location of those actions. In fact one thinks about this in object oriented programming terms, the agents and locations are objects, with the how and the why as attributes of the object or constraints on what that object allows, the behaviors are methods in the software that represent the behavior of the agents. For each agent, its environment is the collection of other agents, and the set of possible how, what, where, and whys that exist at a specific when. Each agent’s perception of this metanetwork is that agent’s transactive memory. This meta-network specifies a matrix of relations, often referred to as the metamatrix. Specifying the meta-matrix is a helpful way to specify key aspects of the design of the multi-agent simulation system. Adding another level of detail to our thinking is even more helpful for actually designing and developing a specific model. Table 8.2. lays out a matrix that identifies the types of networks that should be considered as part of the design. For example, the simulation requires some abstraction for “who knows who”. In BioWar and Construct the agent has a set of alters that are in its sphere of influence that it normally interacts with, but based on where the agent is when or what events are ongoing the agent my engage in potentially random interactions with others outside this sphere. These networks may reflect known


219

socio-demographic constraints as in BioWar or be specified using very stylized hypothetical structures such as the scale-free networks in EpiSims. Specifying all the relevant relationships among all of the agents in the agent population a priori would be a daunting task with many thousands of agents. A possibility is to specify a set of attributes that allow one to adjust the probability that two agents will interact based on their similarity. In the IRS example above the authors used a vector of attributes, including age, gender, race, income, marital status, and education as indicators of similarity. The more attributes the agents held in common, the higher the likelihood that they would interact and exchange information. More generally, we need to have some representation of the fact that people are embedded in different social networks, and that those networks influence who interacts. Table 8.2. Network view of illustrative relationships in a multi-agent simulation at a particular point in time Agents

Knowledge

Resources

Actions Events

Locations Beliefs

Agents Social Network

Knowledge Knowledge Network Information Network

Resources Capabilities Network Skills Network

Actions Activities Network

Substitution Network

Resource Needs

Events Participation Network

Locations Physical Presence

Knowledge Needs

Beliefs Belief Network Factual basis

Availability

Workflow Network Precedence Network Borders

The concept of differential access to information (knowledge) is further complicated when we introduce the ideas behind the knowledge network and the capabilities network. For example, there is some type of information available through internet sources. To represent this effectively in research or analysis we would likely need to create a “smart agent” that has that knowledge available for an agent to find. Then the searching agent would have to be able to access the internet (a resource) and either have knowledge that the information was available (transactive memory) or have some behavior that allowed it to search the internet. Again, one could randomly indicate that agents have access to the internet, but as we saw earlier technology use is very different depending on age, and other demographic features. This means that in cases where understanding information flows is central to the research or analysis question then a more detailed model is warranted. In designing and developing a multi-agent simulation, the types of thought experiments and considerations described above should be conducted for all relevant networks described in Table 2. A useful technique for conducting these thought experiments is to think about what is (or might be) flowing through the network. In

220


some cases we are looking at the transfer of material goods and services to satisfy and economic demand (Chaturvedi, A et al., 2008). In the case of material goods and services it is important to specify the set of attributes and relationships that prevent very unrealistic things from occurring. (e.g. infinite supplies of goods) In other cases we are exploring the propagation of knowledge and beliefs throughout a population. Again, in some cases randomization or cursory treatment of these concepts may be sufficient, but others will require explicit treatment. Our experience is that this requirement is especially prevalent in the representation of an agent’s knowledge, beliefs, and decision making processes. This is because not all messages are created equal. As a simple example, think about a message that addresses the belief about a behavior being “right or wrong”. A website, radio message, or news article will have a different impact than a parent or a cleric communicating a message. Think about situations where the messages are different, depending on the goals of the agents. One example of this might be a simulation of strategic communications in a counterinsurgency environment. Just asserting the effectiveness of some positive messages, or even positive behavior, with out simultaneously considering the effects of conflicting messages will more often than not lead a researcher or analyst to become overly optimistic about how the system will respond to stimulus. It is true that one can not always predict what the overall changes in a complex adaptive system will look like. This does not imply that one does not need to understand the processes that produce those changes. In fact, it is absolutely essential that the basic processes be both understood, and clearly described as functions (software methods) in the simulation software. There are three facets to achieving an understanding of change processes. The first is developing an understanding about the nature of change. For example, providing a person with money will certainly increase the amount of money they have immediately available. And, the additional money makes it more likely that they will save some of it. In the simulation, the first change, receiving money, is likely best represented just by adding financial resources to the agent. In the second case, we probably want to represent the action “saving” as a decision that is a function of the additional money, but also considers other goals, knowledge, and beliefs held by the agent. This ability to locally consider multiple factors is an essential part of the power of multi-agent simulation. The second facet is to understand the rate of change. In the case of money transferring from agent to agent, the effect immediate. But it says nothing about how frequently the transfer occurs. Is it weekly or monthly, like a paycheck? Or is it annually, like a tax refund? Other types of changes occur along different timelines. For example prejudicial beliefs will likely change very slowly. Years to decades could go by before any meaningful change is seen in deeply held beliefs and engrained attitudes. Consequently, practitioners should be careful not to be overly optimistic or specific about the rates at which change happens. The final facet of change that must be understood is the mechanism that executes change. Using our financial example again, moving money from one agent to another changes their resource position. That is the nature of the change. The mechanism describes how the transfer takes place. Is it a cash transaction in person; is it a check in the mail, or an electronic fund transfer? Different mechanisms for change will have implications on what can and should be represented explicitly, or left out as peripheral to the question under study.


221

8.6 Model Verification, Validation and Testing Depending on why the model was built, verification and validation (or V&V) activities may be an important aspect of project success with multi-agent simulations of complex socio-technical systems. If the model was built to simply illustrate a process (as in training) V&V is not warranted. In principle, the level and type of V&V depends on the maturity of the model and the uses to which it will get put (Zacharias, et al. 2008). In practice, the level and type of V&V depends heavily on available empirical data, which may not exist in sufficient quantity for statistical validation, and the resources available for validation. Verification activities answer the question “Did I build the model right?” and validation addresses the question “Did I build the right model?” There is a literature available that describes a wide range of techniques for conducting V&V (e.g. Balci, 1994; Windrum, et al. 2007). On the verification side, good software engineering practice, version control and testing are needed. Even relatively simple multi-agent simulations, with simple local interactions can quickly become rather complicated pieces of software, with significant amounts of data. So, the entire system needs to be methodically and comprehensively checked for errors in implementation, design, and data. In terms of validation, there are a plethora of validation challenges that face multiagent simulations of complex socio-technical systems that simply do not arise for engineering level simulations. The range, level and types of validation techniques have exploded with the complexity of these systems. Early researchers in artificial intelligence used the idea of a Turing Test (Turing, 1950) as a test for the quality of a computational model attempting to replicate human behavior. The basic idea is that if you interact with a device and cannot tell whether the information is coming from a computer or a human then that computer model is an adequate model of the human. This is a test of the isolated individual. In multi-agent simulations we have social agents. Carley and Newell (1994) introduced the idea of a “social Turing test” that can be helpful for V&V purposes for social agents. The social Turing test is “weaker than the Turing test because it does not require confusing a computer with a person. It is stronger because it allows for plugging “in many values.” The basic idea is that if you see results about a group or population generated by a device and cannot tell whether these results were gathered from a real group or population or generated by computer simulation, then the computer simulation model is an adequate model of the social milieu. This type of test would allow a researcher to explore the range of possible behaviors for an agent under many different sets of conditions to assess its validity. Moreover, if this is done systematically across the set of agents the test could also provide some insight into the reasonableness of the behavior of the population as a whole as well. At the time Carley and Newell introduced the idea of the “social Turing test” they indicated that “carrying out such a test is well beyond the current art,” as no known simulation at that time had an adequate model social agent. We note that even for the sophisticated models described here, the model social agent’s are nearer but still not completely consistent with the full range of behavior expected of the model social agent. Practitioners need to pay particular attention to the available data, not only during model development, but also during validation verification, and testing. The quality of

222


the available supporting data supporting simulation input speaks volumes about what simulation results might be useful for. The data confirms what we know and guides what we can reasonably infer from the simulated results. Therefore, the input data should be evaluated to ensure it is relevant to the variables that are being populated. It should be reasonably available or relatively easily (and reliably) imputed from data that is available. As an example, for a recent IRS study we had census data readily available for describing the overall population of a particular community. But, the focus of the study was on a relatively small subset of the population. In order to improve the emphasis on the study population we applied a matched sampling technique and imputed an agent population that emphasized the study population, but allowed us to statistically infer the population level statistics from the matched sample. (Rubin, 2006) Additionally, some data are uncertain. These uncertainties should be clearly documented and explored using sensitivity analysis techniques to evaluate what the impact of that uncertainty might be on the simulation’s results.

8.7 Conducting Virtual Experiments The execution of a virtual experiment, similar to all other types of experiments, requires serious thought and some planning to effectively execute. The quality of the experiment’s design and analysis can have as much influence on the usefulness of the results as the entire development effort. Moreover, the previously identified limitations on the ability to validate multi-agent simulations make it even more critical to think through carefully how the simulation is to be applied. A first step is to select a set of independent variables that are relevant to the policy alternatives or hypotheses that are under consideration. Then for each variable a set of levels need to be chosen that are “representative” or critical for these alternatives. For example, if we are examining the impact of IRS interventions then the variables might be the presence of an intervention such as a newspaper add or letter to taxpayer. Whereas the level would be the number of days the add runs or the number of letters. These levels should cover the range of possibilities for the independent variables and so sample the entire space of feasible possibilities (e.g. no intervention at all, maximum intervention possible). The sample should also include sufficient interim possibilities to allow for the possibility of identifying trends, especially points of inflection in response surfaces over the results. As we stated earlier dependent variables, or simulation results, in the experiment should inform the analysis of the overall effort. In the case of training, it is likely that the dependent variables will be performance data collected through observation of the human participants and their supporting tools. The simulation appropriately provides context for that interaction. In the case of scientific research and decision support the dependent variables should relate directly to the key hypothesis or hypotheses, or the fundamental objectives of the decision makers. In cases where the dependent variables are indirect proxies for the fundamental objectives the asserted relationships between the proxies and the fundamental objectives should be thought through and documented before the experiment is executed. This disciplined step will help frame the results analysis effort and increase the quality and defensibility of the conclusions.


223

In general, one might want to apply standard experimental design constructs such as Box-Behken. However, it should be noted that the number of variables in these models is sufficiently large and the variables themselves may not be continuous that design constructs devised for physical device simulations may not be appropriate. Experimental designs need to consider the possibility of interaction effects across the set independent variables under study. Too often in simulation studies of all sorts independence among the independent variables is just asserted and experiment designs are then built on that assumption. It is more often the case, especially in multiagent simulations that there are interactions among the independent variables. In some cases the interactions provide greater than additive returns (i.e. synergy) and in others the interactions can reduce the expected returns to something less than additive (destructive interaction). A better approach is to develop design for experiments that test for independence rather than assert it. Those dependencies that emerge can then be explored in some detail, either in search of an opportunity in the case of synergy or to mitigate downside risk in the case of destructive interactions. Once the virtual experiment is run the results need to be statistically analyzed and the local response surface estimated. Often the desire to identify high coefficients of correlation and tight confidence intervals on the statistics can increase with the number of replications to infeasible levels. This is further complicated because even you if you achieve tight confidence intervals and a high R2 by increasing the number of replications, one still may not have the kind of insight that is necessary for drawing meaningful conclusions. Consequently simply judging the results using significance levels can be meaningless. To deal with this reality experimenters should do considerable sensitivity analyses (Gilbert, 2008), and look to nonparametric statistical analysis techniques and the use of data farming environments to generate sufficient results for meaningful analysis. When analyzing these results concentrate on the relative value of the beta (standardized) coefficients rather than just the significance levels.

8.8 Presenting Results The use of multi-agent simulation in support of policy decision presents a special presentation challenge. Decision makers and operational staffs are very focused on reducing and where possible eliminating uncertainty and then selecting and executing the “right” course of action. Multi-agent simulation makes explicit uncertainties they have always faced, but may have necessarily assumed away to keep their planning and analysis challenges feasible. The analysts challenge in presenting multi-agent simulation results is to quickly and effectively communicate what the simulation is saying and why it is important to them. The age old guidance “keep it simple” is extremely important in operational decision and policy analysis environments. As we indicated earlier, the results need to be transparent, not at the level of describing the complicated inner workings of the simulation; rather they should make clearly visible the cumulative if-then result for that decision of policy context. One rule of thumb is to structure the presentation to very quickly answer two questions; “So what?” and, why?” Normally, the so what is a report on visible trends in the movement of the dependent variables in response to some of the different treatments. The “why” can be much trickier in explanation

224


because the trends, especially counterintuitive ones, emerge as a consequence of second and higher order interactions over time. A very effective approach we have used to illuminate the results is to complement the aggregate results with a couple of anecdotal descriptions of how a few agents got to the state. This can be especially helpful for counterintuitive cases. Another important thing to consider in presenting multi-agent simulation results is in the area of uncertainty. Multi-agent simulations are stochastic, and often illuminate significant uncertainties that exist in the environment. These uncertainties should be discussed explicitly with decision makers in terms that make their significance clear and actionable whenever possible. Talk about the results as identifying the space of possibilities. Highly replicated results are those that are more probably, but not guaranteed to occur. Examples of cases in point are combinations of factors that might be seen that present a special opportunity for achieving exceptional results, or a set of circumstances that highlight a rising likelihood of bad outcomes that can be mitigated by some condition based operational action.

8.9 Conclusions and Recommendations for Further Research We have seen that multi-agent simulation has been and can continue to be usefully applied for many applications. We have identified a set of things that should be considered in each of the applications as well as a set of general principles to be followed for most effective simulation development. Adherence to these principles can be a key contributor to the long run success of a multi-agent simulation development effort. As we have indicated, multi-agent simulation is a rapidly growing and rapidly changing field. There are still a number of critical unanswered questions that will benefit from ongoing and future research. Future simulation developers and users would benefit from looking at the current state-of-the-art when they read this paper. Some areas of particular interest are: • Validation and Verification practices for multi-agent simulations • Multi-resolution modeling in simulations • Statistical analysis techniques for simulation results to include data farming techniques • Presentation techniques for communicating multi-agent simulation results

Acknowledgments The authors would like to acknowledge the support of multiple US Government organizations in both the preparation of this paper and our research in recent years. In particular we would like to recognize the support of Ms. Patricia McGuire, Director of the Office of Policy Evaluation and Risk Analysis at the Internal Revenue Service. Her vision and persistence have made invaluable contributions to our work in simulation. Of course any errors are the responsibility of the authors alone.


225

References Axelrod, R.: The Evolution of Cooperation. Basic Books, New York (1984) Bailey, N.: The mathematical theory of infectious diseases and its applications, 2nd edn. Oxford University Press, New York (1975) Balci, O.: Validation, Verification and testing techniques Throughout the lifecycle of a Simulation Study. Annals of Operations Research 23, 121–173 (1994) Bankes, S.: Exploratory Modeling for Policy Analysis. Operations Research 41(3), 435–449 (1993) Batty,: Cities and Complexity: Understanding Cities with Cellular Automata, Agent-Based Models, and Fractals. MIT Press, Cambridge (2005) Brown, R.E., Mazur, M.J.: IRS’s Comprehensive Approach to Compliance Measurement, IRS White Paper, Washington D.C (2003) Carley, K.M.: A Theory of Group Stability. American Sociological Review 56(3), 331–354 (1991) Carley, K.: Computational Approaches to Sociological Theorizing. In: Turner, J. (ed.), pp. 69– 84 (2001) Carley, K.: On the Evolution of Social and Organizational Networks (1999), http://www. casos.cs.cmu.edu/events/summer_institute/2001/reading_list/ pdf/EvolutionofNetworks.pdf Carley, K., et al.: Destabilizing Dynamic Covert Networks. In: Proceedings of the 8th International Command and Control Research and Technology Symposium, Washington D.C (2003) Carley, K.M., Fridsma, D.B., Casman, E., et al.: BioWar: Scalable Agent-Based Model of Bioattacks. IEEE Transactions on Systems, Man and Cybernetics – Part A: Systems and Humans 36, 252–265 (2006) Carley, K.M., Altman, N., Kaminsky, B., Nave, D., Yahja, A.: BioWar: A City-Scale MultiAgent Network Model of Weaponized Biological Attacks: CASOS Technical Report: CMUISRI-04-101. In: Carnegie Mellon University, Pittsburgh, PA (2004) Carley, K., Maxwell, D.: Understanding Taxpayer Behavior and Assessing Potential IRS Interventions Using Multi-Agent Dynamic-Network Simulation. In: Proceedings of the 2006 Internal Revenue Service Research Conference, Washington D.C, June 14-15 (2006) Carley, K., Newell, A.: The Nature of the Social Agent. Journal of Mathematical Sociology 19(4), 221–262 (1994) Chaturvedi, A., Dehnke, R., Snyder, D.: Simulating Nonkinetic Aspects of Warfare. In: Proceedings of the Interservice/Industry Training, Simulation, and Education Conference (I/ITSEC) (2004) Chaturvedi, A.R., Gupta, M., Mehta, S.R., Yue, W.T.: Agent-based simulation approach to information warfare in the SEAS environment, in System Sciences, 2000. In: Proceedings of the 33rd Annual Hawaii International Conference on System Sciences (2000) Chiva, E., Delorme, S.: Performance of Motivational Command Agents in a Command Post Training Simulation. In: Conference on Behavioral Representation in Modeling and Simulation (BRIMS, 2004) (2004) Clark, R.: Intelligence Analysis: A Target Centric Approach, xxxxx (2006) Davis, J.P., Eisenhardt, K.M., Bingham, C.B.: Developing theory through simulation methods. Academy of Management Review 32, 480–499 (2007) Davis, P., Tolk, A.: Observations on New Developments in Composability and Multi-Resolution Modeling. In: Proceedings of the Winter Simulation Conference 2007, Washington D.C (2007) Dooley, K.: A Complex Adaptive Systems Model of Organization Change. Nonlinear Dynamics, Psychology, & Life Science 1(1), 69–97 (1997)

226


Edwards, W., Miles, R., Von Winterfeldt, D.: Advancies in Decision Analysis From Foundations to Applications. Cambridge University Press, Cambridge (2007) Epstein, J., Axtell, R.: Growing Artificial Societies: Social Science From the Bottom Up. Brookings Institution Press, Washington D.C (1996) Eubank, S., Guclu, H., Kumar, V., et al.: Modeling Disease Outbreaks in realistic Urban Social Networks. Science 429 (May 13, 2004) Forester, J.W.: World Dynamics. MIT Press, Cambridge (1971) Gilbert, N.: Agent-Based Models. SAGE Publications, Thousand Oaks (2008) Gilbert, N., Troisch, K.: Simulation for the Social Scientist. Open University Press, Berkshire (2005) Harrison, J.R., Lin, Z., Carroll, G.R., Carley, K.M.: Simulation modeling in Organizational and Management Research. Academy of Management Review 32, 1229–1245 (2007) Helbig, D.: A Fluid Dynamics Model for Movement of Pedestrians. Complex Systems 6, 359– 391 (1992) Horne, G.: Maneuver Warfare Science, US GPO, Washington D.C (2001) Jefferys, W., Berger, J.: Ockham’s Razor and Bayesian Analysis. American Scientist 80, 64–72 (1992) Kaufer, D., Carley, K.: Comunication at a Distance: The nfluence of Print on Sociocultural and Organizational Change (1993) Keeney, R.: Value Focused Thinking: A Path to creative Decisionmaking. Harvard University Press, Cambridge (1992) Kephart, J., White, S.: “Directed-Graph Epidemiological Models of Computer Viruses. In: Proceedings of the 1991 IEEE Computer Society Symposium on Research in Security and Privacy, Oakland, California, May 20-22, pp. 343–359 (1991) Laskey, K., Lehner, P.: Metareasoning and the Problem of Small Worlds, unpublished manuscript (1993) Law, A.M., Kelton, W.D.: Simulation Modeling and Analysis, 3rd edn. McGraw-Hill, New York (2000) Lee, B., et al.: Virtual Epidemic in a Virtual City: Simulating the Spread of Influenza in a United States Metropolitan Area. Unpublished manuscript (2008) Los Alamos, Information found (2008), http://transims.tsasa.lanl.gov/ Maxwell, D., Loech, A.: Executive’s Guide to Practical Computer Models. Public Manager 36(3) (Fall 2007) McPherson, M., Smith-Lovin, L., Cook, J.: Birds of a Feather: Homophily in Social Networks. Annual Review of Sociology 27, 415–444 (2001) Miyao, K.: Dynamic Instability of a Mixed City in the Presence of Neighborhood Externalities. The American Economic Review 68(3), 454–463 (1978) Moon, I., Carley, K.: Testing the Robustness of Team Structures with Social Simulation. In: Proceedings of the WSC 2006, Kyoto, August 21-25 (2006) Morel, B., Ramanajuan, R.: Through the Lokking Glass of Complexity: The Dynamics of Organizations as Adaptive and Evolving Systems. Organizational Science (1998) National Taxpayer Advocate, National Taxpayer Advocate 2007 Report to Congress, USGPO, Washington D.C (2007) Parunak, H.V.D., Savit, R., Riolo, R.L.: Agent-Based Modeling vs. Equation-Based Modeling: A Case Study and User’s Guide. In: Multi-Agent Systems and Agent Based Simulation. Springer, New York (1998) Rubin, D.: Matched Sampling for Causal Effects. Cambridge University Press, Cambridge (2006) Samuelson, D.A., Macal, C.M.: Agent-Based Simulation Comes of Age. OR/MS Today 33(4), 34–38 (2006)


227

Schelling, T.: Dynamic Models of Segregation. Journal of Mathematical Sociology 1, 143–146 (1971) Schreiber, C., Carley, K.M.: Construct - A Multi-agent Network Model for the Co-evolution of Agents and Socio-cultural Environments Carnegie Mellon University, School of Computer Science, Institute for Software Research International, Technical Report CMU-ISRI-04-109 (2004) Simon, H.: The Sciences of the Artificial. MIT Press, Cambridge (1998) Sterman, J.: Business Dynamics; Systes Thinking and Modeling for a Complex Wolrd. McGraw-Hill, New York (2000) Turing, A.: Computing Machinery and Intelligence. Mind 59, 433–460 (1950) Waldrop, M.M.: Complexity: The Emerging Science at the Edge of Order and Chaos (1992) Windrum, P., Fagiolo, G., Moneta, A.: Empirical Validation of Agent-Based Models: Alternatives and Perspectives. Journal of the Artificial Societies and Social Simulation 10(2), 8 (2007) Woolridge, M.: An Introduction to Multi-Agent Systems. John Wiley & Sons, London (2002) Zacharias, G., MacMillan, J., Van Hemel, S.: Behavioral Modeling and Simulation: from Individuals to Societies. National Academies Press, Washington (2008)

9 Ontology Meets Business - Applying Ontology to the Development of Business Information Systems Matthew West Shell International Petroleum Co. Ltd., Shell Centre, London, SE1 7NA, UK [email protected], [email protected] http://www.matthew-west.org.uk

Abstract. Ontologies are often perceived as not useful for practical problems. This chapter shows that this is not true. We present an ontological framework to support development of business information systems with a focus on the conceptual data modeling phase. We introduce four-dimensional analysis, with spatio-temporal extents, and apply this approach to several examples from practical experience. We notice that four-dimensional analysis results in sets with unchanging membership, and show how some alternative set theoretic approaches have application in practice. We look more closely at properties, and in particular physical quantities. Finally, we look at how this affects the development of data models and give a case study of the development of Shell’s Downstream Data Model.

9.1 Introduction Ontology can seem remote from the "real world" in either its philosophical or computer science sense. Philosophical ontology is the study of the sorts of things that exist, and is closely related to metaphysics. It is characterized by argumentation about the philosophical consistency of different ways of viewing the world. The computer science sense of ontology arises from the world of artificial intelligence, and is rooted in representations of the world in formal logical languages of various sorts. Neither of these have had any significant, if any, impact on the world of business. On the other hand, the world of business is driven by data held in databases that are defined by the SQL language. Traditionally, the design of databases has been facilitated by the use of data models, using one of a variety of graphical notations, known as entity-relationship models, developed from the origin work of Chen [27]. The traditional approach to data modeling has been one of normalization. This is a bottom up approach to analysis that looks at the data, and seeks to minimize the holding of redundant (repeating) data. The elimination of different sorts of repeating patterns, by creating new entity types, gives rise to normalization to different levels. There are currently 6 levels of normalization recognized, and if you achieve all of these levels then you would say that your data model was in 6th Normal Form, or 6NF. The details of normalization are well documented in standard textbooks on data modeling such as [30]. What one notices doing analysis over a period is that fully normalized data models have a structure that reflects the objects of interest to the enterprise. This has lead to the development of data models directly using the objects A. Tolk, L.C. Jain (Eds.): Comp. Sys. in Knowledge-based Environments, SCI 168, pp. 229–260. © Springer-Verlag Berlin Heidelberg 2009 springerlink.com

230

M. West

of interest to the business, rather than analyzing the data bottom up [1]. However, these approaches have generally followed a naïve and intuitive approach to identifying the objects of interest, and whilst some efforts have been of high quality [28] the results have been far from uniform, with different practitioners applying different intuitions of varying quality to the analysis process. Serious attempts to apply philosophical and computer science ontology to the development of data models can be found in [29] and [5]. This chapter builds on this work, explaining the practical application of ontologies to the development of information systems for business. In particular the relevance of ontology to data models, and reference data is considered. The chapter brings together, revises, and extends work from a number of publications.

9.2 The Relationship between Ontologies and Data Models 9.2.1 Ontology An ontology is a theory of what exists, i.e. the sorts of things there are and the rules that govern them. An ontology can take many forms, have different levels of detail, define many or few rules, and be represented in many formalisms or none. This definition varies from the one usually quoted for the computer science sense of ontology by Gruber [10] “An ontology is an explicit specification of a conceptualization.” What Gruber means by “conceptualization” in this definition, is “an abstract, simplified view of the world that we want to represent.” This is essentially what a theory is, but “conceptualization” has roots in conceptualism, where it is our ideas about the world that count, rather than the realist view that an ontology is directly about the real world. Finally, the use of “an explicit specification” means that the same theory represented in another form would be considered a different ontology, and here in particular, we are concerned with the same theories perhaps in different representations as we pass through the design process, but wishing to see the theories as what essentially represents the ontology, rather than a particular specification of the theory. 9.2.2 Data Model A data model specifies the data we wish to hold about things of interest to the business using entity types, relationships, and attributes. This in turn may form the basis for the design of the database for one or more computer systems. The types of things of interest usually form the structuring basis for the selection of entity types, thus forming the link between data models and ontology. Indeed, a data model is one way of representing an ontology. However, some restrictions on the expressiveness of data models should be noted: 1. It is not possible to say that one entity type is an instance of another. 2. Individuals (broadly physical objects and activities) cannot be represented as entity types, because they do not have instances. 3. It is not possible to say that an instance of an entity type is a subtype of an entity type.

9 Ontology Meets Business - Applying Ontology

231

9.2.3 Ontology as Data Model or Reference Data With a data modeling approach to ontology, a choice has to be made as to what parts of your ontology are represented as entity types, and which as reference data. The reference data in question here is data about the types of things of interest to the business. Fig. 9.1 shows two ways in which it can be shown that P101 is a pump. In the first case P101 is an instance of the entity type pump. In the second case P101 is classified by the instance of equipment type pump. Another restriction that can be seen here is that there is no way in the second case to show that pump is a subtype of the entity type equipment item. You can also see that the entity type, equipment type, is essentially part of the meta-model for the first case. This means this style of data model can have an unfamiliar feel to those with a background in ontology rather than data modeling. On the other hand, the ontology in the second case is easy to extend with other equipment types as reference data, even after the system has been built. The choice between these two approaches will depend on the purpose of the data model. Indeed, an important design choice when designing database systems, is where to place the divide in the ontology between what part is in the data model and what part is in the reference data.

equipment_ type

equipment_ item

pump

classified by

pump

P101

equipment_ item P101, pump

Fig. 9.1. Alternative ways to represent elements of an ontology in a data model or database.1

9.3 Some Problems Found with Some Data Models Key parts of any enterprise architecture are the data models of its information systems. These sometimes constrain the information that can be held because the ontology in the data model does not match the business reality. Ten common traps are identified in [9]. One of the examples, for relationship cardinalities that lose history, is presented here to illustrate the kind of problem that can be found. 1

Data models are drawn in this chapter using the EXPRESS notation defined in ISO 10303-11. The thin line is a one-to-many relationship with the “lollipop” at the one end. The thick line is a subtype/supertype relationship, with the subtype at the “lollipop” end.

232

M. West

9.3.1 Relationship Cardinalities That Lose History Sometimes cardinalities are set to one-to-many, meaning one at a time, when the cardinalities are really many-to-many over time because the relationship is transferable. 9.3.1.1 Consequences Imposing restrictions through the data structure means: • Arbitrary or inappropriate restrictions are placed on the data that can be held. • History data about a relationship cannot be held. • The entity type will only work within the context defined. A change in business rules may require a change in the database structure. • The resultant system is harder to share. 9.3.1.2 An Example - Ship Fig. 9.2 shows that a Ship is registered at one Port and only one Port, under one name and only one name. registered_at

Port Ship registered_under

Name

Transferable relationships Fig. 9.2. Transferable relationships

However, what happens if you re-register a ship? How do you know what it was previously sailing as? The same applies to the name. If it changes you do not know that it refers to a vessel that you had blacklisted, or was an old friend. registered_at S[0:?]

Port Ship registered_under S[0:?]

Name Fig. 9.3. Correct cardinalities for transferable relationships2 2

The S[0:?] means in this case that a Ship may be registered under a set of 0 or more Names, and registered at a set of 0 or more Ports, i.e. the relationships are many-to-many.


233

Fig. 9.3 shows the correct relationship cardinalities as many-to-many, which recognizes that a one-at-a-time relationship is potentially many-to-many over time. The problem was caused by modeling a business perspective, that we normally refer to a ship by its name and port of registration, rather than looking for what underlies that view. Resolving the many-to-many relationships into entity types leads to a model as illustrated in Fig. 9.4.

Port

at registered

Ship

Ship_registered_ at_port

registered under

Ship_registered_ under_name

Name Fig. 9.4. Resolution of many-to-many relationships

However, in this case there is an activity that underlies both these relationships, Registration, and if this is recognized, then we can have one instead of two entity types representing the registration as shown in Fig. 9.5 below.

of

Date

Ship

registration_ date

Registration

at

Port under

Name

Fig. 9.5. Understanding that activities cause relationships

The relationships to the other entity types are one-to-many, and are now named in terms of the involvement of the entity type in the activity.

234

M. West

9.4 Some Principles for Data Modeling Some general principles for avoiding traps, like the one illustrated above, were also identified in [9]. They are: 1. Entity types should represent, and be named after, the underlying nature of an object, not the role it plays in a particular context. 2. Entity types should be part of a subtype/supertype hierarchy (class hierarchy) in order to define a universal context for the model. 3. Activities and associations should be represented by entity types (not relationships or attributes). 4. Relationships (in the entity/relationship sense) cannot be referred to directly as objects, so should only be used to represent things that you do not need to refer to independently, such as the involvement of something in an activity or relationship. 5. Entity types should have a local identifier within a database or exchange file. These should be artificial and managed to be unique. 6. Candidate attributes should be suspected of representing relationships to other entity types. The first of these principles makes clear the importance of “the nature of things” that is at the heart of ontology. A data model is an ontology, and as such makes ontological commitments, though these are rarely explicitly acknowledged.

9.5 A 4-Dimensionalist Ontological Framework 9.5.1 Introduction Data model consistency is dependent on taking a common view of how to represent things across the business. Unfortunately there are many ways in which we can model the world. However, there are two main approaches, with on the whole minor variations, that dominate the philosophical literature. I will call these the 3 dimensional paradigm, and the 4 dimensional paradigm. The differences between these paradigms are illustrated in Fig. 9.6 below. The 3 dimensional paradigm says, for example, that all of me exists now, and that I pass through time, and therefore I do not have spatial parts. The 4-dimensional paradigm [2, 3] says that I am extended in time as well as space, and that I have temporal parts as well as spatial parts. An additional choice is whether identity of individuals is extensional. For a 3D approach it can be problematic to insist that only one object exists in one place at any time. However, under the 4 dimensional paradigm, since objects are extended in time as well as space, it is an option to take spatio-temporal extent as the basis for identity, and we do. It may be noted that much of natural language seems to favor the 3 dimensional paradigm. I conjecture that perhaps this is because much of natural language is about the here and now, and so has become tuned to be efficient for that. However, it is perfectly possible to speak 4 dimensionally. There is much philosophical debate around whether either or both of the paradigms are correct, however, this debate is beyond the scope of this chapter. Here the 4


235

4D + Extensionalism

3D

The past and the future exist as well as the present

The present (all that exists)

space

space

Object passes through time.

Object extended in time

time 1.

Physical objects do not have temporal parts.

2.

Different physical objects may coincide (non-extensional).

time 1.

Individuals extend in time as well as space and have both temporal parts and spatial parts.

2.

When two individuals have the same spatiotemporal extent they are the same thing (extensionalism).

Fig. 9.6. 3-dimensionalism compared to 4-dimensionalism

dimensional paradigm is adopted, because it is seen as having change over time built in – rather than as something that is added on to the basic paradigm. This chapter then works through the consequences of applying this paradigm in practice in a number of areas. It is conjectured that applying such ontological principles to data model development makes them more rigorous, and as a result, where data models are developed with the same ontological commitments, consistency is likely to be easier to achieve. 9.5.2 A 4-Dimensional Ontological Framework We now present an ontological framework with a 4-dimensional foundation. It consists of: • 4-dimensional spatio-temporal extents with extensional identity, • Dissective and non-dissective classes, • 4-Dimensional Patterns, • Ordinary physical objects, • Replaceable parts, • Intentionally constructed individuals, • Levels of reality for what things are constituted from, • Activities and events, • Roles as temporal parts of individuals, • Time, • Relationships as states with states of individuals as parts, • Possible Worlds for dealing with plans,

236

M. West

• Classes as sets, since membership does not change, • Properties of various sorts including physical quantities. Together these give the building blocks we need to model the world around us. 9.5.3 Spatio-temporal Extents, Individuals and States A spatio-temporal extent is any piece (not necessarily contiguous) of space-time; see Fig. 9.7. All possible spatio-temporal extents are allowed, which is not to say that you have to be interested in all of them. Some spatio-temporal extents will be the whole lives of things that may be of interest such as persons, atoms, activities, and brooms. We call these individuals. Some spatio-temporal extents will be temporal parts of individuals, i.e. they will consist of the entire individual spatially for a part of its life. We call these states. It follows that an individual is a maximal state. A state, whether or not it is also an individual, has a temporal boundary (strictly it may be spatio-temporal, but we will deal only with the simple case here) that marks its beginning and end. We call these events. An event is the change in state, not what brings about the change.

space

Time period

State Individual Events time

Fig. 9.7. Spatio-temporal extents, individuals, states, and events

9.5.4 Time One thing to notice in Fig. 9.7 is how time appears. A point in time goes across all of space, and a period of time is a spatio-temporal extent across all space, bounded by two points in time. A 4D treatment of the relationships between objects, activities, and time is presented in [4]. Fig. 9.8 shows some key relationships objects have to time. Note that the black pieces are in fact one object that has periods of non-existence, as happens sometimes.


237

• Historical closure: the spatio-temporal extent that is all space (i.e. everything going on at the same time) whilst the object exists. • Pre-history: the spatio-temporal extent that is all space before the first point in time when the object existed. • Post-history: the spatio-temporal extent that is all space after the point in time when the object has finally ceased to exist. • Extended history: the spatio-temporal extent that is all space from the point in time that the object first existed, to the point in time after which it no longer ever exists. • Extended pre-history: the spatio-temporal extent that is all space until the last point in time that the object exists. • Extended post-history: the spatio-temporal extent that is all space after the first point in time that the object existed.

Historical closure Pre-history

space

Post-history Extended history

Extended pre-history time

Extended post-history

Fig. 9.8. The relationship between an object and time

Other useful operators are also defined: • Historical connection: When the historical closure of two objects meet or overlap. • Historical part: when the part falls within the historical closure of the whole. This at least is the case for pure time and pure periods. However, in business we might be interested in something slightly different. Imagine that you are running a business that works in lots of different time-zones around the world, and that you need to keep global accounts of your sales on a daily basis. What then is your global day? Fig. 9.9 below illustrates how this looks as a spatio-temporal extent. Of course this is still relatively simple: • There is summer time, • Not all offsets are one hour, • The start and end of the business day might be at different times (and not say midnight).

M. West

space

238

time local_day

global_local_day

geopolitical_area (time zone)

Fig. 9.9. Local, and global local days

However, space-time maps, and the 4D paradigm enable you to show these things in an intuitive way. 9.5.5 Different Sorts of Physical Objects One of the consequences of a 4 dimensional approach is that you can examine the space-time patterns that different sorts of individuals exhibit. Indeed, you can use the spatio-temporal patterns that individuals can exhibit to identify the sorts of things there are. 9.5.5.1 Ordinary Physical Objects Ordinary physical objects, like the broom illustrated in Fig. 9.10, are expected to have continuous existence3, but they can change parts or lose parts over time without losing

space

event 1

B A

event 2

D C

Head Handle

time

Fig. 9.10. A broom, with various heads and handles 3

This can be questioned. For example, when a car or watch is disassembled for repair or maintenance, is it still a car, or does the absence of emergent properties mean it is just a collection of parts?


239

identity, but they cannot change all their parts at the same time. Thus, whilst at the end of the period shown in Fig. 9.10, none of the original parts of the broom are now part of the broom, we say it is the same broom because not all the parts changed at once. Organisms are similar in renewing themselves by gaining and losing parts. 9.5.5.2 Intentional Objects Many of the objects in the world around us only exist because we are here: money, companies, agreements etc. Here we look at how these exist and what implications this has. We call such objects intentional. The view I have taken in this case follows the work of John Searle [12]. Functional Objects The simplest types of intentional object are functional object, this is where a function is imposed on an object, and has that function because of that assignment by someone. So a stone becomes a paperweight because someone (anyone) said so, and whilst they said so. This principle also applies to most types of equipment that man (and some animals) use for various purposes such as pumps and screwdrivers. Note that these objects consist of natural materials, and the function is put on them over and above being an amount of these natural materials. Socially Constructed Objects Socially constructed objects require the agreement of at least two people to exist: contracts, companies, money, etc. For example, money requires not only the authority of the issuer, but the acceptance of the populace who use it as money. A key aspect of socially constructed objects is that they need a process to manage their life, since they do not come into existence except by human will. 9.5.5.3 Levels of Reality One challenging problem that 4-dimensionalism can help to explain, is the apparent coincidence of different objects. A simple example is presented in Fig. 9.11 below. The problem arises when, because of the way that parts are arranged, the whole has emergent properties that are not present in the simple aggregate of the parts. So in this case: • When the nut and bolt are screwed together, they act as a fastener, • When the steel they consist of is formed into the shape required, they have the properties of a nut and bolt respectively, • When iron and carbon are mixed and arranged appropriately, they make steel, • Carbon and iron molecules are arrangements of carbon and iron atoms respectively, • A carbon or iron atom is an arrangement of particular numbers of protons, neutrons and electrons. Now at a point in time, each of these is coincident. However, when you look over time, you can see that the spatio-temporal extents for each level are different, as illustrated in Fig. 9.12 below.

240

M. West

Nut and bolt Nut

bolt steel

Neutron

C12

Fe2

C

Fe Proton

Electron

Fig. 9.11. Some levels of reality in a nut and bolt

Nut Bolt

Steel C12 Fe2 C Fe Proton Neutron Electron time

Fig. 9.12. The levels as potentially distinct objects

A problem case that is often used in the literature, is of the two pieces of clay that are brought together to form a vase, which at some later time is broken into a number of pieces, see Fig. 9.13 below. Neither the clay nor the pot exists as one piece before the two parts are brought together or after the vase is smashed. So there is one object that is both the vase and the piece of clay it is made from. The consequence of this for an extensionalist is that the same individual can belong to classes at different levels of reality. This in turn means that a level of reality is in the end about the relationship between the classes, rather


241

Fig. 9.13. The example of the coincident piece of clay and vase

Intentional Levels functional object organization

Biological Levels

Physical Levels composite material particulate material

organism

crystalline structure solid liquid

compound

gas

molecule atom subatomic particle

Fig. 9.14. Levels of reality implicit in ISO 15926-2

than between particular individuals, where the rule is that it must be possible for individuals to have a different spatio-temporal extent at the different levels, rather than that they must be different. Fig. 9.14 above shows the levels of reality that are implicit in the data model of ISO 15926-2 [5]. It should be noted that, because any whole that has emergent properties because of the arrangement of its parts is a new level, many of these levels may be strata or sub-strata rather than distinct levels, and are certainly not complete. However, the levels in the physical strata are thought to be distinct. 9.5.6 Plans and How Possible Worlds Can Support Them A key issue in ontology is how to deal with what could be, as well as what is. We adopt an approach based on possible worlds [7]. This allows a number of things, including allowing worlds where the basic laws of physics might be different, and

242

M. West

allowing alternative views of history or the future to be explored. However, in business, the practical use of this approach is for planning, where plans belong to a possible world, and the outcome belongs to the actual world, so that comparison can be made between them.

Past

Future Possible

Actual

Desired Possible

Fig. 9.15. Possible worlds

Fig. 9.15 illustrates how this can work. With a spatio-temporal approach to individuals, possible worlds can be allowed to intersect, with temporal parts of individuals being shared across possible worlds, since the possible world would be defined by its whole spatio-temporal extent, and only this would have to be unique. 9.5.6.1 Participation in Activities and Replaceable Parts An activity is something that brings about change, i.e. causes an event (change of state). However, if an activity exists in space-time, it is not obvious what its

Object continues Replaceable Parts

Scattered parts

space

Owen

Rooney

Player 2

Lampard

Player 3

Gerard

1 st

Player 1

2 nd

Half

Half

Football Match time

Fig. 9.16. A football match showing players as replaceable parts of a team, and of the football match itself


243

spatio-temporal extent is. Fig. 9.16 answers this question with an example of a game of football. It can be seen here that the football match consists of the states of the players (and other individuals) that participate in the game. This is true of all activities: that they consist of the participating states of their participants. Note that the parts may be scattered, both spatially and temporally. Fig. 9.16 can also be used to illustrate the principle of replaceable parts. A football team has 11 places. These are independent of both the number on the players back, and the role (goalkeeper, forward, defense) a player is allocated to. Further, one player may be substituted by another. Owen being substituted by Rooney in the middle of the second half of the game illustrates this in Fig. 9.16. A key thing to be noted here is that all the parts of player 1 have been substituted at the same time, something that with ordinary physical objects would mean you had a new object. So this pattern of replaceable parts is distinctive.

Replaceable Part/ Role Captain

space

Owen Gerard

2nd Half

1st Half

Football Match time Fig. 9.17. Roles, like being team captain, are a type of replaceable part

Some replaceable parts can be roles. This is illustrated in Fig. 9.17. This is another view of the same game. But here we see that Owen was captain whilst he was on the field, but when he left, the captaincy was given the Gerard. Notice that whilst Owen’s numerical replacement was Rooney that did not mean that Rooney took over the role of captain. These can be seen as distinct, because they have different spatio-temporal extents. Other examples of replaceable parts that are roles are positions in an organization, such as President of the United States. A comforting thing about this analysis, compared to others that see roles as abstract objects, is that it makes sense to talk about shaking hands with (a state of) the president. There is only one object that you shake hands with, but it is a state of the President as well as say a state of Bill Clinton. Both are physical objects, they just have different patterns. 9.5.7 Roles of Individuals in Relationships Historically many data models have taken a snapshot view of the world, which means that when change takes place, history is lost because it is overwritten. Recall the Ship example from earlier. In fact for relationships involving individuals, it may be the

244

M. West

case that a relationship of a particular type holds for different objects at the same time, for different objects at different times, or even the same objects at different times. One approach to dealing with this is to make the relationships temporal, we call such relationships associations. This is a 3D approach. However, from a 4D perspective some questions arise. • If the relationships are temporal then they at least exist in time, so what is their spatio-temporal extent? • If we can identify the spatio-temporal extent, what sort of thing are they? The 4 dimensional approach is to manage change through recognising different states of individuals that are valid for a period of time, together with timeless relationships between these. This approach enables us to answer the questions above. Two different patterns are presented for how different sorts of association can be represented in spatio-temporal terms. They are taken from [6], but revised and updated. 9.5.7.1 Relationships between Two States of an Individual Fig. 9.18 below illustrates the case where an association represents a relationship between two states of individual things. To illustrate the model an example is given of how a wheel, "Wheel1", is part of a car, "Car1" from 1/1/2001 to 5/4/2001. Car1 Wheel1

individual

whole

part

composition_ association Wheel1 part of Car1 from 1/1/2001 to 5/4/2001

Fig. 9.18. Association between two individuals

Fig. 9.19 below shows this example as a space-time map, showing the different states of the car and wheel, as well as the whole life of the car and wheel. The diagram shows that in this case there is a state of Car1, S1, and a state of the Wheel1, S2, both with the same state and end date, and S2 is a part of S1. When this space-time map is modelled explicitly the result is found in Fig. 9.20 below. Here the states S1 and S2 are modelled explicitly. S1 is shown as being a temporal part of Car1, S2 is shown as being a temporal part of Wheel1, and S2 is shown as being a part of S1.


245

S1 space

Car1 Wheel1

S2 time

1/1/2001 5/4/2001 Fig. 9.19. A space-time map for composition

temporal_ whole_part temporal_whole

temporal_part

state_of_ individual whole

S1 part of Car1 S2 part of Wheel1

Car1 Wheel1 S1 (from 1/1/2001 to 5/4/2001) S2 (from 1/1/2001 to 5/4/2001)

part S2 part of S1

composition

Fig. 9.20. Composition using states

Finally, although we have not shown it in the data models in order to keep them simple, subtypes of state_of_individual can be introduced for individual (whole life) and the roles played by various states, part, whole, temporal_part and temporal_ whole, with the various objects being distributed appropriately. 9.5.7.2 Relationships between a State of an Individual and a Class Fig. 9.21 shows a classification pattern. An example is given of where an individual, "Car1", is classified as being "Red" from 1/1/2001 to 4/3/2001.

246

M. West Car1

Red

class

individual

classification_ association Car1 is Red from 1/1/2001 to 4/3/2001

Fig. 9.21. An example of a classification association

If we examine what is happening here using a space-time map, Fig. 9.22, we see that there is a state of Car1 that is classified as being red (the shaded area).

space

Car1 Red time

1/1/2001 4/3/2001 Fig. 9.22. A space-time map for classification of an individual

A data model that represents this space-time diagram is shown in Fig. 9.23. Here the state of the car that is red, state 1, is recognized, and timeless relationships are held to show: 1. That State 1 is a temporal part of Car 1, and 2. That State 1 is red. Clearly, State 1 is always a part of Car 1, and State 1 is always red. 9.5.8 Sets This section looks at sets from the perspective of their use in ontology and data modeling, rather than the axioms that define sets. It is largely taken from an informative annex of [5].


247

State1 part of Car1

temporal_ whole_part whole

part

Red

state_of_ individual

class

classifier

classified

Car1 State1 (1/1/2001 to 4/3/2001)

classification

State1 is Red

Fig. 9.23. Classification using states

9.5.8.1 What is a Set? A set is a thing that has members, and a set is defined by its membership (note: the null set is the set that has no members). That is, if two sets have the same members, they are the same set (so, for example, there is only one null set). If two sets have different members, they are different sets. In saying this, it is important to note that whilst its members define a set, it may be that at any point in time, not all the members of a set may be known. 9.5.8.2 Sets and 4-Dimensionalism A problem with 3-dimensionalism is that because individuals do not have temporal parts (states), then the membership of sets changes over time. So, for example, taking the car that was red for a period of time, at one time the membership of the class Red Cars includes this car, and at another it does not. Now whilst the relationship between the class and the instance is of the same nature as set membership, the things that have the members are not strict sets. An advantage of 4-dimensionalism is that because it is states of individuals that are instances of a set, the membership of the set is unchanging. Viewed from any point in time, that state of the car is red. This makes it much more straight forward to apply set theory. The only caveat being that we need to distinguish between sets where we know all the members, and sets where we do not. Thus under 4-dimensionalism classes are synonymous with sets. 9.5.8.3 Some Different Sorts of Set Theory Single level sets Single level sets allow sets to have members, but cannot themselves be members of sets. Entity relationship models where entity types cannot be members of other entity

248

M. West

A

1

B

2

3

C

4

5

6

Fig. 9.24. Single level sets

types are an example of single level sets. This is illustrated in Fig. 9.24 below, where boxes indicate entity types, ellipses indicate instances, and arrows indicate which instances are members of which entity types. In some cases, it is not allowed to be a member of more than one set. Hierarchical sets With hierarchical sets, sets at one level may be members of sets at the level above, but there is no crossing of levels. So sets can only have members in the level below. Fig. 9.25 below illustrates this. Note that the relationship between levels is membership, and not specialization. Hierarchical sets occur naturally and this is a useful pattern to look for (but not to force). It should be noted that hierarchical sets include single level sets as a subset. An example of hierarchical sets in use is in data model, meta-model, meta-meta-model approaches. Another example is that of the powerset. A powerset is the set of all possible subsets of a set (including itself). An illustration of a powerset is given below in Fig 9.26. The representation is based on the Venn diagram, however, a set may be represented both as a set container, as an ellipse, and as an instance of a set, as a hexagon. A straight line links the two representations. In ISO 15926-2 [5] this pattern can be found, for example, in the relationship between the entity types possible_individual, class_of_individual, and class_of_class_of_individual, where class_of_individual is the powerset of possible_individual, and class_of_class_of_individual. Well-founded sets Well-founded sets are the sets of "standard" set theories such as Zermello-Fraenkel (ZF) set theory and von Neuman, Bernays, Goedel (VNBG) set theory that can be


X

Y

M

N

1

Z

O

A

P

B

2

3

249

C

4

5

6

Fig. 9.25. An example of hierarchical sets

powerset

X a

P(X)

A

X B

C

AC

BC

AB

b c

Fig. 9.26. An example of a powerset

found in standard texts [8]. Well-founded sets can take members from any level below their own, but are not allowed membership loops (e.g. a set being a member of itself). This is illustrated in Fig. 9.27. below. This form of set theory was largely developed as a reaction (perhaps even an overreaction) to Russell's Paradox. An early version of set theory developed by Frege allowed that for any predicate, there was a set that corresponded to that predicate.

250

M. West

X

Y

M

N

O

A

1

Z

B

2

3

P

C

4

5

6

Fig. 9.27. An example of well-founded sets

Russell gave an example of such a predicate that gave rise to a contradiction: the set of all sets that do not contain themselves. Either the resulting set is a member of itself (in which case it should not be) or it is not a member of itself (in which case it should be). Those working on set theory at the time felt that the best way to solve this problem was to disallow sets that had themselves as members (or other membership loops) and retain the property that any predicate (that did not involve a self reference or loop) would result in a set. However, this leaves some untidiness, for example, how does one say that a set is a set?4 It should be noted that well-founded sets include hierarchical sets as a subset. Non-well-founded set theory The essence of non-well-founded sets (also known as hypersets) is to allow sets to be members of themselves, where the membership graphs can be constructed. This is illustrated in Fig. 9.28 below. In this case, Russell's Paradox is avoided by requiring that all sets can be constructed out of their members, so it is not assumed that there is a set that corresponds to any predicate. This allows useful things to be said that well-founded sets prevent, like "class is a class", "thing is a member of class", and "class is a member of thing". It should be noted that non-well-founded sets include well-founded sets as a subset. 4

One of the differences between the different versions of “standard” set theory is in how this question is answered.


X

Y

M

N

1

Z

O

A

B

2

3

251

P

C

4

5

6

Fig. 9.28. An example of non-well-founded sets

9.5.9 Dissective and Non-dissective Sets of Individuals The ordinary sense of being dissective applies to the distinction between mass and count nouns. So for example, when you take a piece of water and divide in two you get two pieces of water, but when you take a person and divide them in two you do not get two people. One way of looking at this is to see it as a kind of inheritance, when a property of the whole is inherited by the part. 9.5.9.1 Temporally Dissective and Non-dissective Sets of Individuals A particular sort of dissectiveness, relevant to 4-dimensionalism, is temporal dissectiveness. Here the question is whether a state (temporal part) of some spatio-temporal extent is also a member of a class, or has a relationship, that the whole has. In general, states are useful precisely because they enable you to say something that is true at all times during which the state exists, so there is a presumption for dissectiveness. However, this only serves to make the exceptions more interesting. Obviously, temporal properties, such as the period that the state was a spatial part of, would not expect to be inherited. However, probably the most significant group of sets whose membership would not be inherited, are the subsets of individual, i.e. those spatio-temporal extents that are something for the whole of its life, e.g. car, person, flower. Clearly, a proper state of a car is not a car for the whole of its life. On the other hand, if you take the set, state of car, then a temporal part of a member is also a

252

M. West

state of car. It is interesting to note that temporally non-dissective sets correspond closely to the traditional idea of natural kinds, and can perhaps be thought to usefully be the 4-dimensional definition of a natural kind. 9.5.10 Properties On the other hand, the traditional idea of a property, with the notable exception of temporal properties, would seem to correspond closely to temporally dissective sets of individuals. Thus properties are inherited by states of the spatio-temporal extent to which they apply (although it is not only individuals that can have properties). Fig. 9.29 below illustrates the structure of a property, using temperature as an example, using a modified form of Venn diagram. property value

state of physical object T-2

T-1

temperature T-3

T-3

T-5

T-6 T-7

temperature

T-2

T-1

T-4

property space

T-8

T-4 T-6 T-8

T-5 T-7

Fig. 9.29. Temperature as an example of property

The black dots in the left hand ellipse are members of the class, state of physical object. Those states that have a constant temperature are shown as members of the appropriate temperature property value, being a particular degree of hotness, such as 300 K. These are designated T-1 to T-8. The middle ellipse is the set of all property values, and T-1 to T-8 shown as hexagons, to show that here they are members rather than subsets of the class that contains them. They have a dashed line to link them to their representation as a set in the left hand ellipse. They are, of course, all shown as members of the temperature property space. Finally, the right hand ellipse shows that temperature is a member of the class property space. Notice that this is an example of hierarchical sets, as illustrated in Fig. 9.25. Whilst this illustrates the common pattern shared by properties, there are a number of different types. Some of these are related to the structure of the property values, and others to the nature of the property type. We can identify: 1. Intrinsic and extrinsic properties. 2. Direct and indirect properties, and 3. Unordered and ordered properties – including physical properties such as temperature,


253

9.5.10.1 Intrinsic and Extrinsic Properties The distinction between intrinsic and extrinsic properties is a philosophical distinction, where an intrinsic property, say mass, depends only on the object whose mass is of interest, but the weight of that object depends on the objects relationship to the surrounding gravitational field. 9.5.10.2 Direct and Indirect Properties The distinction between direct and indirect properties is somewhat pragmatic. Here a direct property is one that is expressed directly, like temperature. On the other hand, an indirect property is expressed in terms of some direct property. So for example, the Maximum Allowable Working Pressure (MAWP) of a boiler is expressed as a pressure, but it is not the observed pressure of the boiler. It is important not to think that an MAWP is a type of pressure, but recognize that it is in fact a property that makes reference to a pressure. It is clear that all indirect properties are extrinsic, and that all intrinsic properties are direct, but it is not clear that all direct properties are intrinsic. Further, looking at a case like MAWP, it is clear that this property is a short cut for some more detailed analysis that explains the way the MAWP was derived, and the use that should be made of it. The world of engineering is full of such properties. 9.5.10.3 Unordered and Ordered Properties A property is unordered when there is no real sense of one value being greater than another. This can only happen when the values a property can take are discrete: an example might be a set of statuses something can take up. Ordered properties typically map to an integer space (discrete properties) of to a real number space for continuous properties, though these refer to total ordering, and in principle partial ordering is also possible. For a totally ordered property there is at least one ordering function that orders the property values so that it can be determined for each pair of property values whether one is greater than the other, or whether they are the same property value. 9.5.10.4 Quantity Space A quantity space is a class with structure, i.e. a property and a particular total ordering function. The most interesting of these are the physical quantities, such as temperature, pressure, volume, mass etc. Relatively little has been written in recent years about quantities, with Ellis [11] being one of the better writers. 9.5.10.5 Scales and Units of Measure If we want to put a number against a property value, then we need a scale. A scale is a structure preserving isomorphic mapping between a quantity space and a number space, where the number space might be all or part of the real numbers or the integers. Now a scale will have a unit of measure. Traditionally, this is taken to be the value of one on the scale, but I think it makes more sense to think of the unit of measure as a plus-one function for the scale.

254

M. West

9.5.10.6 Other Aspects of Physical Quantities There is much more about physical quantities that has not been covered here. These include: • • • •

Measurements of physical quantities, Measurement methods, Accuracy of measured values, and Dimensionality of physical quantities.

9.6 Impact of Applying Ontological Principles on Data Modeling Conceptual modeling is an important activity in terms of both organizational understanding and systems development. Despite this importance, and evidence to suggest that ‘errors’ in modeling are increased by orders of magnitude later in the systems development and maintenance process, it is well noted that conceptual modeling remains more of an ‘art’ than science [14,15]. In addition, given an age of integration, it is increasingly recognized that semantic understanding and interoperability is a key challenge for organizations and their systems [16,17]. Semantic interoperability is a knowledge-level concept that provides the “ . . . ability to bridge semantic conflicts arising from differences in implicit meanings, perspectives, and assumptions, thus creating a semantically compatible information environment based on the agreed concepts between different business entities.” [17]. Ontology is an emerging mechanism for dealing with semantic interoperability. An ontological framework, such as that described here, provides a basis for developing data models that are consistent across a wide range of information requirements and business processes. The benefits are: • The same things get modeled the same way, irrespective of the context in which they arise because similar things turn up in the data model close to each other, so that differences can be examined to see if they are real or not. • The treatment of change over time is built into the 4-dimensional modeling approach, rather than bolted on afterwards. This means that it is always present and is done in a consistent manner. • Data models can be developed more quickly, more cheaply, and are of higher quality because there is less rework that arises from the consistent (re)use of the framework. 9.6.1 Case Study: Shell’s Downstream Data Model [13] reports on the development of Shell’s Downstream Data Model (DDM). 9.6.1.1 Background Shell is a global group of energy and petrochemicals companies. Shell Downstream encompasses all the activities necessary to transform crude oil into Shell petroleum products and petrochemicals, and deliver them around the world. Shell’s Downstream Business refines, supplies, trades and ships crude oil worldwide, and manufactures,


255

transports and markets fuels, lubricants, bitumen, LPG and bulk petrochemicals for domestic, transportation and industrial uses. Altogether, the organization employs some 80,000 people. In an increasingly competitive downstream market, Shell assessed that the cost and complexity of business systems and processes provided an opportunity to improve performance. As a consequence, it has aggressively sought to achieve operational excellence through an ongoing program of global standardization. In practice the organization seeks to achieve such excellence primarily through a combination of (a) business portfolio improvements, (b) the introduction of global processes and standards underpinned by a simplified global organization and (c) the adoption of consistent behaviors to reinforce the perceived benefits of going global. Process streamlining forms a key component in the strategy to simplify and standardize the way that the organization does business, with the objectives of: • • • •

Promoting more accurate and responsive customer interactions. Removing errors and rework. Reducing costs by eliminating ‘noise’ in business processes. Providing proven and simpler ways of doing things.

Unsurprisingly, the standardization of the critical IT systems is seen as key to the success of the streamlining initiative. Thus, a partner initiative aims to replace fragmented Enterprise Resource Planning and other legacy information systems with a harmonized global platform. Broadly speaking, the aim is to reduce the number of operational information systems to less than a tenth of those that existed at the start of the globalization process (a reduction that is significant). In order to assist standardization on the process and systems fronts, Shell have also sought to instigate a step change in the way that key Master and Reference Data (MRD) is managed in relation to their customers, products, suppliers, materials, technical assets and accounts across the Downstream businesses and functions. One key requirement here is that of deploying quality standards and measures to ensure that key reference data is fit for purpose. This means, for instance, that the right product be delivered to the right customer at the right address, with costs and profits correctly classified and reported. Consequently, Data Quality Standards (DQSs) have been defined along such lines (e.g., no obsolete customers, no duplicate records etc.) and a significant program has been instigated to ensure that streamlined IT systems are cleansed and validated. Cleansing is the process of removing or correcting data that is incomplete, inaccurate or improperly formatted. Validation is the process of ensuring that DQSs have been properly implemented. Again, this is a significant program, with an effort estimated at 300 man-years. Data cleansing is seen as important as poor data quality not only results in inefficient business processes, it also potentially limits organizational ability to analyze, understand and manage the business in the most effective ways. The effort here mirrors observations in the literature that data quality issues have become increasingly prevalent in practice - costing organizations significantly, alienating customers and suppliers and hindering decision making and the implementation of strategy for example [18, 19, 20, 21, 22, 23]. In addition, data quality in the context of compliance has become more critical since the Sarbanes-Oxley Act of 2002. The intrinsic treatment of data quality (devoid of context) is problematic however [22]. To

256

M. West

this extent, a smaller element of the body of literature starts to form the basis of a ‘business case’ for a slightly different but less explored perspective on the issues of data quality. Redman [20] is an early work that notes the difference between comparing data and the real world and ‘database bashing’, which is more in line with typical industrial treatment. Importantly, he also notes that the fact that solution approaches of the former type are often attempted downstream, resulting in improvements are not typically sustained (ibid). Orr [24] makes a similar argument, proposing that data quality is “the measure of the agreement between the data views presented by an information system and that same data in the real world” (p.67). Other works take a similarly representational view on data quality, noting the importance of the semantic/ontological foundations of data quality and including incomplete and/or ambiguous representation as key design deficiencies [23, 25]. For reference, the later literature in the area favours the term ‘information quality’ over ‘data quality’. While much of the literature explicitly uses the terms interchangeably, the distinction is that ‘data’ typically refers to the stored content, whereas ‘information’ refers to the situation where such content has been delivered/presented and interpreted [25]. The representational view has relevance here as the MRD team realized that, in the context of streamlining and standardization, data cleansing and validation is not action enough in relation to MRD. The Downstream Data Model (DDM) was thus developed in response to the recognition that the large number of relatively independent projects that were bringing about the transformation in business and IT processes required a standardized basis for integration and consistency across the business. In essence, common processes and common systems indicated a strong requirement for a common data model. The stated business purposes of the model are to: • Identify the key objects of interest to the business and the relationships between them • Provide a specification of the information requirements for the Downstream business • Identify the underlying transactions and relationships • Provide a basis for checking that the process model includes the processes for managing both objects and data about objects • Provide a basis for checking that the physical data model, user and system interfaces in applications support the information requirements In the context of the literature, the approach is a sensible one. The objective of streamlining IT systems around a core set of Enterprise Resource Planning systems is a common means of attempting to provide a seamless integration across a full range of organisational processes – uniting functional and global areas within the business and making their data visible in a real-time manner. Some analyses of ERP systems implementation indicate that organizations must be willing to develop common definitions and understanding for both data and process across the business [26], though typically the concentration is on the link with process. 9.6.1.2 Foundations of the Data Model The DDM thus represents a model of the Shell domain that is independent of any system in which representations of the domain may be implemented. This characterization requires a focus on the information requirements of the organization


257

(and thus of any system) allowing the structure or processing of the system to remain undetermined. For reference, the DDM is a Computationally Independent Model (CIM) from a Model Driven Architecture (MDA) perspective. CIMs are relatively underexplored in relation to the work available in other areas of the MDA and initial work in relation to the DDM indicated that a finer separation of concerns was required in relation to the CIM classification. Essentially, one can distinguish an ontological representation (a model of ‘what is’, in essence a view from nowhere) from epistemological representation (a model of ‘what is known’ about the domain by some agent, and how it may be represented in a system). In these terms, the DDM is developed as a hybrid model - it is in large part an ontology, but with an epistemological ‘gloss’, which represents what Shell as an organization (the ‘agent’) knows, rather than what any particular system knows. Given that business users in Shell are unfamiliar with terms such as ontology and epistemology, the DDM is referred to within Shell as a (conceptual) ‘data model’. This can be further distinguished from an implementational representation – a representation in terms of the technology used to implement a particular application or set of applications of the implementation. In traditional data processing this would be known as a physical model. Given that streamlining within Shell is process-centric, the breadth of the scope was defined as covering the following business processes in Shell’s Downstream business (some processes such as Human Resources were scoped out for this version of the model): • • • • • •

Sell to Business Customer Sell to Retail Customer Manufacturing Manage Lubricants Supply Chain Manage Bulk Hydrocarbons Supply Chain Procure Goods and Services

The depth of scope of the model was to range from the metaphysical choices at the framework level to a level of abstraction that reflected business language (i.e., leaf subtypes should represent things directly recognized by the business, rather than highlevel abstractions of those things). In providing some ‘flesh’ to the scope, the development of the DDM drew on a range of existing written material as a start point (which meant that interviewing business staff for requirements was not been necessary except for clarification in some cases). The evidence that has been drawn upon in developing the DDM included (a) ISO 15926 [5], (b) the Downstream Process Model, (c) a Glossary of Terms for the Downstream business, (d) the previous version of the Downstream Data Model, (e) Project Logical Data Models (where they have been developed), (f) Physical Data Models from implemented systems, and (g) data from existing systems. 9.6.1.3 Data Model Development The work was divided up among several data modellers in the form of schemas. EXPRESS and Visual EXPRESS support the development of a number of schemas that make reference to each other to provide integration. Visual EXPRESS, however, is a single user tool, so that each schema can only be worked on by one person at a

258

M. West

time (the tool was thus a determining factor in process terms). Initially, each data modeller was allocated one or more process areas to model as one or more process schemas. However, it quickly became clear that this was unworkable, because so many things like products, organizations, properties, and locations appeared in many of the process areas without them clearly belonging to one of them. This lead to duplication of concepts between schemas and the need for reconciliation between them. This commonality of concepts between process areas led to this approach being abandoned in favor of one where: • Subject Area schemas were developed for common concepts, responsibility for which was given to one data modeller, • Data modellers were given responsibility for ensuring that requirements from their Process Area were met in the Subject Areas.

ISO 15926 (201) Com mon Objects (37) Properties (158) Time (104) ISO 19107 (17)

Produc ts and Materials (111) Location (38) Organization (222)

Agreements (40) Buy/Sell (82)

Marketing (36)

Operation Flows (12)

Manufacture (155)

Retail (100)

Basic Accounts (27)

CRM (39)

Movement (128)

Hydrocarbon Supply Chain (26)

Carri er (11) Demand (6)

Trans port Constraint (174)

Fig. 9.30. The set of subject areas for the DDM V2.0

By project completion, almost the whole model was in Subject Areas – this proving an important factor in integrating requirements across the different Process Areas. The final set of Subject Areas is shown in Fig. 9.30 – the more abstract and widely referred to Subject Areas are shown at the top, with the more Process Area specific schemas shown lower in the triangle. For reference, the numbers in brackets show the number of entity types in each schema (the total size of the DDM is in excess of 1700 entity types).

9.7 Conclusions In this chapter we have brought together several threads of ontological analysis founded on a 4-dimensional ontology and we have presented a case study of their use


259

in a business context. This has demonstrated the effectiveness of an ontological approach to information systems design, in particular for data models.

References 1. West, M., Fowler, J.: Developing High Quality Data Models (Version 2.0) EPISTLE (1996) 2. Sider, T.: Four Dimensionalism - An Ontology of Persistence and Time 2001. Oxford University Press, Oxford (2001) 3. Hawley, K.: How things persist. Clarendon Press, Oxford (2001) 4. Stell, J.G., West, M.: A 4-Dimensionalist Mereotopology pp 261-272 Formal Ontology in Information Systems. In: Varzi, A.C., Vieu, L. (eds.). IOS Press, Amsterdam (2004) 5. ISO 15926-2: Industrial automation systems and integration — Integration of life-cycle data for process plants including oil and gas production facilities — Part 2: Data Model (2003) 6. West, M.: Information Modelling: An analysis of the uses and meanings of associations, PDT Europe (2002) 7. Lewis, D.: On the Plurality of Worlds. Basil Blackwell, Oxford (1986) 8. Suppes, P.: Axiomatic set theory. Dover Publications Inc. (1972) ISBN 0-486-61630-4 9. Aczel, P.: Non-well-founded sets. CSLI Publications (1998) 10. Gruber, T.R.: A translation approach to portable ontology specification. Knowledge Acquisition 5(2), 199–220 (1993) 11. Ellis, B.: Basic concepts of measurement. Cambridge University Press, Cambridge (1966) 12. Searle, J.R.: The construction of social reality. Penguin Books (1995) ISBN-13: 978-0-14023590-6 13. West, M., Partridge, C., Lycett, M.: Enterprise Data Modelling: Developing an OntologyBased Framework for the Shell Downstream Business. FOMI (2006) 14. Moody, D.L.: Theoretical and Practical Issues in Evaluating the Quality of Conceptual Models: Current State and Future Directions. Data & Knowledge Engineering 55, 243–276 (2005) 15. Nelson, J., Poels, G., Genero, M., Piattini, M.: Quality in Conceptual Modeling: Five Examples of the State-of-the-Art (Guest Editorial 2005). Data & Knowledge Engineering 55, 237–242 (2005) 16. March, S., Hevner, A., Ram, S.: Research Commentary: An Agenda for Information Technology Research in Heterogeneous and Distributed Environments. Information Systems Research 11, 327–341 (2000) 17. Park, J., Ram, S.: Information Systems Interoperability: What Lies Beneath? ACM Transactions on Information Systems 22, 595–632 (2004) 18. hengalur-Smith, I.N., Ballou, D.P., Pazer, H.L.: The Impact of Data Quality Information on Decision Making: An Exploratory Analysis. IEEE Transactions on Knowledge and Data Engineering 11, 853–864 (1999) 19. Fisher, C.W., Kingma, B.R.: Criticality of Data Quality as Exemplified in Two Disasters. Information & Management 39, 109–116 (2001) 20. Redman, T.C.: Improve Data Quality for Competitive Advantage. Sloan Management Review 36, 99–107 (1995) 21. Redman, T.C.: The Impact of Poor Data Quality on the Typical Enterprise. Communications of the ACM 41, 79–82 (1998)

260

M. West

22. Strong, D.M., Lee, Y.W., Wang, R.Y.: Data Quality in Context. Communications of the ACM 40, 103–110 (1997) 23. Wand, Y., Wang, R.Y.: Anchoring Data Quality Dimensions in Ontological Foundations. Communications of the ACM 39, 86–95 (1996) 24. Orr, K.: Data Quality and Systems Theory. Communications of the ACM 41, 66–71 (1998) 25. Price, R., Shanks, G.: A Semiotic Information Quality Framework: Development and Comparative Analysis. Journal of Information Technology 20, 88–102 (2005) 26. Strong, D.M., Volkoff, O.: A Roadmap for Enterprise Systems Implementation. IEEE Computer 37, 22–29 (2004) 27. Chen, P.P.: The Entity-Relationship Model – Towards a unified view of data. ACM Transactions on Database Systems 1(1), 9–36 (1976) 28. Hay, D.C.: Data Model Patterns: Conventions of Thought. Dorset House, New York (1996) 29. Partridge, C.: Business objects: re-engineering for re-use, 2nd edn. The Boro Centre, Butterworth-Heinemann (2005) 30. Simsion, G.C., Witt, G.C.: Data Modeling Essentials, 3rd edn. Morgan Kaufmann, San Francisco (2005)

Bibliography

Abstract. Every professor and researcher knows the problem: a new team member enters the team and his to be educated. Where should he start? The authors of these book chapters helped us by preparing a “reading list” and composition of other valuable source of information regarding their topics. We asked them: What do you recommend a new member of your team to spend his time on? What are books, papers, journals, or websites should he focus on to get up to speed as fast as possible. This bibliography is the result of this request.

1 General Resources The following Books on general principles of systems engineering should be known by students and practitioners in the field: • •

Sage, A.P. and Armstrong, J.E., Jr., An Introduction to Systems Engineering, John Wiley and Sons, 2000. Sage, A.P. and Rouse, W.B. (Eds), Handbook of Systems Engineering and Management, John Wiley and Sons, 1999.

In the knowledge-based environment, the following books are a good start. • • •

Jain, L.C.(Editor), Evolution of Engineering and Information Systems, CRC Press USA, 2000 Jain, L.C. (Editor), Soft Computing Techniques in Knowledge-Based Intelligent Engineering Systems, Springer-Verlag, Germany, 1997 Jain, L.C. and Jain, R.K. (Editors), Hybrid Intelligent Engineering Systems, World Scientific Publishing Company, Singapore, 1997

The following Journals are of general interest to all chapters in this book: • • • • • •

IEEE Intelligent Systems, IEEE Press, USA (website: www.computer.org/intelligent/) IEEE Transactions on Systems, Man and Cybernetics, Part A, B, C, IEEE Press USA. Journal of Systems Engineering, Wiley Inter Science. International Journal of Knowledge-Based Intelligent Engineering Systems, IOS Press, The Netherlands. (website: http://www.kesinternational.org/journal/) International Journal of Hybrid Intelligent Systems, IOS Press, The Netherlands. Intelligent Decision Technologies: An International Journal, IOS Press, The Netherlands.

The following Proceedings of the annual conference on Knowledge-Based Intelligent Information and Engineering Systems (KES) is conducted since 1997 and covers topics of general interest. The following proceedings are available • •

Apolloni, B., Howlett, R.J. and Jain, L.C. (Editors), Knowledge-Based Intelligent Information and Engineering Systems, Lecture Notes in Artificial Intelligence, Volume 1, LNAI 4692, KES 2007, Springer-Verlag, Germany, 2007. Apolloni, B.,Howlett, R.J.and Jain, L.C. (Editors), Knowledge-Based Intelligent Information and Engineering Systems, Lecture Notes in Artificial Intelligence, Volume 2, LNAI 4693, , KES 2007, Springer-Verlag, Germany, 2007.

A. Tolk, L.C. Jain (Eds.): Comp. Sys. in Knowledge-based Environments, SCI 168, pp. 261–267. © Springer-Verlag Berlin Heidelberg 2009 springerlink.com

262

Bibliography • • • • • • • • • • • • • • • •

Apolloni, B.,Howlett, R.J.and Jain, L.C. (Editors), Knowledge-Based Intelligent Information and Engineering Systems, Lecture Notes in Artificial Intelligence, Volume 3, LNAI 4694, KES 2007, Springer-Verlag, Germany, 2007. Howlett, R.P., Gabrys, B. and Jain, L.C. (Editors), Knowledge-Based Intelligent Information and Engineering Systems, Lecture Notes in Artificial Intelligence, KES 2006, Springer-Verlag, Germany, Vol. 4251, 2006. Howlett, R.P., Gabrys, B. and Jain, L.C. (Editors), Knowledge-Based Intelligent Information and Engineering Systems, Lecture Notes in Artificial Intelligence, KES 2006, Springer-Verlag, Germany, Vol. 4252, 2006. Howlett, R.P., Gabrys, B. and Jain, L.C. (Editors), Knowledge-Based Intelligent Information and Engineering Systems, Lecture Notes in Artificial Intelligence, KES 2006, Springer-Verlag, Germany, Vol. 4253, 2006. Khosla, R., Howlett, R.P., and Jain, L.C. (Editors), Knowledge-Based Intelligent Information and Engineering Systems, Lecture Notes in Artificial Intelligence, KES 2005, Springer-Verlag, Germany, Vol. 3682, 2005 Khosla, R., Howlett, R.P., and Jain, L.C. (Editors), Knowledge-Based Intelligent Information and Engineering Systems, Lecture Notes in Artificial Intelligence, KES 2005, Springer-Verlag, Germany, Vol. 3683, 2005. Khosla, R., Howlett, R.P., and Jain, L.C. (Editors), Knowledge-Based Intelligent Information and Engineering Systems, Lecture Notes in Artificial Intelligence, KES 2005, Springer-Verlag, Germany, Vol. 3684, 2005. Khosla, R., Howlett, R.P., and Jain, L.C. (Editors), Knowledge-Based Intelligent Information and Engineering Systems, Lecture Notes in Artificial Intelligence, KES 2005, Springer-Verlag, Germany, Vol. 3685, 2005. Negoita, M., Howlett, R.P., and Jain, L.C. (Editors), Knowledge-Based Intelligent Engineering Systems, KES 2004, Lecture Notes in Artificial Intelligence, Vol. 3213, Springer, 2004 Negoita, M., Howlett, R.P., and Jain, L.C. (Editors), Knowledge-Based Intelligent Engineering Systems, KES 2004, Lecture Notes in Artificial Intelligence, Vol. 3214, Springer, 2004 Negoita, M., Howlett, R.P., and Jain, L.C. (Editors), Knowledge-Based Intelligent Engineering Systems, KES 2004, Lecture Notes in Artificial Intelligence, Vol. 3215, Springer, 2004 Palade, V., Howlett, R.P., and Jain, L.C. (Editors), Knowledge-Based Intelligent Engineering Systems, Lecture Notes in Artificial Intelligence, Vol. 2773, Springer, 2003 Palade, V., Howlett, R.P., and Jain, L.C. (Editors), Knowledge-Based Intelligent Engineering Systems, Lecture Notes in Artificial Intelligence, Vol. 2774, Springer, 2003 Damiani, E., Howlett, R.P., Jain, L.C. and Ichalkaranje, N. (Editors), Proceedings of the Fifth International Conference on Knowledge-Based Intelligent Engineering Systems, Volume 1, IOS Press, The Netherlands, 2002. Damiani, E., Howlett, R.P., Jain, L.C. and Ichalkaranje, N. (Editors), Proceedings of the Fifth International Conference on Knowledge-Based Intelligent Engineering Systems, Volume 2, IOS Press, The Netherlands, 2002. Baba, N., Jain, L.C. and Howlett, R.P. (Editors), Proceedings of the Fifth International Conference on Knowledge-Based Intelligent Engineering Systems (KES’2001), Volume 1, IOS Press, The Netherlands, 2001.

Bibliography • • • • • • • • •

263

Baba, N., Jain, L.C. and Howlett, R.P. (Editors), Proceedings of the Fifth International Conference on Knowledge-Based Intelligent Engineering Systems (KES’2001), Volume 2, IOS Press, The Netherlands, 2001. Howlett, R.P. and Jain, L.C.(Editors), Proceedings of the Fourth International Conference on Knowledge-Based Intelligent Engineering Systems, IEEE Press, USA, 2000. Volume 1. Howlett, R.P. and Jain, L.C.(Editors), Proceedings of the Fourth International Conference on Knowledge-Based Intelligent Engineering Systems, IEEE Press, USA, 2000. Volume 2. Jain, L.C.(Editor), Proceedings of the Third International Conference on KnowledgeBased Intelligent Engineering Systems, IEEE Press, USA, 1999. Jain, L.C. and Jain, R.K. (Editors), Proceedings of the Second International Conference on Knowledge-Based Intelligent Engineering Systems, Volume 1, IEEE Press, USA, 1998. Jain, L.C. and Jain, R.K. (Editors), Proceedings of the Second International Conference on Knowledge-Based Intelligent Engineering Systems, Volume 2, IEEE Press, USA, 1998. Jain, L.C. and Jain, R.K. (Editors), Proceedings of the Second International Conference on Knowledge-Based Intelligent Engineering Systems, Volume 3, IEEE Press, USA, 1998. Jain, L.C. (Editor), Proceedings of the First International Conference on KnowledgeBased Intelligent Engineering Systems, Volume 1, IEEE Press, USA, 1997. Jain, L.C. (Editor), Proceedings of the First International Conference on KnowledgeBased Intelligent Engineering Systems, Volume 2, IEEE Press, USA, 1997.

2 Computational Models of Probabilistic Reasoning In chapter of this book, Laskey and Costa introduce Computational Models of Probabilistic Reasoning. The following websites help to get a deeper understanding of their model and introduce alternatives that could not be captured within the constraints of writing a book chapter. • • • • •

http://ite.gmu.edu/~klaskey/CompProb - Web site for Computational Models of Probabilistic Reasoning course http://pr-owl.org - PR-OWL probabilistic ontology language web site. It includes links and information to related resources https://sourceforge.net/projects/unbbayes/ - UnBBayes web site at SourceForge. UnBBayes is a java-based, open source MEBN/PR-OWL reasoner http://www.w3.org/2005/Incubator/urw3/ - Site for World Wide Web Consortium Incubator Group on Uncertainty Reasoning for the World Wide Web. http://c4i.gmu.edu/ursw/2008/ - The Uncertainty Reasoning for the Semantic Web workshop series. This link is to the 2008 version, and contains links to the other versions. Specially recommended are the respective “agenda and papers” webpages, which contains papers and presentations regarding the subject.

The following reading list complements the references given in chapter 2. •

Kathryn Blackmond Laskey; MEBN: A Language for Bayesian Knowledge Bases. Artificial Intelligence. 172(2-3), 2007.

264

Bibliography • • • • • • • • •

•

•

Eugene Charniak; Bayesian Networks without Tears, AI Magazine, Winter 1991. Paulo Cesar G. Costa, and Kathryn Blackmond Laskey; Multi-Entity Bayesian Networks without Multi-Tears. Research Draft. Department of Systems Engineering and Operations Research, George Mason University: Fairfax, VA, USA, 2005. Ian Hacking, The Emergence of Probability: A Philosophical Study of Early Ideas about Probability; Induction, and Statistical Inference. Cambridge, MA, USA: Cambridge University Press, 1975. Judea Pearl; Probabilistic Reasoning in Intelligent Systems: Networks of Plausible Inference. San Mateo, CA: Morgan Kaufmann, 1998. Judea Pearl; Causality: Models, Reasoning, and Inference. Cambridge, U.K.: Cambridge University Press, 2000. Finn V. Jensen; Bayesian Networks and Decision Graphs. New York, NY, USA: Springer-Verlag, 2001. Stuart Russell, and Peter Norvig; Artificial Intelligence: A Modern Approach (2nd Edition). Upper Saddle River, NJ, USA: Prentice Hall Richard E. Neapolitan ; Learning Bayesian Networks. New York, Prentice Hall, 2003. Rommel N.Carvalho, Marcelo Ladeira, Laécio L. Santos, Shou Matsumoto, and Paulo Cesar G. Costa; UNBBayes-MEBN: Comments on Implementing a Probabilistic Ontology Tool. Accepted to the IADIS International Conference Applied Computing 2008, April 10-13, 2008, Algarve, Portugal, 2008. Paulo Cesar G. Costa, Kathryn Blackmond Laskey, and Kenneth J. Laskey; Probabilistic Ontologies for Efficient Resource Sharing in Semantic Web Services. Proceedings of the second workshop on Uncertainty Reasoning for the Semantic Web (URSW 2006), held at the Fifth International Semantic Web Conference (ISWC 2006). November 5-9, 2006, Athens, GA, USA. Paulo Cesar G. Costa, Kathryn Blackmond Laskey, Kenneth J. Laskey, and Edward J. Wright; Probabilistic Ontologies: the Next Step for Net-Centric Operations. Proceedings of the 12th International Command and Control Research and Technology Symposium (12th ICCRTS). June 19-21, 2007, Newport, RI, USA: CCRP publications.

3 Levels of Interoperation Computer science and software engineering contributed significantly to layered models identifying levels of interoperation. The new aspect in chapter 3 is the connection of knowledge-based artifacts and ontological means to support such levels in complex systems. In addition to the references in chapter 3, the following books are highly recommended for students and scholars: • • • •

David C. Hay, "Data Model Patters" - Dorset House Publishing, New York, 1996 R.J. Brachman and H.J. Levesque, "Knowledge Representation and Reasoning" Elsevier, San Francisco, 2004 J.F. Sowa, "Knowledge Representation: Logical, Philosophical and Computational Foundations" - Brooks Cole Publishing Co., Pacific Grove, CA, 2000 C. Parent, S. Spaccapietra, E. Zimanyi, "Conceptual Modeling for Traditional and Spatio-Temporal Applications" -Springer-Verlag, Berlin 2006

Bibliography • •

265

D. Gasevic, D. Djuric, V. Devedzic, "Model Driven Architecture and Ontology Development" - Springer-Verlag, Berlin 2006 F. Baader, D. Calvanese, D. McGuinness, D. Nardi, and P. Patel-Schneider (Eds.), "The Description Logic Handbook" - Cambridge University Press, Cambridge UK 2003

Additional journal and conference papers covering these ideas are •

•

• •

Andreas Tolk, Charles D. Turnitsa, Saikou Y. Diallo: “Implied Ontological Representation within the Levels of Conceptual Interoperability Model,” International Journal of Intelligent Decision Technologies (IDT), Special Issue on Ontology Driven Interoperability for Agile Applications using Information Systems: Requirements and Applications for Agent Mediated Decision Support, Volume 2, Issue 1, pp. 3-19, January 2008 Andreas Tolk, Saikou Y. Diallo, Charles D. Turnitsa: “Applying the Levels of Conceptual Interoperability Model in Support of Integratability, Interoperability, and Composability for System-of-Systems Engineering,” Journal of Systemics, Cybernetics and Informatics, Volume 5 Number 5, pp. 65-74, IIIS, 2007 Andreas Tolk, Charles D. Turnitsa: “Conceptual Modeling of Information Exchange Requirements based on Ontological Means,” Winter Simulation Conference WSC’07, Washington, DC, December 2007 Andreas Tolk, Charles Turnitsa, Saikou Diallo: “Model-Based Alignment and Orchestration of Heterogeneous Homeland Security Applications Enabling Composition of System of Systems,” Winter Simulation Conference WSC’07, Washington, DC, December 2007

4 Complexity and Emergence Chapter 5 introduces the theory on complexity and emergence in engineering systems. The following journals are of particular interest for researcher, scholars, and students in this field. • • • • • •

Advances in Complex Systems. World Scientific. ISSN: 0219-5259. Artificial Life and Robotics. Springer. ISSN: 1433-5298. Complex Systems. Complex Systems Publications. ISSN: 0891-2513. Complexity. Wiley. ISSN: 1076-2787 (print) and 1099-0526 (online). Journal of Complexity. Elsevier. ISSN: 0885-064X. Journal of Systems Science and Complexity. Springer Boston. ISSN: 1009-6124 (print) and 1559-7067 (online).

The following institutions and organizations are of interest as well, as they deal with complexity and emergence. • • • • •

Complex Systems Society: http://cssociety.org/ Michigan Center for the study of Complex Systems: http://www.cscs.umich.edu/ New England Complex Systems Institute: http://www.necsi.edu/ Open Network of Centres of Excellence in Complex Systems: http://once-cs.net/ Santa Fe Institute: http://www.santafe.edu/

266

Bibliography

5 Feature Modeling Feature modeling is covered in chapter 6 of this book. The following books, papers, and articles give additional information on this topic: • • • • • • • •

Czarnecki, K., Eisenecker, U.: Generative Programming. AddisonWesley (2000). Rubn Prieto-Daz and Guillermo Arango: Domain analysis and software systems modeling. IEEE Computer Society Press (1991). Paul Clements and Linda Northrop. Software product lines: Practices and patterns. Addison-Wesley (2002). K.Kang, S.G.Cohen, J.A.Hess, W.E.Novak, S.A.Peterson: Feature-Oriented Domain Analysis (FODA) - Feasibility Study. Technical Report CMU/SEI-90-TR-21, Carnegie-Mellon University (1990) Lee, K., Kang, K.C., Lee, J.: Concepts and Guidelines of Feature Modeling for Product Line Software Engineering. In: Proceedings of The Seventh Reuse Conference. (2002) Trigaux, J., Heymans, P.: Modelling Variability Requirements in Software Product Lines: A comparative survey. Technical report, Institut d'Informatique FUNDP (2003) Pierre America, Steffen Thiel, Stefan Ferber, and Martin Mergel. Introduction to domain analysis. Technical report, ESAPS, 2001. Coplien, J.; Hoffman, D.; Weiss, D., "Commonality and variability in software engineering," Software, IEEE , vol.15, no.6, pp.37-45, Nov/Dec 1998.

6 Semantic Robots For a deeper understanding for the semantic robots introduced in chapter 7, the reader is referred to additional specifications. • • • • • • • • • • • •

Microchip Lithium Battery Management Chipset MCP73864, http://ww1.microchip. com/downloads/en/DeviceDoc/21893c.pdf Atmel AVR Microcontroller AtMega16L, http://www.atmel.com/dyn/products/ product_card.asp?part_id=2010 Devantech Ultrasonic Range Finder SRF10, http://www.robot-electronics.co.uk/htm/ srf10tech.htm ICOP Technologies, http://icop.com.tw/ VORTEX86-6082LV Embedded System Board, http://www.vortex86.com/ Sharp IR distance Measurement Sensors GP2D120, http://document.sharpsma.com/ files/GP2D120_SS_final.pdf Lynxmotion Infrared Proximity Sensors TRA-V5, http://www.lynxmotion.com/ images/data/tra-v5.pdf HiTec Servo motor HS-422, http://www.hitecrcd.com/homepage/product_fs.htm Hamamatsu quadrature optical wheel shaft encoder disk P5587, http://www. roboticsconnection.com/catalog/item/988888/772775.htm W3C Semantic Web Activity: http://www.w3.org/2001/sw/ W3, Web Services Activity: http://w3.org/2002/ws/; and Semantic Web Activity: http://w3.org/2001/sw/. Semantic Web Protocol stack: http://www.w3.org/DesignIssues/diagrams/sw-stack2002.png.

Bibliography

267

7 Practical Applications of Ontology West gives in chapter 9 an example that shows that ontologies are no longer only of interest to the academic community, but that ontology now meets business. He recommends several books that are all characterized by their practical relevance. The additional text gives explanations on the relevance of the book. •

•

•

• •

•

Ong, W.J. Orality and literacy: The technologizing of the word Methuen, 1988, ISBN 0-415-02796-9 A brilliant book that takes the long view on information - from the start of speech, through hand writing, to printing and the computer. In particular it looks at how the changing technology affects and supports information. Kent, W. Data and reality: basic assumptions in data processing reconsidered North Holland, 1978, ISBN 0-444-85187-9 This is a seminal work on what the key issues are in data modeling and database design. Barker, Richard CASE*METHOD Entity Relationship Modelling Addison Wesley 1989 An excellent text to introduce data modelling techniques and good practice in general and the Oracle data modelling notation in particular (though I dislike their requirement that subtypes be mutually exclusive and does not support multiple inheritance). Hay, David. C. Data Model Patterns: A Metadata Map. Morgan Kaufmann, 2006 A collection of data model patterns for an Enterprise Architecture based loosely on the Zachmann Framework. Sowa, J.F. Knowledge Representation: logical, philosophical and computational foundations Brooks/Cole - Thomson Learning, 2000, ISBN 0-534-94965-7 This book is encyclopedic in its content and touches on most of the key aspects of logic and mathematics relevant to ontology. If you only have one book in this area, this should be it. Gives good references for further reading. Simons, P. Parts: a study in ontology, Oxford University Press, 1987, ISBN 0-19924146-5 This is the seminal work on mereology (the study of whole and part). Seeing how complex this could be if a continuant based approach to individuals was adopted helped to convince me that a spatio-temporal approach was worth persevering with.

The authors and editors would like to emphasize that this list is neither complete nor exclusive. Its main purpose is to be a start for further reading and study of topics being dealt with in the chapters of this book.

Author Index

Carley, Kathleen M. 199 Chen, Chih-Chun 99 Clack, Christopher D. 99 Costa, Paulo Cesar G. 7 Cruz, Isabel F. 75 Diallo, Saikou Y. El¸ci, Atilla

Maxwell, Daniel T. Nagl, Sylvia B.

Sandkuhl, Kurt

163

Hartung, Ronald L. Jain, Lakhmi C.

1

King, Robert D.

41

163

129

Th¨ orn, Christer 129 Tolk, Andreas 1, 41 Turnitsa, Charles D. 41

261

Laskey, Kathryn Blackmond

99

Rahnama, Behnam

41

199

West, Matthew 7

Xiao, Huiyong

229 75

Editors

Andreas Tolk is Associate Professor for Engineering Management and Systems Engineering in the Frank Batten College of Engineering and Technology at Old Dominion University, Norfolk, Virginia, USA. He is also affiliated as a Senior Scientist with the Virginia Modeling Analysis and Simulation Center in Suffolk, Virginia, USA. His research interests comprise system of systems engineering, integration of complex modelling and simulation functionality into operational systems, agent-mediated systems composition, and decision support systems.

Professor Lakhmi C. Jain is a Director/Founder of the Knowledge-Based Intelligent Engineering Systems (KES) Centre, located in the University of South Australia. He is a fellow of the Institution of Engineers Australia. His interests focus on the artificial intelligence paradigms and their applications in complex systems, artscience fusion, virtual systems, e-education, e-healthcare, unmanned air vehicles and intelligent agents.

Complex Systems in Knowledge-based Environments: Theory, Models and Applications (Studies in Computational Intelligence)

Advances in Computational Intelligence: Theory And Applications

Advances in Computational Intelligence: Theory And Applications

Intelligent Networking, Collaborative Systems and Applications (Studies in Computational Intelligence)

Statistical Implicative Analysis: Theory and Applications (Studies in Computational Intelligence)

Web Personalization in Intelligent Environments (Studies in Computational Intelligence)

Advances in computational intelligence: theory & applications

Computational Intelligence in Engineering (Studies in Computational Intelligence)

Computational Intelligence in Engineering (Studies in Computational Intelligence, 313)

Neural Networks: Computational Models and Applications (Studies in Computational Intelligence, Volume 53)

Innovative Applications in Data Mining (Studies in Computational Intelligence)

Evolutionary Algorithms and Chaotic Systems (Studies in Computational Intelligence)

Evolutionary Algorithms and Chaotic Systems (Studies in Computational Intelligence)

Intelligent Interactive Systems in Knowledge-Based Environments (Studies in Computational Intelligence)

Complex Time-Delay Systems: Theory and Applications (Understanding Complex Systems)

Advanced Computational Intelligence Paradigms in Healthcare 5: Intelligent Decision Support Systems (Studies in Computational Intelligence)

Computational Intelligence: A Compendium (Studies in Computational Intelligence, Volume 115)

Complex Time-Delay Systems: Theory and Applications (Understanding Complex Systems)

Challenges for Computational Intelligence (Studies in Computational Intelligence, Volume 262)

Computational Intelligence in Automotive Applications (Studies in Computational Intelligence, Volume 132)

Partial Covers, Reducts and Decision Rules in Rough Sets: Theory and Applications (Studies in Computational Intelligence)

Challenges for Computational Intelligence (Studies in Computational Intelligence)

Innovations in Bayesian Networks: Theory and Applications (Studies in Computational Intelligence)

Innovations in Swarm Intelligence (Studies in Computational Intelligence, Volume 248)

Computational Optimization, Methods and Algorithms (Studies in Computational Intelligence, 356)

Advances of Computational Intelligence in Industrial Systems

Quantum Inspired Intelligent Systems (Studies in Computational Intelligence)

Intelligent Systems for Knowledge Management (Studies in Computational Intelligence)

Swarm Intelligent Systems (Studies in Computational Intelligence, Volume 26)

Successful Case-based Reasoning Applications (Studies in Computational Intelligence)

Business Applications And Computational Intelligence

Complex Systems in Knowledge-based Environments: Theory, Models and Applications (Studies in Computational Intelligence)

Advances in Computational Intelligence: Theory And Applications

Advances in Computational Intelligence: Theory And Applications

Intelligent Networking, Collaborative Systems and Applications (Studies in Computational Intelligence)

Statistical Implicative Analysis: Theory and Applications (Studies in Computational Intelligence)

Web Personalization in Intelligent Environments (Studies in Computational Intelligence)

Advances in computational intelligence: theory & applications

Computational Intelligence in Engineering (Studies in Computational Intelligence)

Computational Intelligence in Engineering (Studies in Computational Intelligence, 313)

Neural Networks: Computational Models and Applications (Studies in Computational Intelligence, Volume 53)

Innovative Applications in Data Mining (Studies in Computational Intelligence)

Evolutionary Algorithms and Chaotic Systems (Studies in Computational Intelligence)

Evolutionary Algorithms and Chaotic Systems (Studies in Computational Intelligence)

Intelligent Interactive Systems in Knowledge-Based Environments (Studies in Computational Intelligence)

Complex Time-Delay Systems: Theory and Applications (Understanding Complex Systems)

Advanced Computational Intelligence Paradigms in Healthcare 5: Intelligent Decision Support Systems (Studies in Computational Intelligence)

Computational Intelligence: A Compendium (Studies in Computational Intelligence, Volume 115)

Complex Time-Delay Systems: Theory and Applications (Understanding Complex Systems)

Challenges for Computational Intelligence (Studies in Computational Intelligence, Volume 262)

Computational Intelligence in Automotive Applications (Studies in Computational Intelligence, Volume 132)

Partial Covers, Reducts and Decision Rules in Rough Sets: Theory and Applications (Studies in Computational Intelligence)

Challenges for Computational Intelligence (Studies in Computational Intelligence)

Innovations in Bayesian Networks: Theory and Applications (Studies in Computational Intelligence)

Innovations in Swarm Intelligence (Studies in Computational Intelligence, Volume 248)

Computational Optimization, Methods and Algorithms (Studies in Computational Intelligence, 356)

Advances of Computational Intelligence in Industrial Systems

Quantum Inspired Intelligent Systems (Studies in Computational Intelligence)

Intelligent Systems for Knowledge Management (Studies in Computational Intelligence)

Swarm Intelligent Systems (Studies in Computational Intelligence, Volume 26)

Successful Case-based Reasoning Applications (Studies in Computational Intelligence)

Business Applications And Computational Intelligence

Recommend Documents