Ontology Engineering. Elisa F. KendallЧитать онлайн книгу.
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 continually 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 postulate 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 information 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, performed 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. Library science. Search engine optimization. Data modeling. Software design and methodology. Ontology 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 management. 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
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 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