[delta-l] Interactive vs automatic generation of conventional keys

Kirkbride, Joseph Joseph.Kirkbride at ARS.USDA.GOV
Mon Jan 9 17:09:48 CET 2012

Please read my message of 28 October 1996 in the DELTA-L archive:
This is a description of how I wrote my first key using the DELTA software system. The was for 32 species, and ended up with 36 couplets. I had 203 morphological characters in the database, and attempted to include as many as possible in the key. A few of the species were highly variable, which greatly complicated building the key.

My second key built from DELTA-formatted data was for 435 genera of faboid legumes using 128 seed characters and 154 fruit characters. The key was supposed to use only seed characters, but in a few instances fruit characters were required to separate genera. I tried to use the KEY program of the DELTA system, but it was very difficult, and I could not imagine how many pieces that the key would have to be divided into. So I tried Kconi, and it would not even load the data because the matrix was so large. I contacted Richard Pankhurst, and obtained Big Kconi from him, which would load the data. I ended up with a master key to 16 subkeys, which each had 8-133 couplets. It took me about a month to prepare the key. You can peruse the final product in volume 1 of the resulting publication, which is online at:

Writing keys that work is never easy, no matter how you do it.

Joe K

Joseph H. Kirkbride, Jr.
USDA-ARS, U.S. National Arboretum
Floral & Nursery Plants Research Unit
3501 New York Avenue NE
Washington, DC 20002-1958 USA
Tel.: 202-245-4534
Cell: 301-602-6958
FAX: 202-245-5973
E-mail: joseph.kirkbride at ars.usda.gov

-----Original Message-----
From: delta-l-bounces at science.uu.nl [mailto:delta-l-bounces at science.uu.nl] On Behalf Of Mike Dallwitz
Sent: Saturday, January 07, 2012 6:51 AM
Subject: [delta-l] Interactive vs automatic generation of conventional keys

- From: Hans Nooteboom

> Kconi ... allows you to choose the character you want, the most
> obvious (for the end user) or the character that divides the rest of
> the taxa in two equal portions. You can play with it to make the best
> key possible. Very easily you can make partial keys for different
> distributions, a key based on flowering specimens, and one based on
> fruiting specimens. And for the editors you really must make
> dichotomous keys. (At least for this editor).
> If you use DELTA's Key, this all is impossible or at least very
> complicated.

Both Kconi and Key generate conventional (printable) keys. Kconi works 
interactively: the user (i.e. the author of the key) selects the 
characters one by one, with the help of the program. Key works 
automatically: when it is run, the whole key is generated without the 
intervention of the user. Nevertheless, Key does allow the user to control 
the generation of the key, by setting parameters beforehand.

I think it would usually be considerably quicker and easier to generate a 
satisfactory key by using Key than by using Kconi.

The basic method of using Key is very easy. Within the DELTA Editor, run 
the Confor action set 'tokey', which converts the DELTA data to the format 
used by Key; then run a Key action set (e.g. 'key5'), which produces the 
key. This takes only a few seconds.

The default action sets provided with the Editor will try to produce a key 
having the smallest number of steps, averaged over all possible paths 
through the key. But you will seldom be satisfied with this, so you will 
need to refine the key by editing and rerunning the action sets.

(1) If you have numeric characters, they won't be used unless you divide 
them into ranges with a KEY STATES directive in 'tokey'. E.g.
     *KEY STATES 26,~2/2-5/5~
meaning 'up to 2', '2-5', and '5 or more'.

(2) Some characters are easier to use, or have a lower probability of 
error. For these characters, set a higher 'reliability' in the Key action 
set. You could use the reliabilities that you are (I hope!) using in 
Intkey. Alternatively, start afresh and set higher reliabilities for your 
preferred characters, and lower ones for poor or inaccessible characters. 
The allowed values are 0 to 10, and the default value is 5. E.g.

*CHARACTER RELIABILITIES 26,9 27,8 44,8 45-47,7 69,1 70,2

If you have altered 'tokey' (or altered the DELTA data), rerun 'tokey'. 
Then rerun the Key action set, and examine the resulting key. If you would 
prefer different characters to be used at some places, change the relevant 
character reliabilities (i.e. increase the reliabilities of characters 
that you would prefer to be used, and/or decrease the reliabilities of 
characters that you would prefer /not/ to be used).

Iterating this process a few times will usually produce a satisfactory 
key. There are also other options available, e.g. how strongly the 
character reliabilities influence the structure of the key, and how hard 
the program tries to avoid taxa coming out more than once in the key. You 
can also override the automatic character selection at any point in the 
key. For details, see the chapter on Key in the User's Guide to the DELTA 
System (http://delta-intkey.com/www/uguide.htm).

To make special-purpose keys, e.g. for for vegetative, flower, or fruit 
characters, specify the required characters with an INCLUDE CHARACTERS 
directive in the Key action set, and (preferably) save it with a different 
name, e.g. 'keyveg'. You might also need to make a few adjustments to the 
reliabilities. With an interactive program, you would have to start again 
from scratch.

If the DELTA data change, e.g. if new taxa are added, satisfactory new 
keys will usually be obtained by simply rerunning the unchanged action sets.

To make strictly dichotomous keys, use the KEY STATES directive to combine 
states as necessary, so that only 2 states remain. But I advise against 
uncritically converting /all/ multistate characters in this way (unless 
require by editorial policy), as it will often make the key more 
cumbersome, and it may make some characters harder to use. For example,

     Flowers blue
     Flowers purple
     Flowers white

is easier to use than

     Flowers blue
     Flowers not blue

In the first form, the alternatives to 'blue' are immediately apparent. In 
the second form, the user would be more likely to mistakenly deem a purple 
flower to be blue - which would be a reasonable choice if the unspecified 
alternatives comprising 'not blue' happened to be 'red or yellow' rather 
than 'purple or white'.

Mike Dallwitz
Contact information: http://delta-intkey.com/contact/dallwitz.htm
DELTA home page: http://delta-intkey.com
delta-l mailing list
delta-l at science.uu.nl

More information about the delta-l mailing list