owljs – a javascript library for OWL hacking
March 30, 2014 3 Comments
owljs ia a javascript library for doing stuff with OWL. It’s available from github:
https://github.com/cmungall/owljs
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
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:
- A REPL that supports autocomplete on class labels.
- A stable documented API mirroring many OWLAPI capabilities, with fewer hoops to jump through.
- Ability to use any OWL API call as required (including reasoning etc)
- Some ready-made scripts, including an OWL Diff implementation that uses markdown, currently used for Uberon release diffs (example here).
- A powerful OPPL-like axiom pattern matching and replacement framework.
Stay tuned for more information!
This is a nice idea. I thought about Javascript before I went for Clojure with Tawny-OWL. In the end, I was weighed up the ubiquitous familiarity of Javascript against the syntactic plasticity of Clojure.
I like the pattern matching. It’s something that Tawny is missing at the moment, although I think it could be nicely implemented with (functional) pattern matching which there is support in Clojure for.
There is some good opportunity for collaboration here, I think! There are a number of tools that all languages like this need, and (like it or not) we are all JVM based.
Do you know anything more about LSW2? I am very interesting in using Common Lisp for working with ontologies and Semantic Web.
Email Alan Ruttenberg for info on LSW2. Even if you are restricted to Lisp sensu stricto take a look at Tawny too.