owljs – a javascript library for OWL hacking

owljs ia a javascript library for doing stuff with OWL. It’s available from github:


Whilst it attempts to following CommonJS, you currently have to use RingoJS  (a Rhino engine) as it makes use of JVM calls to the OWLAPI

owl plus rhino equals fun


Why javascript?

Why javascript you may ask? Isn’t that a hacky language run in browsers? In fact javascript is increasingly used on the server side as well as in browsers, as can be seen in the success of node.js. With Java 8 incorporating Nashorn as a scripting engine, it looks like javascript on the server side is here to stay.

Why not just use java? Java can be very verbose and is not the ideal language for writing short ontology processing scripts, especially with the OWL API.

There are a number of other languages better suited to scripting and declarative programming in general, many of which run on the JVM. This includes

  • Groovy – a popular choice for interfacing with the OWL API
  • The Armed Bear flavor of Common Lisp, as used in LSW2.
  • Clojure, a variant of lisp, as used in Phil Lord’s powerful Tawny-OWL framework.
  • Scala, a superbly elegant functional programming language used to great effect in Jim Balhoff’s beautifully elegant scowl.
  • Iron Python – a popular choice for interfacing with the Brain. And of course, Python is the de facto language for bioinformatics these days

There are also offerings in non-JVM languages such as my own posh – in addition most languages provide some kind of RDF library, but this can often be low level for working in OWL.

I decided to write a javascript library for a number of reasons. Our group already produces a lot of javascript code, most of which can be run on the server. For example, the golr libraries used in the AmiGO 2 codebase are CommonJS, as are those used for the Monarch API. Thse APIs all access ontologies through services (and can thus be run on a non-JVM javascript engine like node), and we would not make these APIs depend on a JVM. However, the ability to go the other way is useful – in a powerful ontology processing environment that offers all the features of the OWL API, being able to access all kinds of bioinformatics data through ready-made javascript APIs.

Another reason is that JSON is ubiquitous, and having your data format be a subset of the language has some major advantages.

Plus, after an initial period of ambivalence, I have grown to really like javascript. It’s just functional enough to do some cool things.

What can you do with it?

I hope to provide some specific examples later on this blog. For now, take a look at the docs on github. Major features are:

Stay tuned for more information!






Perl library for OWL hacking

I would recommend using a JVM language plus the OWL API for doing programmatic processing of OWL.

NOT perl.

If you really insist on perl, and you don’t mind insane magical AUTOLOAD heavy modules with no documentation:


Unlike many modules, this doesn’t attempt to map some RDF monster into OWL axioms. It takes in a very simple JSON format and provides a very slim layer on top of that. Unfortunately there isn’t a standard JSON for OWL, so owlhack uses a custom translation as provided by OWLTools. This is a very generic axiom-oriented lispy rendering of OWL functional syntax.

Currently I’m using this module for tasks such as generating ad-hoc chunks of markdown derived from the ontology. The resulting md can then be pasted into github tracker postings, or used to generate html.

There’s also a “sed” script that comes with the library that’s useful for performing perl “s/” operations on annotation values.

It’s all a bit hacky, kind of an OWL replacement for https://github.com/cmungall/obo-scripts

Caveat emptor!

Migration of Gene Ontology bridging ontologies to OWL

In the GO, we’ve historically maintained a number of experimental extensions to the ontology as obo-format bridging files in the infamous “scratch” folder. Sometimes sets of these migrate into the main ontology (the regulation logical definitions, as well as the occurs in ones started this way). This has always been harder for axioms that point to external ontologies like chebi (although with this change it should be simpler).

These “bridging ontologies” fall into two main categories:

  • logical definitions [1]
  • taxon constraints[2]

As part of a general move to make more direct use of OWL in GO, we have moved the primary location of some of the bridging ontologies to the new SVN repository, with the primary format being OWL. Some of  See: the Ontology extensions page on the GO wiki.

