In the first two chapters, we introduced the 30% of OWL that gets used 90% of the time. Everything was motivated by commercially relevant examples. You now have just enough knowledge to be dangerous. The goal of this chapter is to keep everyone safe. We step back and consider some fundamental concepts that are important for understanding the use of OWL for building ontologies. This will prepare you to dive into the details of OWL in subsequent chapters.

We report on ten years of experience building enterprise ontologies for commercial clients. We describe key properties that an enterprise ontology should have, and illustrate them with many real world examples. They are: correctness, understandability, usability, and completeness. We give tips and guidelines for how best to use inference and explanations to identify and track down problems. We describe a variety of techniques that catch bugs that an inference engine will not find, at least not on its own. We describe the importance of populating the ontology with data to drive out more bugs. We point out some common ontology design practices in the community that lead to bugs in ontologies and in downstream semantic web applications based on the ontologies. These include proliferation of namespaces, proliferation of properties and inappropriate use of domain and range. We recommend doing things differently to prevent bugs from arising.

This paper analyzes the similarities and differences between an ontology (focused on meaning), and a database schema (focused on data). We address questions about purpose, representation, creation, usage and semantics of each. We distill out twenty-five features that characterize these two representational artifacts, the majority of which are relevant to both. Each has a strong semantic heritage using formal logic to build conceptual models of some subject matter. And while there are differences in 90% of the features, the differences are mostly historical, not technical. We identify pros and cons for each, and notice that there is usually no free lunch. The disadvantage that you think you are getting rid of may show up elsewhere in a different and unexpected way. We close by considering how ontology contributes to enterprise data integration. The emergence of using URIs as global identifiers (e.g. in OWL) dramatically enhances data integration as well as schema reuse and sharing. The primary focus on meaning helps ontology break through a lot of unnecessary complexity that exists in large traditional databases and greatly simplifies the process of integration. Ontology is providing a glimmer of light at the end of the tunnel for enterprise-wide data integration.

The goal of the 2011 Ontology Summit was to assist in making the case for the use of ontology by providing concrete application examples, success/value metrics and advocacy strategies. This communique provides tips, guidelines and strategies for making the case for ontology to a variety of potential beneficiaries and future stakeholders. This communique specifically targets ontology technology evangelists who already get the value but want to overcome the blank stares they get when trying to explain it to people who do not.

We trace the roots of ontology-drive information systems (ODIS) back to early work in artificial intelligence and software engineering. We examine the lofty goals of the Knowledge-Based Software Assistant project from the 80s, and pose some questions. Why didn't it work? What do we have today instead? What is on the horizon? We examine two critical ideas in software engineering: raising the level of abstraction, and the use of formal methods. We examine several other key technologies and show how they paved the way for today's ODIS. We identify two companies with surprising capabilities that are on the bleeding edge of today's ODIS, and are pointing the way to a bright future. In that future, application development will be opened up to the masses, who will require no computer science background. People will create models in visual environments and the models will be the applications, self-documenting and executing as they are being built. Neither humans nor computers will be writing application code. Most functionality will be created by reusing and combining pre-coded functionality. All application software will be ontology-driven.

The most widely accepted defining feature of the semantic web is machine-usable content. By this definition, the semantic web is already manifest in shopping agents that automatically access and use web content to find the lowest air fares or book prices. However, where are the semantics? Most people regard the semantic web as a vision, not a reality--so shopping agents should not "count." To use web content, machines need to know what to do when they encounter it, which, in turn, requires the machine to know what the content means (that is, its semantics). The challenge of developing the semantic web is how to put this knowledge into the machine. The manner in which it is done is at the heart of the confusion about the semantic web. The goal of this article is to clear up some of this confusion.I explain that shopping agents work in the complete absence of any explicit account of the semantics of web content because the meaning of the web content that the agents are expected to encounter can be determined by the human programmers who hardwire it into the web application software. I therefore regard shopping agents as a degenerate case of the semantic web. I note various shortcomings of this approach. I conclude by presenting some ideas about how the semantic web will likely evolve.

No abstract available.

From 19.09.04 to 24.09.04, the Dagstuhl Seminar 04391 ``Semantic Interoperability and Integration'' was held in the International Conference and Research Center (IBFI), Schloss Dagstuhl. During the seminar, several participants presented their current research, and ongoing work and open problems were discussed. Abstracts of the presentations given during the seminar as well as abstracts of seminar results and ideas are put together in this paper. The first section describes the seminar topics and goals in general. Links to extended abstracts or full papers are provided, if available.

Executive summary

Over the course of the week, one of the questions that came up repeatedly was: “what kind of infrastructure would be needed to support semantic interoperability and integration of systems”? It was widely assumed that semantics would be used for enabling translation and improving interoperability. However, it was not well understood how semantics or semantic mappings were to be shared. The emerging notion of a Semantic Web built on the World Wide Web infrastructure has spurred renewed interest in the possibility of semantic interoperability. However, much remains to be done to clearly articulate what the vision of ‘semantic interoperability’ is exactly, and many fundamental issues need to be addressed before we will see some broad-based theoretical and practical results that will make the vision become a reality. These questions range from the pragmatics of how definitions and mappings are published, shared and found to more fundamental concerns about what level of description the shared semantics needs to address.

The aim of this breakout session was to chart the landscape of existing approaches for representing mappings between heterogeneous models, identify common ideas and formulate research questions to be addressed in the future. In the session, the discussion mainly concerned three aspects: The nature of mappings, existing proposals for mappings and open research questions.