Ontology-Driven Automated Generation Of Data Entry Interfaces To Databases

. This paper discusses an ontology based approach for the automatic generation of data entry interfaces to databases. An existing domain ontology is mapped to a system domain model, which a domain expert can then specialise using their domain expertise, for their data entry needs as required for individual projects. Based on this specialised domain knowledge, the system automatically generates appropriate data entry interfaces with the aid of a presentation model. By constraining the data entered to a term definition ontology and utilising appropriate defined domain terminology the quality of the collected data can be improved. Compared with traditional model-based user automatic interface development environments, this approach also has the potential to reduce the labour requirements for the expert developer, as the applied ontology provides initial domain knowledge to the system.


Introduction
Designing Data Entry Interfaces (DEI) which allow the capture of high quality data to databases without overburdening users remains a significant challenge in database and user interface research.It is common to present forms-based user interfaces to allow data entry to the database.These forms, whilst often automatically generated, are generally simplistic, being designed to conform to the structure of database tables (or views) and at best can only constrain data entered to conform to the system data type associated with the particular table attributes.In most databases many attributes are stored as character strings, for which it is difficult to ensure consistent use or data quality, especially in terms of their semantics related to the domain of the attribute.In order for data to be meaningful in the long term and to allow data integration across databases, it is important that the semantics of the data are captured along with the actual data.However, achieving this without placing undue requirements on users has proven difficult.In this paper we present a semi-automatic data entry interface generation tool to help improve the quality of data entry to databases, the system generates an interface that reflects the semantics of the data as captured in a domain ontology.
A domain in which the problem of capturing semantically well-defined data is important is that of biological taxonomy, the branch of biology concerned with the classification of organisms into an ordered hierarchical system of groups reflecting their natural relationships and similarities.In the Prometheus projects we are investigating tools and techniques to aid plant taxonomists to capture and interact with their data.In particular we have developed database models for storing multiple classifications [1,2] and data visualisation tools for exploring multiple overlapping classifications [3].Currently we are developing tools for allowing plant taxonomists to describe the specimens used during the classification process.This classification process is based upon the identification and description of variation between different plant specimens.A key task for taxonomic projects therefore involves describing the characteristics of a number of specimens.Currently taxonomists capture these specimen descriptions using paper forms (proformas) that are designed specifically for particular projects, to reflect the characteristics of importance for differentiating specimens in the plant group under study.These characteristics will vary between plant groups.Some electronic data formats have been developed for capturing taxonomic characteristic data [4,5,6 ], but do not address the semantic standardisation and quality of data stored [7].
During our research it became apparent that there was no agreed vocabulary used by taxonomists when describing their specimens.This meant that although specimen descriptions were comparable within one project, it was impossible to compare descriptions across projects undertaken by different taxonomists and possibly even by the same taxonomist at different times.This led us to develop a data model of plant descriptions and an associated ontology which defines the terms used in describing plants [7].Taxonomy, as a traditional discipline, is resistant to changing working practices, where extra time requirements to record higher quality data would be imposed on the individual taxonomist.This is particularly emphasised by the fact that any improvement in data, tends not to benefit the taxonomist capturing it, as much as other taxonomists who interpret it later.We therefore wanted to improve the semantics and rigour of the recorded data whilst minimizing the burden of data capture and still allowing taxonomists to adequately describe their specimens.Although we describe our work in the context of plant taxonomy, we believe our approach is applicable to any domain where the capture of the semantics of the data in the database is important.
Creating appropriate, good quality data entry interfaces (DEIs) for databases is traditionally a difficult and time-consuming process for a user interface expert.This mirrors the situation in graphical user interface development in general.In addition, creating appropriate DEIs specifically for the needs of complex databases is a neglected field of research.Two relevant strands of research do however continue to address the problem of improving the generation of UI.In one strand, research into model based user interface development environments [e.g. 8, 9, 10] and other development environments [e.g.11] attempt to combine abstract modelling with a more systematic approach to interface development.In these methods the UI developer investigates and models their understanding of the domain (as well possibly as the task, presentation and layout models), to specialise the interface design for that domain.Abstraction in itself does not free the UI developer of the need to select appropriate interaction objects (although they may only be selecting abstract versions of them, with the details of the concrete coding being done automatically [ 12]).A convergent strand of research concerns automatic UI generation.Automatic UI generation is often based upon some form of model based solution or abstract design, which uses a presentation model to control the selection and layout of DEIs, based on the modelled tasks and/or domain (e.g.Janus [8], and Mecano [13] primarily use a domain model whereas Trident [14], and Modest [15] primarily use a task model).These approaches still require substantial investment by a UI developer, particularly if they are to be successful in creating a useful domain specific interface, and Novak has observed that.'Nobody will create applications using specifications (models), if they can do it faster directly editing' [16].This is doubtless one of the reasons that model based approaches have so far failed to achieve widespread commercial adoption, despite their strong research base [17].
Database interface research tends to lag in regard to general database research [18] so whilst there have been advances in database applications and data modelling to effectively store complex data, there has not been equivalent advances in approaches which promote the ability to capture rigorous data for such applications.Ontologies are increasingly used to describe and define complex data.Using an ontology to control the data entry for a database has the potential for ensuring that better quality data is captured and that data from differing data providers will be compatible.It may also allow a DEI to be developed which allows domain users to enter data using terms with which they are familiar but which are clearly defined semantically.Existing ontology based approaches for data entry are, however, generally still limited to using automatically generated forms-based data entry interfaces, unless manual editing is used (e.g.Protege [ 19]).These systems are designed to populate a knowledge base describing relationships between described instance items of interest, rather than regulate the capture of the description of a complex concept.An alternative approach for UI generation involves using an ontology to provide domain knowledge to a system which can automatically generate a user interface based on a presentation model to capture data.An ontology-based approach of this kind has been proposed in regard to universal UI design [20] but the approach has not been widely investigated, nor has it addressed the needs of rigorous data entry.This paper presents an ontology-based approach to semi-automatically generate data entry interfaces to databases.The remainder of the paper is organised as follows: section 2 provides an overview of the conceptual approach and introduces the specific domain of biological taxonomy.The models used during the process of defining the data requirements for the data entry interface are described in section 3. Section 4 considers the models and processes involved in generating the data entry interface.Finally, section 5 concludes the paper.

