The OWL API: A Java API for OWL Ontologies

Paper Title: 
The OWL API: A Java API for OWL Ontologies
Matthew Horridge, Sean Bechhofer
We present the OWL API, a high level Application Programming Interface (API) for working with OWL ontologies. The OWL API is closely aligned with the OWL 2 structural specification. It supports parsing and rendering in the syntaxes defined in the W3C specification (Functional Syntax, RDF/XML, OWL/XML and the Manchester OWL Syntax); manipulation of ontological structures; and the use of reasoning engines. The reference implementation of the OWL API, written in Java, includes validators for the various OWL 2 profiles - OWL 2 QL, OWL 2 EL and OWL 2 RL. The OWL API has widespread usage in a variety of tools and applications.
Full PDF Version: 
Submission type: 
Tool/System Report
Responsible editor: 

The downloadable manuscript is the final accepted version. The reviews below are for the original submission.

Review by Peter Haase:

The article provides an overview of the OWL API. The OWL API is the de-facto standard API for working with OWL ontologies. As such, it is a relevant tool to any Semantic Web application developer dealing with ontology development, engineering, reasoning, etc., and it thus a perfect subject for the special issue on tools and systems. The details about usage and takeup are impressive and speak for themselves.

The article is very well written. It does not only provide a technical description of the API itself, but also gives interesting insights into its history, design decisions, usage of software patterns, related frameworks etc. The technical level of discussion is deep enough to get a clear understanding of the API, but not dry like a specification.

As a developer who has used the OWL API extensively before, I can affirm the technical quality of the API itself.

In summary, I recommend to accept the article for this special issue.

Detailed comments
- When describing the design philosophy (Section 2), you state that the representation in the OWL API is not on the level of RDF triples. It would be good to explain the differences and implications. (Some aspects are mentioned later in the article)
- When describing the design principles (Section 3), you first mention: "read-only model interfaces with explicit change operations" and shortly after that: "the model interfaces are read-only, in that they do not provide explicit functionality for change…" While the interfaces are described in detail later on, these two statements appear contradicting when first reading.
- In the description of the reasoning tasks, I am missing conjunctive queries. Please explain why they are not part of the API and whether there are workarounds.
- In the list of "other frameworks", I am missing KAON2. (Please note that KAON2 and KAON2 are completely different systems, with different ontology languages supported)
- The funding details for the NeOn project are irrelevant for this article, in the current form they are even misleading, as one might interpret that this funding was merely for the development of the NeOn toolkit. Please remove.
- The elements in the list of usages (Section) should follow a parallel structure (in syntax and style).
- Reference [20] should be Kleb et al. (not Henss et al), check the bibtex entry.
- Page 2: "which turn facilitated" -> : "which in turn facilitated"

Review by Frederick Maier:

Considerable effort has been put into the development of the OWL API, and it has already been adopted in one way or another by several now standard tools (e.g. Protege, Pellet). The library will increase adoption of OWL in the long run, and so the developers have done a great service to the community.

To date, there have been a few papers written about the API. One was presented at ISWC 2003, and two were presented at OWLED workshops (2007 and 2009). The actual papers are given below (references pulled from the OWL API site):

1. Sean Bechhofer, Phillip Lord, Raphael Volz. Cooking the Semantic Web with the OWL API. 2nd International Semantic Web Conference, ISWC, Sanibel Island, Florida, October 2003.

2. Matthew Horridge, Sean Bechhofer, Olaf Noppens. Igniting the OWL 1.1 Touch Paper: The OWL API. OWLED 2007, 3rd OWL Experienced and Directions Workshop, Innsbruck, Austria, June 2007.

3. Matthew Horridge, Sean Bechhofer. The OWL API: A Java API for Working with OWL 2 Ontologies. OWLED 2009, 6th OWL Experienced and Directions Workshop, Chantilly, Virginia, October 2009.

The submitted paper bears considerable resemblance to the last of these, with some passages and figures included from the 2009 paper without alteration (both describe a post OWL 2 API). There is an increased discussion of tools that use the OWL API in the submitted paper, and also a brief note on limitations of the framework. As OWLED papers are informal publications, inclusion of the current paper in the journal is warranted; it would at any rate make citations easier.

