ONTOLOGIES ARE EVERYWHERE
We can’t order merchandize online, stream a movie, search the Web, or access social media without interacting with software that uses ontologies. Most of the software that surrounds us and that we often take for granted has at its core ontologies—almost always taken for granted—that characterize the merchandize, the movies, the websites, the users, and everything else that the software needs to compute about. Whether they are actually called ontologies, or product catalogs, or knowledge graphs, data structures that capture models of the entities in the world with which a system interacts are critical components of modern computing technologies.
But ontologies sure are hard to build. Understanding how the entities in some application area might be modeled, how they might interrelate with one another, and how they might be captured in software is really difficult. The problem is exacerbated because the standard computer language for representing ontologies—OWL—is complex and often nonintuitive. OWL causes all kinds of problems for new ontology engineers. In OWL, it’s easy to infer that left is right and that up is down, unless you are extremely careful. An OWL ontology that states that an opera is a play in which all the words are sung will also classify as an opera a pantomime—a play that has no words at all! If you’re not vigilant, OWL might tell you that a gall bladder is a golf club or that a toothbrush is a sonnet.
Why do we put up with this nonsense? We use OWL because it has many useful properties that allow us to understand the implications of our modeling choices, enabling us to have more confidence that we have modeled things correctly. We also use OWL because it has become an international standard. Before OWL became a recommendation of the World Wide Web Consortium, there was no prevailing language for encoding ontologies, no easy way to integrate ontologies, and few widely used tools for building ontologies. That chaos disappeared with the advent of OWL. Standardization simplified many practical aspects of ontology engineering and allowed the ontology-development community to share ontology content, ontology-engineering systems, and best practices for ontology engineering on a broad scale.
The Protégé ontology editor developed by my group at Stanford University was the first widely used tool for building ontologies in OWL, and it remains the only open-source platform that supports OWL-based ontology development that is in common use. Over the years, we’ve continued to enhance Protégé with additional features that, we believe, help users to deal with many of the complexities of ontology engineering in OWL. But none of these features overcomes the basic problem that description logics in general, and OWL in particular, have elements that are unintuitive and hard to learn.
I teach about OWL at Stanford, and students who are new to the language always seem to end up building ontologies that classify toothbrushes as sonnets, scratching their heads trying to figure out why. OWL’s “open world assumption” and its somewhat arcane methods for defining the characteristics of the entities in a model are initially hard to grasp. Students are confused that language developers would choose to make things so difficult and complicated. They persevere, however, because they appreciate the importance of ontology engineering in the development of many modern software systems and the critical role that ontologies play in many modern professional activities, particularly in the sciences. Students still struggle, both because the syntax is difficult and because the implications of their modeling choices are often hard to predict. As an instructor, I have been frustrated that there is no easy way to teach students the basic components of knowledge modeling in OWL other than to sit them down in front of an ontology editor such as Protégé and ask them to represent the essential features of a toothbrush or a golf club. To date, all the writings about OWL have come from scientists in the description-logic community whose main objectives have been completeness and accuracy rather than pedagogy and understanding. The literature is thus one written by experts for experts, leaving novice learners to stare helplessly at pages of complex equations and at unpronounceable abbreviations such as SHOIN and SHROIQ, always set in ridiculous fonts.
This book is different. It clearly “demystifies” OWL by distilling the language to its very basic features and by presenting clear, easy-to-follow examples. The emphasis is on communicating clearly the core elements of the language, rather than on expansiveness and logical rigor. This volume is an important contribution, coming at an important time, as ontologies enter the mainstream of software engineering and are no longer in the exclusive domain of highly specialized experts.
This book marks an important transition. At last, there is recognition that ontologies are often being constructed in the course of routine software development. It is now apparent that there is a need for more traditional software engineers to be able to create ontologies and to render them in OWL, the representation language that has now entered standard usage. This is a natural evolution in the trend toward translation of human knowledge into computable forms, enabling new technologies to interact with people and to communicate human ideas in novel ways. Most people don’t think critically about the ontologies that allow them to find the products that they want online or that suggest the content in which they might be interested on social media; their interactions with these ontologies come naturally and implicitly. Similarly, the software engineers who build these semantically aware systems should not get hung up on the complexities or enigmatic properties of OWL; their work to model and represent ontologies should come just as instinctively.
It’s about time that OWL became demystified. The next generation of intelligent software systems depends on it.
Mark A. Musen
Palo Alto, California