Overview of the ontology driven automatic data entry interface generation approach
In the design of our system for generating data entry interfaces to databases we have adopted a model based approach in that we have task, domain and presentation models.Figure 1 shows the basic ontology driven approach for generating data entry interfaces for the capture of descriptive data about concepts of interest.In taxonomy, the domain expert and the domain actors are usually the same individual, though that is not a requirement of the approach.

Task Model
The task model is pre-determined to be the general task of data entry for a database.The Data Entry Task Model (see figure 1) is encapsulated within the system.The only aspect related to the task model which is modifiable is the order in which the data entry task is completed (see Section 3).

Domain Modelling
We use a series of domain models to represent domain knowledge (see figure 1).

Abstract Domain Model
Our system is designed to capture data concerning any high level concept that may be sub-divided into a hierarchy of defined constituent sub-concepts ('Description Objects') that are themselves described by instantiating Attributes that they possess.Each Attribute of a Description Object can be instantiated within the limits of its value constraints.These value constraints might restrict entered data (such as the data type or numerical range of entered data), or define selection from a limited set of Value Objects.A Value Object represents a defined concept which can be used to instantiate an Attribute.Additional entities (modifiers and units of measurement) allow more detailed description of Attributes and their value constraints.This data format is captured in an Abstract Domain Model (see figure 1).This data format should be widely applicable and could represent physical or abstract concept domains (such as a control system process or an academic department).

