The basic statement

Kevin Thiele kevin.thiele at PI.CSIRO.AU
Tue Sep 5 08:57:06 CEST 2000


----- Original Message -----
From: Eric Zurcher <ericz at ENTO.CSIRO.AU>
To: <TDWG-SDD at 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




More information about the tdwg-content mailing list