Specialisation Process
6.4 Ontology presentation model
6.4.4 Mapping tasks to the interface 1 Task summary
Known task Interaction with presentation element Search for descriptive
element
1. Search tree views 2. Use search bar Check for existence of
desired term in ontology
1. Search definitions explorer pane alphabetically 2. Search for an example descriptive element Include descriptive element Relevant tree node (double click or node menu) Remove descriptive element Relevant tree node (double click or node menu)
Change attribute nametag Attribute details panel Fix Score Attribute details panel Specify preferred units Attribute details panel Specify relational or spatial
modifier
Attribute details panel
(select modifier from pull down list to access pop- up guided window e.g. figure 6.11)
Define new attribute relationship
Description object node menu (then select attribute from presented menu list)
Check text definition Mouse-over tool tip on relevant tree node
Check full definition Definition box accessed from relevant node menu Include universal description
object
Parent description object node menu to access pop- up window (e.g. figure 6.4) and select description object
Clone description object Parent description object node menu Change description object
nametag
Description object node menu (access pop-up interaction box)
Determine concrete status Description object node menu
Alter task order Main menu item and description object hierarchy Review specialised domain
model
1. Description object hierarchy tree
1b. Filtered Description object hierarchy tree 2. Data entry interface
3. XML export Export/Load specialised
domain model
Main menu
Table 6.2 shows a summary of the major tasks in the specialisation process including elements of the primary task of specifying attributes. Some of these tasks are discussed in more detail below.
6.4.4.2 Primary user task
To specify an attribute, the user identifies and selects the relevant description object node on the description object hierarchy tree. This gives the user access to the relevant attribute-value tree on which the user identifies the desired attribute. Where appropriate, the user can then identify value objects to be included in the attribute’s value domain in the specialised domain model. Users can include elements using a standard double-click selection technique that is intended to make the task of specifying quick and easy.
Special cases of identifying the description object exist where the node must first be added to the description object hierarchy view. These cases include cloned description objects and universally applicable description objects. These special cases essentially require the user to define a hierarchy relationship that is not explicit in the ontology but is permitted. A similar case occurs when the user has already included an attribute for the description object that utilises the same base term and now they desire to add another attribute with the same type of term (e.g. where a user wants two different measurements of length, one for normal measurement and one for a ratio with the width). Adding another attribute node involves selection from all possible attributes that are relevant for that description object.
At any point once a description object, attribute or value object has been selected, the user can include them in the specialised domain model by interacting with the selected node. Reversing the inclusion of descriptive elements is achieved by interaction with the appropriate nodes in a similar manner to that for including elements.
A number of other specialisation sub-tasks for the selected attribute can be carried out by simple interaction with the attribute details panel (see figure 6.1C). These include: editing the attribute nametag, determining a preferred unit, determining the attribute should be considered a fixed score. Two other interaction objects on the attribute specialisation panel (figure 6.1C, 6.8) are used for more complex specifying with
relational or spatial modifiers. Figure 6.11 shows the pop-up panel that is used for this type of task.
6.4.4.3 Search tree
Users can either navigate the tree directly using their domain knowledge to seek objects of interest or they can utilise the search bar to find the description object they are interested in. The search bar was introduced following the 4th stage evaluation where users were experiencing difficulties finding some terms, particularly for value objects, where the associated attribute was not obvious from domain knowledge. This occurred due to weaknesses in that aspect of the ontology.
The search bar identifies and highlights the first node that matches the search text, other matches can be found by clicking the ‘Next Match’ button (see bottom portion of figure 1A). This obviously still requires some domain knowledge to have an idea of the term, though it can still help if users are unsure of the exact form of the spelling of the ontology term or where in the description object hierarchy it might appear. Whenever a description object node is selected, the represented description object is placed in the search box to allow users to search for other instances of the ontology term in the hierarchy.
The search bar at the bottom of the attribute-value tree panel (see figure 6.1B) can be used in a similar manner as the search bar in the description object hierarchy tree to find attributes in the attribute and value hierarchy tree (see above).
6.4.4.4 Searching for existence of terms
In testing, the definitions explorer was rarely used to search for the existence of terms in the ontology. Usually users just searched for the descriptive elements directly, only looking for terms if they could not find the element where they expected to. For example if it was not obvious to the user from their domain knowledge, which attribute the value object was related to in the ontology or where users assumed a domain term would exist as one type of descriptive element such as a description object, but in fact it was being used as another type of descriptive element, such as an attribute.
In these rare cases, users could find out that the term they were seeking existed but was to be found in a different context. The definitions explorer’s nodes included all mapped ontology terms and the definition includes the information on what type of descriptive element it is. The inclusion of a search function for the tree views reduced the definitions explorer usage to virtually non-existent.
6.4.4.5 Specify relative or spatial modifier
Attributes can be specialised by users using relative or spatial modifiers using the attribute details panel (see figure 6.8). The modifiers presented in the selection IO (a pull down list) are drawn from the ontology. Upon selection of one of the specialisation options, a pop-up window is generated, presenting users with further details and steps to complete the specialisation. Figure 6.11 shows an example of one of these pop-up windows for applying a relative modifier (‘ratio’) to a ‘number’ attribute of the ‘Infloresence: flower’ description object to capture the concept of number of flowers per infloresence. This example is taken from a RBGE taxonomist’s specialisation for the ‘Alyxia’ group of plants.
In the pop-up window, seen in figure 6.11, the description object hierarchy is presented in a collapsible tree in the same way as in the description object hierarchy in the main window, except that the interactivity on the nodes is restricted to informational definition access and selection of the description object target for the relative modifier (e.g. in figure 6.11, the selected target is the ‘infloresence’ description object). The attributes of the selected description object are represented as entries in a selection pull down list. The task process of specifying the relative modifier is represented with headers giving basic instructions for each of the sub-tasks, with the name of the primary attribute and description object drawn from the selected elements in the linked main window. These guidance notes were added in response to user difficulties in completing this uncommon task during the 5th phase development full task tests. The process of defining the relationship was more complicated than other tasks both in number of steps and conceptually. This taken together with the infrequent occurrence of the task, meant users were becoming confused over how to proceed when they came across the need to define such a relationship.
The spatial modifier pop-up window is similar but only represents the description object hierarchy for selecting description objects as they are the only type of target applicable in this case.
6.4.4.6 Task Model Ordering
The data entry task order is represented in the description object hierarchy tree (figure 6.1A). Users can interact with the file tree to effect a limited alteration of the order of the description objects. These changes are then reflected in the file tree visualisation. Users can alter the default data entry order at any time during the specialisation process by altering the position of sibling nodes on the description object hierarchy tree. This is achieved by using arrow icon buttons to move selected nodes up or down, till the required position is achieved. Drag and drop techniques are not supported in order to enforce the constraint that users cannot change the hierarchal parent-child structures, merely the order of sibling nodes, without having to issue usability unfriendly ‘not permitted warnings’ or have users wondering why their dragging worked sometimes but not others.
6.4.4.7 Reviewing the specialised domain model
Users can use the tree views with greyed-out and bold elements plus the other indicators of content (see table 6.2) to review the state of the model. Filtering techniques (3.4.2) can be used to get a clearer view of the specialised domain model. Users can choose to filter all non-included elements from the visualisations, including the description object hierarchy tree and the linked attribute-value trees.