- From: "Gregor Hagedorn" G.Hagedorn@BBA.DE - To: "Mike Dallwitz" mike.dallwitz@netspeed.com.au
I am just back from the TDWG meeting in Lisbon and working on the minutes for SDD. In Lisbon we had two questions concerning DELTA.
DELTA, as far as I know, can generate something like genus descriptions from multiple species descriptions. I have worked myself relatively little with the Confor program itself and I now cannot find any information about this in the DELTA Users manual.
This is carried out by the Intkey command 'Output Summary'. Any subset of the taxa can be combined in this way. The output is a text file in DELTA format. It can be done interactively, or by means of a script, which can be run whenever the data are changed. For details, see the DELTA-L posting Subject: Combining DELTA items Date: Fri, 27 Oct 2000 which is available in the list archive at http://listserv.surfnet.nl/archives/delta-l.html
We intended to put in the DELTA Editor a more general mechanism for passing information between items. This would have allowed, for example, species items to use information coded in genus items, and vice versa. It would also have replaced the 'variant items' mechanism. See Dallwitz, M. J., Paine, T. A. and Zurcher, E. J. (1993 onwards). Proposed new features for the DELTA system. http://delta-intkey.com
Character dependencies:
We had a long discussion about how dependencies should be handled. We believe it makes sense to support both Applicable and Inapplicable versions concurrently and tried to analyse what that means.
In that context we started to wonder, how the DELTA definitions are to be interpreted.
In the DELTA users guide under "*DEPENDENT CHARACTERS" I find for "4,2:16 10,1/3:12-13:20:30-35"
"Attribute 4,2 implies that character 16 is inapplicable. Attributes 10,1 and 10,3 imply that characters 12, 13, 20, and 30-35 are inapplicable."
We have two options to interpret this:
- Attributes 10,1 and 10,3 means both 1 and 3 must be scored to make
the dependent characters inapplicable.
- Attributes 10,1 and 10,3 means any of 1 and 3 or both must be
scored to make the dependent characters inapplicable.
I as well as all members present in the group assumed that the first option is what is meant, and DEltaAccess implements it that way.
It's not clear from the description, but the second option is the one I intended. I can't think of a plausible case where the first option would be appropriate.
The sample data supplied with the DELTA programs contains a relevant example.
However, I found that in the case of more than one dependency in a single character the two forms Inapplicable and Applicable can NOT be converted. What confuses me now is that under "APPLICABLE CHARACTERS" it is stated that "This is equivalent to the DEPENDENT CHARACTERS directive in Section 3.5.1." This seems to imply a convertibility to me.
The directives _are_ convertible. The example in Section 3.5.1 of the DELTA User's Guide is taken from the sample data. To confirm that the two forms are equivalent, take the 'APPLICABLE CHARACTERS' version given in the User's Guide, and substitute it for the 'DEPENDENT CHARACTERS' version in the specifications file of the sample data. Then run 'Confor check', and you will find that no errors are reported.
We are really homing in on a version that should be at least a good basis for trying it out. I did try originally to have it open, including options for pure ontological schemata and pure state- matrices (like in LucID, in contrast to the character matrices DELTA uses). I can only say that by and large we are homing in on a DELTA like model (including LucID).
Actually, DELTA and Lucid are not qualitatively different in this regard - they both have the states organized into characters. The only differences are in the kinds and amount of information associated with each state in the data matrix. Associated with each state, the current version of DELTA has an unrestricted amount of free-text information, Intkey has 1 bit of information (present/absent), and Lucid has 8 bits of coded information. The proposed new version of DELTA (Dallwitz et al., loc. cit.) had both free text and coded information associated with each state and character in the matrix. The coded information included all the types used by the current Lucid.
At least one program, MEKA, does use a state matrix, i.e. the states are not grouped into characters.
-- Mike Dallwitz 13 Warrambool Close, Giralang ACT 2617, Australia Phone: +61 2 6241 2884 Email: mike.dallwitz@netspeed.com.au Internet: delta-intkey.com