> 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.
