(RQT) DELTA, XDELTA and LucID

[Mike Dallwitz]

> Date: Fri, 7 Jan 2000
> From: Kevin Thiele <kevin.thiele at PI.CSIRO.AU>
> To: TDWG-SDD at USOBI.ORG

Sorry for taking so long to reply to this - I've been on holiday.

> I've been looking through your XDELTA DTD. ... LucID can do a number of
> things that DELTA can't, and perhaps XDELTA as it stands can't either. You
> should consider these (quotes are from your xdelta.dtd document).

We need to clarify what is meant by 'DELTA' in this context. The definition
of DELTA data in the 'DELTA Standard' document (included in the program
distribution and also available separately as
http://biodiversity.uno.edu/delta/standard/standard.exe) is deliberately
quite narrow:

     "The essential components of DELTA-format data are normally the
     'character list', the 'taxon or item descriptions', the 'character
     types', the 'implicit values', and the 'character dependencies'."

It was intended that only the 'data matrix' (ITEM DESCRIPTIONS), and a few
other directive that were necessary for interpreting the matrix would be
defined in the standard (e.g. 'implicit values' and 'character dependencies'
affect the interpretation of missing values).

In recent discussions, 'DELTA' has been used in the broader sense of some or
all of the features (directives) implemented in CONFOR, DeltaAccess, etc.
This is appropriate, as standardization requirements now go far beyond the
basic data matrix.

> 1. Character groups
>
>>    A character group allows the grouping of related characters together.
>>    DELTA does not enforce the grouping of characters, and neither does
>>    XDELTA. However the CHARACTER HEADINGS directive seems to assume that
>>    related characters will be grouped together within a DELTA file (as it
>>    only specifies the first character that falls under each heading).
>>    XDELTA therefore allows characters to be grouped in this way.
>
> I assume that character groups here are equivalent to character sets in
> LucID - groupings of characters so that you can e.g. display only leaf
> characters in a random-access key. In LucID there is no requirement that
> characters in a set are consecutive in the character list. Further, any
> character may belong to more than one set - this is very useful so that
> e.g. you can have the sets "leaves", "flowers", "petals", "simple" in
> which "petal" characters also belong to the "flowers" set, and the
> "simple" set comprises a selection of characters from all the other sets.

Intkey also implements arbitrary groupings of characters, and I agree with
Kevin that this is a useful feature, which needs to be retained. There may
also be a need for hierarchical groupings, but the CHARACTER HEADINGS
directive does not fill this need. These headings are purely for reading by
humans in certain contexts, they are not hierarchical (except perhaps
visually by means of font changes), and different ones may be needed in
different circumstances. They are often, but not always, the same as
the ITEM SUBHEADINGS, which appear in natural-language descriptions.

Intkey also implements arbitrary groupings of taxa.

> 2. Character state notes
>
> DELTA stores all notes as plain text, sometimes marked up with its own
> typesetting marks, but pretty plain nonetheless. LucID allows builders of
> keys to associate a formatted file (txt, rtf, html) with a character
> state, to hold explanatory notes.

DELTA associates notes with characters, not states. The notes can have RTF
markup. Associating notes with the character as a whole is sometimes
necessary, and is usually more convenient for the end user.

> 3. Taxon multimedia
>
> LucID allows any number of multimedia files (images, videos, sounds, txt,
> rtf, html) files to be associated with a taxon. Each file has a title for
> display in a drop down menu. ... It's useful to allow an image to have
> both a title and associated text e.g. notes, credits, copyright notice.

All of these features are also available in DELTA. In addition, text
overlays on images are supported.

> 6. Taxon subkeys
>
> In LucID keys one key may be linked as a child to another. A taxon thus
> has the name of a subkey associated with it, so that a user on reaching
> the taxon can ask the program to automatically drop to the subkey to
> continue the identification.

In Intkey, this is handled by the same mechanism described in (3) - the
subkeys are just another type of associated file. These would typically be
other Intkey keys, but could be any file with an associated application,
e.g. a conventional key in HTML, or, presumably, a LucID key.

--

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/