Combining DELTA items; character dependencies

[Mike Dallwitz]

- From: "Gregor Hagedorn" <G.Hagedorn at BBA.DE>
- To: "Mike Dallwitz" <mike.dallwitz at 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:

> 1. Attributes 10,1 and 10,3 means both 1 and 3 must be scored to make
> the dependent characters inapplicable.

> 2. 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 at netspeed.com.au  Internet: delta-intkey.com