Ontologies have been widely used for representing data in biomedicine. The largest have 100,000s of concepts, and taken together all the ontologies in bioportal there are nearly 10 million classes. The computational infrastructure that we have to support these eforts though will often not scale to this size, requiring either splitting the ontology into parts or high memory computers. We have designed and built a new library, Horned-OWL, implemented in Rust that can scale to 10 million classes on a standard desktop machine, with large performance diferences compared to the Java based OWL API. We believe that as well as enabling scalability, higher levels of performance can alter the way we build ontologies by making what is currently dificult, simple, and fast.
declarations that together define the OWL2 data model. Unlike the OWL API, where the core data model is defined as interfaces, this is concretely defined in Horned-OWL. For example, an IRI is defined: 1 pub struct IRI(Rc<str>);
This is a reference counted pointer to an in memory String. The reference counting provides an easy mechanism to allow interning of the String, so each IRI is represented by only a single String. In the current implementation, Horned-OWL is hard-coded to this reference counting, but will be made generic in future versions: this means that the interning need not be used for smaller examples, therefore simplifying the code; and is also necessary to allow multi-threaded code. Equivalently, the axiom SubClassOf is defined: 1 pub struct SubClassOf { 2 pub sup: ClassExpression, 3 pub sub: ClassExpression, 4 }
This will compile to code that will use 160 bytes to represent SubClassOf, which is exactly twice memory needed to represent the individual ClassExpression. An AnnotatedAxiom is slightly longer (at 192 bytes). While this means that Horned-OWL is theoretically bound by the size of the computer memory, it uses that memory extremely eficiently: we predict that around six million axioms can be stored in 1GB of memory, plus the space for the IRI strings which will depend on their length. This makes it highly scalable as we show in Figure 1a.
This simplicity of implementation is also seen in the Ontology implementation. The simplest version uses an in-memory set of axioms, plus two IRIs (the ontology and version IRI). In contrast to the OWL API, this provides no indexing at all by default, while providing a pluggable mechanism should it be required. This follows the “zero-cost” idiom of Rust. For example, the OWX1 reader does not need to perform axiom lookup during parsing, so needs no indexes, does not use them, and pays no cost for them. The RDF parser2 meanwhile makes extensive use of indexes to allow rapid look up of declaration axioms and by logical comparison; without this, RDF parsing scales poorly3.
While Horned-OWL has been written as a general library, we have also added a command line interface. This uses the common subcommand interface, with every command prefixed with horned. Currently, the available commands are rather biased toward commands which are useful for debugging ontology development libraries, but these will be expanded in future. Some of the commands include:
horned-big: Generates OWL files of arbitrary size, useful for performance testing horned-materialize: Downloads (recursively) imported files
horned-parse: Parses a given OWL file horned-summary: Prints summary statistics of an ontology 1https://www.w3.org/TR/owl2-xml-serialization/ 2https://www.w3.org/TR/owl2-mapping-to-rdf/ 3In at least quadratic time, possibly worse; without indexes, it took several hours to load the Gene Ontology The performant interface of Horned-OWL makes this command line quite usable; for example, the NCBI Taxonomy can be parsed in 1-2 minutes; the OWL API takes 2-3 minutes to perform an equivalent task (Figure 1b). This speed means that Horned-OWL can be used in practice to perform a series of manipulations passing output through a Unix pipe. To do the same with the OWL API would require a tool like Tawny-OWL[1], which would load the ontology once and perform multiple operations before saving4.
(a) Generating a big ontology (b) Parsing GO and the NCBI Taxonomy
While Horned-OWL was written as a library for ontology manipulation as well as the underpinning for the command line tools that it ofers, the implementation provides a number of possibilities that we are investigating. First, while Rust is a clean, modern language, it is not easy to script with, nor particularly familiar to the ontology community. Therefore, we are currently experimenting with using it as the backend to a Python library. The heavy computational work will be performed in Rust, linked together using a Python script. Second, the Ontology Web Language despite its name is currently not usable on the web. Rust supports WebAssembly which means that it can be run within a web browser; therefore, it will provide future implementation options to make OWL available in this environment. Acknowledgments Thanks to James Overton and Janna Hastings for working on a Python interface to HornedOWL.