Intkey and LucID

Mike Dallwitz miked at ento.csiro.au
Thu Mar 20 07:00:38 CET 1997


- From: Kevin Thiele via David Yeates

> Please note ... that the DELTA team have carefully dissected a 
> six-month old beta- test version of Lucid, and found it lacking.

As I have mentioned several times, we used the latest generally 
available version of LucID. We did attempt to obtain a later version; 
here is the response (in part).

    Date: Mon, 3 Mar 1997 13:21:01 +1000

    The LucID Player version 1.0 which includes a key to the Orders of
    Insects is due for release shortly. A DEMONSTRATION VERSION OF
    THIS KEY IS AVAILABLE FROM OUR WEBSITE [my emphasis].

> I also think I should make it clear that Lucid is more than a key. One 
> of its uses could be as an electronic publishing platform - 
> monographs, floras etc could be published entirely in Lucid.

.From David Yeates' original posting:

    Don't forget that DELTA is basically a data-organising program for
    taxonomy, and the interactive keying component is a small
    appendage. LucID is a dedicated interactive key system.

> But what about when the construction of the character states 
> themselves is problematic. I first came across this when trying to 
> capture the diversity of indumentum types in the plant family 
> Rhamnaceae onto DELTA. For a description, I'd like to use the rich and 
> varied terminology available to me - I can call leaves pubescent, 
> hirsute, tomentose, pilose, scabrous, even subvelutinulous, by crikey. 
> These terms describe subtle variations, and are perfectly appropriate 
> in a description, because a reader of a description, holding a plant, 
> could read "Leaves subvelutinulous..." and could look at the specimen 
> and say "Yep, that fits". But a key user who has to decide whether 
> their specimen is subvelutinulous or shortly hirsute will be in deep 
> trouble.
>
> When I came across this problem, two solutions were proposed to me by 
> experienced DELTA users: (1) maybe we shouldn't use terms like 
> subvelutinulous at all, ever (a case of cutting the man to fit the 
> cloth, perhaps even with Orwellian overtones), or (2) double-up on 
> some characters in the database, and use one of the pair for the 
> description and one from the key. Twice the coding for these 
> characters, and you basically end up with two databases that just 
> happen to be merged into one structure.

Subtle differences between character states certainly can cause problems 
when used in classification and in conventional keys. If such a 
character is to be used for these purposes, groups of states can be 
combined into new states (the CONFOR directive KEY STATES carries out 
this function). If simple merging of states is inadequate, then there is 
really no option but to record the information twice (even if keys and 
descriptions are being constructed by hand).

Another way of handling this problem is to record the subtle information 
as comments attached to a character with more broadly defined states.

The use of subtle distinctions between character states need not cause 
any problem in interactive identification. If the user cannot decide 
whether a specimen is subvelutinulous or shortly hirsute, it is simply a 
matter of selecting both states.

> I admit that there are plenty of characters where this problem doesn't 
> arise, but the problem still exists.

So, is it better to tackle the occasional problem character by one of 
the methods above, which might involve 'repetition' of a small amount of 
information; or treat classification, identification, and description as 
separate processes, and 'repeat' most of the information?

> DELTA stores a taxon x character matrix. ... Lucid stores a taxon x 
> state matrix.

This frequently made assertion is meaningless. The facts are that: (a) 
DELTA stores an unlimited amount of uncoded (i.e. text) qualifying 
information with each character state; (b) LucID stores a small, fixed 
amount (1 byte per state?) of coded qualifying information with each 
character state; (c) Intkey stores no qualifying information with each 
state (1 bit per state).

The new DELTA system will store various types of coded as well as 
uncoded qualifying information with each state (see proposals on the 
Net). In due course, Intkey will also be modified to use this 
information.

Mike Dallwitz
CSIRO Division of Entomology, GPO Box 1700, Canberra ACT 2601, Australia
Email md at ento.csiro.au  Phone +61 6 246 4075  Fax +61 6 246 4000



More information about the delta-l mailing list