concept is even possible. To demonstrate this we will build a small application
that takes an ontology prepared by Protege and attempt to generate LaTeX and
then PDF.
For my test data I built an ontology of quality attributes. Every term like
maintainability or performance that was mentioned in the literature was dumped
into this ontology, along with a short description of what it means. This will
later be enhanced to incorporate the various quality frameworks that
researchers have developed to try and bring some structure to this collection.
I then started by using GCJ to compile the Java OWLAPI library so that it could
be linked to my C++ code. After a bit of hacking the Ant build script a
successful build was created. I was able to call this from C++ code and
generate some fragments of LaTeX. Adding in some calls to the dvips and ps2pdf
programs completed the process.
After a bit of work it became evident that the version of OWLAPI that I was
using had a problem with one of the functions that I wanted to use. The release
notes for the subsequent version indicated that this had been resolved, so I
downloaded the latest version and recompiled it using GCJ.
At this point things started to go wrong. The program would build OK, but when
run it would disappear into a loop that steadily used up all available memory.
I tried to run it under Valgrind to determine where the memory leak was, but it
promptly reported that I was attempting to execute an illegal instruction.
Trying it under GDB was no better; it reported a segment violation and showed
a stack trace that made no sense whatsoever. As far as I can tell the code
generated by GCJ was not being loaded correctly by the linker. After a week or
so of trying to get to the root cause I decided that perhaps an alternative
approach was warranted.
The only other solution I can think of for combining Java and C++ is to use CORBA.
The OWLAPI library would be made into a server process and the application would
be a client. This would give the application some additional freedom since we
could now distribute it across multiple processes or machines if necessary.
However, I wanted to use open source and it became apparent that there was no
viable open source CORBA product that had bindings for both C++ and Java. There
were plenty that supported Java and a few for C++, but nothing workable for both.
I was starting to look into passing data between CORBA implementations, which seemed
to be a possibility thanks to standards employed by these products. The idea
of having to support two CORBA implementations, though, was a bit of an issue.
During my CORBA research I came across the ICE product by ZeroC. This product is
open source, has bindings for a wide range of languages and platforms and seems
to be actively supported. It works much like CORBA but without a lot of the
complexity, which I think is nearly always a good thing. After a few experiments
to become familiar with building ICE applications I redesigned the interface to
use ICE generated code and successfully completed the proof of concept.
My work with Protege to develop the quality attribute ontology highlighted a
problem with the visualisation of the ontology. I decided that it would be good
practice to develop an application that would enable its user to graphically
navigate the ontology and to display all the relationships between the entities
of the ontology. I used the GraphViz dot program to generate a diagram based on
the data extracted from the OWLAPI using the ICE generated interface. The
output of dot was set to SVG and I used Qt's SVG and SceneGraph components to
create the visual representation. The result was a program that can quickly
navigate an ontology.
The first increment of the project was thus completed successfully, albeit with
a radically different architecture that was first envisaged. We now have a basis
for designing and developing the software.
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
No comments:
Post a Comment