Kevin Thiele kevin.thiele at PI.CSIRO.AU
Fri Jan 7 10:34:43 CET 2000

Dear Leigh,

I've been looking through your XDELTA DTD. The group has already commented
that it's "merely" a literal mapping of DELTA, but it's a very useful start :-)

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):

(forgive me if I've misinterpreted some things in the DTD - I'm new to these

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
>     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.

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. One option would be to include xml markup as
comment (would this be messy if the notes included embedded images, hotlinks
etc). Another would be to treat state notes as you do images, with an href
pointer to a file. LucID also allows sound files to be associated with a
state (imagine a key to cicadas or frogs with calls as characters).

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. e.g. the taxon "Polygalaceae" may have notes
files "Brief Description", "Full Description", "List of genera", "Ecology"
etc., images "Polygala japonica (habit)", "Polygala japonica (detail of
flower)", "Comesperma volubile", sound file "The wind blowing through leaves
of Polygala minuta" etc.

We store all these as separate files for the convenience of the builder and
speed of retrieval. I can see that for the notes it would perhaps be
possible to store everything in one xml file or block and use a style sheet
to give different views, but this may be awkward and limiting.

4. Images

<!-- An image. An image can have associated text (e.g. a title).

It's useful to allow an image to have both a title and associated text e.g.
notes, credits, copyright notice. Defining the title separately from the
text allows an application to retrieve and display just this without the rest.

5. Character values

LucID allows a richer assignation of character state values to taxa. Thus, a
taxon may be scored as having state 1 as its normal state, state 2 rarely,
state 3 by misinterpretation, and be unknown for state 4. The full list is:

normally present
rarely present
present by misinterpretation
rarely present by misinterpretation

These are important. Note that the proposed extensions to DELTA incorporate
some or all of these. Gregor has already proposed a system of modifiers to
allow this.

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.

Note that if the promise of a universal lexicon fails to materialize, we'll
need a way of mapping characters from one key to another, so that characters
can be passed from the parent key to the child.

7. A small point:

>     A multistate character must contain at least one state.

Surely a multistate character must contain at least two states.

8. General Information

Not all information in a key or other treatment can be associated with
character states or taxa. Some is associated with the treatment as a whole
e.g. introductory notes, notes on using the key, general notes for the
parent taxon of the key (e.g. a key to genera of Grossulariaceae may have a
description of the family) etc. In LucID this information may comprise html
files, images etc just as with taxa and states. This could be easily dealt
with by expanding your DTD. A special case is an "About this key" file. This
needs much more than is allowed in the document description:

<!ELEMENT xdelta (description?, character-list?, item-list?)>
<!ATTLIST xdelta revised        CDATA #IMPLIED>

9. Collaborative projects

>TODO - its feasible that documents may grow quite lengthy with
>     large datasets and users may prefer to hold character and item
>     descriptions in separate documents. The item document can then
>     refer to a main document which describes the characters. This might
>     facilitate collaborative working as a centrally located document
>     describing common characters could be referenced by several teams.
>     In this case the semantics of importing other character lists should
>     be defined - i.e. how inter-document references are managed, and
>     how conflicting/over-riding character descriptions should be dealt
>     with by applications.

It will sometimes happen that several collaborators will share a common
character list and score different taxa, as you describe. But it will also
happen that the collaborators share a taxon list and score different
characters. This may be simple, but the same issues (interdocument
references, conflicts etc) need to be addressed.

Cheers - k

More information about the tdwg-content mailing list