New DELTA features

Robin Wilson rwilson at
Mon Mar 3 03:35:16 CET 1997

A few comments on the reply of Mike Dallwitz to Gregor Hagedorn and 

- From: Mike Dallwitz

> The main difficulties we encounter in reconciling the requirements of 
> natural-language descriptions and Intkey relate to the wording of the 
> character list itself, not the comments in the ITEMS file.

Yes! I am now making a 2nd version of the chars file for Intkey, since 
the one that produces nicely worded tonat descriptions is often cryptic 
when individual characters are read during Intkey identifications. This 
is the approach I recall reading in the documentation somewhere, but it 
is a bit of a nuisance remembering to maintain 2 chars files for each 
database (I am trying to standardise and call one charsint and the other 
charsnat). But I have noticed that the latest version of Intkey makes 
this a bit more complex again: the "DESCRIBE TAXA" output from within 
Intkey now produces sentences that look ok using my charsnat file, but 
the individual characters when read during an identification make much 
more sense when I use my charsint file. Perhaps I should go back to my 
charsint file and think through character wording in a way that makes 
better use of the current implementation in "DESCRIBE TAXA". My view is 
that the "DESCRIBE TAXA" output from the current Intkey is nice and 
compact, but that it is a small step backwards in terms of a wording of 
a chars file consistently for all aspects of Intkey use. Maybe I am 
missing something here, and I would welcome comments.

> ... the proposals state: 'The current mechanism, where the comment in 
> a name is interpreted as the authority, will not be supported' (I 
> should have said 'usually interpreted'). One of the examples in the 
> proposals shows the mechanism I propose to use:
>     *ALPHABETIC LIST authorities
>     . . .
>     #10. Harms
>     #11. van Meeuwen
>     . . .
>     *ALPHABETIC LIST species_names
>     #1. Pericopsis elata (<@auth 10>) <@auth 11>
>     . . .

The above mechanism looks a litle clumsy for manual editing. Given the 
number of keystrokes in typing "@auth 11" the advantage over simply 
typing "van Meeuwen" seem marginal. Unless the new DELTA data editor 
will enable these lists to maintained more easily I am not sure I see 
the advantage of the cryptic coding.

A more general issue, which may be alluded to in the exchanges between 
Mike Dallwitz and Gregor Hagedorn, is the extent to which the DELTA 
programs will support external database linkages. At some stage in 
implementing support for author names and bibliographic citations it 
will be better to just allow DELTA to obtain those data from an external 
database (maybe via OLE or some other system tool). The Platypus program 
for maintaining nomenclature and distribution information in a hierarchy 
(designed to make preparation of the Zoological Catalogue of Australia 
easier) makes this mistake. That program reinvents the wheel by having a 
bibliographic database (with an inferior set of features compared with 
specialised bibliographic databases) within the program. Potential users 
who already use a bibliographic database will be frustrated by the need 
to do regular imports into Platypus to maintain these data. Far better 
to allow all these tools to talk to each other. I know this is harder 
than it sounds, but it does deserve some thought and discussion. 
Personally, I see Confor and Intkey (or their successors) as vital to my 
work, but I will want some of the raw data pertaining to each taxon 
maintained in other, more appropriate, databases. Examples of these are 
specimen databases (museum register databases and the like), and 
bibliographic databases. I would be interested to hear how the Delta 
development team see future versions of Intkey and Confor fitting into 
such a model.

Robin Wilson wrote:

>> For what it is worth, I agree with Gregor on this. It is 
>> frequently troublesome to me keeping track of item numbers. 
>> Another solution would be for confor to support item names or 
>> item numbers in all directives that require item selection 
>> (instead of just those few directives that currently support item 
>> names). ...

Mike Dallwitz replied:

> It is bad practice to have multiple copies of things like taxon names, 
> as it can be difficult to get and keep them consistent. As mentioned 
> above, this will not be necessary in the new Confor. ... I would 
> strongly advise that new items should be put in their logical place 
> (whatever that might be - I favour alphabetical order). Directives 
> involving taxon numbers can be generated afresh via Intkey, by various 
> mechanisms, as needed. If you let me know your specific needs, I will 
> try to suggest solutions.

I take the point about maintaining multiple copies of taxon names, and 
look forward to the new version of Confor. I have tended to use manually 
edited EMPHASISE CHARACTERS and other directives using item numbers 
rather than make these using Intkey output to a file. I think that 
nearly all of these cases will be adequately dealt with if I generate 
these data anew from Intkey after adding items as Mike suggests. 
However, there will perhaps remain a few instances where I would want to 
emphasize some characters even though Intkey does not want to emphasise 
those characters for that taxon. Clearly this will be because I know 
something that has not been coded. Probably use of a text character to 
remind me and users of these cases will suffice.



Robin Wilson				rwilson at
Museum of Victoria			
71 Victoria Crescent			telephone 61-3 9284 0216
Abbotsford  Victoria			fax       61-3 9416 0475
Australia  3067

More information about the delta-l mailing list