Joy and pain of plug-in architectures

Both ontology editors that I have developed over the last few years have been based upon a pre-existing platform using the platforms' plug-in mechanisms. In the case of Protege-OWL this was the Protege platform which was originally built for frame-based knowledge modeling in the 1990's. In the case of TopBraid Composer, we selected Eclipse, a well-known general-purpose platform for all kinds of tools.

To those who have followed the evolution of Protege-OWL in 2003 and 2004 it should be obvious that we had to iterate and change quite a bit, leading to a lot of frustration among our dear users. The original vision of building an OWL plugin on top of Protege-frames was to be able to reuse pre-existing features and user interface components. This turned out to be a very unrealistic vision, and in the end I found myself rewriting essentially the whole platform, even though my fellow programmers made significant efforts to adjust the core platform to accommodate the OWL requirements as well. It just didn't fit: widgets that were developed for a frame-based knowledge model, did not know anything about namespaces, supported different value types, had different layout conventions, assumed a closed world etc etc were rather obstacles than really reusable.

In TopBraid Composer the situation has been very different because I could start from the scratch and could pick the platform and API that I thought would make most sense. The obvious choices were Eclipse and Jena. I did not need to pay attention to the pseudo-backward compatibility of Protege and did not have to reuse unsuitable components and UI frameworks. Eclipse does a marvelous job as a base platform and is very enjoyable to implement against. It provides a clean plug-in mechanism through so-called extension points. Here is an example.

The screenshot below shows a new feature for the upcoming 1.1.4 build of TBC: A task list that allows users to attach "TODO" list items to resources in their ontology. For example, this feature can be used to annotate that a certain class definition should be changed in the future. Following the convention that we introduced in Protege-OWL, we use the owl:versionInfo property to store such items: any versionInfo starting with the string "TODO" is considered to be a todo list item. Java IDE's and other tools follow similar conventions to embed TODO items into source code.




One nice thing to say about Eclipse here is that it provides a complete framework to manage such todo items as co-called markers. Eclipse also comes with default windows to display all markers of a given type. One just needs to declare the new marker types and their attributes, and the system knows how to display and persist them. Beside the Task view shown above I used the same mechanism for a (closed world) constraint checker that helps users find violations of owl:Restrictions in their instances.



Eclipse is flexible enough to support navigation so that a double-click on any item in the list will take you to the problem resource. All this is very nice and took less than a day to implement. However, no matter how flexible a UI platform may be, there will always be plug-in requirements that cannot be fulfilled. My experience is that while adding new features is always easy and nice, it is extremely challenging or impossible to remove existing features. In the case of the Task list I wanted to replace the button to create a new Task so that it automatically also creates a corresponding owl:versionInfo enty. Since Eclipse does not provide a clean mechanism to remove or replace existing buttons, I had to go through some rather painful work-arounds to get this going (ask me how if you're interested). At least it is working and no changes to Eclipse were needed :)