TopBraid's Form Layout Editor
Most ontology development tools including Protege, Swoop and TopBraid provide form-based user interfaces to display and edit the details of classes, properties and individuals. Depending on the type of resource, these forms typically display different characteristics, e.g. subclass or disjointness relationships for classes, range definitions for properties, and an area for annotation properties for all. The selection of properties that are shown on such forms is typically encoded in the tool, based on introspection into the available values of the subject.
One of the distinguishing features of Protege (at least up to version 3) has always been a forms tab that enables users to customize what information they should edit and how forms would be laid out. This feature continues to be very popular because it provides some control over how instances or "knowledge" should be entered by domain experts in the most appropriate way.
As of the new milestone version 1.4.0, TopBraid Composer catches up with Protege, and provides similar capabilities like Protege's forms editor, but custom-tailored for RDF and OWL. TopBraid users can now customize how property widgets are grouped and laid out, and the resulting form settings can be used within TopBraid Composer as well as other RDF-based applications such as web forms.
Here is an example customized form for instances of a Person class:
As you can see on the screenshow above, users can specify that values of "first name" shall appear to the left of "right name", and that there shall be visual separators (horizontal lines) in appropriate places. The corresponding forms editor page looks like this:
Those familiar with the Protege forms editor may recognize that we have chosen a new approach. Protege's layout algorithm is essentially pixel-based, i.e. you can freely position and resize widgets on a virtual screen. From TopBraid's RDF/OWL-centric perspective, using hard-coded coordinates are not the best choice, because RDF resources assume an open world, where properties and their cardinality are much more unpredictable than in Protege's traditional closed-world metamodel.
Therefore, form design in TopBraid is based on loosely defining groups of properties with similar characteristics, and on roughly defining the relative layout of widgets to each other. For example, a form layout can instruct an application that all annotation properties shall be grouped into a corresponding annotations section on the screen. The actual layout is then determined by dynamically dividing the available space, possibly into 2 or more columns.
In order to implement this, I designed a simple forms ontology in RDF Schema. Forms settings are instances of this forms ontology, and can therefore be used by any application that can parse RDF. The current version of the TopBraid forms ontology looks like the following:
Some details about this ontology are described in TopBraid's Eclipse help pages, but those familiar with SWT and Swing may recognize that I borrowed some ideas. I am sure we will add more features to this design in the future, but for now this is a simple yet flexible architecture for RDF/OWL forms. Our users will be able to use TopBraid Composer to create ontologies and customize form layouts, and then use exactly the same layout settings for web-based applications. Early next year, TopQuadrant will publish web server components that will enable multiple users to view and edit ontologies and instances based on these form layouts, but with Ajax-based thin clients instead of a fat Eclipse-based user interface. We hope that this tool support will smoothen out some rough edges in the development process for semantic web and mash-up applications.