Ontology Engineering. Elisa F. Kendall

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 increasing 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 ontology 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

       Contents

      Foreword by Dean Allemang

      Foreword by Richard Mark Soley, Ph.D

       Preface

       1 Foundations

       1.1 Background and Definitions

       1.2 Logic and Ontological Commitment

       1.3 Ontology-Based Capabilities

       1.4 Knowledge Representation Languages

       1.4.1 Description Logic Languages

       1.5 Knowledge Bases, Databases, and Ontology

       1.6 Reasoning, Truth Maintenance, and Negation

       1.7 Explanations and Proof

       2 Before You Begin

       2.1 Domain Analysis

       2.2 Modeling and Levels of Abstraction

       2.3 General Approach to Vocabulary Development

       2.4 Business Vocabulary Development

       2.5 Evaluating Ontologies

       2.6 Ontology Design Patterns

       2.7 Selecting a Language

       3 Requirements and Use Cases

       3.1 Getting Started

       3.2 Gathering References and Potentially Reusable Ontologies

       3.3 A Bit About Terminology

       3.4 Summarizing the Use Case

       3.5 The “Body” of the Use Case

       3.6 Creating Usage Scenarios

       3.7 Flow of Events

       3.8 Competency Questions

       3.9 Additional Resources

       3.10 Integration with Business and Software Requirements

       4 Terminology

       4.1 How Terminology Work Fits into Ontology Engineering

       4.2 Laying the Groundwork

       4.3 Term Excerption and Development

       4.4 Terminology Analysis and Curation

       4.4.1 Concept Labeling

       4.4.2 Definitions

       4.4.3 Synonyms

       4.4.4 Identifiers and Identification Schemes

       4.4.5 Classifiers and Classification Schemes

       4.4.6 Pedigree and Provenance

       4.4.7 Additional Notes (Annotations)

       4.5 Mapping Terminology Annotations to Standard Vocabularies

       5 Conceptual Modeling

       5.1 Overview

       5.2 Getting Started

       5.3 Identifying Reusable Ontologies

       5.4 Preliminary Domain Modeling

       5.5 Naming Conventions for Web-Based Ontologies

       5.6 Metadata for Ontologies and Model Elements

       5.7 General Nature of Descriptions

       5.8 Relationships and Properties

       5.9 Individuals and Data Ranges

       5.10 Other Common Constructs

       6 Conclusion

       Bibliography

       Author’s Biographies

       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, beyond 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