Intkey and LucID
J.Connors at PICAN.PI.CSIRO.AU
Fri Mar 21 00:13:15 CET 1997
- From: Alex Chapman
- To: Kevin Thiele
> I have a question for you Kevin. In my previous posting I suggested
> that the role and facility of the DELTA-LUCID converter (which I
> understand you have personally written) was crucial, particularly for
> content developers attempting to choose which approach and package is
> best for them.
> Given the differences in data matrix design and character handling
> methods between the two packages, can you outline (and comment on the
> success and completeness of) the data conversion process from DELTA to
The DELTA-Lucid Tranlater was written for two purposes.
Its main use is for people who want to load their DELTA data into the
Lucid Builder (still under development) for subsequent maintenance and
development of the data in Lucid. The heart of the Builder is a rather
neat (we think) point-and-click scoring module with features to really
streamline the scoring of taxa FOR A KEY!!!! (future critics please
The second use is subsidiary. We have a problem that the Lucid Player
will be released some months before the Builder is ready. The Player
will come with some keys that people can play with, but many people out
there will want to try their own data in Lucid. Until the Builder is
released, we felt that these people would get frustrated.
Hence, there is an option in the Translater to allow a fairly
quick-and-dirty dump of DELTA data into Lucid Player files. The dump
does essentially what TOINT does (but without all of its features, I
hasten to add). It takes the chars file and translates to the Lucid
equivalent, then loops through the items files creating the Lucid data
All text characters are ignored - that is, only characters that are
directly relevant to the operations of keying (multistates and numerics)
are retained. In Lucid, textual information is stored in the galaxy of
information files surrounding the key. We feel that putting the data
here allows a more pleasing and user-friendly treatment of this data,
although currently there is the limitation that this data can only be
got at through a taxon name (you can't search "synonyms" for a
particular string, for instance). If people find this to be very
important, we'll try to incorporate it in later versions.
All comments in the item blocks of the items file are stripped out (just
as does TOINT). Comments in the chars file, of course, are retained.
The following are not translated:
Pointers to images
TNotes and CNotes
(There are probably more things, but I can't remember everything)
The translate-to-player mode is quick-and-dirty, and was designed to be
so. At the end, there is a very skeletal Lucid Player key, so that users
can get some idea what their data looks like in Lucid. Many of the
features of both Lucid and DELTA will be lost in this key. If users
really want to build a proper Lucid key, then they will need to get
their data into the Builder.
The translater was not designed as a permanent DELTA-to-Lucid
translater, partly because the solution (FOR A KEY) of storing data in
DELTA then dumping it to the Lucid Player is not a particularly good
one, since the differences in the way the data are stored inevitably
results in a loss of information, on the one hand, and an inability to
make the most of Lucid on the other.
Note that I've tested the Translater on a couple-of-dozen DELTA
datasets, but there may well be some variants of DELTA syntax that I've
forgotten which may cause it to fall over in some cases. My apologies if
this happens - get in touch and I'll try to fix the problem. Note also
that the translated data should always be checked carefully for accuracy
- it may perhaps happen in some cases that the translater doesn't bomb,
but doesn't translate correctly.
I hope this helps. If you need anything clarified further, I'll still be
able to read this discussion group during the course of today, but
tomorrow I go back to my farm to plant the brussels sprouts.
Cheers - Kevin Thiele
More information about the delta-l