In this paper we describe the design and implementation of a relational database back-end for the OWL API [3]. The motivation for this work is to allow servers, such as the NCBO BioPortal [4] and WebProtege1, to use the OWL API to access several large ontologies at the same time while maintaining a small memory footprint. Our database backed implementation of some key OWL API interfaces allows such a server to use the OWL API to access several large OWL ontologies within a limited memory footprint. This database backend for the OWL API was implemented independently of but in parallel with a very di erent implementation of a database backend [2, 1] for the OWL API based on Hibernate. This paper will describe the design of the Protege database backend and discuss some of the key design decisions and di erences from the Hibernate-based database backend. We have tested this database backend with the MySql and Postgres databases and it is now being tested on the BioPortal with the MySql database.
have fty ontologies open at the same time several of which may be quite large. Due to resource limitations, it is not feasible for servers such as BioPortal to load a large number of ontologies into memory. The problem is two-fold. First these servers have many demands on their resources. They will quickly run out of resources if they preload all the available ontologies. Second, even if memory would be su cient for on-demand loading of needed ontologies, the time required to load an ontology is incompatible with a reasonable response time for users. The Protege database backend allows a developer to very quickly load and access an implementation of the OWL API OWLOntology interface for even the largest OWL ontologies being considered.
The primary disadvantages of putting ontology data into a database
backend are: (
The second problem occurs because database queries are very expensive when compared with their analogous in-memory operations. We often see times just under a millisecond to perform even very simple queries in a database. A primary design goal of the Protege database backend is to try to improve performance by avoiding SQL queries when the result can be calculated in Java code. To this end, we have decided to perform all serialization and deserialization of OWL axioms in Java code. The serialization of an axiom is stored in the database but never queried or indexed. This means that OWL axioms never need to be pieced together by joining the contents of several di erent tables in the database. The downside is that a signi cant amount of time during read operations is spent deserializing representations of axioms. This is a signi cant di erence between our implementation and the Hibernate database backend.
Since the serialized form of the axioms is only retrieved and never examined during SQL queries, the database must hold enough information to rapidly nd the right axiom in the database when needed. In addition the database implementation has been optimized for use with the OWL API - other possible uses of the data have not been considered. For example, one of the interfaces that the Protege database backend needed to implement was getReferencingAxioms which retrieves all axioms that have the speci c entity in their signature. In order to retrieve these axioms, the Protege database backend makes use of three tables. The rst table contains a list of all the entities in the signature of the OWL ontology, providing a database identi er for the entity, the name (IRI) of the entity and the type of the entity. The second table lists all the axioms in the OWL ontology providing each axiom with a database identi er for the axiom, the serialized form of the axiom and several other properties of the axiom. The third table links the rst two tables by indicating which entities appear in which axioms. These three tables can easily be joined together and queried to retrieve, in a single database query, the set of axioms required by the OWL API call. The choice of what data needs to be included in these tables is purely driven by the question of what is needed to e ciently provide the information needed by the OWL API interfaces.
The third issue with a database backend is the added complexity. From a user point of view, the database needs to be installed and the con guration of the database is very important. Then the user needs to gure out how to provide the right connection strings for the database and how to use and protect the database passwords. But for our target applications, web servers that load many ontologies, this complexity already exists and is part of what a web server must deal with.
But there is also additional complexity in the implementation of the database backend itself. Instead of simple lookups in a hash table, the database backend designer has to work with SQL queries and must additionally understand the di erent datatypes that are used by di erent databases and di erences between supported SQL queries. For example the fact that Postgres supports the \SELECT DISTINCT ON" but MySql does not meant that we needed to provide di erent versions of the same query for the two databases. In addition, the database backend needs to avoid storing large amounts of data in memory. For example, in the Protege database backend, a lot of e ort went into ensuring that the OWL API call that retrieves all the axioms in an ontology provides a set that is constructed on demand and does not use all the memory that would be required to load these axioms at the same time. Finally, in-memory calls to Hash tables rarely fail and usually then only because of an outof-memory condition. In contrast, database queries can fail in numerous ways.
In the area of complexity, we believe that the Hibernate approach probably has a natural advantage over the approach that we took. It provides a layer that protects the developer from low level details. To implement our database backend, we needed to carefully craft over seventy SQL queries. A mistake in any one of these queries may lead to errors or serious performance loss. In addition, some of these queries can easily use features that are available in one database but not in another. In many cases the same queries for the Hibernate implementation will be generated by Hibernate and not the developer.
We are already using the database backend in the BioPortal server and work is in progress to use a database backend in WebProtege. Most, if not all, of this work will work equally well with either database backend. Since it is easy to switch between the two implementations it is important . So we plan on doing some testing work to compare how the database backends perform both in terms of memory use and in terms of performance. Since the two database backends have very di erent design approaches it will be interesting to see how their behavior di ers. Both database backends are open source available from SVN34. There is also a proof of concept implementation of a plugin that integrates that database backend into Protege 4.1. 3 http://smi-protege.stanford.edu/repos/protege/protege4/libraries/org.protege.owlapi/trunk 4 https://owldb.svn.sourceforge.net/svnroot/owldb