Ontology Engineering Synthesis Lectures on Data Semantics and Knowledge 1st Edition Elisa F. Kendall
- 1. Ontology Engineering Synthesis Lectures on Data Semantics and Knowledge 1st Edition Elisa F. Kendall install download https://ebookmeta.com/product/ontology-engineering-synthesis- lectures-on-data-semantics-and-knowledge-1st-edition-elisa-f- kendall/ Download more ebook from https://ebookmeta.com
- 2. We believe these products will be a great fit for you. Click the link to download now, or visit ebookmeta.com to discover even more! Concepts, Frames and Cascades in Semantics, Cognition and Ontology: 7 (Language, Cognition, and Mind, 7) Sebastian Löbner (Editor) https://ebookmeta.com/product/concepts-frames-and-cascades-in- semantics-cognition-and-ontology-7-language-cognition-and- mind-7-sebastian-lobner-editor/ Provenance in Data Science From Data Models to Context Aware Knowledge Graphs Leslie F. Sikos https://ebookmeta.com/product/provenance-in-data-science-from- data-models-to-context-aware-knowledge-graphs-leslie-f-sikos/ NoSQL and SQL Data Modeling: Bringing Together Data, Semantics, and Software First Edition Hills https://ebookmeta.com/product/nosql-and-sql-data-modeling- bringing-together-data-semantics-and-software-first-edition- hills/ A Citrus Cookbook: Enjoy the Tastes of Citrus In Your Meals With Delicious Fruit Recipes 2nd Edition Booksumo Press https://ebookmeta.com/product/a-citrus-cookbook-enjoy-the-tastes- of-citrus-in-your-meals-with-delicious-fruit-recipes-2nd-edition- booksumo-press/
- 3. Learning and Personality The Experience of Introverted Reflective Learners in a World of Extroverts 1st Edition William K. Lawrence https://ebookmeta.com/product/learning-and-personality-the- experience-of-introverted-reflective-learners-in-a-world-of- extroverts-1st-edition-william-k-lawrence/ Line of Duty I Love Mounties 1st Edition Brynn Paulin https://ebookmeta.com/product/line-of-duty-i-love-mounties-1st- edition-brynn-paulin/ Economics - Study Guide 3rd Edition Constantine Ziogas https://ebookmeta.com/product/economics-study-guide-3rd-edition- constantine-ziogas/ Object and Pattern Recognition in Remote Sensing: Modelling and Monitoring Environmental and Anthropogenic Objects and Change Processes 1st Edition Stefan Hinz https://ebookmeta.com/product/object-and-pattern-recognition-in- remote-sensing-modelling-and-monitoring-environmental-and- anthropogenic-objects-and-change-processes-1st-edition-stefan- hinz/ Artificial Intelligence And International Economic Law: Disruption, Regulation, And Reconfiguration 1st Edition Shin-Yi Peng https://ebookmeta.com/product/artificial-intelligence-and- international-economic-law-disruption-regulation-and- reconfiguration-1st-edition-shin-yi-peng/
- 4. All s Fair in Love Zaftig Dating Agency 57 1st Edition Jane Fox Fox Jane https://ebookmeta.com/product/all-s-fair-in-love-zaftig-dating- agency-57-1st-edition-jane-fox-fox-jane/
- 7. iii Synthesis Lectures on the Semantic Web:Theory and Technology Editors Ying Ding, Indiana University Paul Groth, University of Amsterdam Founding Editor James Hendler, Rensselaer Polytechnic Institute Synthesis Lectures on the Semantic Web:Theory and Technology is edited by Ying Ding of Indiana Uni- versity and Paul Groth of University of Amsterdam.Whether you call it the Semantic Web, Linked Data, or Web 3.0, a new generation of Web technologies is offering major advances in the evolution of the World Wide Web. As the first generation of this technology transitions out of the labora- tory, new research is exploring how the growing Web of Data will change our world. While topics such as ontology-building and logics remain vital, new areas such as the use of semantics in Web search, the linking and use of open data on the Web, and future applications that will be supported by these technologies are becoming important research areas in their own right. Whether they be scientists, engineers or practitioners, Web users increasingly need to understand not just the new technologies of the Semantic Web, but to understand the principles by which those technologies work, and the best practices for assembling systems that integrate the different languages, resources, and functionalities that will be important in keeping the Web the rapidly expanding, and constantly changing, information space that has changed our lives. Topics to be included: • Semantic Web Principles from linked-data to ontology design • Key Semantic Web technologies and algorithms • Semantic Search and language technologies • The Emerging “Web of Data” and its use in industry, government and university ap- plications • Trust, Social networking and collaboration technologies for the Semantic Web • The economics of Semantic Web application adoption and use
- 8. iv • Publishing and Science on the Semantic Web • Semantic Web in health care and life sciences Ontology Engineering Elisa F. Kendall and Deborah L. McGuinness 2019 Demystifying OWL for the Enterprise Michael Uschold 2018 Validating RDF Jose Emilio Labra Gayo, Eric Prud’hommeaux, Iovka Boneva, and Dimitris Kontokostas 2017 Natural Language Processing for the Semantic Web Diana Maynard, Kalina Bontcheva, and Isabelle Augenstein 2016 The Epistemology of Intelligent Semantic Web Systems Mathieu d’Aquin and Enrico Motta 2016 Entity Resolution in the Web of Data Vassilis Christophides, Vasilis Efthymiou, and Kostas Stefanidis 2015 Library Linked Data in the Cloud: OCLC’s Experiments with New Models of Resource Description Carol Jean Godby, Shenghui Wang, and Jeffrey K. Mixter 2015 Semantic Mining of Social Networks Jie Tang and Juanzi Li 2015 Social Semantic Web Mining Tope Omitola, Sebastián A. Ríos, and John G. Breslin 2015 Semantic Breakthrough in Drug Discovery Bin Chen, Huijun Wang, Ying Ding, and David Wild 2014
- 9. v Semantics in Mobile Sensing Zhixian Yan and Dipanjan Chakraborty 2014 Provenance: An Introduction to PROV Luc Moreau and Paul Groth 2013 Resource-Oriented Architecture Patterns for Webs of Data Brian Sletten 2013 Aaron Swartz’s A Programmable Web: An Unfinished Work Aaron Swartz 2013 Incentive-Centric Semantic Web Application Engineering Elena Simperl, Roberta Cuel, and Martin Stein 2013 Publishing and Using Cultural Heritage Linked Data on the Semantic Web Eero Hyvönen 2012 VIVO: A Semantic Approach to Scholarly Networking and Discovery Katy Börner, Michael Conlon, Jon Corson-Rikert, and Ying Ding 2012 Linked Data: Evolving the Web into a Global Data Space Tom Heath and Christian Bizer 2011
- 10. © Springer Nature Switzerland AG 2022 Reprint of original edition © Morgan & Claypool 2019 All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means—electronic, mechanical, photocopy, recording, or any other except for brief quota- tions in printed reviews, without the prior permission of the publisher. Ontology Engineering Elisa F. Kendall and Deborah L. McGuinness ISBN: 978-3-031-79485-8 paperback ISBN: 978-3-031-79486-5 ebook DOI 10.1007/978-3-031-79486-5 A Publication in the Springer series SYNTHESIS LECTURES ON THE SEMANTIC WEB: THEORY AND TECHNOLOGY Lecture #18 Series Editors: Ying Ding, Indiana University, Paul Groth, University of Amsterdam Founding Editor: James Hendler Series ISSN 2160-4711 Print 2160-472X Electronic
- 11. Ontology Engineering Elisa F. Kendall Thematix Partners LLC Deborah L. McGuinness Rensselaer Polytechnic Institute SYNTHESIS LECTURES ON THE SEMANTIC WEB: THEORY AND TECHNOLOGY #18
- 12. viii ABSTRACT Ontologies have become increasingly important as the use of knowledge graphs, machine learning, natural language processing (NLP), and the amount of data generated on a daily basis has exploded. As of 2014, 90% of the data in the digital universe had been generated in the preceding two years, and the volume of data was projected to grow from 3.2 zettabytes to 40 zettabytes in the following six years. The very real issues that government, research, and commercial organizations are facing in order to sift through this amount of information to support decision-making alone mandate in- creasing automation. Yet, the data profiling, NLP, and learning algorithms that are ground-zero for data integration, manipulation, and search provide less-than-satisfactory results unless they utilize terms with unambiguous semantics, such as those found in ontologies and well-formed rule sets. Ontologies can provide a rich “schema” for the knowledge graphs underlying these technologies as well as the terminological and semantic basis for dramatic improvements in results. Many on- tology projects fail, however, due at least in part to a lack of discipline in the development process. This book, motivated by the Ontology 101 tutorial given for many years at what was originally the Semantic Technology Conference (SemTech) and then later from a semester-long university class, is designed to provide the foundations for ontology engineering. The book can serve as a course textbook or a primer for all those interested in ontologies. KEYWORDS ontology; ontology development; ontology engineering; knowledge representation and reasoning; knowledge graphs; Web Ontology Language; OWL; linked data; terminology work
- 13. ix Contents Foreword by Dean Allemang. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ��xi Foreword by Richard Mark Soley, Ph.D. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii Preface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv 1 Foundations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ���1 1.1 Background and Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Logic and Ontological Commitment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3 Ontology-Based Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.4 Knowledge Representation Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.4.1 Description Logic Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.5 Knowledge Bases, Databases, and Ontology . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.6 Reasoning, Truth Maintenance, and Negation . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.7 Explanations and Proof . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2 Before You Begin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.1 Domain Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.2 Modeling and Levels of Abstraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3 General Approach to Vocabulary Development . . . . . . . . . . . . . . . . . . . . . . . 16 2.4 Business Vocabulary Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.5 Evaluating Ontologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.6 Ontology Design Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.7 Selecting a Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3 Requirements and Use Cases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.1 Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.2 Gathering References and Potentially Reusable Ontologies . . . . . . . . . . . . . . 29 3.3 A Bit About Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.4 Summarizing the Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.5 The “Body” of the Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 3.6 Creating Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.7 Flow of Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 3.8 Competency Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
- 14. x 3.9 Additional Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 3.10 Integration with Business and Software Requirements . . . . . . . . . . . . . . . . . . 41 4 Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.1 How Terminology Work Fits into Ontology Engineering . . . . . . . . . . . . . . . 47 4.2 Laying the Groundwork . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 4.3 Term Excerption and Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.4 Terminology Analysis and Curation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.4.1 Concept Labeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 4.4.2 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 4.4.3 Synonyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 4.4.4 Identifiers and Identification Schemes . . . . . . . . . . . . . . . . . . . . . . . . 59 4.4.5 Classifiers and Classification Schemes . . . . . . . . . . . . . . . . . . . . . . . . 60 4.4.6 Pedigree and Provenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 4.4.7 Additional Notes (Annotations) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.5 Mapping Terminology Annotations to Standard Vocabularies . . . . . . . . . . . . 62 5 Conceptual Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 5.2 Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 5.3 Identifying Reusable Ontologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 5.4 Preliminary Domain Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 5.5 Naming Conventions for Web-Based Ontologies . . . . . . . . . . . . . . . . . . . . . . 75 5.6 Metadata for Ontologies and Model Elements . . . . . . . . . . . . . . . . . . . . . . . . 78 5.7 General Nature of Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 5.8 Relationships and Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 5.9 Individuals and Data Ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 5.10 Other Common Constructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 6 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Bibliography. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Author’s Biographies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
- 15. xi Foreword by Dean Allemang When we think of the history of engineering in computing, we see a repeating trend. We start by identifying a discipline, say, computer programming. Then as we write more and more programs and discover issues around maintenance and reuse of the programs, we come to understand that there is a strategic view that we can take, and we start to have a repeatable engineering discipline, like software engineering. As we recognize that the sort of strategic work that engineers do, be- yond software, is a real and tangible thing, we give it a name, usually a name that includes the word “architecture.” We have seen this pattern with business modeling/architecture/engineering, data modeling/architecture, enterprise architecture, and so on. There is a classic progression from some tactical practice to a strategic awareness. As our understanding of effective action in a field matures, we develop specialized language, advanced tools, and specific methods for working.Together, these things make effective practice in the field a repeatable, shareable activity. “Knowledge engineering,” as a buzzword, has been around for about as long as any of the other computer engineering words—perhaps longer than some more recent words like “enterprise architecture.” But it has also been the most controversial. When I was in graduate school, I con- tinually had to defend the fact that I was studying “knowledge” when my peers were doing more topical studies like networking, databases, or memory management. Around that time, Alan Newell postulated that a system could be productively described at the “knowledge level,” but this postu- late remained controversial for many years. The vast majority of software was built without paying attention to entities at the “knowledge level,” paying more attention to programming languages, memory management, and a new discipline that gathered around the name,“software engineering.” That was over three decades ago, and today, the value of a “knowledge graph” (in contrast to a database) is now well accepted. The huge search engines manage massive amounts of informa- tion connected in highly contextualized ways. We now accept that knowledge is key for managing massively distributed shared data (i.e., on the Web), and that Ontologies play a central role in representing, modularizing, and distributing that knowledge. So, it is timely that we now see a volume that makes the construction and distribution of ontologies into an engineering discipline. What heretofore resembled an artistic endeavor, per- formed with idiosyncratic methods only by uniquely skilled artisans, is now becoming a repeatable engineering practice. The volume you hold in your hands represents a watershed in this field. As a reader of this book, you are now part of the first generation of ontology engineers. It should come as no surprise that such a seminal book on ontology engineering is also a book about software engineering. And it is about business architecture. Mathematics and logic. Li-
- 16. xii FOREWORD brary science. Search engine optimization. Data modeling. Software design and methodology. On- tology engineering is not a hodge-podge of techniques taken from all these fields; by its very nature, ontology engineering genuinely and essentially touches all facets of computer science application. Earlier disciplines could draw boundaries; business architecture is distinct from data modeling. Data modeling is distinct from processing. Enterprise architecture is different from content man- agement. Each of these fields has a clear boundary, of what they do and do not have to deal with. The ontology engineer, by contrast, has to be conversant in all of these fields, since the job of the ontology is to bring the system together and connect it to its operation in the real world of business. As you read this book, you will understand that ontology engineering is not just the sum of all these parts, but it is indeed a new activity of its own, with its own goals and challenges.This book breaks this activity down into its basic pieces, providing goals, methodologies, tools, and insights at each level. You couldn’t ask for better authors for such a work. In those early days when we debated the nature and even the existence of something called “knowledge,”McGuinness was right there in the thick and thin of the global discussion. She is a seasoned researcher and educator who has been central to the development of our understanding of knowledge management, representation, or processing throughout the long and varied history of knowledge-based systems. Whenever anyone in the history of knowledge management has considered an alternative to any representational or processing aspect of knowledge, McGuinness was there, and can tell today’s student where every line of argument will lead. Kendall has spent years (decades?) in the trenches, in the field, in a variety of industries, behind the hyper-secure firewalls of the military and in the open data universe of global standards, applying these ideas even as they were still being worked out. She’s been there through thick and thin, as the computing world has developed its understanding of the role of knowledge in its systems. While others were talking about how one might do these things, she was out there doing them. It’s about time she writes this down for the rest of us. Wherever you start your journey—as a beginning student with an interest in building knowledge-based systems that make use of the rich contextual information in today’s world, or as a seasoned veteran in one of the related fields—this work will show you a context in which all these things come together to form something new. Now it’s time to take your first step. Dean Allemang Principal Consultant Working Ontologist LLC
- 17. xiii Foreword by Richard Mark Soley, Ph.D. Recently, I was speaking at a conference and spent most of the hour talking about metadata and semantics. At the end of the hour, we had some time for audience questions and answers, so I opened the floor to questions. The first question floored me: “Great speech, Dr. Soley, but I’m still hazy on one point. What do you mean by metadata?” Great speech, indeed! I was grumpy and tired and probably hungry too. “Three!” said I, immediately drawing a reply from the confused audience member. “Three what?” he asked. “Congratulations,” I answered. “You’ve just reinvented metadata!” This vignette repeats time and time again across the world as metadata, semantics and on- tology swirl around every discussion of data value. “Data is the new oil!” we’re told; but it’s not. What’s important is what that data means in context. And the context is the metadata, or the (unfortunately) implied ontology governing the meaning of that data. Defining those contexts is not a trivial thing; if it was, one of the myriad attempts over the years to define the “semantics of everything” would likely have worked. Instead of redefining Yet Another Middleware solution (as often is the case, starting with an easy or solved problem first), we’d have a way to easily connect any two or more software applications. Natural language trans- lation would be a snap. User interfaces would be obvious! But that hasn’t happened, and it likely won’t. Semantics of information are highly dependent on context (vertical market, application usage, time of day, you name it). Corralling data into us- able information remains hard but worth the trouble. No longer will governments publish all their collected data without explaining what it means; something that has already happened! At the Object Management Group, ontologies are of supreme importance. This three-de- cade-old well-established standards organization, having gone through middleware and modeling phases, is now tightly focused on vertical markets; more than three-quarters of all standards cur- rently in development are focused on vertical markets like financial systems, retail point-of-sale systems, military command-and-control systems, manufacturing systems, and the like. The core of all of these standards are ontologies that bring orderly semantics to the syntax of the con- nections. And high-quality design and engineering of ontologies allows them to withstand the changing vicissitudes of markets and gives some hope that ontological (semantic) information might cross domains.
- 18. xiv FOREWORD Well-engineered ontologies are therefore the cornerstone of high-quality standards. Far more than mere data models or interface definitions, an ontology leads to both; that is, if you get the semantics right, it is much more likely that your interface definitions, database metamodels—in fact, all of the artifacts that you need will almost design themselves. Some or all of the necessary artifacts forming the basis of good programming may simply “fall out” of the ontology! I hope this gets you thinking about how to engineer a high-quality ontology that stands the test of time. You’re ready for an explanation of exactly how to do that. Richard Mark Soley, Ph.D. Chairman and Chief Executive Officer Object Management Group, Inc.
- 19. xv Preface Several years ago, when Jim Hendler first suggested that we contribute our Ontology 101 tutorial from the Semantic Technologies Conference (fondly known as SemTech) in the form of a book to this series, we were convinced that we could crank it out in a matter of weeks or a few months at most. The tutorial was presented as a half-day workshop, and we had nine years’ experience in presenting and updating it in response to audience feedback. We knew from feedback that the tutorial itself was truly a firehose, and that making it available in an extended, more consumable and referenceable form would be helpful. We also knew that despite the growing number of books about semantic technologies, knowledge representation and description logics, graph databases, machine learning, natural language processing, and other related areas, there was really very little that provided a disciplined methodology for developing an ontology aimed at long-lived use and reuse. Despite the number of years that have gone by since we began working on it, that sentiment hasn’t changed. The tutorial was initially motivated by the Ontology 101 (Noy and McGuinness, 2001) paper, which was based on an expansion of a pedagogical example and ontology that McGuinness provided for wine and food pairing as an introduction to conceptual modeling along with a meth- odology for working with description logics (Brachman et al., 1991a). It was also influenced by a number of later papers such as Nardi and Brachman’s introductory chapter in the DL Handbook (Baader et al., 2003), which described how to build an ontology starting from scratch. None of the existing references, however, really discussed the more holistic approach we take, including how to capture requirements, develop terminology and definitions, or iteratively refine the terms, defini- tions, and relationships between them with subject matter experts through the development pro- cess. There were other resources that described use case development or terminology work, several of which we reference, but did not touch on the nuances needed specifically for ontology design. There were many references for performing some of these tasks related to data modeling, but not for developing an ontology using a data model as a starting point, what distinguished one from the other, or why that mattered. And nothing we found addressed requirements and methodologies for selecting ontologies that might be reused as a part of a new development activity, which is essential today. Nothing provided a comprehensive, end-to-end view of the ontology development, deploy- ment, and maintenance lifecycle, either. In 2015, we extended the tutorial to a full 13-week graduate course, which we teach together at Rensselaer Polytechnic Institute (RPI), where Dr. McGuinness is a constellation chair and pro- fessor of computer and cognitive science.We needed a reference we could use for that course as well
- 20. xvi PREFACE as for the professional training that we often provide as consultants. That increased our motivation to put this together, although business commitments and health challenges slowed us down a bit. The content included in this initial edition reflects the original tutorial and the first five lectures of our Ontology Engineering course at RPI. It covers the background, requirements gathering, termi- nology development, and initial conceptual modeling aspects of the overall ontology engineering lifecycle. Although most of our work leverages the World Wide Web Consortium (W3C) Resource Description Framework (RDF), Web Ontology Language (OWL), SPARQL, and other Semantic Web standards, we’ve steered away from presenting many technical, and especially syntactic, details of those languages, aside from illustrating specific points. Other references we cite, especially some publications in this series as well as the Semantic Web for the Working Ontologist (Allemang and Hen- dler, 2011), cover those topics well. We have also intentionally limited our coverage of description logic as the underlying technology as many resources exist. The examples we’ve given come from a small number of use cases that are representative of what we see in many of our projects, but that tend to be more accessible to our students than some of the more technical, domain-specific ontologies we develop on a regular basis. This book is written primarily for an advanced undergraduate or beginning graduate student, or anyone interested in developing enterprise data systems using knowledge representation and semantic technologies. It is not directed at a seasoned practitioner in an enterprise per se, but such a person should find it useful to fill in gaps with respect to background knowledge, methodology, and best practices in knowledge representation. We purposefully pay more attention to history, research, and fundamentals than a book tar- geted for a corporate audience would do. Readers should have a basic understanding of software engineering principles, such as knowing the difference between programs and data, the basics of data management, the differences between a data dictionary and data schema, and the basics of querying a database. We also assume that readers have heard of representation formats including XML and have some idea of what systems design and architecture entail. Our goal is to introduce the discipline of ontology engineering, which relates to all of these things but is a unique discipline in its own right. We will outline the basic steps involved in any ontology engineering project, along with how to avoid a number of common pitfalls, what kinds of tools are useful at each step, and how to structure the work towards a successful outcome. Readers may consider reading the entire book as a part of their exploration of knowledge en- gineering generally, or may choose to read individual chapters that, for the most part, are relatively self-contained. For example, many have already used Chapter 3 along with the use case template provided in our class and book materials. Others have found the terminology chapter and related template useful for establishing common vocabularies, enterprise glossaries, and other artifacts independently of the modeling activities that follow.
- 21. xvii Our intent is to continue adding chapters and appendices in subsequent editions to support our teaching activities and based on feedback from students and colleagues. We plan to incorpo- rate our experience in ontology engineering over the entire development lifecycle as well as cover patterns specific to certain kinds of applications. Any feedback on what we have presented here or on areas for potential expansion, as we revise and augment the content for future audiences, would be gratefully appreciated. PREFACE
- 22. 1 CHAPTER 1 Foundations Ontologies have become increasingly important as the use of knowledge graphs, machine learning, and natural language processing (NLP), and the amount of data generated on a daily basis has exploded. Many ontology projects have failed, however, due at least in part to a lack of discipline in the development process. This book is designed to address that, by outlining a proven meth- odology for the work of ontology engineering based on the combined experience of the authors, our colleagues, and students. Our intent for this chapter is to provide a very basic introduction to knowledge representation and a bit of context for the material that follows in subsequent chapters. 1.1 BACKGROUND AND DEFINITIONS Most mature engineering fields have some set of authoritative definitions that practitioners know and depend on. Having common definitions makes it much easier to talk about the discipline and allows us to communicate with one another precisely and reliably about our work. Knowing the language makes you part of the club. We hear many overlapping and sometimes confusing definitions for “ontology,” partly be- cause the knowledge representation (KR) field is still maturing from a commercial perspective, and partly because of its cross-disciplinary nature. Many professional ontologists have background and training in fields including formal philosophy, cognitive science, computational linguistics, data and information architecture, software engineering, artificial intelligence, or library science. As com- mercial awareness about linked data and ontologies has increased, people knowledgeable about a domain but not trained in any of these areas have started to build ontologies for use in applications as well. Typically, these individuals are domain experts looking for solutions to something their IT departments haven’t delivered, or they are enterprise architects who have run into brick walls attempting to use more traditional technologies to address tough problems. The result is that there is not as much consensus about what people mean when they talk about ontologies as one might think, and people often talk past one another without realizing that they are doing so. There are a number of well-known definitions and quotes in the knowledge representation field that practitioners often cite, and we list a few here to provide common grounding: “An ontology is a specification of a conceptualization.” (Gruber, 1993) This definition is one of the earliest and most cited definitions for ontology with respect to artificial intelligence. While it may seem a bit academic, we believe that by the time you finish reading this book, you’ll understand what it means and how to use it. It is, in fact, the most terse
- 23. 2 1. FOUNDATIONS and most precise definition of ontology that we have encountered. Having said this, some people may find a more operational definition helpful: “An ontology is a formal, explicit description of concepts in a domain of discourse (classes (sometimes called concepts)), properties of each concept describing various features and at- tributes of the concept (slots (sometimes called roles or properties)), and restrictions on slots (facets (sometimes called role restrictions)).” (Noy and McGuinness, 2001) The most common term for the discipline of ontology engineering is “knowledge engineer- ing,” as defined by John Sowa years ago: “Knowledge engineering is the application of logic and ontology to the task of building computable models of some domain for some purpose.” (Sowa, 1999) Any knowledge engineering activity absolutely must be grounded in a domain and must be driven by requirements. We will repeat this theme throughout the book and hope that the “of some domain for some purpose” part of John’s definition will compel our readers to specify the context and use cases for every ontology project you undertake. Examples of what we mean by context and use cases will be scattered throughout the sections that follow, and will be covered in depth in Chapter 3. Here are a few other classic definitions and quotes that may be useful as we consider how to model knowledge and then reason with that knowledge: “Artificial Intelligence can be viewed as the study of intelligent behavior achieved through computational means. Knowledge Representation then is the part of AI that is con- cerned with how an agent uses what it knows in deciding what to do.” (Brachman and Levesque, 2004) “Knowledge representation means that knowledge is formalized in a symbolic form, that is, to find a symbolic expression that can be interpreted.” (Klein and Methlie, 1995) “The task of classifying all the words of language, or what’s the same thing, all the ideas that seek expression, is the most stupendous of logical tasks. Anybody but the most accom- plished logician must break down in it utterly; and even for the strongest man, it is the severest possible tax on the logical equipment and faculty.” (Charles Sanders Peirce, in a letter to editor B. E. Smith of the Century Dictionary) Our own definition of ontology is based on applied experience over the last 25–30 years of working in the field, and stems from a combination of cognitive science, computer science, enter- prise architecture, and formal linguistics perspectives. An ontology specifies a rich description of the • terminology, concepts, nomenclature;
- 24. 3 • relationships among and between concepts and individuals ; and • sentences distinguishing concepts, refining definitions and relationships (constraints, restrictions, regular expressions) relevant to a particular domain or area of interest. Figure 1.1: Ontology definition and expressivity spectrum. Figure 1.1 provides an abbreviated view of what we, and many colleagues, call the “ontology spectrum”—the range of models of information that practitioners commonly refer to as ontologies. It covers models that may be as simple as an acronym list, index, catalog, or glossary, or as expressive as a set of micro theories supporting sophisticated analytics. The spectrum was developed during preparation for a panel discussion in 1999 at an As- sociation for the Advancement of Artificial Intelligence (AAAI) conference, where a number of well-known researchers in the field attempted to arrive at a consensus on a definition of ontology. This spectrum is described in detail in McGuinness, Ontologies Come of Age (2003). We believe that an ontology can add value when defined at any level along the spectrum, which is usually deter- mined by business or application requirements. Most of the ontologies we have developed, whether conceptual or application oriented, include at least a formal “is-a” or subclass hierarchy, and often additional expressions, such as restrictions on the number or type of values for a property, (i.e., they fall to the right of the red “squiggle” in the diagram). Regardless of the level of expressivity and whether the ontology is conceptual in nature or application focused, we expect that an ontology will be: (1) encoded formally in a declarative knowledge representation language; (2) syntactically well-formed for the language, as verified by an appropriate syntax checker or parser; (3) logically consistent, as verified by a language-appropriate reasoner or theorem prover; and (4) will meet business or application requirements as demonstrated through extensive testing.The process of evaluating and testing an ontology is both science and art, with increasingly sophisticated methods available in commercial tools, but because no “one size fits 1.1 BACKGROUND AND DEFINITIONS
- 25. 4 1. FOUNDATIONS all,” we typically need multiple tools to fully vet most ontologies. We will discuss some of the more practical and more readily available approaches to ontology evaluation in later chapters of this book. 1.2 LOGIC AND ONTOLOGICAL COMMITMENT The primary reason for developing an ontology is to make the meaning of a set of concepts, terms, and relationships explicit, so that both humans and machines can understand what those concepts mean. The level of precision, breadth, depth, and expressivity encoded in a given ontology depends on the application: search applications over linked data tend to require broader ontologies and tol- erate less precision than those that support data interoperability; some machine learning and natu- ral language processing applications require more depth than others. Ontologies that are intended to be used as business vocabularies or to support data governance and interoperability require more metadata,including clearly stated definitions,provenance,and pedigree,as well as explanatory notes and other usage information than machine learning applications may need. The foundation for the machine-interpretable aspects of knowledge representation lies in a combination of set theory and formal logic. The basis for the metadata stems from library science and terminology work, which we discuss in Chapter 4. Most people who are interested in knowledge representation took a course in logic at some point, either from a philosophical, mathematical, or linguistics perspective. Many of us also have basic knowledge of set theory, and can draw Venn diagrams showing set intersection when needed, but a little refresher may be helpful. Logic can be more difficult to read than English, but is clearly more precise: (forall ((x FloweringPlant)) (exists ((y Bloom)(z BloomColor))(and (hasPart x y)(hasCharacteristic y z))) ) Translation:Everyfloweringplanthasabloomwhichisapartofit,andwhichhasacharacteristic bloom color. Language: Common Logic, CLIF syntax (ISO/IEC 24707:2018, 2018) Logic is a simple language with few basic symbols.The level of detail depends on the choice of predicates made by the ontologist (e.g., FloweringPlant, hasPart, hasCharacteristic, in the logic, above); these predicates represent an ontology of the relevant concepts in the domain. 1.3 ONTOLOGY-BASED CAPABILITIES An ontology defines the vocabulary that may be used to specify queries and assertions for use by independently developed resources, processes, and applications. “Ontological commitments are
- 26. 5 agreements to use a shared vocabulary in a coherent and consistent manner.”1 Agreements can be specified as formal ontologies, or ontologies with additional rules, to enforce the policies stated in those agreements.The meaning of the concepts included in the agreements can be defined precisely and unambiguously, sufficient to support machine interpretation of the assertions. By composing or mapping the terms contained in the ontologies, independently developed systems can work to- gether to share information and processes consistently and accurately. Through precise definitions of terms, ontologies enable shared understanding in conversa- tions among agents to collect, process, fuse, and exchange information. For example, ontologies can be used to improve search accuracy through query expansion to clarify the search context.Typically, search accuracy includes both precision and recall, meaning that correct query results are returned and relevant answers are not missing. Ontologies designed for information sharing may be used in a number of ways, including but not limited to: • on their own as terminologies or common vocabularies to assist in communications within and across groups of people; • to codify, extend, and improve flexibility in XML2 and/or RDF Schema-based3 agree- ments; • for information organization, for example for websites that are designed to support search engine optimization (SEO) and/ or those that use mark-up per schema.org;4 or • to describe resources in a content management system, for example for archival, cor- porate website management, or for scientific experimentation and reuse. Ontologies that describe information resources, processes, or applications are frequently designed to support question answering, either through traditional query languages such as SQL5 or SPARQL,6 or through business rules, including rule languages such as RuleML,7 Jess,8 Flora-2,9 and commercial production rule languages. They may also be designed to support more complex applications, including: 1 http://www-ksl.stanford.edu/kst/what-is-an-ontology.html. 2 Extensible Markup Language (XML), see http://www.w3.org/standards/xml/core. 3 The Resource Description Framework (RDF) Vocabulary Description Language (RDF Schema), available at https://www.w3.org/RDF/. 4 See https://schema.org/ for more information. 5 Structured Query Language, see https://docs.microsoft.com/en-us/sql/odbc/reference/structured-query-lan- guage-sql?view=sql-server-2017. 6 SPARQL 1.1 Query Language, available at https://www.w3.org/TR/sparql11-overview/. 7 The Rule Mark-up Initiative, see http://wiki.ruleml.org/index.php/RuleML_Home. 8 Jess, the Java Expert System Shell and scripting language, see https://herzberg.ca.sandia.gov/docs/52/. 9 FLORA-2: Knowledge Representation and Reasoning with Objects, Actions, and Defaults, see http://flora. sourceforge.net/. 1.3 ONTOLOGY-BASED CAPABILITIES
- 27. 6 1. FOUNDATIONS • recommender systems, for example, for garden planning, product selection, service provider selection, etc. as part of an event planning system; • configuration systems such as product configurators or systems engineering design verification and validation; • policy analysis and enforcement, such as for investment banking compliance and risk management; • situational analysis systems, such as to understand anomalous behaviors for track and trace, fraud detection, or other business intelligence applications; and • other complex analyses, such as those required for understanding drug formularies, disease characteristics, human genetics, and individual patient profiles to determine the best therapies for addressing certain diseases. In other words, ontologies and the technologies that leverage them are well suited to solve problems that are cross-organizational, cross-domain, multi-disciplinary, or that span multiple systems. They are particularly useful in cases where traditional information technologies are insuf- ficiently precise, where flexibility is needed, where there is uncertainty in the information, or where there are rich relationships across processes, systems, and or services that can’t be addressed in other ways. Ontologies can connect silos of data, people, places, and things. In the sections that follow, we will provide examples and modeling patterns that are com- monly used to support both lightweight use cases that do not involve much reasoning, as well as richer applications such as recommender systems or systems for policy analysis and enforcement that depend on more representation and reasoning power. 1.4 KNOWLEDGE REPRESENTATION LANGUAGES Today’s approaches to knowledge representation (KR) emerged from 1970s and 1980s research in artificial intelligence, including work in areas of semantic networks, question-answering, neural networks, formal linguistics and natural language processing, theorem proving, and expert systems. The term knowledge representation is often used to talk about representation of information for consumption by machines, although “good” knowledge representations should also be readable by people. Every KR language has a number of features, most of which are common to software engineering, query, and other languages. They include: (1) a vocabulary, consisting of some set of logical symbols and reserved terms plus variables and constants; (2) a syntax that provides rules for combining the symbols into well-formed expressions; (3) a formal semantics, including a theory of reference that determines how the constants and variables are associated with things in the universe of discourse and a theory of truth that distinguishes true statements from false ones; and (4) rules
- 28. 7 of inference, that determine how one pattern can be inferred from another. If the logic is sound, the rules of inference must preserve truth as determined by the semantics. It is this fourth element, the rules of inference and the ability to infer new information from what we already know, that distinguishes KR languages from others. Many logic languages and their dialects have been used for KR purposes. They vary from classical first order logic (FOL) in terms of: (1) their syntax; (2) the subsets of FOL they implement (for example, propositional logic without quantifiers, Horn-clause, which excludes disjunctions in conclusions such as Prolog, and terminological or definitional logics, containing additional restric- tions); (3) their proof theory, such as monotonic or non-monotonic logic (the latter allows defaults), modal logic, temporal logic, and so forth; and (4) their model theory, which as we mentioned above, determines how expressions in the language are evaluated with respect to some model of the world. Classical FOL is two-valued (Boolean); a three-valued logic introduces unknowns; four-val- ued logic introduces inconsistency. Fuzzy logic uses the same notation as FOL but with an infinite range of certainty factors (0.0–1.0). Also, there are differences in terms of the built-in vocabularies of KR languages: basic ISO/IEC 24707:2018 (2018) is a tight, first-order language with little built in terminology, whereas the Web Ontology Language (Bao et al., 2012) includes support for some aspects of set theory.10 1.4.1 DESCRIPTION LOGIC LANGUAGES Description logics (DLs) are a family of logic-based formalisms that represent a subset of first order logic.They were designed to provide a “sweet spot” in that they have a reasonable degree of expres- siveness on the ontology spectrum, while not having so much expressive power that it is difficult to build efficient reasoning engines for them. They enable specification of ontologies in terms of concepts (classes), roles (relationships), and individuals (instances). Description logics are distinguished by (1) the fact that they have a formal semantics, repre- senting decidable fragments of first order logic,and (2) their provisions for inference services,which include sound and complete decision procedures for key problems. By decidable, we mean that there are effective algorithms for determining the truth value of the expressions stated in the logic. De- scription logics are highly optimized to support specific kinds of reasoning for implementation in operational systems.11 Example types of applications of description logics include: 10 For more information on general first-order logics and their use in ontology development, see Sowa (1999) and ISO/IEC 24707:2018 (2018). 11 For more information on description logics, KR and reasoning, see Baader et al. (2003) and Brachman and Levesque (2004). 1.4 KNOWLEDGE REPRESENTATION LANGUAGES
- 29. 8 1. FOUNDATIONS • configuration systems—product configurators, consistency checking, constraint prop- agation, etc., whose first significant industrial application was called PROSE (Mc- Guinness and Wright, 1998) and used the CLASSIC knowledge representation system, a description logic, developed by ATT Bell Laboratories in the late 1980s (Borgida et al., 1989); • question answering and recommendation systems, for suggesting sets of responses or options depending on the nature of the queries; and • model engineering applications, including those that involve analysis of the ontolo- gies or other kinds of models (systems engineering models, business process models, and so forth) to determine whether or not they meet certain methodological or other design criteria. 1.5 KNOWLEDGE BASES, DATABASES, AND ONTOLOGY An ontology is a conceptual model of some aspect of a particular universe of discourse (or of a do- main of discourse).Typically, ontologies contain only “rarified” or “special” individuals, representing elemental concepts critical to the domain. In other words, they are comprised primarily of concepts, relationships, and axiomatic expressions. One of the questions that we are often asked is, “What is the difference between an ontology and a knowledge base?” Sometimes people refer to the knowledge base as excluding the ontology and only containing the information about individuals along with their metadata, for example, the triples in a triple store without a corresponding schema. In other words, the ontology is separately maintained. In other cases, a knowledge base is considered to include both the ontology and the individuals (i.e., the triples in the case of a Semantic Web-based store). The ontology provides the schema and rules for interpretation of the individuals, facts, and other rules comprising the domain knowledge. A knowledge graph typically contains both the ontology and related data. In practice, we have found that it is important to keep the ontology and data as separate resources, especially during development. The practice of maintaining them separately but combining them in knowl- edge graphs and/or applications makes them easier to maintain. Once established, ontologies tend to evolve slowly, whereas the data on which applications depend may be highly volatile. Data for well-known code sets, which might change less frequently than some data sets, can be managed in the form of “OWL ontologies,”but, even in these cases, the individuals should be separate from the ontology defining them to aid in testing, debugging, and integration with other code sets. These data resources are not ontologies in their own right, although they might be identified with their own namespace, etc.
- 30. 9 Most inference engines require in-memory deductive databases for efficient reasoning (in- cluding commercially available reasoners). The knowledge base may be implemented in a physical, external database, such as a triple store, graph database, or relational database, but reasoning is typically done on a subset (partition) of that knowledge base in memory. 1.6 REASONING, TRUTH MAINTENANCE, AND NEGATION Reasoning is the mechanism by which the logical assertions made in an ontology and related knowledge base are evaluated by an inference engine. For the purposes of this discussion, a logical assertion is simply an explicit statement that declares that a certain premise is true. A collection of logical assertions, taken together, form a logical theory. A consistent theory is one that does not contain any logical contradictions.This means that there is at least one interpretation of the theory in which all of the assertions are provably true. Reasoning is used to check for contradictions in a collection of assertions. It can also provide a way of finding information that is implicit in what has been stated. In classical logic, the validity of a particular conclusion is retained even if new information is asserted in the knowledge base. This may change if some of the prior knowledge, or preconditions, are actually hypothetical assumptions that are invalidated by the new information. The same idea applies for arbitrary actions—new information can make preconditions invalid. Reasoners work by using the rules of inference to look for the “deductive closure” of the information they are given. They take the explicit statements and the rules of inference and apply those rules to the explicit statements until there are no more inferences they can make. In other words, they find any information that is implicit among the explicit statements. For example, from the following statement about flowering plants, if it has been asserted that x is a flowering plant, then a reasoner can infer that x has a bloom y, and that y has a characteristic which includes a bloom color z: (forall ((x FloweringPlant)) (exists ((y Bloom)(z BloomColor))(and (hasPart x y)(hasCharacteristic y z))) ) During the reasoning process, the reasoner looks for additional information that it can infer and checks to see if what it believes is consistent. Additionally, since it is generally applying rules of inference, it also checks to make sure it is not in an infinite loop. When some kind of logical inconsistency is uncovered, then the reasoner must determine, from a given invalid statement, whether or not others are also invalid.The process associated with tracking the threads that support determining which statements are invalid is called truth maintenance. Understanding the impact of how truth maintenance is handled is extremely important when evaluating the appropriateness of a particular inference engine for a given task. If all new information asserted in a knowledge base is monotonic, then all prior conclusions will, by definition, remain valid. Complications can arise, however, if new information negates a 1.6 REASONING,TRUTH MAINTENANCE, AND NEGATION
- 31. 10 1. FOUNDATIONS prior statement. “Non-monotonic” logical systems are logics in which the introduction of new axi- oms can invalidate old theorems (McDermott and Doyle, 1980). What is important to understand when selecting an inference engine is whether or not you need to be able to invalidate previous assertions, and if so, how the conflict detection and resolution is handled. Some questions to con- sider include the following. • What happens if conclusive information to prove the assumption is not available? • The assumption cannot be proven? • The assumption is not provable using certain methods? • The assumption is not provable in a fixed amount of time? The answers to these questions can result in different approaches to negation and differing interpretations by non-monotonic reasoners. Solutions include chronological and “intelligent” backtracking algorithms, heuristics, circumscription algorithms, justification or assumption-based retraction, depending on the reasoner and methods used for truth maintenance. Two of the most common reasoning methods are forward and backward chaining. Both leverage “if-then” rules, for example, “If it is raining, then the ground is wet.” In the forward chain- ing process, the reasoner attempts to match the”if” portion (or antecedent) of the rule and when a match is found, it asserts the “then”portion (or the consequent) of the rule.Thus, if the reasoner has found the statement “it is raining”in the knowledge base, it can apply the rule above to deduce that “The ground is wet.” Forward chaining is viewed as data driven and can be used to draw all of the conclusions one can deduce from an initial state and a set of inference rules if a reasoner executes all of the rules whose antecedents are matched in the knowledge base. Backward chaining works in the other direction. It is often viewed as goal directed. Suppose that the goal is to determine whether or not the ground is wet. A backward chaining approach would look to see if the statement,“the ground is wet,”matches any of the consequents of the rules, and if so, determine if the antecedent is in the knowledge base currently, or if there is a way to de- duce the antecedent of the rule.Thus, if a backward reasoner was trying to determine if the ground was wet and it had the rule above, it would look to see if it had been told that it is raining or if it could infer (using other rules) that it is raining. Another type of reasoning, called tableau (sometimes tableaux) reasoning, is based on a technique that checks for satisfiability of a finite set of formulas. The semantic tableaux was intro- duced in 1950s for classical logic and was adopted as the reasoning paradigm in description logics starting in the late 1990s. The tableau method is a formal proof procedure that uses a refutation approach—it begins from an opposing point of view.Thus, when the reasoner is trying to prove that something is true, it begins with an assertion that it is false and attempts to establish whether this is satisfiable. In our running example, if it is trying to prove that the ground is wet, it will assert that
- 32. 11 it is NOT the case that the ground is wet, and then work to determine if there is an inconsistency. While this may be counterintuitive, in that the reasoner proposes the opposite of what it is trying to prove, this method has proven to be very efficient for description logic processing in particular, and most description logic-based systems today use tableau reasoning. Yet another family of reasoning, called logic programming, begins with a set of sentences in a particular form. Rules are written as clauses such as H :- B1, … Bn. One reads this as H or the “head” of the rule is true if B1 through Bn are true. B1-Bn is called the body. There are a number of logic programming languages in use today, including Prolog, Answer Set Programming, and Datalog. 1.7 EXPLANATIONS AND PROOF When a reasoner draws a particular conclusion, many users and applications want to understand why. Primary motivating factors for requiring support for explanations in the reasoners include interoperability, reuse, trust, and debugging in general. Understanding the provenance of the infor- mation (i.e., where it came from and when) and results (e.g., what sources were used to produce the result, what part of the ontology and rules were used) is crucial to analysis. It is essential to know which information sources contributed what to your results, particularly for reconcilliation and un- derstanding when there are multiple sources involved and those sources of information differ. Most large companies have multiple databases, for example, containing customer and account informa- tion.In some cases there will be a “master”or “golden”source,with other databases considered either derivative or “not as golden”—meaning, that the data in those source databases is not as reliable. If information comes from outside of an organization, reliability will depend on the publisher and the recency of the content, among other factors. Some of the kinds of provenance information that have proven most important for interpret- ing and using the information inferred by the reasoner include: • identifying the information sources that were used (source); • understanding how recently they were updated (currency); • having an idea regarding how reliable these sources are (authoritativeness); and • knowing whether the information was directly available or derived, and if derived, how (method of reasoning). The methods used to explain why a reasoner reached a particular conclusion include expla- nation generation and proof specification. We will provide guidance in some depth on metadata to support provenance, and on explanations in general in the chapters that follow. 1.7 EXPLANATIONS AND PROOF
- 33. 13 CHAPTER 2 Before You Begin In this chapter we provide an introduction to domain analysis and conceptual modeling, discuss some of the methods used to evaluate ontologies for reusability and fit for purpose, identify some common patterns, and give some high-level analysis considerations for language selection when starting a knowledge representation project. 2.1 DOMAIN ANALYSIS Domain analysis involves the systematic development of a model of some area of interest for a particular purpose. The analysis process, including the specific methodology and level of effort, de- pends on the context of the work, including the requirements and use cases relevant to the project, as well as the target set of deliverables. Typical approaches range from brainstorming and high- level diagramming, such as mind mapping, to detailed, collaborative knowledge and information modeling supported by extensive testing for more formal knowledge engineering projects. The tools that people use for this purpose are equally diverse, from free or inexpensive brainstorming tools to sophisticated ontology and software model development environments.The most common capabilities of these kinds of tools include: • “drawing a picture” that includes concepts and relationships between them, and • producing sharable artifacts, that vary depending on the tool—often including web sharable drawings. Analysis for ontology development leverages domain analysis approaches from several re- lated fields. In a software or data engineering context, domain analysis may involve a review of existing software, repositories, and services to find commonality and to develop a higher-level model for use in re-engineering or to facilitate integration (de Champeaux, Lea, and Faure, 1993; Kang et al., 1990). In an artificial intelligence and knowledge representation context, the focus is on defining structural concepts, their organization into taxonomies, developing individual instances of these concepts, and determining key inferences for subsumption and classification for example, as in Brachman et al. (1991b) and Borgida and Brachman (2003). From a business architecture perspective, domain analysis may result in a model that provides wider context for process re-en- gineering, including the identification of core competencies, value streams, and critical challenges of an organization, resulting in a common view of its capabilities for various purposes (Ulrich and McWhorter, 2011). In library and information science (LIS), domain analysis involves studying
- 34. 14 2. BEFORE YOU BEGIN a broad range of information related to the knowledge domain, with an aim of organizing that knowledge as appropriate for the discourse community (Hjørland and Albrechtsen, 1995). Domain analysis to support ontology development takes inspiration from all of the above, starting from the knowledge representation community viewpoint and leveraging aspects of each of the others as well as from the terminology community (ISO 704:2009, 2009). The fact that the techniques we use are cross-disciplinary makes the work easier for peo- ple from any of these communities to recognize aspects of it and dive in. At the same time, this cross-disciplinary nature may make the work more difficult to understand and master, involving unfamiliar and sometimes counterintuitive methods for practitioners coming from a specific per- spective and experience base. Some of the most common disconnects occur when software or data engineers make assumptions about representation of relationships between concepts, which are first class citizens in ontologies, but not in some other modeling paradigms such as entity relationship diagramming (Chen, 1976) or the Unified Modeling Language, Version 2.5.1 (2017). Java pro- grammers, for example, sometimes have difficulty understanding inheritance—some programmers take short cuts, collecting attributes into a class and “inheriting from it” or reusing it when those attributes are needed, which may not result in a true is-a hierarchy. Subject matter experts and analysis who are not fluent in logic or the behavior of inference engines may make other mistakes initially in encoding. Typically, they discover that something isn’t quite right because the results obtained after querying or reasoning over some set of model constructs are not what they expected. Although there may be many reasons for this, at the end of the day, the reasoners and query en- gines only act as instructed. Often the remedy involves modeling concepts and relationships more carefully from the domain or business perspective, rather than from a technical view that reflects a given set of technologies, databases, tagging systems, or software language. 2.2 MODELING AND LEVELS OF ABSTRACTION Sometimes it helps people who are new to knowledge representation to provide a high-level view of where ontologies typically “play”in a more traditional modeling strategy. Figure 2.1, below, provides a notional view of a layered modeling architecture, from the most abstract at the highest level to very concrete at the lowest. This sort of layering is common to many modeling paradigms. An ontology can be designed at any level of abstraction,but with reference to Figure 2.1, typ- ically specifies knowledge at the context,conceptual,and/or logical layers.By comparison,entity-re- lationship models can be designed at a conceptual, logical, or physical layer, and software models at the physical and definition layers. Knowledge bases, content management systems, databases, and other repositories are implemented at the instance layer. In terms of the Zachman Framework™,12 which is well known in the data engineering community, an ontology is typically specified with 12 See https://www.zachman.com/about-the-zachman-framework.
- 35. 15 respect to at least one of the elements (what, how, where, who, when, why) across the top three rows of the matrix—executive perspective, business perspective, and architect’s perspective. A com- prehensive ontology architecture might include some or all of these perspectives, with increasing granularity corresponding to increasingly specific levels in the framework. • Idenfy subject areas • Define the meaning of things in the domain • Describe the logical representation of concepts, terminology, and their relationships • Describe the physical representation of data for repositories and systems • Encode the data, rules, and logic for a specific development platform • Hold the values of the properties applied to the data in tables in a repository Context Conceptual Logical Physical Definion Instance Figure 2.1: Abstraction layers. An ontology architecture developed to address requirements of a finance application might include: 1. a foundational layer of reusable and customized ontologies for metadata and prove- nance description (e.g., based on Dublin Core,13 SKOS (Simple Knowledge Organi- zation System),14 and the PROV Ontology (PROV-O),15 potentially with extensions that are context-specific); 2. a domain-independent layer of reusable ontologies covering standard concepts for dates and times, geopolitical entities, languages, and other commonly used concepts, building on the metadata layer—there are standardized and de facto standards that may be used for this purpose; 3. a domain-dependent layer of reusable ontologies covering standards for the domain area relevant to the use cases—any known standard vocabularies should be con- sidered, such as the Financial Industry Business Ontology (FIBO)16 for financial 13 See http://www.dublincore.org/specifications/. 14 See https://www.w3.org/standards/techs/skos#w3c_all. 15 See https://www.w3.org/TR/prov-o/. 16 More on FIBO can be found at https://spec.edmcouncil.org/ and at https://www.omg.org/industries/finance.htm. 2.2 MODELING AND LEVELS OF ABSTRACTION
- 36. 16 2. BEFORE YOU BEGIN products and services or the Unified Medical Language System (UMLS) for medical applications; and 4. a domain-dependent layer of ontologies specific to the problems of interest, that build on and extend ontologies in the other three layers Separation of abstraction layers in an ontology architecture is one of a number of strategies that can improve organization and facilitate evolution and change management for large-scale ap- plications. Key questions for an ontologist starting to organize a domain model include whether a given concept or relationship is general enough to be reused, either by other ontologies or applica- tions, and whether that concept or property is independent from others they are working with.The answers can assist in determining how to modularize the domain. At a domain-dependent level an architect might incorporate further separation based on criteria such as • behavioral, functional, and structural knowledge for engineering systems; • presentation-layer, process logic, business logic, information infrastructure, and policy infrastructure-related (network, security, and system management) functions in soft- ware; and • “as designed,” “as built,” “as configured,” and “as maintained” for product oriented systems. Identifying the set of concerns and abstraction layers appropriate for a large-scale ontology development effort should be done early in the process to ensure that the resulting ontologies sup- port these modularization strategies and to avoid downstream rework. 2.3 GENERAL APPROACH TO VOCABULARY DEVELOPMENT Ontologies can be designed for general use, without any specific application in mind (i.e., as business or scientific vocabularies and controlled vocabularies), or to support applications such as searching and data mining, information, data and systems integration, business intelligence and decision support systems, recommendation systems, question answering systems, natural language processing, predictive analytics, machine learning, or other systems involving automated reasoning and/or rules-based analysis. Use of a logically consistent ontology as the vocabulary used to drive rules and decision management systems increases rule set completeness and accuracy, reduces development time, error, and maintenance costs, and increases user satisfaction with the resulting systems (Nitsche et al., 2014). Like any other engineering task, the starting point for analysis purposes is to gather require- ments and source materials. We use two important tools to support requirements analysis, called Use Cases and Competency Questions. Use cases, which we discuss in detail Chapter 3, provide the
- 37. 17 structure we need for organizing requirements. Competency questions, which we cover in Section 3.8, are a set of representative questions and example answers that a knowledge graph or application must be able to answer to ensure success. The requirements and use case analysis process ensures sufficient coverage and limits scope creep. Some of the materials that may be relevant, depending on the domain and purpose of the ontology, include not only any available specifications, (e.g., for existing systems or data sources), but policies, procedures, regulations, international and national standards, published dictionaries and glossaries (given that the source is authoritative), and so forth. Source materials should be referenced in the individual use cases that they support and in metadata describing the source(s) used to develop definitions in the ontologies. If a suitable set of requirements is available to start with, then development of use cases and competency questions, reflecting those requirements, is typically the next step. For example, in fi- nancial services, banks and other financial intermediaries need to be able to answer questions raised by their regulators, such as the following. • What is my current exposure to a given counterparty? • What is my current exposure with respect to a specific financial instrument (e.g., stock, bond, derivative, future, option) or set of related instruments? • What is my current exposure to instruments originating from a specific region or country? Most banks of size, including the globally systemically important banks (G-SIBs) and many other smaller institutions, are required to demonstrate fundamental improvements in risk data ag- gregation and reporting.The requirements for doing so are specified in Basel Committee on Bank- ing Supervision (BCBS) Principles for effective risk data aggregation and risk reporting (BCBS 23917 ). A preliminary analysis would • include these questions and others derived from the BCBS 239 document in use cases; • search the laws and regulations in applicable jurisdictions (in this case, in the EU, including BCBS-related regulations, those of the International Accounting Standards Board (IASB), regulations and rules published by the European Central Bank (ECB), and any national or regional equivalents), for glossaries, other definitions, and explan- atory content; • identify the concepts mentioned in the competency questions, such as “counterparty,” “exposure,” “financial instrument,” and “region,” as provided in those regulations and other legal dictionaries, including their relationships to one another; and 17 https://www.bis.org/publ/bcbs239.pdf. 2.3 GENERAL APPROACH TO VOCABULARY DEVELOPMENT
- 38. 18 2. BEFORE YOU BEGIN • identify the touch points (systems, data sources, policies, procedures, reports, and so forth) where those concepts are used or referenced,both implicitly and explicitly-these form a subset of the actors required for use case development. Another very early and critical task is to identify key subject matter experts (SMEs) and stakeholders that can validate the competency questions, definitions, critical source materials, and use cases, as well as provide usage scenarios for the relevant terms. The stakeholders and possibly some of the SMEs will also be represented as actors in the use cases. We have customized tradi- tional use case development for ontology and semantically enabled application development pur- poses, which we will discuss in more detail in Chapter 3. From the use cases and competency questions, we recommend iterative domain analysis starting with a “thread” that covers the basic content (concepts and relationships), scoped to cover the competency questions developed during use case analysis, which will ground further work and assist in prioritizing what to build out next. An initial analysis should identify the concepts and terminology that are central to the domain or application and the high-level relationships between those concepts. The natural relationships and topic areas identified in the definitions will also sug- gest how the concepts can be grouped into independent ontologies that reference one another, for example, covering business entities in one ontology, contracts and the definition of a counterparty in another, and financial instruments in yet another, and then further refining those concepts into an increasingly broad and deep network. Once you have a high-level ontology architecture in mind, and before a great deal of time is spent defining specific concepts, it is important to understand and articulate the architectural trade-offs you’re making with your broader team and stakeholders, as well as the technical benefits you believe you will gain from making those trade-offs. The nature of the information and kinds of competency questions that need to be answered, as identified in the use cases, should drive the architecture, approach, ontology scope, and design decisions you make. Documenting and explain- ing the requirements as you understand them through the use cases, identifying stakeholders and SMEs and getting approval for your interpretation of the requirements together with the set of information sources (actors in your use cases) and reference materials you plan to use is essential at this stage in any project. Understand and communicate the pros and cons of adopting any standard (actual or ad hoc) ontology that you plan to depend on. We recommend that you reuse standard- ized, well-tested, and available ontologies whenever possible, and a discussion of the trade-offs with respect to such decisions should also be included in your use cases. Section 2.4 discusses vocabulary development from a more business-oriented perspective, although it is relevant for any situation where requirements are lacking.
- 39. 19 2.4 BUSINESS VOCABULARY DEVELOPMENT In cases without a business or technical specification as a starting point, for example, when the goal is to develop a general-purpose vocabulary for some domain rather than an application-specific on- tology, then we suggest that the place to start is with a business architecture (Business Architecture Guild, 2014).18 A business architecture is essential to development of a general-purpose business vocabulary in the absence of other sources of requirements and scoping information. Use cases and competency questions can be derived from the capability and information maps developed as a part of the business architecture process. The use cases, including usage scenarios and competency questions (again, the set of questions that the use case entails—questions that a repository needs to be able to answer, an application needs to cover, etc.), should weave a path through the capability and information maps, such that every capability and every information element is addressed by at least one use case. The individual capabilities (one or more) should expand to multiple scenarios in the use cases. Information elements should be represented as actors in those use cases.This ensures that the set of competency questions developed provides sufficient coverage of the domain for that business area. Ontology development can be initiated once a preliminary set of use cases with sufficient domain coverage is available. The target ontology, or family of ontologies, should contain the terms, definitions, and relevant metadata that enable every competency question to be asked and answered. This includes coverage of any ancillary vocabulary identified/used in the use cases, capability maps and descriptions, and information maps and descriptions from the business archi- tecture, as appropriate. Again, depending on the use cases, it may be appropriate to reuse existing ontologies that cover the required terminology, extending them as appropriate. Typically, and especially in scientific domains, there are openly available, and sometimes standard ontologies on which a gap analysis and evaluation for reusability can be performed. In such cases, the ontology development process includes reuse of the selected ontology(ies), mapping terms from different ontologies to each other, and developing extensions to fill any gaps. Test cases, test content, and a set of test competency questions that can later be used for regression testing are also an essential piece of the development process. Depending on the environment and business requirements, policies and procedures for man- aging, evolving, and governing the ontology and the development artifacts may also be required. The policies and procedures should cover review cycles, version management, test case and test con- tent development, automation of as much of the testing and review as possible, and management of the interim artifacts that themselves can provide tremendous value to the organization. The use cases, which provide a bridge from a given capability to the vocabulary needed to perform that ca- pability, must cite all reference materials—regulatory and internal policy documents, international 18 See https://www.businessarchitectureguild.org/default.aspx. 2.4 BUSINESS VOCABULARY DEVELOPMENT
- 40. 20 2. BEFORE YOU BEGIN and national standards, other relevant references and sanctioned source materials for definition development—and source and product repositories and artifacts, as well as all stakeholders and other actors, that are appropriate for that use case.These references fill in some of the gaps that the business architecture might not naturally cover. Deliverables from a business architecture-based ontology engineering process include the business architecture artifacts (value streams, capability maps, information maps, interview ques- tions and responses, gap analysis, and so forth), a set of use cases that leverage the capability and information maps, and related ontology artifacts (e.g., models, diagrams, documentation), and a publishable repository containing the ontologies that comprise the business vocabulary as well as all of the other artifacts, interlinked, for web-based access by the relevant stakeholders. 2.5 EVALUATING ONTOLOGIES A number of dimensions should be considered when analyzing or classifying ontologies as a part of a development process, for potential reuse, or for other purposes such as refactoring to assist in maintenance activities. Many papers on ontology evaluation cite completeness, correctness, un- derstandability, and usability as the basic measures for determining reusability (Tartir et al., 2005; Duque-Ramos et al., 2011). Metrics describing a particular ontology may reflect the content, in- herent structures or patterns, or the semantics of the model itself. Other metrics may indicate the nature of the repositories or other resources that the model describes, or the functionality required of a target application. Understanding these dimensions and how a given ontology stacks up against them can be important in determining whether an ontology is appropriate for reuse. For example, the expressive power required to reason with an ontology will affect the performance as well as reasoning efficiency in any target application. Expressivity, and in fact any of the other dimensions highlighted below, are only interesting if the ontology in question provides epistemological adequacy (i.e., the ontology provides sufficient coverage in terms of content richness and scope). Key semantic aspects19 to consider include: • the level of expressivity of the representation language used to specify the ontology (as described by the ontology spectrum presented in Chapter 1); • the level of complexity (including complexity in the number and nature of axioms in the ontology, as well as the processing complexity required to reason with the ontology, with an understanding of how that complexity may impact performance); and • the level of granularity in the ontology—explicitly underspecifying the details of the terms may be an appropriate strategy for an ontology with high reuse potential, and 19 Identified at an Ontology Summit held at the National Institute of Standards and Technology (NIST) in 2007, see http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2007.
- 41. 21 particularly for one intended for use in search applications, with increasing levels of detail in dependent layers in the ontology architecture. Many of the basic ontology development tools in use today provide an indication of the level of expressivity and complexity of an individual ontology as well as over its imports closure, i.e., the result of importing the ontologies it references into an integrated knowledge graph.The underlying metrics used to determine these indicators can also be helpful in identifying potential performance issues in applications that use the ontology. For example, some more advanced relationships that we will discuss later, such as inverse relations and qualified cardinality restrictions, are known to impact performance, and understanding how prevalent these are in the ontology under evaluation may be an important consideration for reuse. Certain axioms that impact performance can be simulated to minimize any potential impact.20 What is important is to be able to recognize that there could be an issue and determine when simulation is necessary to reduce the impact on business objectives. Some practical metrics for analyzing the content of an ontology are presented on the BioPortal site,21 and with respect to a knowledge base that uses it (Tartir et al., 2005). Metrics that support ontology analysis with respect to cohesion as a measure of modularity and reusability are discussed in Yao, Orme, and Etzkorn (2005). Metrics that support suitability for project reuse, evolution, and merging are presented in McGuinness et al. (2000). A comprehensive analysis of model, application, and other characteristics of ontologies that also provides observations on how these characteristics typically apply to classes of applications is given in (Hart, et al., 2004). Some complementary considerations are given in Das, Wu, and Mc- Guinness (2001).According to Hart et al.,functional criterion for ontology evaluation may include: • the degree of relevance to the problem based on the intended use cases; • the degree of rigor required to support an application and how well the ontology supports this requirement (i.e., ontologies used for prescriptive purposes have a much higher need for correctness than those that are intended for descriptive uses only); and • the amount and nature of automation envisioned, and the extent to which the on- tology was designed to support the automated reasoning requirements of the target system or application. Model centric perspectives characterize the ontologies themselves and are concerned with their structure, formalism, and dynamics, including: • the level of authoritativeness, from the least authoritative, and typically broader, shal- lower ontologies to most authoritative, narrower, and more deeply defined ontologies; 20 See https://doi.org/10.4018/IJSWIS.2018010101, for example. 21 https://www.bioontology.org/wiki/Ontology_Metrics. 2.5 EVALUATING ONTOLOGIES
- 42. 22 2. BEFORE YOU BEGIN • the source and nature of structure—from passive (transcendent) structure that orig- inates outside of the system, often from direct development, to active (immanent) structure that emerges from the data or behavior; • the degree of formality, from informal or primarily taxonomic to quite formal, having rigorously defined types, relationships, and theories or axioms; • model dynamics, ranging from cases where the ontologies themselves are read-only and static or slow to change, to situations in which the ontologies are fluid in nature and evolving; and • instance dynamics, ranging from cases where the instances asserted in a knowl- edge-base that reflects the ontology are read-only to those where the instances are volatile, changing continuously Application-centric perspectives are concerned with how applications use and manipulate ontologies: • the degree of control or management oversight, ranging from externally focused ontol- ogies that are public in nature and developed by loosely related communities or even by crowd sourcing to those that are internally focused and entirely controlled by the development organization; • the nature of application changeability, from static (with periodic updates) to dynamic; • the nature of application coupling—from loosely coupled to tightly coupled; • the integration focus, if any, ranging from information integration to application in- tegration; and • the application lifecycle usage demands on the ontology, at design time, at run-time, or in an operational system. Aspects supporting ontology design and evolution methodologies include: • the level of conformance with development policies, including those for naming con- ventions, documentation and annotation usage, requirements for modularity, test and validation policies, and so on, as required; • the level of conformance with organizational governance policies; and • the degree to which the ontology is designed to support collaborative development, change management, and other model evolution expectations;
- 43. 23 These characteristics are representative of the kinds of things that people need to think about and prioritize when determining whether or not a particular version of an ontology meets require- ments and corporate standards, or whether reusing an existing ontology is appropriate for a given situation. Many of these aspects can also assist project managers in understanding and managing the scope of ontology development projects. 2.6 ONTOLOGY DESIGN PATTERNS Design patterns have proven to be invaluable across modeling and engineering domains, and re- search to identify common patterns has been ongoing since the early days of the Semantic Web Best Practices working group.22 One of the first patterns published by the working group described how to model part—whole relationships in Web Ontology Language (OWL).23 Another pattern published by the working group that is cited frequently describes how to represent n-ary relations24 in OWL; others include how to represent classes as property values25 as well as specified values and value sets.26 Despite language evolution and tremendous progress since then on many technology fronts, these patterns continue to be relevant today. Building on the work done by Best Practices, there are many papers and conference work- shops dedicated to developing an ever-growing catalog of ontology design patterns. Most nota- bly, these include the Ontology Design Patterns wiki created by Aldo Gangemi and Valentina Presutti,27 which covers general design patterns. A number of websites focused on patterns for domain-specific ontology use are available as well. The important takeaway from this is that a combination of reuse of existing ontologies and applying these kinds of patterns in new ontologies results in higher quality, more maintainable, and more reusable ontologies. 2.7 SELECTING A LANGUAGE Determining what knowledge representation language to use in a development project is similar to making other technology decisions. While some of the issues highlighted below may seem focused more on applications that use the ontologies rather than on the languages per se, it is important to understand whether the language in question has sufficient tool support to meet project require- ments. In addition to organizational requirements, decision criteria may include: 1. the intended use of the ontologies, including domain- and application-specific knowledge representation requirements; 22 The Best Practices working group legacy page is available at https://www.w3.org/2001/sw/BestPractices/. 23 See https://www.w3.org/2001/sw/BestPractices/OEP/SimplePartWhole/index.html. 24 See https://www.w3.org/TR/swbp-n-aryRelations/. 25 See https://www.w3.org/TR/2005/NOTE-swbp-classes-as-values-20050405/. 26 See https://www.w3.org/TR/2005/NOTE-swbp-specified-values-20050517/. 27 See http://ontologydesignpatterns.org/wiki/Main_Page. 2.7 SELECTING A LANGUAGE
- 44. 24 2. BEFORE YOU BEGIN 2. the requirements for the knowledge-based systems that will implement the ontolo- gies, including reasoning requirements, question answering requirements, integration with other systems, etc.; 3. the number and nature of any potential transformations required among processes, resources, services to support semantic mediation, and performance requirements specific to the services that require such transformations; 4. ontology and knowledge representation system alignment, de-confliction, and/or ambiguity resolution requirements; 5. collaborative development requirements, especially those where the need for commu- nity participation, such as for vetting definitions, is important; and 6. general performance, sizing, timing requirements of the target environment, other operational considerations, such as those specific to highly distributed environments. While this list is not exhaustive, it provides a view of some of the factors that architects need to consider as a part of the language and broader application environment selection process. For example, even for ontologies whose primary intended use is as an extensible business vocabulary, as a reference for human and perhaps automated systems usage, there may be a requirement for basic calculation support in a deployment environment. We typically use the OWL when it provides enough expressive power and reasoning support. OWL does not provide inherent support for arithmetic, analytical processes, or other computations, however, but can be integrated with rule- based processing or supporting functions, which may be sufficient to fill the gap. Certain financial services and business applications may require support for “negation as failure,” which also requires the ontology to be extended through the use of rules if OWL is selected as the underlying ontology language. In cases where there are real-time constraints on processing, such as for handling certain kinds of high-throughput transactions, an ontology may be appropriate as the basis for relational or dimensional schema development and validation, and in out-of-band analysis capabilities (e.g., as part of a related business intelligence application), but may not be the right choice for the un- derlying transaction processing system.
- 45. 25 CHAPTER 3 Requirements and Use Cases In this chapter we provide an introduction to use cases (Jacobson et al., 1992; Jacobson, Spence, and Bittner, 2011), tailored to ontology design, evaluation, and maintenance and for incremental requirements development for constructing semantically enhanced systems. Ontology engineering is cross-disciplinary, and may benefit from background in logic, ter- minology, library science, data science and engineering, business analysis, or software engineering depending on the context and requirements.The reasons for developing an ontology range from the need for a reference vocabulary to something more sophisticated such as support for reasoning in the context of business intelligence, predictive analytics, question answering, recommender systems, or other complex tasks. Because of this diversity in requirements and usage, people who are launch- ing projects using semantics may not think about a full range of ontology-specific requirements.Yet, in order to determine what the ontology needs to provide, in what context, for what purpose, given what data, requirements are essential. It is the requirements that provide the basis for determining the scope of work and what it means to be successful. Without scoping requirements, ontology proj- ects tend to wander down “interesting but not essential”paths, and do not reach focused completion with clear termination criteria. Without an understanding of the success criteria, how do you know when you’re done? And, how can you test any revisions to the ontology to ensure that you haven’t made changes that will invalidate something users depend on? We have participated in countless projects where there is pressure to skip the requirements step and jump straight into modeling—“throwing a bunch of classes” into an ontology editor such as Protégé or boxes onto a diagram as a starting place. While someone with a longer term or high- er-level view may request requirements, many projects proceed too quickly to modeling without paying enough attention to the requirements step. And there are all kinds of excuses—“oh, this is really research, so there aren’t requirements.”Another common response is “We need a general-pur- pose, reference ontology for the entire domain, so there is no way to constrain it.” Or—“we’ll use the development process to figure it out, because we don’t really know what we need.” In reality there are always requirements, although you may need to work a bit harder to draw them out of the various stakeholders involved and iterate to obtain a representative set. Ontology development is an engineering activity. This means that although there is certainly art and creativity involved, it’s also a discipline. Eliciting requirements and determining scoping boundaries can be daunting, but for every domain, there are sub-domains. For every sub-domain, there are capabilities and topical ways of organizing and prioritizing the work with stakeholders.There must be some way of determining
- 46. 26 3. REQUIREMENTS AND USE CASES what “successful” means and when “you’re done”—at least for a given time frame and for a given “release” of an ontology. Well-written use cases are critical to scoping any ontology. They become a part of the doc- umentation that should be managed and maintained together with other requirements and design artifacts, so that others can understand the design intent, the criteria for success and completion, and serve as support for making informed judgments as to whether an ontology is fit for reuse. Use cases not only summarize the context and requirements for ontology development, they also help establish agreement on requirements with stakeholders. We advocate a use case-based approach in part because we have not seen other methods for capturing ontology requirements and scoping questions that are better, but also because we have seen far too many people dive in to development without sufficient knowledge of what they should be modeling, how to evaluate the ontology, and, most importantly, when to stop modeling work. 3.1 GETTING STARTED A basic use case is essentially an ordered set of steps, typically defining the interactions between an actor and a system. A more complete use case includes a collection of possible sequences of interac- tions between a system and its actors relating to a particular goal or objective. In an ontology-driven or ontology-guided system, ontologies provide the communications fabric for those interactions —the content for those communications. So, from the perspective of an ontologist, a complete col- lection of use cases should define all known system behavior relevant to the actors, but with a focus on the content exchanged between them rather than on the detailed communications mechanisms, and with emphasis on the knowledge bases and knowledge-based analysis performed, if any. Any system behaviors that are irrelevant to the actors are extraneous from the ontologist’s perspective. Although this may seem a bit heavy on the requirements at first blush, remember that use case development is iterative, starting with a lightweight description and adding increasing detail over time is expected. If you are working without other sources for requirements, then anticipate that it will be even more iterative, and that the resulting use case may have little in common with where you started. There are templates available on the Web for specifying use cases, ranging from Alistair Cockburn’s site,28 to suggestions in Jacobson’s most recent book (Jacobson, Spence, and Bittner, 2011). We’ve gathered some of the main points included in these and other recommendations, together with additional requirements for semantically enabled systems and ontology development in an extended template that we recommend for this purpose.29 You likely will not have all of the 28 https://alistair.cockburn.us/. 29 Our use case template can be downloaded from the Morgan Claypool book abstract page, here http://bit. ly/2IpFOGp..
- 47. 27 details from the outset, but we recommend filling in what you know, as well as listing any known user stories in the body of the use case as a starting point. Before we begin, or as a part of the initial requirements gathering process, we need to: • identify the specific sub-domain, topic area, or organizational perspective to focus on; • gather relevant content—i.e., any documentation (policies, procedures, standards, other sources of terminology) that we know about in advance; • identify key stakeholders, principal subject matter SMEs, and consumers of the ontol- ogy or work product that use it; • identify any other known interfaces—systems and data sources—that will participate in the use case; • sketch out any user stories or usage scenarios for the ontology of which you are aware; and • seed the use case template with as much information as possible. Each use case should address the basic capabilities or features needed to accomplish some task, or represent a similar set of questions that certain users would like to be able to ask and an- swer in some context. In an “agile” or “scrum” development environment, one would seed each use case with some number of user stories30 that have something in common. The user stories would be collected in a usage scenarios/user stories section of the use case, and preserved for traceability purposes. Consider the flowering plant example described in Chapter 1. User stories derived from the example might include: • I would like to purchase flowering plants that should do well in sunny areas of my garden; and • I am designing a south-facing bed that is partially shaded, and would like drought-tolerant plant suggestions. Other user stories that have been important to us include: • I would like plants that are not likely to attract and be eaten by deer and that tolerate clay soil; and 30 https://en.wikipedia.org/wiki/User_story. 3.1 GETTING STARTED
- 48. 28 3. REQUIREMENTS AND USE CASES • I need to purchase a new tree that is oak-root fungus resistant to replace one that recently died of that disease. It must be selected from the city of Los Altos preferred tree list and, of those, I would like one that flowers and whose leaves turn in the fall. From the financial example in Chapter 2, questions such as the following qualify as user stories if rephrased as statements. • What is my current exposure to a given counterparty? • What is my current exposure with respect to a specific financial instrument (e.g., stock, bond, swap agreement, future, option) or set of related instruments? • What is my current exposure to instruments originating from a specific region? A more general competency question in this last case might be, “From a set of approved plants for a given setting in a specific region, identify all those that are resistant to certain known diseases and pests and that have certain traits in their phenotype.” The ability to map a specific question, such as the one about the Los Altos preferred tree list, to something more general, high- lights the power of a well-designed ontology. The user stories should come from stakeholders in the project rather than from developers (or ontologists) to the degree possible, and only from the latter if they are derived. Derived user stories (e.g., from requirements documents or a business architecture) should be reviewed by the stakeholders for validation and prioritization purposes. If you use a business architecture as the starting point, as discussed in Chapter 2, the user stories should be developed from a combination of the capabilities and interviews, such that every capability is involved in at least one user story,31 and ultimately in at least one use case. As helpful as user stories can be on their own, one of the downsides of an agile approach that is solely based on user stories is that the overall architecture for the system, the larger usage scenario, and the architecture for the ontology may be lacking. To avoid that pitfall we recommend orga- nizing and mapping the user stories into narratives that cover broader aspects or themes reflecting the desired functionality (i.e., usage scenarios, or mini concepts of operations). This will provide a “thread” that flows through a related set of capabilities, interactions, questions, or functions, as the basis for development of a particular use case, as well as for knitting the use cases together into a more cohesive architecture (Patton and Economy, 2014). The goal is to end up with a set of use cases that cover the desired features of the target system or ontology, and in the case of an ontology, that provide a representative set of competency questions, with sample answers that can be used for testing). 31 User stories are more fully described in Section 1.6.
- 49. 29 If your project uses an automated issue and project management system (e.g.,Trello32 (a free general tracking tool), or JIRA,33 a commercial tool aimed largely at software development projects but can also be used successfully for ontology development), every user story can be entered into that system and be identified for the purposes of requirements traceability. If you are using an even more formal requirements management system, then you should be able to (1) select one or more requirements, and (2) relate each requirement to one or more user stories, to ensure that you have good coverage. Every functional requirement must be covered by at least one user story and every user story must become part of one or more use cases. Ideally, you should already be able to say with some certainty what percentage of requirements coverage the use cases will provide, even before you flesh them out. You should also be able to use the use cases to discover gaps in the requirements and user stories, allowing you to go back to the stakeholders to iterate until coverage is largely complete. A traceability map, from the requirements and user stories to use cases, developed as a part of the requirements analysis process, is often helpful, and may be mandated by project stake- holders, depending on the project and methodology adopted by your organization. The traceability map can also act as an invaluable input for testing purposes. In an agile development environment, some subset of requirements/user stories can be selected for each sprint for a more iterative and incremental development approach. 3.2 GATHERING REFERENCES AND POTENTIALLY REUSABLE ONTOLOGIES Once you have seeded your initial use case(s) with the details you know, the next step is to start gathering resources you can use as the basis for terms, definitions, and relationships. The terms in the user stories and competency questions will provide guidance and additional content as you build out the use case, but your subject matter experts should be able to provide a list of relevant standards and other references to start with. The goal is to gather the best of a representatives set of : • controlled vocabularies and nomenclatures already available for the domain; • any well-known hierarchical and or taxonomic resources that are appropriate; • standard dictionaries for the domain, such as for financial applications, the Interna- tional Accounting Standards Board /Financial Accounting Standards Board (IASB/ FASB) glossaries, regulatory glossaries, and Barron’s dictionaries for finance and busi- ness terminology; and 32 https://trello.com. 33 https://www.atlassian.com/software/jira/. 3.2 GATHERING REFERENCES AND POTENTIALLY REUSABLE ONTOLOGIES
- 50. Another Random Scribd Document with Unrelated Content
- 51. canal bleu. Et le canal fléchissait avec la route, et entre les deux un talus vert suivait leurs contours. Des bouquets d’arbrisseaux croissaient de part et d’autre; et aussi loin que l’œil pouvait atteindre, on ne voyait que des marécages et l’ombre verdoyante. Parmi les taches des marais s’élevaient de petites huttes coniques et la longue route s’enfonçait directement dans les nuages sanglants du ciel. Là elle rencontra un petit garçon, dont les yeux étaient drôlement fendus, et qui halait le long du canal une lourde barque. Elle voulut lui demander s’il avait vu la reine; mais s’aperçut avec terreur qu’elle avait oublié le nom. Lors elle s’écria, et pleura, et tâta sa jarretière, en vain. Et elle s’écria plus fort, voyant qu’elle marchait sur la route de trois couleurs, faite de poussière jaune, d’un canal bleu, et d’un talus vert. De nouveau elle toucha les trois nœuds qu’elle avait noués, et sanglota. Et le petit garçon, pensant qu’elle souffrait et ne comprenant point sa douleur, cueillit au bord de la route jaune une pauvre herbe, qu’il lui mit dans la main. —La mandosiane guérit, dit-il. Voilà comment Lilly trouva sa reine vêtue de feuilles vertes. Elle la serra précieusement, et retourna aussitôt sur la longue route. Et le voyage de retour fut plus lent que l’autre, car Lilly était lasse. Il lui parut qu’elle marchait depuis des années. Mais elle était joyeuse, sachant qu’elle guérirait la pauvre Nan. Elle traversa la mer, où les vagues étaient monstrueuses. Enfin elle arriva dans le Devon, tenant l’herbe entre sa cotte et sa chemise. Et d’abord elle ne reconnut pas les arbres; et il lui parut que tous les bestiaux étaient changés. Et dans la grand’salle de la ferme, elle vit une vieille femme entourée d’enfants. Courant, elle demanda Nan. La vieille, surprise, considéra Lilly et dit: —Mais Nan est partie depuis longtemps, et mariée. —Et guérie? demanda joyeusement Lilly. —Guérie, oui, certes, dit la vieille.—Et toi, pauvre, n’es-tu pas Lilly?
- 52. —Oui, dit Lilly; mais quel âge puis-je donc avoir? —Cinquante ans, n’est-ce pas, grand’mère, crièrent les enfants: elle n’est pas tout à fait si vieille que toi. Et comme Lilly, lasse, souriait, le parfum très fort de la mandosiane la fit pâmer, et elle mourut sous le soleil. Ainsi Lilly alla chercher la reine Mandosiane et fut emportée par elle.
- 53. III Monelle
- 54. Rencontre de Monelle RENCONTRE DE MONELLE Je ne sais comment je parvins à travers une pluie obscure jusqu’à l’étrange étal qui m’apparut dans la nuit. J’ignore la ville et j’ignore l’année; je me souviens que la saison était pluvieuse, très pluvieuse. Il est certain que dans ce même temps des hommes trouvèrent par les routes de petits enfants vagabonds qui refusaient de grandir. Des fillettes de sept ans implorèrent à genoux pour que leur âge restât immobile, et la puberté semblait déjà mortelle. Il y eut des processions blanchâtres sous le ciel livide, et de petites ombres à peine parlantes exhortèrent le peuple puéril. Rien n’était désiré par elles qu’une ignorance perpétuée. Elles souhaitaient se vouer à des jeux éternels. Elles désespéraient du travail de la vie. Tout n’était que passé pour elles. En ces jours mornes, sous cette saison pluvieuse, très pluvieuse, j’aperçus les minces lumières filantes de la petite vendeuse de lampes. Je m’approchai sous l’auvent, et la pluie me courut sur la nuque tandis que je penchais la tête. Et je lui dis: —Que vendez-vous donc là, petite vendeuse, par cette triste saison de pluie? —Des lampes, me répondit-elle, seulement des lampes allumées.
- 55. —Et en vérité, lui dis-je, que sont donc ces lampes allumées, hautes comme le petit doigt et qui brûlent d’une lumière menue comme une tête d’épingle? —Ce sont, dit-elle, les lampes de cette saison ténébreuse. Et autrefois ce furent des lampes de poupée. Mais les enfants ne veulent plus grandir. Voilà pourquoi je leur vends ces petites lampes qui éclairent à peine la pluie obscure. —Et vivez-vous donc ainsi, lui dis-je, petite vendeuse vêtue de noir, et mangez-vous par l’argent que vous payent les enfants pour vos lampes? —Oui, dit-elle simplement. Mais je gagne bien peu. Car la pluie sinistre éteint souvent mes petites lampes, au moment où je les tends pour les donner. Et quand elles sont éteintes, les enfants n’en veulent plus. Personne ne peut les rallumer. Il ne me reste que celles-ci. Je sais bien que je ne pourrai en trouver d’autres. Et quand elles seront vendues, nous demeurerons dans l’obscurité de la pluie. —Est-ce donc la seule lumière, dis-je encore, de cette morne saison; et comment éclairerait-on, avec une si petite lampe, les ténèbres mouillées? —La pluie les éteint souvent, dit-elle, et dans les champs ou par les rues elles ne peuvent plus servir. Mais il faut s’enfermer. Les enfants abritent mes petites lampes avec leurs mains et s’enferment. Ils s’enferment chacun avec sa lampe et un miroir. Et elle suffit pour leur montrer leur image dans le miroir. Je regardai quelques instants les pauvres flammes vacillantes. —Hélas, dis-je, petite vendeuse, c’est une triste lumière, et les images des miroirs doivent être de tristes images. —Elles ne sont point si tristes, dit l’enfant vêtue de noir en secouant la tête, tant qu’elles ne grandissent pas. Mais les petites lampes que je vends ne sont pas éternelles. Leur flamme décroît, comme si elle s’affligeait de la pluie obscure. Et quand mes petites lampes s’éteignent, les enfants ne voient plus la lueur du miroir, et se désespèrent. Car ils craignent de ne pas savoir l’instant où ils vont grandir. Voilà pourquoi ils s enfuient en gémissant dans la nuit. Mais
- 56. il ne m’est permis de vendre à chaque enfant qu’une seule lampe. S’ils essaient d’en acheter une seconde, elle s’éteint dans leurs mains. Et je me penchai un peu plus vers la petite vendeuse, et je voulus prendre une de ses lampes. —Oh! il n’y faut pas toucher, dit-elle. Vous avez passé l’âge où mes lampes brûlent. Elles ne sont faites que pour les poupées ou les enfants. N’avez-vous point chez vous une lampe de grande personne? —Hélas! dis-je, par cette saison pluvieuse de pluie obscure, dans ce morne temps ignoré, il n’est plus que vos lampes d’enfant qui brûlent. Et je désirais, moi aussi, regarder encore une fois la lueur du miroir. —Venez, dit-elle, nous regarderons ensemble. Par un petit escalier vermoulu, elle me conduisit dans une chambre de bois simple où il y avait un éclat de miroir au mur. —Chut, dit-elle, et je vous montrerai. Car ma propre lampe est plus claire et plus puissante que les autres; et je ne suis pas trop pauvre parmi ces pluvieuses ténèbres. Et elle leva sa petite lampe vers le miroir. Alors il y eut un pâle reflet où je vis circuler des histoires connues. Mais la petite lampe mentait, mentait, mentait. Je vis la plume se soulever sur les lèvres de Cordelia; et elle souriait, et guérissait; et avec son vieux père elle vivait dans une grande cage comme un oiseau, et elle baisait sa barbe blanche. Je vis Ophélie jouer sur l’eau vitrée de l’étang, et attacher au cou d’Hamlet ses bras humides enguirlandés de violettes. Je vis Desdémone réveillée errer sous les saules. Je vis la princesse Maleine ôter ses deux mains des yeux du vieux roi, et rire, et danser. Je vis Mélisande, délivrée, se mirer dans la fontaine. Et je m’écriai: Petite lampe menteuse ... —Chut! dit la petite vendeuse de lampes, et me mit la main sur les lèvres. Il ne faut rien dire. La pluie n’est-elle pas assez obscure?
- 57. Alors je baissai la tête et je m’en allai vers la nuit pluvieuse dans la ville inconnue.
- 58. Monelle MONELLE Je ne sais pas où Monelle me prit par la main. Mais je pense que ce fut dans une soirée d’automne, quand la pluie est déjà froide. —Viens jouer avec nous, dit-elle. Monelle portait dans son tablier des vieilles poupées et des volants dont les plumes étaient fripées et les galons ternis. Sa figure était pâle et ses yeux riaient. —Viens jouer, dit-elle. Nous ne travaillons plus, nous jouons. Il y avait du vent et de la boue. Les pavés luisaient. Tout le long des auvents de boutique l’eau tombait, goutte à goutte. Des filles frissonnaient sur le seuil des épiceries. Les chandelles allumées semblaient rouges. Mais Monelle tira de sa poche un dé de plomb, un petit sabre d’étain, une balle de caoutchouc. —Tout cela est pour eux, dit-elle. C’est moi qui sors pour acheter les provisions. —Et quelle maison avez-vous donc, et quel travail, et quel argent, petite ... —Monelle, dit la fillette en me serrant la main. Ils m’appellent Monelle. Notre maison est une maison où on joue: nous avons chassé le travail, et les sous que nous avons encore nous avaient été
- 59. donnés pour acheter des gâteaux. Tous les jours je vais chercher des enfants dans la rue, et je leur parle de notre maison, et je les amène. Et nous nous cachons bien pour qu’on ne nous trouve pas. Les grandes personnes nous forceraient à rentrer et nous prendraient tout ce que nous avons. Et nous, nous voulons rester ensemble et jouer. —Et à quoi jouez-vous, petite Monelle? —Nous jouons à tout. Ceux qui sont grands se font des fusils et des pistolets; et les autres jouent à la raquette, sautent à la corde, se jettent la balle; ou les autres dansent des rondes et se prennent les mains; ou les autres dessinent sur les vitres les belles images qu’on ne voit jamais et soufflent des bulles de savon; ou les autres habillent leurs poupées et les mènent promener, et nous comptons sur les doigts des tout petits pour les faire rire. La maison où Monelle me conduisit paraissait avoir des fenêtres murées. Elle s’était détournée de la rue, et toute sa lumière venait d’un profond jardin. Et déjà là j’entendis des voix heureuses. Trois enfants vinrent sauter autour de nous. —Monelle, Monelle! criaient-ils, Monelle est revenue! Ils me regardèrent et murmurèrent: —Comme il est grand! Est-ce qu’il jouera, Monelle? Et la fillette leur dit: —Bientôt les grandes personnes viendront avec nous. Elles iront vers les petits enfants. Elles apprendront à jouer. Nous leur ferons la classe, et dans notre classe on ne travaillera jamais. Avez-vous faim? Des voix crièrent: —Oui, oui, oui il faut faire la dînette. Alors furent apportées des petites tables rondes, et des serviettes grandes comme des feuilles de lilas, et des verres profonds comme des dés à coudre, et des assiettes creuses comme des coquilles de noix. Le repas fut de chocolat et de sucre en miettes; et le vin ne
- 60. pouvait pas couler dans les verres, car les petites fioles blanches, longues comme le petit doigt, avaient le cou trop mince. La salle était vieille et haute. Partout brûlaient des petites chandelles vertes et roses dans les chandeliers d’étain minuscules. Contre les murs, les petites glaces rondes paraissaient des pièces de monnaie changées en miroirs. On ne reconnaissait les poupées d’entre les enfants que par leur immobilité. Car elles restaient assises dans leurs fauteuils, ou se coiffaient, les bras levés, devant de petites toilettes, ou elles étaient déjà couchées, le drap ramené jusqu’au menton, dans leurs petits lits de cuivre. Et le sol était jonché de la fine mousse verte qu’on met dans les bergeries de bois. Il semblait que cette maison fût une prison ou un hôpital. Mais une prison où on enfermait des innocents pour les empêcher de souffrir, un hôpital où on guérissait du travail de la vie. Et Monelle était la geôlière et l’infirmière. La petite Monelle regardait jouer les enfants. Mais elle était très pâle. Peut-être avait-elle faim. —De quoi vivez-vous, Monelle, lui dis-je tout à coup. Et elle me répondit simplement: —Nous ne vivons de rien. Nous ne savons pas. Aussitôt elle se prit à rire. Mais elle était très faible. Et elle s’assit au pied du lit d’un enfant qui était malade. Elle lui tendit une des petites bouteilles blanches, et resta longtemps penchée, les lèvres entr’ouvertes. Il y avait des enfants qui dansaient une ronde et qui chantaient à voix claire. Monelle leva un peu la main, et dit: —Chut! Puis elle parla doucement, avec ses petites paroles. Elle dit: —Je crois que je suis malade. Ne vous en allez pas. Jouez autour de moi. Demain, une autre ira chercher de beaux jouets. Je resterai avec vous. Nous nous amuserons sans faire de bruit. Chut! Plus tard
- 61. nous jouerons dans les rues et dans les champs, et on nous donnera à manger dans toutes les boutiques. Maintenant on nous forcerait à vivre comme les autres. Il faut attendre. Nous aurons beaucoup joué. Monelle dit encore: —Aimez-moi bien. Je vous aime tous. Puis elle parut s’endormir près de l’enfant malade. Tous les autres enfants la regardaient, la tête avancée. Il y eut une petite voix tremblante qui dit faiblement: «Monelle est morte.» Et il se fit un grand silence. Les enfants apportèrent autour du lit les petites chandelles allumées. Et, pensant qu’elle dormait peut-être, ils rangèrent devant elle, comme pour une poupée, de petits arbres vert-clair taillés en pointe et les placèrent parmi les moutons de bois blanc pour la regarder. Ensuite ils s’assirent et la guettèrent. Un peu de temps après, l’enfant malade, sentant que la joue de Monelle devenait froide, se mit à pleurer.
- 62. Fuite de Monelle FUITE DE MONELLE Il y avait un enfant qui avait eu coutume de jouer avec Monelle. C’était au temps ancien, quand Monelle n’était pas encore partie. Toutes les heures du jour, il les passait auprès d’elle, regardant trembler ses yeux. Elle riait sans cause et il riait sans cause. Quand elle dormait, ses lèvres entr’ouvertes étaient en travail de bonnes paroles. Quand elle s’éveillait, elle se souriait, sachant qu’il allait venir. Ce n’était pas un véritable jeu qu’on jouait: car Monelle était obligée de travailler. Si petite, elle restait assise tout le jour derrière une vieille vitre pleine de poussière. La muraille d’en face était aveuglée de ciment, sous la triste lumière du nord. Mais les petits doigts de Monelle couraient dans le linge, comme s’ils trottaient sur une route de toile blanche et les épingles piquées sur ses genoux marquaient les relais. La main droite était ramassée comme un petit chariot de chair, et elle avançait, laissant derrière elle un sillon ourlé; et crissant, crissant, l’aiguille dardait sa langue d’acier, plongeait et émergeait, tirant le long fil par son œil d’or. Et la main gauche était bonne à voir, parce qu’elle caressait doucement la toile neuve, et la soulageait de tous ses plis, comme si elle avait bordé en silence les draps frais d’un malade.
- 63. Ainsi l’enfant regardait Monelle et se réjouissait sans parler, car son travail semblait un jeu, et elle lui disait des choses simples qui n’avaient point beaucoup de sens. Elle riait au soleil, elle riait à la pluie, elle riait à la neige. Elle aimait être chauffée, mouillée, gelée. Si elle avait de l’argent, elle riait, pensant qu’elle irait danser avec une robe nouvelle. Si elle était misérable, elle riait, pensant qu’elle mangerait des haricots, une grosse provision pour une semaine. Et elle songeait, ayant des sous, à d’autres enfants qu’elle ferait rire; et elle attendait, sa petite main vide, de pouvoir se pelotonner et se nicher dans sa faim et sa pauvreté. Elle était toujours entourée d’enfants qui la considéraient avec des yeux élargis. Mais elle préférait peut-être l’enfant qui venait passer près d’elle les heures du jour. Cependant elle partit et le laissa seul. Elle ne lui parla jamais de son départ, sinon qu’elle devint plus grave, et le regarda plus longtemps. Et il se souvint aussi qu’elle cessa d’aimer tout ce qui l’entourait: son petit fauteuil, les bêtes peintes qu’on lui apportait, et tous ses jouets, et tous ses chiffons. Et elle rêvait, le doigt sur la bouche, à d’autres choses. Elle partit dans un soir de décembre, quand l’enfant n’était pas là. Portant à la main sa petite lampe haletante, elle entra, sans se retourner, dans les ténèbres. Comme l’enfant arrivait, il aperçut encore à l’extrémité noire de la rue étroite une courte flamme qui soupirait. Ce fut tout. Il ne revit jamais Monelle. Longtemps il se demanda pourquoi elle était partie sans rien dire. Il pensa qu’elle n’avait pas voulu être triste de sa tristesse. Il se persuada qu’elle était allée vers d’autres enfants, qui avaient besoin d’elle. Avec sa petite lampe agonisante, elle était allée leur porter secours, le secours d’une flammèche rieuse dans la nuit. Peut-être avait-elle songé qu’il ne fallait pas l’aimer trop lui seul, afin de pouvoir aimer aussi d’autres petits inconnus. Peut-être l’aiguille avec son œil d’or ayant tiré le petit chariot de chair jusqu’au bout, jusqu’à l’extrême bout du sillon ourlé, Monelle était-elle devenue lasse de la route écrue de toile où trottaient ses mains. Sans doute elle avait voulu jouer éternellement. Et l’enfant n’avait point su le moyen du
- 64. jeu éternel. Peut-être avait-elle désiré enfin voir ce qu’il y avait derrière la vieille muraille aveugle, dont tous les yeux étaient fermés, depuis les années, avec du ciment. Peut-être qu’elle allait revenir. Au lieu de dire «au revoir,—attends-moi,—sois sage!» pour qu’il épiât le bruit de petits pas dans le corridor et le cliquètement de toutes les clés dans les serrures, elle s’était tue, et viendrait, par surprise, dans son dos, mettre deux menottes tièdes sur ses yeux—ah oui!—et crierait: «coucou!» avec la voix de l’oisillon revenu près du feu. Il se rappela le premier jour qu’il la vit, sautillant comme une frêle blancheur flamboyante toute secouée de rire. Et ses yeux étaient des yeux d’eau où les pensées se mouvaient comme des ombres de plantes. Là, au détour de la rue, elle était venue, bonnement. Elle avait ri, avec des éclats lents et plus lents, semblables à la vibration cessante d’une coupe de cristal. C’était au crépuscule d’hiver, et il y avait du brouillard; cette boutique était ouverte—ainsi. Le même soir, les mêmes choses autour, le même bourdon aux oreilles: l’année différente et l’attente. Il avançait avec précaution; toutes les choses étaient pareilles, comme la première fois; mais il l’attendait: n’était-ce pas une raison pour qu’elle vînt? Et il tendait sa pauvre main ouverte à travers le brouillard. Cette fois, Monelle ne sortit pas de l’inconnu. Aucun petit rire n’agita la brume. Monelle était loin, et ne se souvenait plus du soir ni de l’année. Qui sait? Elle s’était glissée peut-être à la nuit dans la chambrette inhabitée, et le guettait derrière la porte avec un tressaillement doux. L’enfant marcha sans bruit, pour la surprendre. Mais elle n’était plus là. Elle allait revenir,—oh! oui,—elle allait revenir. Les autres enfants avaient eu assez de bonheur d’elle. C’était à son tour, maintenant. L’enfant entendit sa voix malicieuse murmurant: «Je suis sage aujourd’hui!» Petite parole disparue, lointaine, effacée comme une ancienne teinte, usée déjà par les échos du souvenir.
- 65. L’enfant s’assit patiemment. Là était le petit fauteuil d’osier, marqué de son corps, et le tabouret qu’elle aimait, et la petite glace plus chérie parce qu’elle était cassée, et la dernière chemisette qu’elle avait cousue, la chemisette «qui s’appelait Monelle», dressée, un peu gonflée, attendant sa maîtresse. Toutes les petites choses de la chambre l’attendaient. La table à ouvrage était restée ouverte. Le petit mètre dans sa boîte ronde allongeait sa langue verte, percée d’un anneau. La toile dépliée des mouchoirs se soulevait en petites collines blanches. Les pointes des aiguilles se dressaient derrière, semblables à des lances embusquées. Le petit dé de fer ouvragé était un chapeau d’armes abandonné. Les ciseaux ouvraient indolemment la gueule comme un dragon d’acier. Ainsi tout dormait dans l’attente. Le petit chariot de chair, souple et agile, ne circulait plus, versant sur ce monde enchanté sa tiède chaleur. Tout l’étrange petit château de travail sommeillait. L’enfant espérait. La porte allait s’ouvrir, doucement; la flammèche rieuse volèterait; les collines blanches s’étaleraient; les fines lances se choqueraient; le chapeau d’armes retrouverait sa tête rose; le dragon d’acier claquerait rapidement de la gueule, et le petit chariot de chair trottinerait partout, et la voix effacée dirait encore: «Je suis sage aujourd’hui!»—Est-ce que les miracles n’arrivent pas deux fois?
- 66. Patience de Monelle PATIENCE DE MONELLE J’arrivai dans un lieu très étroit et obscur, mais parfumé d’une odeur triste de violettes étouffées. Et il n’y avait nul moyen d’éviter cet endroit, qui est comme un long passage. Et, tâtonnant autour de moi, je touchai un petit corps ramassé comme jadis dans le sommeil, et je frôlai des cheveux, et je passai la main sur une figure que je connaissais, et il me parut que la petite figure se fronçait sous mes doigts, et je reconnus que j’avais trouvé Monelle qui dormait seule en ce lieu obscur. Je m’écriai de surprise, et je lui dis, car elle ne pleurait ni ne riait: —O Monelle! es-tu donc venue dormir ici, loin de nous, comme une patiente gerboise dans le creux du sillon? Et elle élargit ses yeux et entr’ouvrit ses lèvres, comme autrefois, lorsqu’elle ne comprenait point, et qu’elle implorait l’intelligence de celui qu’elle aimait. —O Monelle, dis-je encore, tous les enfants pleurent dans la maison vide; et les jouets se couvrent de poussière, et la petite lampe s’est éteinte, et tous les rires qui étaient dans tous les coins se sont enfuis, et le monde est retourné au travail. Mais nous te pensions ailleurs. Nous pensions que tu jouais loin de nous, en un lieu où nous ne pouvons parvenir. Et voici que tu dors, nichée comme un petit animal sauvage, au-dessous de la neige que tu aimais pour sa blancheur.
- 67. Alors elle parla, et sa voix était la même, chose étrange, en ce lieu obscur, et je ne pus m’empêcher de pleurer, et elle essuya mes larmes avec ses cheveux, car elle était très dénuée. —O mon chéri, dit-elle, il ne faut point pleurer; car tu as besoin de tes yeux pour travailler, tant qu’on vivra en travaillant, et les temps ne sont pas venus. Et il ne faut pas rester en ce lieu froid et obscur. Et je sanglotai alors et lui dis: —O Monelle, mais tu craignais les ténèbres? —Je ne les crains plus, dit-elle. —O Monelle, mais tu avais peur du froid comme de la main d’un mort? —Je n’ai plus peur du froid, dit-elle. —Et tu es toute seule ici, toute seule, étant enfant, et tu pleurais quand tu étais seule. —Je ne suis plus seule, dit-elle; car j’attends. —O Monelle, qui attends-tu, dormant roulée en ce lieu obscur? —Je ne sais pas, dit-elle; mais j’attends. Et je suis avec mon attente. Et je m’aperçus alors que tout son petit visage était tendu vers une grande espérance. —Il ne faut pas rester ici, dit-elle encore, en ce lieu froid et obscur, mon aimé; retourne vers tes amis. —Ne veux-tu point me guider et m’enseigner, Monelle, pour que j’aie aussi la patience de ton attente? Je suis si seul! —O mon aimé, dit-elle, je serais malhabile à t’enseigner comme autrefois, quand j’étais, disais-tu, une petite bête; ce sont des choses que tu trouveras sûrement par longue et laborieuse réflexion, ainsi que je les ai vues tout d’un coup pendant que je dors. —Es-tu nichée ainsi, Monelle, sans le souvenir de ta vie passée, ou te souviens-tu encore de nous? —Comment pourrais-je, mon aimé, t’oublier? Car vous êtes dans mon attente, contre laquelle je dors; mais je ne puis expliquer. Tu te
- 68. rappelles, j’aimais beaucoup la terre, et je déracinais les fleurs pour les replanter; tu te rappelles, je disais souvent: «si j’étais un petit oiseau, tu me mettrais dans ta poche, quand tu partirais.» O mon aimé, je suis ici dans la bonne terre, comme une graine noire, et j’attends d’être petit oiseau. —O Monelle, tu dors avant de t’envoler très loin de nous. —Non, mon aimé, je ne sais si je m’envolerai; car je ne sais rien. Mais je suis roulée en ce que j’aimais, et je dors contre mon attente. Et avant de m’endormir, j’étais une petite bête, comme tu disais, car j’étais pareille à un vermisseau nu. Un jour nous avons trouvé ensemble un cocon tout blanc, tout soyeux, et qui n’était percé d’aucun trou. Méchant, tu l’as ouvert, et il était vide. Penses-tu que la petite bête ailée n’en était pas sortie? Mais personne ne peut savoir comment. Et elle avait dormi longtemps. Et avant de dormir elle avait été un petit ver nu; et les petits vers sont aveugles. Figure- toi, mon aimé (ce n’est pas vrai, mais voilà comme je pense souvent) que j’ai tissé mon petit cocon avec ce que j’aimais, la terre, les jouets, les fleurs, les enfants, les petites paroles, et le souvenir de toi, mon aimé; c’est une niche blanche et soyeuse, et elle ne me paraît pas froide ni obscure. Mais elle n’est peut-être pas ainsi pour les autres. Et je sais bien qu’elle ne s’ouvrira point, et qu’elle restera fermée comme le cocon d’autrefois. Mais je n’y serai plus, mon aimé. Car mon attente est de m’en aller, ainsi que la petite bête ailée; personne ne peut savoir comment. Et où je veux aller, je n’en sais rien; mais c’est mon attente. Et les enfants aussi, et toi, mon aimé, et le jour où on ne travaillera plus sur terre sont mon attente. Je suis toujours une petite bête, mon aimé; je ne sais pas mieux expliquer. —Il faut, il faut, dis-je, que tu sortes avec moi de ce lieu obscur, Monelle; car je sais que tu ne penses pas ces choses; et tu t’es cachée pour pleurer; et puisque je t’ai trouvée enfin toute seule, dormant ici, toute seule, attendant ici, viens avec moi, viens avec moi, hors de ce lieu obscur et étroit. —Ne reste pas, ô mon aimé, dit Monelle, car tu souffrirais beaucoup; et moi, je ne peux venir, car la maison que je me suis tissée est toute fermée, et ce n’est point ainsi que j’en sortirai.
- 69. Alors Monelle mit ses bras autour de mon cou, et son baiser fut pareil, chose étrange, à ceux d’autrefois, et voilà pourquoi je pleurai encore, et elle essuya mes larmes avec ses cheveux. —Il ne faut pas pleurer, dit-elle, si tu ne veux m’affliger dans mon attente; et peut-être n’attendrai-je pas si longtemps. Ne sois donc plus désolé. Car je te bénis de m’avoir aidée à dormir dans ma petite niche soyeuse dont la meilleure soie blanche est faite de toi, et où je dors maintenant, roulée sur moi-même. Et comme autrefois, dans son sommeil, Monelle se pelotonna contre l’invisible et me dit: «Je dors, mon aimé.» Ainsi, je la trouvai; mais comment serai-je sûr de la retrouver dans ce lieu très étroit et obscur?
- 70. Le royaume de Monelle LE ROYAUME DE MONELLE Je lisais cette nuit-là et mon doigt suivait les lignes et les mots; mes pensées étaient ailleurs. Et autour de moi tombait une pluie noire, oblique et acérée. Et le feu de ma lampe éclairait les cendres froides de l’âtre. Et ma bouche était pleine d’un goût de souillure et de scandale; car le monde me semblait obscur et mes lumières étaient éteintes. Et trois fois je m’écriai: «—Je voudrais tant d’eau bourbeuse pour étancher ma soif d’infamie. O je suis avec le scandaleux: tendez vos doigts vers moi! Il faut les frapper de boue, car ils ne me méprisent point. Et les sept verres pleins de sang m’attendront sur la table et la lueur d’une couronne d’or étincellera parmi.» Mais une voix retentit, qui ne m’était point étrangère, et le visage de celle qui parut ne m’était point inconnu. Et elle criait ces paroles: —Un royaume blanc! un royaume blanc! je connais un royaume blanc! Et je détournai la tête, et lui dis, sans surprise: —Petite tête menteuse, petite bouche qui ment, il n’est plus de rois ni de royaumes. Je désire vainement un royaume rouge: car le temps est passé. Et ce royaume-ci est noir, mais ce n’est point un
- 71. royaume; car un peuple de rois ténébreux y agitent leurs bras. Et il n’y a nulle part dans le monde un royaume blanc, ni un roi blanc. Mais elle cria de nouveau ces paroles: —Un royaume blanc! un royaume blanc! je connais un royaume blanc! Et je voulus lui saisir la main; mais elle m’éluda. —Ni par la tristesse, dit-elle, ni par la violence. Cependant il y a un royaume blanc. Viens avec mes paroles; écoute. Et elle demeura silencieuse; et je me souvins. —Ni par le souvenir, dit-elle. Viens avec mes paroles; écoute. Et elle demeura silencieuse; et je m’entendis penser. —Ni par la pensée, dit-elle. Viens avec mes paroles; écoute. Et elle demeura silencieuse. Alors je détruisis en moi la tristesse de mon souvenir, et le désir de ma violence, et toute mon intelligence disparut. Et je restai dans l’attente. —Voici, dit-elle, et tu verras le royaume, mais je ne sais si tu y entreras. Car je suis difficile à comprendre, sauf pour ceux qui ne comprennent pas; et je suis difficile à saisir, sauf pour ceux qui ne saisissent plus; et je suis difficile à reconnaître, sauf pour ceux qui n’ont point de souvenir. En vérité, voici que tu m’as, et tu ne m’as plus. Écoute. Alors j’écoutai dans mon attente. Mais je n’entendis rien. Et elle secoua la tête et me dit: —Tu regrettes ta violence et ton souvenir, et la destruction n’en est point achevée. Il faut détruire pour obtenir le royaume blanc. Confesse-toi et tu seras délivré; remets entre mes mains ta violence et ton souvenir, et je les détruirai; car toute confession est une destruction. Et je m’écriai: —Je te donnerai tout, oui, je te donnerai tout. Et tu le porteras et tu l’anéantiras, car je ne suis plus assez fort.
- 72. J’ai désiré un royaume rouge. Il y avait des rois sanglants qui affilaient leurs lames. Des femmes aux yeux noircis pleuraient sur des jonques chargées d’opium. Plusieurs pirates enterraient dans le sable des îles des coffres lourds de lingots. Toutes les prostituées étaient libres. Les voleurs croisaient les routes sous le blême de l’aube. Beaucoup de filles jeunes se gavaient de gourmandise et de luxure. Une troupe d’embaumeuses dorait des cadavres dans la nuit bleue. Les enfants désiraient des amours lointaines et des meurtres ignorés. Des corps nus jonchaient les dalles des étuves chaudes. Toutes choses étaient frottées d’épices ardentes et éclairées de cierges rouges. Mais ce royaume s’est enfoncé sous la terre, et je me suis éveillé au milieu des ténèbres. Et alors j’ai eu un royaume noir qui n’est pas un royaume: car il est plein de rois qui se croient des rois et qui l’obscurcissent de leurs œuvres et de leurs commandements. Et une sombre pluie le trempe nuit et jour. Et j’ai erré longtemps par les chemins, jusqu’à la petite lueur d’une lampe tremblante qui m’apparut au centre de la nuit. La pluie mouillait ma tête; mais j’ai vécu sous la petite lampe. Celle qui la tenait se nommait Monelle, et nous avons joué tous deux dans ce royaume noir. Mais un soir la petite lampe s’est éteinte, et Monelle s’est enfuie. Et je l’ai cherchée longtemps parmi ces ténèbres: mais je ne puis la retrouver. Et ce soir je la cherchais dans les livres; mais je la cherche en vain. Et je suis perdu dans le royaume noir; et je ne puis oublier la petite lueur de Monelle. Et j’ai dans la bouche un goût d’infamie. Et sitôt que j’eus parlé, je sentis que la destruction s’était faite en moi, et mon attente s’éclaira d’un tremblement et j’entendis les ténèbres et sa voix disait: —Oublie toutes choses et toutes choses te seront rendues. Oublie Monelle et elle te sera rendue. Telle est la nouvelle parole. Imite le tout petit chien, dont les yeux ne sont pas ouverts et qui cherche à tâtons une niche pour son museau froid. Et celle qui me parlait cria:
- 73. —Un royaume blanc! un royaume blanc! Je connais un royaume blanc! Et je fus accablé d’oubli, et mes yeux s’irradièrent de candeur. Et celle qui me parlait cria: —Un royaume blanc! un royaume blanc! Je connais un royaume blanc! Et l’oubli pénétra en moi et la place de mon intelligence devint profondément candide. Et celle qui me parlait cria encore: —Un royaume blanc! un royaume blanc! Je connais un royaume blanc! Voici la clef du royaume: dans le royaume rouge est un royaume noir; dans le royaume noir est un royaume blanc; dans le royaume blanc ... —Monelle, criai-je, Monelle! Dans le royaume blanc est Monelle! Et le royaume parut; mais il était muré de blancheur. Alors je demandai: —Et où est la clef du royaume? Mais celle qui me parlait demeura taciturne.
- 74. Résurrection de Monelle RÉSURRECTION DE MONELLE Louvette me conduisit par un sillon vert jusqu’à la lisière du champ. La terre s’élevait plus loin, et à l’horizon une ligne brune coupait le ciel. Déjà les nuages enflammés penchaient vers le couchant. A la lueur incertaine du soir, je distinguai de petites ombres errantes. —Tout à l’heure, dit-elle, nous verrons s’allumer le feu. Et demain, ce sera plus loin. Et le jour suivant, plus loin. Car ils ne demeurent nulle part. Et ils n’allument qu’un feu en chaque endroit. —Qui sont-ils? demandai-je à Louvette? —On ne sait pas. Ce sont des enfants vêtus de blanc. Il y en a qui sont venus de nos villages. Et d’autres marchent depuis longtemps. Nous vîmes briller une petite flamme qui dansait sur la hauteur. —Voilà leur feu, dit Louvette. Maintenant nous pourrons les trouver. Car ils séjournent la nuit où ils ont fait leur foyer, et le jour suivant ils quittent la contrée. Et quand nous arrivâmes à la rête où brûlait la flamme, nous aperçûmes beaucoup d’enfants blancs autour du feu.
- 75. Et parmi eux, semblant leur parler et les guider, je reconnus la petite vendeuse de lampes que j’avais rencontrée autrefois dans la cité noire et pluvieuse. Elle se leva d’entre les enfants, et me dit: —Je ne vends plus les petites lampes menteuses qui s’éteignaient sous la pluie morne. Car les temps sont venus où le mensonge a pris la place de la vérité, où le travail misérable a péri. Nous avons joué dans la maison de Monelle; mais les lampes étaient des jouets et la maison un asile. Monelle est morte; je suis la même Monelle, et je me suis levée dans la nuit, et les petits sont venus avec moi, et nous irons à travers le monde. Elle se tourna vers Louvette: —Viens avec nous, dit-elle, et sois heureuse dans le mensonge. Et Louvette courut parmi les enfants et fut vêtue pareillement de blanc. —Nous allons, reprit celle qui nous guidait, et nous mentons à tout venant afin de donner de la joie. Nos jouets étaient des mensonges, et maintenant les choses sont nos jouets. Parmi nous, personne ne souffre et personne ne meurt: nous disons que ceux-là s’efforcent de connaître la triste vérité, qui n’existe nullement. Ceux qui veulent connaître la vérité s’écartent et nous abandonnent. Au contraire, nous n’avons aucune foi dans les vérités du monde; car elles conduisent à la tristesse. Et nous voulons mener nos enfants vers la joie. Maintenant les grandes personnes pourront venir vers nous, et nous leur enseignerons l’ignorance et l’illusion.