>>>From Mike...
>In DELTA, character values in a description can't be separated from the
>'attribute' which contains them, without losing information. This is because
>the order of the values, and the words 'or', 'and', and 'to' which may
>connect them, are significant. Also, the position of a qualifier (before or
>after a value) may be significant, and some qualifiers, e.g. 'reliability',
>may apply to the attribute as a whole rather than to a particular value.
>
>Example:
>
> 5,3/3&1<when infected with virus>/<occasionally>2<@reliability 3>
>
> = Flowers red, or red and white (when infected with virus), or
> occasionally yellow.
>
>This doesn't seem to be accommodated in the proposal - at least, it's not
>spelled out.
Courple of things:
1. This raises one of the problems of DELTA as pointed out by Gregor and others at the TDWG meeting,which is that <comments> are being overloaded with meaning. There are various types of things here that are masquerading as being similar, when they're not at all.
* "<when infected by a virus>" is perhaps a true comment. In the above example, could this perhaps be covered by content?
<DESCRIPTION Name = "a taxon or thing">
<ELEMENT> Name = "Flower colour">
<VALUE> red
<QUALIFIER> rarely </QUALIFER>
</VALUE>
when infected by a virus
</ELEMENT>
</DESCRIPTION>
Note that these comments are only used for natural-language descriptions (they're stripped out when DELTA translates to an interactive key etc). I don't see why the ordering of these true comments can't be accomodated by their position in the content with respect to the tags - since these are "trivial" comments in most contexts, this doesn't seem weak to me.
* <occasionally> is a qualifier as defined in the draft spec (only I'm calling it "rarely" in line with Lucid's terminology). Lucid is currently the only program that uses this type of qualifier in identification, and it's very important. But it's not to be confused with the common-or-garden variety of comment as above.
* <@reliability 3> is a command for a program. This should be made clear by the tag so that other programs can ignore it.
2. &.
I've always been bothered by the use of & (and) vs / (or) in DELTA. Using Mike's example:
5,3/3&1 = "Flowers red, or red and white"
The use of & is handy for codifying natural-language descriptions, but in other applications it's highly problematical. This is a homology problem and has been discussed at length in the cladistic literature e.g.
*CHARACTERS
#1. Dorsolateral appendages/
1. arms/
2. wings/
*ITEMS
#Humans 1,1
#Birds 1,2
#Angels 1,1&2
The discovery of angels (having both arms and wings) would prove the non-homology of arms~wings, so the character as stated is false and should be restated "Arms present/absent" "Wings present/absent".
Similarly, in Mike's example, the red&white broken colouring of virus-infected tulips is actually non-homologous with uniform red or uniform white and should be a separate character (or at least a separate state).
So pending further discussion (which I'm sure will come) I propose that the standard should not support the & coding of DELTA.
Over to you, Mike... :-)
Cheers - k
------=_NextPart_000_006C_01C01717.B7C1EC40
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=iso-8859-1" http-equiv=Content-Type>
<META content="MSHTML 5.00.2614.3500" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#f8f8d0>
<DIV><FONT face=Arial size=2>
<DIV>From Mike...</DIV>
<DIV> </DIV>
<DIV>>In DELTA, character values in a description can't be separated from
the<BR>>'attribute' which contains them, without losing information. This is
because<BR>>the order of the values, and the words 'or', 'and', and 'to'
which may<BR>>connect them, are significant. Also, the position of a
qualifier (before or<BR>>after a value) may be significant, and some
qualifiers, e.g. 'reliability',<BR>>may apply to the attribute as a whole
rather than to a particular value.</DIV>
<DIV>></DIV>
<DIV>>Example:</DIV>
<DIV>></DIV>
<DIV>> 5,3/3&1<when infected with
virus>/<occasionally>2<@reliability 3></DIV>
<DIV>></DIV>
<DIV>> = Flowers red, or red and white (when infected with virus),
or<BR>> occasionally yellow.</DIV>
<DIV>></DIV>
<DIV>>This doesn't seem to be accommodated in the proposal - at least, it's
not<BR>>spelled out.</DIV>
<DIV> </DIV>
<DIV>Courple of things:</DIV>
<DIV> </DIV>
<DIV>1. This raises one of the problems of DELTA as pointed out by Gregor and
others at the TDWG meeting,which is that <comments> are being overloaded
with meaning. There are various types of things here that are masquerading as
being similar, when they're not at all. </DIV>
<DIV> </DIV>
<DIV>* "<when infected by a virus>" is perhaps a true comment. In the
above example, could this perhaps be covered by content?</DIV>
<DIV> </DIV>
<DIV><DESCRIPTION Name = "a taxon or thing"><BR>
<ELEMENT> Name = "Flower
colour"><BR>
<VALUE> red</DIV>
<DIV>
<QUALIFIER> rarely
</QUALIFER><BR>
</VALUE></DIV>
<DIV> when infected by a
virus<BR> </ELEMENT><BR></DESCRIPTION><BR></DIV>
<DIV>Note that these comments are only used for natural-language
descriptions (they're stripped out when DELTA translates to an
interactive key etc). I don't see why the ordering of these true comments can't
be accomodated by their position in the content with respect to the tags - since
these are "trivial" comments in most contexts, this doesn't seem weak to
me.</DIV>
<DIV> </DIV>
<DIV>* <occasionally> is a qualifier as defined in the draft spec
(only I'm calling it "rarely" in line with Lucid's terminology). Lucid is
currently the only program that uses this type of qualifier in identification,
and it's very important. But it's not to be confused with the common-or-garden
variety of comment as above.</DIV>
<DIV> </DIV>
<DIV>* <@reliability 3> is a command for a program. This should be
made clear by the tag so that other programs can ignore it.</DIV>
<DIV> </DIV>
<DIV>2. &.</DIV>
<DIV>I've always been bothered by the use of & (and) vs / (or) in
DELTA. Using Mike's example: </DIV>
<DIV> </DIV>
<DIV>5,3/3&1 = "Flowers red, or red and white"</DIV>
<DIV> </DIV>
<DIV>The use of & is handy for codifying natural-language descriptions, but
in other applications it's highly problematical. This is a homology problem
and has been discussed at length in the cladistic literature e.g.</DIV>
<DIV> </DIV>
<DIV>*CHARACTERS</DIV>
<DIV> #1. Dorsolateral appendages/</DIV>
<DIV> 1. arms/</DIV>
<DIV> 2. wings/</DIV>
<DIV> </DIV>
<DIV>*ITEMS</DIV>
<DIV>#Humans 1,1</DIV>
<DIV>#Birds 1,2</DIV>
<DIV>#Angels 1,1&2</DIV>
<DIV> </DIV>
<DIV>The discovery of angels (having both arms and wings) would prove the
non-homology of arms~wings, so the character as stated is false and should be
restated "Arms present/absent" "Wings present/absent". </DIV>
<DIV> </DIV>
<DIV>Similarly, in Mike's example, the red&white broken colouring of
virus-infected tulips is actually non-homologous with uniform red or uniform
white and should be a separate character (or at least a separate state).</DIV>
<DIV> </DIV>
<DIV>So pending further discussion (which I'm sure will come) I propose that the
standard should not support the & coding of DELTA.</DIV>
<DIV> </DIV>
<DIV>Over to you, Mike... :-)</DIV>
<DIV> </DIV>
<DIV>Cheers - k</DIV></FONT></DIV></BODY></HTML>