The paper is short (under 10 pages, the maximum specified by the solicitation), and it necessarily gives only a high level view of the API. My general opinion is that the API is excellent and important work; the paper is pretty lite on substantive details, however. I would have preferred a few pages devoted to an expanded discussion of the the data-structures used by default and of the API's strengths and weaknesses. Space for this could have been obtained by compressing the discussion of the API's use in other tools, omitting Fig 2 (which serves little real purpose), and omitting a several references (roughly 20% of the allocated space is given to references; this seems a lot, given the page limit). The authors note that, by default, the OWL API manipulates ontologies in working memory, and that this could prove to be a bottleneck for some applications. The paper gives a few examples of performance--specifically load times for SNOMED and a few other ontologies (the performance is comparable to Jena). Publishing more empirical tests indicating how far the API can be pushed before breaking would be of great interest to readers.

One complaint I have in general for the API at the moment is the relative lack of documentation and tutorials on how to use it. On the website (, there is a JavaDoc file and sample code. There are slides as well, but these appear to be out of date. The documentation is realistically better than what is provided for many other pieces of software, but in my view it's still insufficient. If the goal is wide-spread adoption of the API and OWL, then the documentation should be nothing less than excellent.

A few more minor comments:

1) page 4: No reference is given for the sno-rocket reasoner.

2) the graphs on page 6 are low-res and a bit difficult to read.

3) page 7: When first reading the text, it was unclear whether the online services mentioned (validator, syntax converter, etc.) are all to be found at Manchester U.

Last note: The negative bits in the above part of the review should not be given much weight. The primary consideration for inclusion in the journal should be the "Quality, importance, and impact of the described tool or system." The API certainly meets those requirements.

Review by Jérôme Euzenat:

The paper describes the OWL API and its reference implementation. The
OWL API offers an axiom-centric view of OWL ontologies which follows
closely the OWL specification. Its implementation offers various
services (validation, parsing, rendering) and others can be plugged in
generically (reasoning).

About the OWL API

The OWL API is an unvaluable piece of software that has maintained since
2003 support for entity-level (and axiom-level) for
OWL. It is used by many developments on top of OWL, some important
ones are mentioned in the paper (e.g., Protégé-4, Pellet).
It has been the software that partly inspired the design of our own
Alignment API and we have taken advantage of the OWL API since the
There is no doubt that the OWL API is part of the core semantic web
infrastructure and as such this tool paper is appropriate.

Section 4 mentions the choice of changing the API vocabulary for
aligning it with OWL specifications. I agree with this and I add that
this has been well-documented online so that the migration process was

About the paper

The paper describes adequately the OWL API. Sections about its
principles, history and evolution are very useful for potential
users. Other sections give an idea of the impact of the system. It
provides good rationale about choices like axiom-based API, or the use
of the visitor and command patterns.

However, I think that it could be improved in a few respects:

I would have appreciated a more complete description of the API
components. Section 3 presents the model, change, reasoning, and
parsing and rendering components. Section 5, provides a short
description of the validation, explanation and modularisation
components, but we discover in Section 7, that there is a Metrics API
that is not mentioned before. I assume that there are not tens of
other components, so it would be great to be exhaustive in this
regards. This should not take so much space. It would also be worth
adding two words about querying and what kind of support is available
within the OWL API.

The second point is that I would have liked a more precise comparison
with other OWL APIs. I understand that explaining in which case to use
the OWL API and in which case to use another one is out of the scope
of such a paper. However, it would have been interesting to explain
what part of the OWL API are not available in other implementation and
which parts of other implementations are not available in the OWL API.
Moreover, there seems to be a Protege OWL API and it is not mentioned
in Section 6 while kaon2 which seems to be unmaintained is covered. I
think that this section should be rethought so as to be useful for the

In conclusion, I think that the paper should be welcomed in the
Semantic web journal as it is a missing reference for an important
tool of the semantic web infrastructure.