Often, DELTA uses "characters", "states", and "comments" in the following manner: (Using XDELTA here instead of DELTA-CLASSIC because to me it's a bit more clear)
:) Nice to see it has some uses anyway!
<character number="8"> <description>outer edge of front wing</description> <comment>shape</comment> <multi type="unordered"> <state number="1">convex</state> <state number="2">straight</state> <state number="3">concave</state> <state number="4">irregular</state> </multi> </character>
It was pointed out that "shape" is more than just a comment, but a critical piece of data, a "property", which modifies the character and perhaps even restricts the states to various types. Mike seemed to indicate that there would be a way to make this explicit in DELTA, though I don't recall what the mechanism was.
As a first cut I just transferred everything from DELTA comments into XDELTA comments, although it was quite obvious that the 'comment' component of DELTA was overloaded depending on context (a legacy problem I guess, and one which raises the prospect of 'extensibility' as a requirement of the new format).
In the above example the character description is discussing the 'shape' property of the 'outer edge of front wing' character. An alternate possible encoding would have been the 'shape' property of the 'outer edge' property of the 'front wing' character. I'd say that both are equally valid, just that the latter is normalised to a great extent.
However there would appear to be some problems with assuming an morphological bias to the data model - i.e. a butterfly has wings which have shape... because its hard to draw the correct distinctions (see Gregors posting on 1/12 entitled Character and item hierarchy). Therefore attempting to normalise properties might lead to varying and inconsistent results.
DELTA already allows dependencies between characters - such that if a specific state has been selected for a character, other characters are ignored (i.e. no wings, ignore anything to do with wings). Is there any other dependency relationships that might be required, or additional information about such a relationship?
Restricting states to particular options depending on the property in question (e.g. leaf and/or wing shape) leads back to the prior discussion on accepted standards for character description.
Defining, and agreeing upon these standard notations/descriptions are a fundamental part of specifying this new format, and one that isn't solved simply by deciding to use XML (for example). Its part of the fundamental design and modelling, and is therefore something that should be addressed early on.
Cheers,
L.