This has a number of advantages:

  • the bridging axioms can be edited directly in protege, in the context of the GO and the external ontology, using an importer ontology
  • we can make use of more expressive class expressions

We will provide translations back to obo but these may be lossy.

Eventually these will move into the main ontology, but there are issues regarding import chains, MIREOTing and public releases that need resolved. For now you have to explicitly import these ontologies plus any dependent ontologies. Note that this is made easier by a combination of svn:externals and catalog xml files – see tips.

Check out the repository like this:

svn co svn+ssh://ext.geneontology.org/share/go/svn/trunk go-trunk
cd go-trunk/ontology/extensions

This should result in a directory structure like this:


The importer ontologies are designed to be loaded into Protege or programatically via OWLTools (use the new “–use-catalog” option with OWLTools).

Here is an example importer file – it contains no axioms of its own, it exists as a parent to other ontologies:

    <owl:Ontology rdf:about="http://purl.obolibrary.org/obo/go/extensions/x-metazoan-anatomy-importer.owl">
        <owl:imports rdf:resource="http://purl.obolibrary.org/obo/go.owl"/>
        <owl:imports rdf:resource="http://purl.obolibrary.org/obo/ro.owl"/>
        <owl:imports rdf:resource="http://purl.obolibrary.org/obo/uberon/composite-metazoan.owl"/>
        <owl:imports rdf:resource="http://purl.obolibrary.org/obo/go/extensions/x-cell.owl"/>
        <owl:imports rdf:resource="http://purl.obolibrary.org/obo/go/extensions/x-metazoan-anatomy.owl"/>

Note that most of these will be fetched from the svn externals directory (if you load from svn, rather than the web).

After loading, you should see something like:
protege import chain screenshot
See the wiki for more details.

The bridging axioms have been under-used in the GO, expect more use of them, as part of ontology development and downstream applications over the coming year!

[1]Mungall, C. J., Bada, M., Berardini, T. Z., Deegan, J., Ireland, A., Harris, M. A., Hill, D. P., and Lomax, J. (2011). Cross-product extensions of the Gene Ontology. Journal of Biomedical Informatics 44, 80-86.PMC dx.doi.org/10.1016/j.jbi.2010.02.002

[2] Deegan Née Clark, J. I., Dimmer, E. C., and Mungall, C. J. (2010). Formalization of taxon-based constraints to detect inconsistencies in annotation and ontology development. BMC Bioinformatics 11, 530. http://www.biomedcentral.com/1471-2105/11/530

Phenotype ontologies on googlecode

For the PATO project we’ve set up a repository on googlecode to collect phenotype ontologies and various bridging axioms:


This aggregates together the main phenotype ontologies, together with logical definitions bridging ontologies, as defined in

Mungall, C. J., Gkoutos, G. V., Smith, C. L., Haendel, M. A., Lewis, S. E., and Ashburner, M. (2010). Integrating phenotype ontologies across multiple species. Genome Biology 11, R2. Available at: http://dx.doi.org/10.1186/gb-2010-11-1-r2

You can access the aggregated ontology via this PURL:


It may be slow to open this via the web. If you have the phenotype-ontologies repository checked out, you can open the file from the filesystem – external ontologies will be obtained via svn:externals.

I recommend using Elk as the reasoner, others will be too slow with the combination of HP, MP, FMA, MA, PATO, etc. Unfortunately Elk doesn’t yet allow DL queries or explanations of inferences.

The above ontology uses a slightly modified version of the definitions described in the Genome Biology paper – instead of modeling each phenotype as a single quality (e.g. redness of nose), we now model them as aggregates of phenotypes. This tends to work better for HPO, which has many composite phenotypes.

Note also that we’re using a hacked version of the uberon bridging axioms to ZFA, MA and FMA – we treat these as precise equivalents rather than taxonomic equivalents. This is necessary as we mix uberon in with the species ontologies in the logical definitions.