Applied Ontology 10 (2015) 243–258 243 DOI 10.3233/AO-150158 IOS Press Position paper Ontology and database schema: What’s the difference? Michael Uschold Semantic Arts, 7405 125th Place SE, Newcastle, WA 98056, USA Tel.: +1 425 830 9475; E-mail: [email protected] Abstract. 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. Keywords: Ontology, schema, database schema, conceptual model, logical schema, physical schema, triple store, relational database, data integration Accepted by: Leo Obrst 1. Introduction We address the frequently asked question: what is the difference between an ontology and a database schema? This paper adopts a conversational perspective focusing on operational and pragmatic issues rather than attempting to offer deep theoretical insights into formal matters. Because they are by far the most prevalent, we will focus mostly on relational schema. Some but not all of our remarks will apply beyond the relational model, where there are many ways to specify schema and represent data. JSON an XML schema are popular. There are also deductive databases object-oriented databases and graph databases. • An ontology is a model that clarifies and specifies a set of meanings in a formal language. Those meanings reflect the ontologist’s understanding of the target subject matter, regarding the kinds of things there are and how those things are related to each other. • A database schema defines the structure of a database in a formal language. There are three kinds: conceptual, logical and physical. While we recognize that there are important differences, for con- 1570-5838/15/$35.00 © 2015 – IOS Press and the authors. All rights reserved 244 M. Uschold / Ontology and database schema: What’s the difference? Fig. 1. An ontology generally has a taxonomy as a backbone with multiple link types each having a precise meaning. Cardinality constraints are not shown. venience, we will conform to common usage and use the term “database schema” loosely to refer to all of these. We will call out differences as appropriate. The fundamental similarity between an ontology and a relational database schema is that (at the con- ceptual level) both consist of set of type definitions expressed in a formal notation. There is significant overlap with ontologies and early work on conceptual schema for database systems. Many of the same researchers worked on both. For example, there was an ACM workshop in 1980 on data abstraction, databases and conceptual modeling.1 Consider the simple example in Fig. 1, showing a graphical view of an ontology which has a taxon- omy as a backbone, plus various relationships each with a well-defined meaning. This could be easily expressed in a formal ontology language such as OWL. Figure 2 shows a logical schema in a graphic notation based on Information Engineering (IE) notation, described in Finkelstein (2006). Although the graph structures are identical, a deeper look reveals a wide range of important differences. Many arise from the fact that the database and ontology communities evolved fairly independently for very different purposes. From decades of personal experience and careful analysis of the similarities and differences between an ontology and a database schema, the following five questions emerged as the basis for comparison. 1. What is it for? 2. What does it look like? 3. How do you build one? 4. How is it implemented and used? 5. Where are the semantics? These questions are addressed in turn in Sections 2–6 of this paper. We consider how the questions are answered differently for a database schema vs. for an ontology. In Section 7 we summarize the analysis and draw some conclusions. 1http://dblp.uni-trier.de/db/conf/sigmod/pingree80.html. M. Uschold / Ontology and database schema: What’s the difference? 245 Fig. 2. Logical schema in IE notation. Boxes denote entities. Dashed lines connecting two entities denote relationships and cardinality constraints. 2. What is it for? 2.1. Purpose The fundamental focus of an ontology is to specify and share meaning. The fundamental focus for a database schema is to describe data. A relational database schema has a single purpose: to structure a set of instances for efficient storage and querying. The structure is specified as tables and columns. An ontology can also be used to structure a set of instances in a database. However, the instances would usually be represented in a [possibly virtual] triple store, or deductive database rather than directly in a relational database. Ontologies have a broader range of purposes including human communication, interoperability, search, and software engineering – Uschold and Gruninger (1996). The structure in an ontology is speci- fied in as a network of objects and relationships. One or more parties commit to using the terms from the ontology with their declared meaning. To some extent, this is also true for conceptual or logical schemas. The different roles played by an ontology vs. a database schema are responsible for a variety of other differences. For example, ER diagrams certainly can and are used to get people to agree on terminology and meaning of things that the data is about (the primary purpose of an ontology), but structuring data is their primary purpose. ER diagrams are typically used in the conceptual modeling phase, which abstracts away from data – but people typically don’t create ER diagrams unless they are going to build a relational 246 M. Uschold / Ontology and database schema: What’s the difference? database. A possible exception to this is to use an ER tool to build conceptual models that are exported into an ontology language. The goals of sharing and reuse have been recognized as important by the database community long before ontology modeling languages became popular. For example, as part of the ANSI/SPARC project, Jardine (1977) proposed three levels of schema. The external schema corresponded to user views; it ad- dressed an API to promote sharing and reuse that is independent of representation. The internal schema addressed efficient storage and access methods and would be called a physical schema today. The con- ceptual schema addressed what data is stored and how the data is inter-related. The word ‘ontology’ was not used in those days, but the conceptual level was about capturing the meaning of the data and its relationship to the world. 2.2. Instances and data The raison d’etre for a database is to store and retrieve data. In a relational setting, data is represented in tables. A row corresponds to an instance of some entity in the ER diagram. By contrast, because the main focus for ontologies is on meaning, ontologies can be useful even when there are no instances or data of any kind. The purpose of such an ontology is to communicate a shared meaning. A second difference is that ontologists commonly create so-called ‘abstract’ classes with the explicit intention of never having any individuals be directly asserted as members. Direct assertions are meant to be into more specific subclasses. Membership into the abstract classes is inferred. Except at the conceptual level, there is nothing comparable in an ER diagram. All entities are intended to have data about individual instances. 2.3. XML schema The primary focus of an XML schema is to define and constrain the structure of a set of documents, all expressing the same kind of information. Meier (2003) describes how in recent years, large collections of XML documents are being stored in specialized XML databases. 3. What does it look like? What a database schema or ontology looks like directly depends on the notation used, and the expres- sivity. Related to this is a question about the information content of the schema or ontology – i.e. what kind of information is being expressed? 3.1. Notation 3.1.1. Syntax ER diagrams such as found in Fig. 2, are the most common syntax for creating a database schema. Although these diagrams have semantic force, there is no standard serialization syntax. There are many notations for ontologies, most are logic-based languages. There are many ad hoc ways to graphically depict ontologies. Unfortunately, unlike ER diagrams, none of the ontology diagramming conventions are standardized at this time. Gasevic et al. (2004) describe tools for converting UML and possibly other standard modeling notations to ontology languages such as OWL.2 2See: http://www.w3.org/2007/OWL/wiki/UML_Concrete_Syntax. M. Uschold / Ontology and database schema: What’s the difference? 247 OWL is currently the only ontology language that is both a standard and also has fairly good tool support.