Ontologies published on the web can be quite large, from a couple of megabytes to more than a gigabyte. Deploying, importing and using such ontologies can be a problem, both in terms of bandwidth and load time over the web, and in terms of physically storing them. Some ontologies in BioPortal for example are shipped in their compressed form (via their web services), which allows lesize reductions to up to 2% of the original. Moreover, many ontologies have been published in their modular form through the use of owl:imports. Some of the imports are dereferenceable on the web, but in many cases, the imports closure is shipped with the actual (root) ontology, which can lead to confusions on how to interpret the directory structure. In this paper, we are proposing a set of simple conventions to distribute ontologies (monolithic or modular) in a canonical fashion to enable tools to make use of pre-compiled modular structures and reduce IO communication to a minimum using compression.
Many important ontologies today, such as the Foundational Model of Anatomy
(FMA) [
A decomposition D of an ontology O (a set of axioms) is a partitioning of O
into a set of subsets S O where it holds that the union of all S O equals O.
There are two fundamentally di erent ways to decompose an ontology:
1. As part of the engineering process, ontologies are designed to be modular to
enable re-use across multiple specialised domains or
2. A decomposition is extracted from the ontology post-engineering to enable
services to interact with logically coherent subsets of the ontology rather than
having to deal with the whole. In the context of this work this distinction
only serves to establish two very di erent interest groups for OWL/ZIP.
Analysing MOWLCorp, a crawl-based corpus of around 21K ontologies [?]1, we
can nd at least 462 syntactically unique ontologies with more than 5 imports,
and 16 with more than 15. All these are examples of the rst kind of
decomposition, where engineers have decided to deploy the ontology in somehow topically
related subsets that might be individually re-used. While imports intended for
re-use should be dereferenceable on the web, the reality is that many ontology
providers prefer to deploy their modular structure with their ontologies, which
creates a need to deal with these kinds of distributions in an unambiguous way.
The need for dealing with the second type of decomposition rst emerged from
rather recent advances in modular reasoning (e.g., maintaining a ontology in
decomposed form removes some overhead from a modular reasoning process). A
decomposition in this sense is more strictly de ned: every subset in the above
de nition corresponds to a logical (in practice locality-based) module. Instead
of duplicating axioms across multiple modules, the modular structure can be
encoded in a much terser representation such as the Atomic Decomposition [
In order to accommodate both for large monolithic ontologies and their decomposed counterparts we mainly need to agree on: 1. a type of compression in order to minimize the e ort to develop suitable tool support 2. an entry point in the archive 3. a standard way to determine whether to prefer local imports, if existent, over global ones
Our suggestions is as follows. ZIP is a widely used type of compression supported by most tools that support compressed les in general. Even if the compression rates might not be optimal, size reductions are possible to between 2 and 20% of the original lesize for text-based ontology serialisations between 1 kilobyte and more than 500 megabyte. A very important consideration here is that Java provides built-in functionality to deal with archives of this kind, which is a strong argument for users of the OWL API (Java-based), the most comprehensive library to deal with OWL 2 ontologies for the community.
As for the entry point, we suggest a simple le naming convention. Although not really an applicable label in the case of a mere monolithic ontology, root.owl might be a generic name to indicate for users of the archive: this is where you start. root.owl might be empty or non-empty and importing its dependencies through owl:imports.
Lastly, we need to specify a standard behaviour for how to deal with imports in the case that imported ontologies are included les in the same directory structure, but referenced as URLs in the owl:imports statements. The problem is that in practice, some of the URLs are dereferenceable, some not. We propose to interpret the existence of les corresponding to the path/ lename in the URL as corresponding to the intention of the distributor to prefer the local versions, as opposed to them being there merely as fallback.
The full protocol of dealing with an OWL/ZIP le is then as follows: 1. Unzip the archive 2. Find the root.owl entry point 3. For each importing, attempt to resolve imports locally and only on failure to attempt to deference the imported URL from the web 4
Use case: the Atomic Decomposition in OWL/ZIP
Reasoners that make use of modular reasoning techniques such as Chainsaw [
Thus, we show how one might encode additional useful information onto of the base OWL/ZIP format. Such conventions can ease the building of layered tools.
minimal maximal
We have conducted a survey using the ORE 2014 dataset [
Compression rates across corpus: As can be seen in Table 1, compression rates can reduce the le size by at least around 80%, up to a maximum of almost 99%. A closer look at Figure 2 reveals that the e ects of the compression (unsurprisingly) are getting better for larger ontologies. Ontologies with more than 1000 logical axioms generally get compression rates above 80%, tending towards 90% and more in very large ontologies above 90,000 axioms. Worse compression rates of less than 85% are generally found only among the very small ontologies (1000 or less logical axioms).
Compression Rate 100% 95% 90% 85% 80% 90 900 9,000 90,000 900,000 9,000,000
Decompression overhead: Figure 3 shows the load time overhead for the decompression. The x-axis shows the original load time in seconds, the y-axis the load time overhead induced by the decompression in percent. The overhead is never more than 100%, i.e., if an ontology in its uncompressed form (x-axis) would take one second to load, the total load time would never be more than 2 seconds. Bad overheads of 80%-100% however only occur in the in the 100 100% 80% 60% 40% 20% 0% 100% 98% 96% 94% 92% 90% millisecond (or less) area. The longer the ontologies would take to load in their uncompressed form, the less e ect does the decompression time have on the overall loading time. For ontologies that take more than 10 seconds to load, the overhead is never more than 50%.
Added Load Time
Compression Rate 0.01 0.1 1 10 100
One of the bene ts of using zip archives is the possibility to deploy an
ontology in its modularised form. We have conducted a short survey to see how the
use of OWL/ZIP might bene t or limit deploying such an ontology. We are
investigating a rather extreme case, were we deploy the ontology as its Atomic
Decomposition (see Section 4). These kinds of decompositions are extreme in
the sense that they contain a lot of les (i.e., each atom will be serialised as a
separate le on the le system), many more than a manual decomposition would
ever contain. We used the ?-decomposition [
For the general setup see Section 5.1. We randomly sampled from the same corpus 10 small (100-1000 logical axioms), 10 medium sized (1000-10000 log. ax.), 10 large (10000-100000 log. ax.) and 10 very large ontologies (>100000 log. ax.), serialised them into their decomposed from as described in Section 4. We introduced a sharp timeout of 30 minutes for the entire process of loading, decomposing, serialising, zipping, unzipping and loading again. 6.2
Out of the 40 ontologies in the testset, 23 were processable within the given timeout. Compression rates: As can be seen in Figure 4 (right) and Table 2, the e ect of the compression is relatively stable across the testset, generally between 60% and 80% (with a single outlier in the better end). The gure shows the compression rate (y-axis) with respect to the number of atoms in the decomposition. This number serves as a proxy for the size of an ontology; the number of atoms is strongly correlated with the number of axioms in the type of decomposition we used here. We use atoms here instead of axioms because it gives a better sense into how many les the ontology is split. Decompression overhead: Even more clearly than in the case of monolithic ontologies, we can observe that the bigger the original load time, the smaller the relative impact of the decompression. Figure 4 (left) shows the load time for the uncompressed ontology (x-axis) in seconds with respect to the relative added load through the decompression. The larger the load time of the ontology in its uncompressed form, the smaller the relative impact of the unzipping on the total load time. The worst case in the test set imposed an additional 56% on the load time, which seems reasonable (Table 2). The results indicate that using a compressed form to deploy ontologies only imposes a reasonable degree of performance reduction on the load time. Furthermore, the general compression rates are compelling at least for the larger ontologies. The di erences between the monolithic and the modular cases are most likely due to the overhead induced by having many, potentially thousands of separate les ( le listings in the archive header, etc).
It is possible that with a more streamlined implementation (i.e. rather than uncompressing to disk and then loading via normal mechanisms, we would directly uncompress to the parser in memory) that the total load (or save) time could be reduced relative to the uncompressed process. This could happen for ontologies which are large enough that IO costs dominate and we have su cient RAM. (If you consider loading an ontology from the web it's clear that in many cases download time dominates by a large factor.)
If we compare our current results with a recent binary OWL proposal [
While more accessible than binary formats, OWL/ZIP still imposes some overhead. Until existing editors catch up, users have to manually unzip and manage the resulting directory. Our reuse of imports helps to a certain extent, but even there, existing OWL IDEs are designed to handle hand-built imports structures.
The zipped directory allows for further easy extension. For example, reasoners wishing to cache some state between invocations can put that into a subdirectory with some hope that the compression would mitigate the size hit and that the user could be safely unaware of this extra information. 8
We have proposed a convention to distribute large monolithic and modular ontologies in a compressed form (OWL/ZIP). The approach covers both an unambiguous interpretation of the imports closure and a proposal of a speci c format for the compression. The general rationale for such a format is the sheer size of many ontologies and the need to distribute decompositions. The results of our survey indicates that using a standard form of compression like zip is su cient to deal with this problem, and there are many tools and APIs available that can deal with it. An interesting investigation would be to include an OWL/ZIP parser in the OWL API that allows to unzip in memory, using the Java 7 FileSystem class. This could potentially give bene ts at load time, even over the standard parsing, due to possible reductions in IO touches. But at least it should make dealing with compressed ontologies faster.