Wiki-based identification key editor

1 Introduction: Wiki keys versus database-keys

Identification keys may have different structures (especially: browsing, single-access, multi-entry, or multi-access) and they may be based on different technical models. Important technical aspects are document storage (SDD-xml documents, Wiki-pages) versus relational database storage (Dryades/Open Key/ETI Linnaeus III), server-side processing (Oracle, PHP) versus client-side processing (FLEX or javascript), and different security and trust models.

These different approaches have advantages and disadvantages without a perfect solution being available. For this reason, the KeyToNature project is forced implement complementary approaches to identification.

Documents excel in that storage and change management is easily understood by most users. Wiki documents support trust between collaborators by making it easy to understand and revise contributions by multiple authors. On the other side, relational databases excel where data collections become truly big. For example, wiki keys become slow for keys with more than 3000 leads in a single document.

With respect to server or client-side programming, server-side programming (as in the FRIDA/Dryades keys) provide the best compatibility with the widest possible array of clients, an aspect important for using keys on PDAs or smartphones. As long as the client supports basic html, the identification tool can work there. However, this comes at the expense of a server round-trip with each interaction, which can lead to slow response times, depending on the speed of the internet connections. Client-side programming, e.g. in Javascript or Adobe FLEX can offer more responsive and richer user interfaces. Within KeyToNature, Adobe FLEX-based tools are found to be especially suitable for complex identification tools such as multi-access keys. For simpler tools, javascript-based tools are often better suited, because of a better integration with browsers. While a few years ago javascript often had compatibility problems, newer browsers and newer javascript frameworks have largely overcome this. Applications like email, word processing or spreadsheet calculations now run readily inside a browser under javascript, without requiring any locally installed software.

The potential strength of the wiki-key approach is not to be found in the isolated key, but in the fact that the key is a natural part of a well designed and tested collaboration and trust building platform, that allows to do many more things than just running keys (e.g. writing rich text, integrating text with images, sound and video) and and which is designed to scale with respect to security management to potentially millions of users.

2 Need for an editor

While basic wiki keys have been developed by KeyToNature already in the first year, some KeyToNature partners expressed the need for more advanced tools: 1) An interactive player that reduces the complexity of the identification process to single decisions, while at the same providing a history of previous decisions, allowing annotations, and later revisions. 2) A web-based editing tool that simplifies modifying, pedagogically reducing, or translating existing keys (as well as creating keys for teaching subjects that are hitherto not covered by the KeyToNature partners).

For community-based editing of identification tools, the existing wiki editing functionalities only provide a reliable base level. It is desirable to extend this with more use-oriented, WYSIWIG interfaces. The educators desire and easy-to-use and adaptable user interface for their keys. It would be desirable to have functionality directly on the wiki as well as through database models.

Specifications: The editor should be based on a simple model, following the existing Dryades editor (but without the need for page-reload cycles). It should incorporate the functionality to filter a large key based on a list of taxa into smaller keys. The filter should support both a positive ("only these taxa") as well as a negative ("all except") mode.

Different routes are possible, including Adobe-FLEX and Javascript-based editors.

3 FLEX

It is possible to read and write to wiki pages using FLEX acting against the Wiki API. An alternative would be to have directly html-embedded functionality. This needs to be explored, see here how it might be done.

4 Javascript

The original wiki key has been improved in 2009 by adding javascript-based additional functionality like toggling the display of secondary text and images and enlarging images on click. Furthermore, a javascript based player called “jKey” has been developed, supporting interactive use, tracking and annotating previous decisions, and allowing all decision steps to be easily revisable. The revision capability is especially useful in classroom use, allowing to quickly identify erroneous decisions, discuss the reasons for these, and continue from there (without restarting the entire identification process).

The jKey Editor allows form-based editing of the identification keys. Its development started towards the end of the second year of KeyToNature and a first demonstration is planned at the meeting in Tartu (October 2009).

See also JKey Player and JKey Editor.