Thinking Clearly .

In our work for NCI, I had the distinct “pleasure” of being the UI guy for the project, a role I find myself in more often these days.  Despite the vagaries and headaches that come with writing Java UI’s, I got the easy part of the deal.  I got to write Swing code while Mike and Evren did some amazing, but difficult work on Pellet.  And while I’m thinking of it, they should be applauded, they did a fantastic job on Pellet.  Anyway, the catch was the UI had to come in the form of Protege tab plug-in.  In the past I’ve done my best to not use Protege, but I was interested in finally using and dissecting a tool that many people use on a regular basis, including the folks at NCI.

Without going into extreme gory details of the work, I have a few thoughts on the ordeal.  I was dismayed by the lack of documentation on how to write your own Protege plug-ins and how to work with the Protege core in general.  There was a short blurb on their site, and some javadocs, but not much else.  Fortunately, coding from javadocs is not a foriegn concept, so I was able to piece together what needed to happen.  And the source is publicly available which was really invaluable.  I unfortunately recieved no support from the mailing list.  I guess perhaps it’s geared more toward users than developers.  So much of the first few days of work were spent fumbling in the dark.  But I eventually pushed through it and got things working.

I was surprised by how many default widgets were supplied with Protege.  Once I got up to speed and figured out how to get a tab installed, I was actually able to drop in a class tree and some list boxes populated from the tree without a whole lot of trouble.  However, the widgets did not seem designed for developers to be able to customize easily.  I could not find a trivially easy way to make the class tree just a plain tree.  I did not want any of the editing functions normally associated with the class trees in other tabs.  Same for the list boxes.  I just needed them to show a list of elements and respond to selection events, I did not need any of the editing features.  Also frustrating was some of what I would consider key functionalities where not present, or no-ops in the default implementation, such as the clearSelection function on the list boxes.  Again, more time spent customizing stuff.  Later in the process, once I had a working draft, I did try some of the widgets from the OWL plugin, which I had a little more success with, but not much.

All in all, the experience was less painful than I expected it to be.  The code definately came together quicker that I originally thought.  But if I was going to do it again, I’d definately consider coding bits of it from scratch rather than using widgets from the core codebase.  I struggled at times for too long trying to overcome some of the over-engineered bits of Protege.  All of this work has made me interested in the Protege 4 effort at Manchester.  I have yet to play with their beta, but I’ve heard some good things about it already, and I look forward to mucking about in their code and fiddling with the tool.

Until next time, stay classy cyberspace.

This entry was posted on Tuesday, April 24th, 2007 at 2:00 pm and is filed under CandP, Explanation, Protege, SemWeb. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.