Text characters in DELTA

[Donovan Sharp]

Mike Dallwitz wrote:

> > From: Jim Croft <jrc at ANBG.GOV.AU>
> > To: TDWG-SDD at USOBI.ORG
>
> > The DELTA spec would probably allow you to include a complete description
> > as a lump of text, but it would not be particularly useful to do so.
>
> Yes, you could do this. It would be slightly more useful to break the text
> up into text characters. For example,
>
> #1. <synonymy>/
> #2. <comments on habit>/
> #3. <comments on leaves>/
> #4. <comments on flowers>/
> #5. <comments on distribution>/
> #6. <general comments and discussion>/
>
> These could still be combined into a single description, but could also be
> displayed and searched separately if necessary.
>
> What is usually done is to intersperse such text characters at the
> appropriate places in a list of coded characters. They can then be used as
> repositories for information that the author can't or doesn't want to code.
> The information they contain is accessible in Intkey, and can be used in
> much the same way as coded information.
>
> --
>
> Mike Dallwitz
>
> CSIRO Entomology, GPO Box 1700, Canberra ACT 2601, Australia
> Phone: +61 2 6246 4075   Fax: +61 2 6246 4000
> Email: md at ento.csiro.au  Internet: biodiversity.uno.edu/delta/

This is also useful for the preparation of written descriptions or associated
text to be displayed with in a key. Observations on a species can greatly
improve species descriptions. Things like 'grows on red loams with a northerly
aspect' or 'Similar to species A but with longer thingies and rounder
whatsits'. These are things which would not normally be coded as part of the
data but are useful to the end user, and it is the needs of the end user which
are ultimately important, and for this reason it is useful. Im not a computer
scientist, I just build keys so perhaps I see this in a different light, and
one thing which concerns me is the amount of double handling (and worse) which
creeps in with coding, preparation of associated text, common links etc. The
standard needs to be able to incorporate all useful entities, including 'hard'
data, comments, images, sounds and other media. At the moment we build a key,
then we add images and other associated things, these things should be
considered part of the data and included from the start. The standard should
then allow the elements which are not included for number crunching to be
formatted and presented to the end user in any desired fashion.