A highly literate approach to Ontology Building

Introduction. Today is going to be a bit of a story, talking about the need for description in ontologies. I want to talk about a new paradigm for ontology development which enables this, and two pieces of technology that implement it.

There is a fair bit of technology involved, so breath deeply, as parts of this will be a whistlestop tour.

An ontology is a specification of a conceptualisation. Clearly it’s a conceptualisation of something. Now there has been a lot of discussion and disagreement on exactly what that "something" should be. And a lot of documents written about it.

But there are some sources of agreement at least. First, we all agree that the something is complicated, and we all agreement that it is worth talking and writing about.

As Christmas is approach, we should start off with a story, a Christmas fable. A long, long time ago, I was working on an ontology called OBI at a meeting not far from here. We found these two definitions in OBI talking about the pellet and supernatant in a centrifuge tube.

Now, why do we have this asymmetry in our definition. It seemed strange and unobvious, and after five minutes of discussion we all agreed that it was wrong. Till I remembered having exactly the same discussion six months before. And it’s because the supernatant is a liquid; once you pour it off, it’s not really a supernatant any more.

This was difficult to remember. And, while the documentation defined the terms, there was no justification.

My conclusion is this. Ontologies need a lot of description. But, there is a problem. OWL does not really support this. Annotations are un-ordered for instance, and protege treats documentation as an add-on. We can’t add sections, bibliographic references and so forth.

Some programs require a lot of documentation also, so this is not an new issue. In fact, this problem gave rise to the idea of literate programming; the overall workflow for a literate program looks like this. We edit a single piece of source code which has got both code for execution and turning into documentation. Examples of this include latex (which documents latex which is as confusing as it sounds) and Sweave which combines latex and R to generate out figures for a paper.

This seemed like a good idea, so I thought that I would this with ontology. I tried a variety of solutions over the years which you can read about on my blog here. All of them were based around OWL Manchester syntax which is a clean syntax for editing.

My conclusions are this:

Basically, no one is going to write an ontology in a flat file. It’s hard enough as it is, without having to get everything right in some obscure syntax. Only a crazy person would write an ontology in a flat file.

Here are two crazy people — in fact, many early versions of GO were written in a flat file, and there are some advantages to it. But, largely, even they have stopped now.

And that is what I thought, until we got to karyotypes.

So, what is a karyotype? It’s a description of all the chromosomes normally, in a human. It’s clinically important because losing bits or all of chromosome is generally bad. We want to describe this ontologically.

There are lots of chromsomes and lots of bands. It’s complicated, and repetitive. In the end, we realised we had to program it.