----- Original Message ----- From: Eric Zurcher ericz@ENTO.CSIRO.AU To: TDWG-SDD@USOBI.ORG Sent: Monday, September 04, 2000 11:29 AM Subject: Re: Draft Spec mark 2
| At 08:13 2/09/2000 +1000, Kevin Thiele wrote: | >These are four (very early) examples, not four models. My intention is to | >develop a | >specification that can allow data represented with varying levels of | >complexity, from very simple statements to fully worked up integral data | >files such as Lucid and DELTA use. I'm not sure why, but I like the idea | >that the most basic document would simply say "Eric Zurcher has two feet". | >Perhaps current programs wouldn't be able to make much use of such a | >document, but maybe in the future we may have a way of collecting and | >organising clouds of such basic scraps (atoms) of description into something | >quite powerful. | | Well, perhaps. But I think that our successors will appreciate it if we | apply a bit of rigour and take care to describe our data with as much | clarity and lack of ambiguity as possible. I don't think they'd find the | statement "Eric Zurcher has two feet" to be particularly interesting or | even unambiguous. Is "two feet" an anatomical statement, or a measurement | (e.g., has two feet of figurative rope, by which he can easily hang himself | in a forum such as this), or both <G>?
True, so long as rigour doesn't become a straightjacket, at least at this stage where we are still in explore mode. Personally, I think that if we merely XMLify the Lucid or DELTA data format, we may have failed our successors...:-(
| >| I might also note that I strongly question the way the above is organized. | >| I think a rearrangement better expressing the relationships (but still not | >| really addressing the problem of a lack of meaningful validation) would be | >| more along the lines of: | >| | >| <ITEM> | >| <ITEM_NAME> Gouania exilis </ITEM NAME> | >| <ELEMENT> | >| <ELEMENT_NAME> Flower colour </ELEMENT_NAME> | >| <VALUE> green | >| <QUALIFIER> rarely </QUALIFIER> | >| </VALUE> | >| </ELEMENT> | >| </ITEM> | > | >This is perhaps a subtle point, perhaps a trivial one, and I'm glad you | >raised it. Why is this better that the above? What exactly is the advantage? | >I know yours is more DELTA-like and I agree it seems more intuitively | >correct, but is there more to your strong belief than that? In truth, I | >played with different ways of structuring unitary statements and presented | >the one I did to draw comment rather than just follow down the path of what | >we do already. | | I think there is a real difference in terms of a reduction in ambiguity. We | should generally make an effort to clearly associate modifiers with the | object that they are intended to modify. Suppose we have something like the | following: | | <ELEMENT> | <ELEMENT_NAME> leaf </ELEMENT_NAME> | <VALUE> | lobed margins | </VALUE> | <VALUE> | with spines | </VALUE> | <QUALIFIER> | rarely | </QUALIFER> | </ELEMENT> | | How should such a construct be interpretted? Do spines cover the leaf as a | whole, or are they confined to the lobed margins? Is it the spines which | are rarely present, or the lobed margins?
Yes, I agree with all over this. OK, so it was a dumb idea...
Are we agreed then that the basic unit of a description is a statement of the form
<DESCRIPTION Name = "a taxon or thing"> <ELEMENT> Name = "a character or feature that the taxon or thing has"> <VALUE> The value that the element has in this case <QUALIFIER> One of a small list of defined qualifiers (e.g. "rarely") </QUALIFER> </VALUE> <VALUE>....</VALUE> </ELEMENT> <ELEMENT>...</ELEMENT> </DESCRIPTION>
..and that this structure (with suitable properties for elements etc see the draft spec) can capture any and all parts of a description?
Cheers - k