New DELTA features
rwilson at mov.vic.gov.au
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 mov.vic.gov.au
Museum of Victoria
71 Victoria Crescent telephone 61-3 9284 0216
Abbotsford Victoria fax 61-3 9416 0475
More information about the delta-l