Ontologies can be used to help supplement information on forms or provide lists of options for completing forms.
Form Generation System | Model Reader System | Configuration Reader | Ontology Services Factory
Each section is structured to address purpose, description, design considerations, scope of effect, and relevant code packages.
An ontology service allows end-users to mark up a form field with terms that come from a controlled list of terms. Although its scope of effect is a single form text field, it may use other information about the current form, the user or document to help constrain the choices of terms it provides to the viewer.
|Purpose||To generate UIs for Project35 which suite displays on desktop and Tablet PCs.|
Project35's architecture maintains a rigid separation between the
structures that hold data and structures that present them to an
end-user. The model aspects are represented by the Native Data
Structures, information for which can be found in the Core Architecture section. The view aspects are represented
by the following packages:
General Classes for Generating Desktop Project35 Forms
When end-users invoke the "run_project35" script, it spawns an instance of Project35 Application. The object prompts end-users to load a model and it produces template record definitions that can be used to populate a document.
General Class Relationship Diagram for Generating Desktop Project35 Forms
Classes for Generating Edit Fields in Desktop Project35 Forms
The image below describes a more detailed view of UI classes
that are used to render text fields, identifier fields, combination box fields and
Class Relationship Diagram for Rendering Edit Fields in Desktop Project35
Classes for Generating List Fields in Desktop Project35 Forms
Class Relationship Diagram for Rendering List Fields in Desktop Project35
Classes for Generating Forms in Tablet Project35
Tablet Project35 was designed to support the same data models as those used to run Desktop Project35. However, we envisioned that different forms of deployment would be used at different stages of editing the same document. End-users will tend to use Tablet Project35 to do simple data entry tasks which require them to be at a work site such as a laboratory or a remote field location. They will tend to use Desktop Project35 to support complex data entry tasks and to fill in the rest of the document.
Tablet Project35 was designed with the following principles in mind:
The classes used to generate forms in Tablet Project35 are in the
First, some of the menu items have been removed. For example, the File Menu does not contain an "Export to Final Submission Format" button. This feature was deemed non-essential because it was likely this would be done with the Desktop version.
To reduce the number of pop-up dialogs, some features were altered so they used a stack of screens instead of separate windows. For example, consider the "Window" feature in Desktop Project35. When end-users switch from one file to another, a new window grabs focus. In Tablet Project35, only one file is shown at a time. When end-users change the current file, it changes the file loaded in the current window.
As another example, the
To economise on screen real estate, the NavigationTree was removed. It is accessible via the "Where Am I" button, which pushes a view of the
Finally, the right click mechanism for activating ontology services is replaced by pressing a "Mark-up" button which appears at the end of a text field.
Initially, Project35 tightly coupled data objects with the objects that viewed them. This led to severe performance problems because Java would potentially be managing thousands of UI components, each using a collection of Swing objects. This led to stripping the native data structures of references to UI components. Eventually the production of form field views was centralised in the class
The most significant change in the form generation classes came when
Tablet Project35 was developed. Initially we wanted to run the software on a PDA. However, these devices often require a specialised form of the JVM which does not support Swing components. Although the native data structures were stripped of references to UI components, they still had one crucial reference to the swing libraries: the
It became clear that we had to make some changes to the forms. The
The development of
|Scope of Effect||The UI classes are probably not used by anything other than classes in Desktop and Tablet deployment packages.|
|Relevant Code Packages||The classes used to generate user interfaces in Project35 are in the
Back to top
|Purpose||To coordinate the reading of the XML Schema and the Configuration File.|
|Description||This system is a construct for classification of coding areas that are found within the
|Design Considerations||We wanted a system that was capable of supporting a replacement of the Schema Reader. This can be accomplished by having the rest of the system interact with an abstract interface rather than a specific implementation something that interprets schemas. We needed a system that could extract information about data structures form the schema and another thing to extract information about form properties that were related to that schema. This system's role as a whole is to obtain enough information/properties to drive form generation.|
|Scope of Effect||Nothing else uses this as it's an abstract concept but parts of it will be used in other places as in the Configuration Reader. The components of the Model Reader System are used to synthesise Native Data Structures that are then used by the rest of the program. Most of the rest of the programme will only use the Configuration Reader.|
|Relevant Code Packages||
Back to top
|Purpose||To manage options for configuring a data entry application that are not expressed in the XML schema.|
Project35 interprets the XML Schema to determine properties of the
data entry application. However, many of the configuration options
can’t be expressed in the XML Schema language, so they are managed in
Data modellers use the Project35 Configuration Tool to produce the file "ConfigurationFile.xml", which describes all the application properties that are associated with XML Schema concepts. When the Project35 application starts, it reads the configuration file and holds the information in instances of data container classes. These classes have properties which are analagous to classes defined in the XML Schema for the Project35 Configuration Tool (See the XML schema for the Configuration Tool in
Various parts of Project35 use the Project35 Configuration Reader to obtain
configuration data that are used to render the application. For
Other Configuration Files
Project35 maintains two other configuration files in the config directory of a model folder: SessionAspects.xml and FileExtensionsToLaunch.xml
The SessionAspects.xml file contains information about the most recently accessed files, and is managed by the class
The FileExtensionsToLaunch.xml file associates file extensions with shell commands used to launch other software applications. The mappings are used when users press the "View" button on a URL Field View. If the file specified in the text field ends with an recognised extension, Project35 will try to launch an application by making a system call.
It remains the only configuration file that end-users still have to configure. Currently, the
In early incarnations of the software, data modellers had to craft the ConfigurationFile.xml file by hand. The file was awkward and time-consuming to maintain, especially when large XML schemas were being used. This led to the idea of using Project35 to edit its own configuration files. The Project35 Configuration Tool was developed using a schema of configuration properties and a collection of plugins which helped data modellers fill in the forms.
The advent of the Project35 Configuration Tool meant that a configuration file could be designed far more rapidly than it could in previous releases. Enshrining configuration options in an XML Schema also meant it was easy to add new properties.
The configuration options for Project35 expanded to include the selective inclusion of menu items and services which could be associated with a field, record or document scope of effect. With new features came data container classes that held the property values in memory.
|Scope of Effect||
The Configuration Reader is referenced in the file menu classes to determine what features should be included. Many of the classes which generate form fields interact with the
|Relevant Code Packages||Code for
Back to top
|Purpose||Provide a system which allows end-users to mark-up form fields using terms from multiple ontology services.|
|Description||The Project35 Ontology Service Framework manages ontology services which collect and render ontology terms for end-users in some kind of display. The Ontology Services Factory produces an instance of what what the Ontology Services Framework describes below.
The basic unit of information handled by the services is the
Ontology Term Data Structure
The label represents the word phrase that would be presented to an end-user in a display. The unique identifier represents the concept referred to by the term. For example, "cat" and "le chat" are word phrases for the same concept "cat". The concept could have an identifier such as "www.dictionary.org/cat_01". Humans will relate to the label whereas software agents that manage the ontology will relate to the unique identifier.
The collection of related terms does not refer to a specific type of relationship such as "has a", or "is a". The way to determine the kind of relationship of related terms is covered later in this section.
Project35 saves the meta data about selected ontology term in its *.META data layer. More information can be found in the sections on the I/O System and the Meta Data System. The provenance information is important in cases where an ontology term has been reclassified in the same ontology, or if a term has been deprecated.
The Project35 Ontology Service Framework can associate one or more ontology services with a form field. An OntologyService will have at most one
An Ontology Service Comprises at Most One Ontology source and One Ontology Viewer
If a service has both a source and a viewer specified, then terms provided by the source are given to the viewer to render in some kind of display. If only a source is provided, then Project35 associates it with its own default ontology viewer. If only the viewer is provided, then Project35 assumes the agent will combine responsibilities of reading and presenting ontology terms.
The flexibility of mixing and matching source and viewer components is meant to make it easy to integrate legacy components. With this scheme, a developer can wrap the part of an application that parses terms; the part that views terms or both. The same application can be wrapped as a source and a viewer, allowing the same component to be marketable for use in other ontology services.
There are a couple of reasons why developers may want to wrap just a viewer. Sometimes the legacy application may not have a rigid separation between its model and view aspects. In this case, the source may somehow be tied to graphical objects even though its job does not include rendering activities. The viewer could require specialised parser routines that contain information which is non-compatible with the
Another reason is to allow the ontology viewer to take advantage of implementation details in the ontology source. A source hides most of its implementation details from an
The image below describes the
Default Ontology Sources Supported in Project35
The Ontology Viewer Interface
Default Viewer’s Use of Introspection on Ontology Sources
In most cases, data modellers will create ontology services that use
the tool’s default ontology viewer. Although the
Marker Interfaces Used by Ontology Sources to Provide Rendering Tips
Ontology services can ask Project35 questions about what else is on the current form. The
An ontology source or ontology viewer can access this object through the following call:
Developers can use the
A Walkthrough for Selecting an Ontology Term
The process of marking up a form field with a term begins with the end-user right clicking over a starred form field label. In the desktop application, the label will belong to
When the user chooses a service from the menu, the
When the end-user saves the data set to a native format *.PDZ file, the
A number of requirements for ontology services were identified early in the development of the software:
|Scope of Effect||
The Project35 Ontology Services Framework (POSF) is used in all of the Project35 tools created thus far including the desktop Project35 application, the Tablet Project35 application, the Project35 Configuration Tool, and the Project35 Meta Data Editor.
Within the Project35 code base, POSF features are referenced in
|Relevant Code Packages||
The packages relevant to POSF include:
The schema for ontology services is defined in the
Back to top