Quasi-Hierarchies (March 2006)
Pieces of the OME data model share a recurring theme that we have been calling "quasi-hierarchical" organization. Roughly speaking, a quasi-hierarchy is a tree that can have
- multiple root multiple roots, and
- multiple parents for any given non-root node. A parent of a node in level n in the graph must be a node from level n-1.
Several quasi-hierarchies in OME also have the appealing quality of being having a small number of levels with significant numbers of items at each level. These "short and broad" structures lend themselves well to compact, interactive browsing:
- Projects, Datasets, and Images.
- Analysis chains, Modules, and Semantic Types.
- Screen, Plates, and Wells.
Of course, additional quasi-hierarchies may be defined through new STs.
These structures have the additional appealing quality of being largely, but not completely orthogonal. As a result, they can be used individually and/or jointly to navigate through an OME data store in order to identify data of interest.
These ideas were explored in our Workshop paper at CSB 2005, and implemented in the qnav browser, which is described in a forthcoming paper from the IEEE 2006 Symposium on Biomedical Imaging. (Both papers are copyright encumbered, but available on request).
Running Qnav
Qnav runs against its own, homegrown OME data retrieval back-end. This back-end must be running alongside a reasonably recent OME database (I use 2.19) which can be accessed from the OME Perl server. Although admittedly a hack, this gets things done. More on this topic below.
Qnav can be run either directly against JDBC or via Spring's remoting facilities. The latter configuration requires a running Tomcat installation - I use Tomcat 5.5.9.
You will need reasonably modern versions of Java and Ant to build and run qnav. Development has been done with Apple's implementaiton of Java 1.4.2_07, and Ant 1.6.5.
Qnav and server
Implementation of Qnav began at a transitional point in the process of developing Java clients for OME. Performance issues had already made OME-JAVA's XML-RPC-based retrieval of OME data seem unappealing for future development.
Qnav used spring and tomcat to set up a back-end that could provide Java objects to a client program, either via JDBC or Spring's remoting facilities through tomcat. All data retrieval is done via hand-coded SQL and code that maps SQL results to Java objects.
