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 ontology 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 translation 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 usable 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-decade-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 currently 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 connections. 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.
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.
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 methodology 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, definitions, and relationships between them with subject matter experts through the development process. 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, deployment, 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 professor of computer and cognitive science. We needed a reference we could use for that course as well 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, terminology 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 Hendler, 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 targeted 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
