Ontology Engineering. Elisa F. Kendall

Чтение книги онлайн.

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