Domain Ontology -The Angiosperm Domain Ontology
Initially, in order to instantiate the Abstract Domain Model with actual domain knowledge, we map an appropriate existing domain ontology to it1 , to create a Concrete Domain Model (see figure 1).Our approach assumes the existence of an appropriate domain ontology which does not necessarily have to be created solely for use by this system.Ontology is a widely used term, with a variety of nuances of meaning, even within the IT field [21].The commonly quoted ontology definition 'a specification of a conceptualisation' [22] is generally appropriate for our usage.Specifically, in this system, we use ontology to mean a semi-formal, constrained and structured form of natural description language, with defined terms and possible relationships between them.Even so defined, ontologies can contain many different objects and relationships with various semantics.
In our example domain, an ontology to control the description of a set of plant specimens is being used as a domain ontology.Classical plant taxonomists describe plant specimens in terms of their observable characteristics, and interpret patterns of shared characteristics to e valuate relatedness between specimens in order to define taxonomic groups and compose a hierarchical tree (taxonomy) of relationships between these groups.As part of a project to attempt to standardize the composition of taxonomic descriptions a defined terminology for the description of flowering plants (angiosperms) has been created in collaboration with taxonomists from the Royal Botanic Gardens, Edinburgh [7].The ontology is composed of 'Defined Terms' (terms with associated definitions and citations) and relationships between these terms.As shown in figure 3, there are three major subclasses of defined terms which can be used to create descriptions of biological specimens: Structure terms representing all the possible anatomical structures of a given specimen (e.g.leaf, petal, stamen); Property terms, which represent possible Attributes of a structure that might be described (e.g.length, shape, colour); and State terms which represent the actual values for a qualitative property of a given structure (e.g.round, yellow).In our description model 'quantitative properties' are scored by numerical values.'Ispart-of' forms the central organising relationship for the ontology, and allows representation of a hierarchy of all the possible structural relationships found on any given specimen (e.g. a blade is potentially part of a leaf, or part of a leaflet, which itself is part of a leaf ).Additional relationships in the ontology group states and relate them to a descriptive property, and capture permitted relationships between groups of states and the set of structures that they may be used to describe.

