Character states 'present by misinterpretation'

[Alessandra <R. at <baptist at WAM.UMD.EDU>.bitnet>]

My personal experience is that the advantages of writing the database in
DELTA and then importing it into LUCID far outweighs the disadvantages.
During the course of building the database, people often add, delete, and
change characters and their states. Dependencies also change, in part due
to that.  As Mike pointed out, this is most important when you have a
large database. It is nearly impossible to check for all inconsistencies
one by one. Delta will do it for you and it will not skip but one.

Even though the present by misinterpretation of LUCID is a great idea in
theory, we have used it only sparingly in our keys. A data abase
containing such information is only useful for the functioning of the key
itself. There is no other use for a character that is present by
misinterpretation. And it gets really confusing when it generates logical
inconsistencies as in the case of dependencies. For example, if a certain
category of ducts is present by misinterpretation, then a projection of
these ducts (dependent character) will be coded as absent? Absent by
misinterpretation also? Present or absent by misinterpretation is a
counter intuitive way of coding characters that generates a certain level
of confusion when you are building the database. It is better left to the
end anyway, if you are going to use it at all. DELTA is also a more
powerful tool to (1) generate descriptions to check your coding, because
you can better manipulate the way these descriptions will be exported (2)
Intkey will readily tell you when two or more taxa cannot be further
separated by the data. Lucid allows you to go on and on and on until you
figure it out. Of course you can also ask LUCID to give you a list
differences between the taxa remaining, but this is less efficient,
because you have to ask. I have
a personal bias towards DELTA as a tool to store and manipulate
taxonomical information. There is yet no substitute for it. As far as the
key itself, I greatly miss the option to weight characters when building
keys in LUCID. If LUCID is to persist and continue to grow, it ought to
incorporate that option.