Concrete Domain Model
The potential variation in composition of domain ontologies makes their automatic adaptation for a domain model a nontrivial task [ 23 defying automatic mapping of the domain ontology, which thus requires the intervention of an IT expert actor.The IT expert makes a mapping between the Abstract Domain Model and the particular domain ontology's conceptual model.This allows the system to derive the Concrete Domain Model from the imported domain ontology.It is only necessary to perform this mapping once for a given domain conceptual model (ontology).Where the database schema and ontology conceptual model are based on the same domain conceptual model, this mapping also allows the system to format the entered data for transfer to the database application.Where this is not the case a second expert mapping would be required for each database schema.
In order, to perform the domain ontology mapping, a number of key objects and relationships need to be identified or derived.At the fundamental level, Description Objects need to be identified along with a primary Description Object Hierarchy inter-relationship and root Description Object(s) (to form a Description Object Hierarchy).Attribute objects must be identified or derived from ontology terms and/or relationships between Description Objects and possible Value Objects.In addition the applicability of Attributes to Description Objects is identified.Value Objects must be identified from the descriptive terms which could form possible values of a Description Object via an Attribute relationship (Value Objects can also be Description Objects themselves or instances of Description Objects).Beyond these basic terms and relationships, the Abstract Domain Model can have modifiers, units, synonym relationships and various other aspects mapped to it (see section 3 for examples).
Mapping the Angiosperm Domain Ontology (figure 3) to the Abstract Domain Model (figure 2), 'specimens' represent the 'high level concepts' that are described.Their constituent 'structures' map to 'Description Objects', and their 'is-part-of' relationships form the 'Hierarchy Relationship'.'Properties' are the 'Attributes' of a Description Object and 'states' form 'Value Objects' which belong to an 'Attribute'2 , and are constrained over a 'Value Domain' defined by the permitted grouping relationships between structures and states.

Specialised Domain Model
A data entry interface based on the whole angiosperm domain ontology would be too large for usability and would cover a much larger number of structures and characteristics than a taxonomist would utilise in any one taxonomic project.Individual projects would typically be restricted to only a small subset of the angiosperm group of plants.Additionally, taxonomists are interested in different sets of specimen characteristics dependent on the focus of their work.The exact data requirements of a given taxonomic project must therefore be established.Normally, taxonomists do this by creating paper-based templates (proformas) for each project, which have entries for the major describable characteristics of the specimens that they wish to record.Our system provides an electronic equivalent to this process by allowing taxonomists to create Specialised Domain Models based on the angiosperm domain model, which enables the system to present them with data entry forms based solely on the data and semantics relevant for their particular project.

Presentation Model
There are two presentation models in the system one for ontology presentation and one for data entry (see figure 1).In order to allow the expert taxonomist to create a Specialised Domain Model, the system uses a modelling tool (the 'Specialisation Interface') which presents the entire angiosperm domain model for exploration and editing.The ontology presentation model is used in this tool, to provide a general layout presentation for displaying ontologies based on the Abstract Domain Model.This presentation model is also utilised to display aspects of the Specialised Domain Model in the final data entry interface.The ontology presentation model was derived by user requirement and evaluation testing and is now captured within the system.The data entry presentation model determines the layout and selection of interaction objects for the data entry interface.Different data entry presentation models could be utilised as plug-ins.User testing and evaluation have also been used to develop one such model.

Summary
Figure 1 shows the interaction of the system and its models.In summary, an existing domain ontology is mapped to the Abstract Domain Model to produce a Concrete Domain Model, which is displayed in an interface, allowing a domain expert to specialise the data entry requirements for a project.The system interprets the domain, task and presentation models, to generate a data entry interface which facilitates the entry of data by domain actors.The system then exports the data which is mapped back to the domain database application.

Domain and Task Model Specialisation Tool
This section describes the process by which domain experts specialise the data requirements for a particular project.The result of this process is the Specialised Domain Model and the default task ordering of the Task Model.The specialisation tool consists of an interface (see figure 5) which allows the user to interact with the domain model and task order.The domain expert can determine which Description Objects (i.e.Structures) they wish to include in the Data Entry Interface (DEI), the Attributes of those Description Objects they wish to use, and the specification (constraints) of those Attributes.The system interprets the task and Concrete Domain Models using its ontology presentation model to determine the layout and interface interaction objects, including the use of colour or icons to indicate summary information (such as greying out excluded elements or warning icons for Attributes with no possible values), as summarised in Table 1.

Specialising the Description Object Hierarchy
A view of all the description objects (i.e.plant structures) is presented in a Description Object Hierarchy (figure 5A), through which the user can select description objects for inclusion in the DEI.The description object hierarchy view is primarily based upon an interpretation of elements of the Concrete Domain Model as summarised in Table 1.
In addition to interpreting the Concrete Domain Model, the Task Model is interpreted to provide the order of the Description Objects (presented as the order they appear in the Description Object Hierarchy tree) which can be modified by the user.Any alterations to the default task order are captured in the Task Model.This functionality is provided to reflect the working practice o f taxonomists, who, within the general task of describing specimens, may want to specify the order in which they describe the particular characteristics of the specimen, to fit with traditional biological description methodologies.

Specialising Attributes of Description Objects
By selecting Description Objects in the hierarchy, the user can access its potential Attributes (i.e the properties of the plant structure to be described).A second hierarchical view is presented which allows users to select Attributes for inclusion for a given Description Object (figure 5B).This Attribute-Value Hierarchy accesses the Attributes3 and their potential Value Objects by interpreting the Concrete Domain Model (see Table 1).The user can also use this interface element to alter value constraints by specifying the set of possible Value Objects.An Attribute Specification interaction object (figure 5C) provides access to Attributes selected in the Attribute-Value Hierarchy, allowing further specification such as determining numerical range constraints, or numerical precision.Attributes can also be more radically varied by adding relational modifiers which can change the nature of an Attribute by relating it to another Description Object and Attribute (e.g. to capture the ratio of leaf-blade-length to stemheight).Other Attribute specification is aimed at affecting the data entry interface without modifying the fundamentals of the data in the domain model.This includes influencing the selection of interaction objects (e.g. by varying the importance of multi-media display), or affecting presentation aspects (e.g.changing the displayed name of the Attribute instance).

Specialisation Restrictions
The domain expert in this specialisation process cannot transform the domain model in such a way as to make it inconsistent with the original domain ontology, for example they cannot change Description Object inter-relationships or use an Attribute for a Description Object which does not have an appropriate relationship in the domain model.This ensures the data exported by the system is compatible with the data model underlying the original ontology.The domain expert cannot directly alter the Data Entry Presentation Model (for example by choosing the actual Data Entry Abstract Interaction Objects (AIO), although they can alter the data in the Specialised Domain Model upon which determinations are made by the Data Entry Presentation Model).This ensures a modelling split between data determination and presentation, thus avoiding confusion between the two different processes.

Domain Expert User Considerations
Editing domain models in model based approaches is usually a task reserved for IT experts.In our case, a domain expert is performing this operation, so the interface must be configured towards a user who is not necessarily familiar with modelling or ontological terminology.The ontology presentation model in the system attempts to aid ease of understanding by using appropriate domain terms based on the domain ontology mapping (e.g.referring to structures instead of Description Objects).In addition the presentation model generally interprets the ontology to attempt to allow easy navigation and feedback, with easy access to related domain knowledge (e.g.access to definitions -see figure 5A for example of mouse-over definition access).Object definitions drawn from the domain ontology provide users with the knowledge to make informed editing choices, thus supporting the eventual capture of semantically good quality data.Definitions are provided in a variety of means, including mouse over pop-up summaries and a definition viewer gives additional details of selected terms on request.Evaluation by taxonomists from the Royal Botanical Gardens Edinburgh showed that the Description Object hierarchy captured in the domain model allows users to navigate the potentially large description space, using their own domain knowledge.

Data Entry Interface
This section describes how data is captured based on the specialised domain and task models.As the details of the data to be entered have been determined by a domain expert actor, there is no further direct intervention by an IT expert before the data entry interface (DEI) is generated.Some fixed design decisions (such as basic architecture layout) are captured in the system, the DEI being generated by interpretation of the Specialised Domain, Task and two presentation models.Working with one high level concept instance (i.e.'Plant Specimen'), a domain actor enters data for the Attributes of one Description Object (i.e.'Structure') at a time.

Navigating the Data Entry Interface
The DEI provides a view of the Description Object Hierarchy (figure 6A) and presents a series of windows with groups of interaction objects for data entry (figure 6B).The default order of the Description Objects and Attributes presented by the system to users for data entry is interpreted from the task model and can be overridden by the data entry user by selecting Description Objects directly from the Description Object Hierarchy display (figure 6A).This display is controlled by the ontology presentation model, as described in the previous section, although in this case it interprets the Specialised Domain Model and is not editable.In the DEI context, the display uses colour, icons and mouse-over text to indicate summary data about the data entry status of the current specimen (for example by to represent whether a structure has been skipped over in normal task order) rather than specialisation summary data.By providing navigation context and summary data for each Description Object, the user is assisted in making informed data entry decisions.
For each Description Object, the DEI generates a grouped set of Attribute Presentation Units (figure 6B), which are complex data entry interaction objects that contain all the data and interaction capability required to enter data for one Attribute of a Description Object.The data entry presentation model controls the level of grouping.In taxonomy we group all Attributes for one structure in one window, which fits with their observational methodology.An appropriate grouping, combined with the hierarchy view and the nature of the pre-determined task, offsets one of the traditional drawbacks of automatic generation, that users require information from multiple objects in one window [24], as all the required information to make an informed data entry decision should be available.The layout of the Presentation Units within the grouped screen is at present controlled by a 'place one below the other strategy', however, more complex layout strategies could be determined by the Data entry Presentation Model.

Entering Data in Attribute Presentation Units
The user enters data for individual Attributes of a structure using a Presentation Unit.A Presentation Unit consists of four major components to support data entry: three data entry interaction objects; and an Attribute display with the data required for the user to make meaningful data entry choices (such as Attribute name, current entry status).This data is interpreted from the domain model and the presentation is fixed and captured in the system.
The primary data entry interaction object controls selection or entering of the values.The implementation of this interaction object varies.The abstract implementation is determined by the DE presentation model, which selects implementations from a system library of Attribute Interaction Objects (AIOs).These AIOs are internally specialised by the relevant Attribute and related data captured in the domain model to create the concrete interaction objects.This specialisation controls aspects such as internal layout management (for example using value cardinality to control number and layout of checkboxes), the display of names and icons, etc.In order to determine an appropriate AIO the DE presentation model accesses various defined criteria of the underlying Attribute object data.
One criterion that can be used to determine this IO, is value type, of which there are two basic choices -Value Object selection and text entry.Selection involves choosing from a set of Value Objects, whereas text entry allows the user to enter data as desired.As this approach is based on an ontology for ensuring rigour of collected data, text entry is usually limited to numerical data entry, as free text entry would allow recording of data not compliant with the description ontology.Data type is often used as a criterion for making automatic IO selection choices, in this case the data type of the allowed values of the Attribute is used.Multi-media representation of descriptive terms is very important in taxonomy, as in many other domains.The presence of multi-media definition representations for possible selectable Value Objects, is thus another criterion which can be used by the presentation model.The importance of the multi-media representations may also vary from Attribute to Attribute, and a tag can be assigned to an Attribute to specify this in the domain specialisation interface.Other common criteria which can be accessed by the presentation model include data cardinality, data precision, numerical range constraints, etc.

Controlling Nuances of Entered Data
The remaining two interaction objects in a Presentation Unit control the adding of semantic nuances to the data.The first of which is an interaction object for adding applicable modifiers to the entered data (such as frequency modifiers like 'rarely', 'usually', etc.).The available modifiers are based on the Attribute links captured in the domain model (see figure 2) and allow users finer control of the entered data; A second interaction object controls the interpretation of multiple values.Initially one Presentation Unit is displayed for each Attribute requiring instantiation.The data entry process however might require additional Presentation Units being generated to capture nuances of description.
A common example of this situation is in distinguishing 'AND-ing' from 'OR-ing'.This applies where a number of values for the same Attribute are applicable to every individual physical instance of the Description Object, as opposed to the situation where the instantiated Attribute has different values on different individual Description Objects (e.g. to distinguish between a specimen whose individual petals are white and purple versus a specimen whose individual petals are either white petals or purple petals).As the permutations of this situation can be quite complex, the domain actor is required to instantiate one Attribute Presentation Unit for every permutation of individual Description Object instances.The system can replicate Presentation Units to allow entry of these different permutations as required by the domain actor using the DEI.This process is made less intrusive by not basing the grouping of Presentation Units upon the available screen space, but instead allowing the expansion of effective screen space using scrolling.For example (as seen in Figure 6B) a taxonomist entering data for a specimen which had some purely white petals and some petals that were both white and purple would select white in the petal colour Presentation Unit, and click on 'Enter Another Score' button.This would generate a copy of the petal colour Presentation Unit, where the taxonomist would select both white and purple in a single Presentation Unit.

Exporting data
Once a user has entered the data for one high level concept instance (i.e. an individual plant specimen), they can enter data for other instances of the concept (i.e.further specimens).The data for each specimen can be exported to the database when desired.As stated earlier, this exported data is formatted using the mapping between the domain conceptual model and the Concrete Domain Model.
If necessary the interface can, by a reverse procedure, be reloaded from the database with specimen data collected earlier.

Conclusions
The system described in this paper utilises domain knowledge from a domain ontology and domain experts to specify the data requirements of an automatically generated data entry interface to databases.This approach aims to improve the quality of data entered by users, without overburdening users or interface developers.In Szekely's retrospective [24] this work would fall into the model based automatic interface generation approaches, specifically those which primarily allow users to access and specify a domain model.This system's domain model is, however, based on an existing ontology to ensure that the semantics of the data are maintained.By tying the entered data to a domain ontology, semantically high quality data can be generated and be entered into a database based on a data model related to the original ontology.
Despite their potential benefits, model based automatic generation approaches have not been widely adopted commercially and have been criticised as being u nable to produce quality, appropriate interfaces [24].Our approach, however, offers access to a modelling tool for domain experts to specialise the domain model rather than to interface developers.This specialisation can be done for individual projects, thus improving the appropriateness of the generated interface.An appropriate, good quality interface is a useful element for ensuring that captured data is an accurate representation of the intent of both the data entry user, and the project designer in a multi-user system.Furthermore, by limiting our approach to a descriptive data entry task, we have already gone some way to limiting the possible permutations of the interface, allowing the presentation model to be more appropriate.Focussed approaches also tend encourage wider adoption of new approaches than universal approaches that attempt to solve all problems at once [25].Another contributory factor in the lack of quality in traditional automatically generated interfaces, lies with the difficulties of automatically selecting appropriate AIOs using a predetermined presentation model.By focussing on data entry tasks and allowing tailoring of the data entry presentation model to particular domains, this approach supports a more appropriate AIO selection.
By using the domain ontology and domain experts to create the Specialised Domain Model, the approach provides further benefits in the avoidance of time consuming and possibly distorted domain knowledge acquisition by a UI expert from a domain expert who must possess or acquire this knowledge for the purposes of their work in any case.A modelling tool has been developed for the system which has been tailored for easy and informed use by domain experts who are not familiar with modelling techniques.
Initial informal user evaluation for our approach has been positive.It has shown for example that taxonomists are able to navigate and interact with the Concrete Domain Model in the Specialisation Interface to create effective Specialised Domain Models, that taxonomists appreciate the value of access to the exact semantics of the domain terminology being used and that data semantically consistent with the Angiosperm Ontology can be collected and exported to a database.More extensive user testing is planned, both in depth with the existing Angiosperm Ontology and with other domain ontologies.Our approach has been applied to the instance field of specimen description in plant taxonomy, however we believe the approach can be more widely applied in data entry applications, particularly where semantically high quality data capture is important and where there are variations in the data requirements for different projects.The provision of supporting tools for use by IT experts in mapping from Domain Conceptual Models to the system's Abstract Domain Model, and for generating alternative Data Entry Presentation Models will ease expansion of this approach beyond Biological Taxonomy applications.
We would like to acknowledge and warmly thank BBSRC for funding of this research, and the Royal Botanical Gardens, Edinburgh for their help in evaluation and development .

Figure 1 :
Figure 1: Ontology Driven Automated Generation Of Data Entry Interfaces To Databases Approach.In taxonomy, the domain expert and the domain actors are usually the same individual, though that is not a requirement of the approach.

Figure 2 :
Figure 2: Abstract Domain Model.This is the conceptual model for controlling domain knowledge in the system.The hierarchy of Description Objects is formed using the Hierarchy Relationship.Some additional non-fundamental details, such as synonym relationships are not shown for clarity.

Figure 3 :
Figure 3: Major terms and relationships represented in the angiosperm domain ontology.

Figure 5 :
Figure 5: Specialisation Interface Screenshot.Panel A represents the Description Object Hierarchy.B represents the potential Attributes and their related possible values for a selected description object (The Attribute-Value Hierarchy).Panel C is an Attribute specification interaction object to allow finer control of the Attribute constraints and modifiers.

Figure 6 :
Figure 6: Data Entry Interface Example.6A is the Description Object Hierarchy view (i.e.plant structures) providing both compositional context and a means of overriding the default data entry ordering.6B is a group of Attribute Presentation Units for the selected Description Object (i.e. the structure with the compositional context Inflorescence-Perianth-Corolla-Petal).(The bottom two Attribute Presentation Units are copies of each other, as explained in the example in section 4.3 below,)

Table 1 :
Creating the modelling tool interface.This table shows the mapping of the Concrete Domain Model to the Specialisation Interface using the Ontology Presentation Model.The Task Model controls node ordering.