TDWG-SDD XML proposals of Kevin Thiele

[Jim Croft]

>The material at
>http://www.cs.umb.edu/efg/ThieleDraft/thiele_0_3.html illustrates our
>efforts to draft an XML Schema from Thiele's draft proposal version
>0.3 ("TDD0.3") and illustrate its utility with simple
>applications manipulating a taxonomic treatment.

No-one seems to be commenting on this, at least on the list... is it all
too scary?  With Halloween just around the corner, do these guys deserve to
be tricked or treated?

Unless people are commenting directly to Kevin/Bob/Jun, I would imagine
they would be feeling pretty disappointed so far...

I have been through this a number of times, still trying to come to grips
with the various options that have been used from the draft specs of a few
weeks ago... and why...

This is a great attempt at implementation and surely demonstrates that we
are on the right track...  doesn't it?

Yes, the format does seem a bit verbose, but from what I gather Bob and Jun
are saying, let the software, applications and databases worry about that...

Personally I prefer something like:

<taxonomy>
     <rank="species" value="alfari"/>
     <rank="genus" value="Azteca"/>
     <author value="Emery"/>
     <year value="1893"/>
</taxonomy>

to something like:

<DESCRIPTION name="Taxonomic Information">
    <FEATURE name="Species Name">
       <FEATURE_VALUE>alfari</FEATURE_VALUE>
    </FEATURE>
    <FEATURE name="Genus Name">
       <FEATURE_VALUE>Azteca</FEATURE_VALUE>
    </FEATURE>
    <FEATURE name="Namer">
       <FEATURE_VALUE>Emery</FEATURE_VALUE>
    </FEATURE>
    <FEATURE name="Name Year">
       <FEATURE_VALUE>1893</FEATURE_VALUE>
    </FEATURE>
</DESCRIPTION>

but if we never have to read it in this format, I do not suppose it really
matters...

Anyway, it looks as though we are settling on an architecture allows both
discursive descriptions accommodated by 'narrative' elements, and for the
compulsive obsessives, a nested set of 'features' that can have
'feature_values', 'qualifers' and associated 'narrative'...  Right?

And that the competing architecture of a list of 'feature_values' that can
be present, absent, unknown, doubtful, present by misinterpretation, absent
by misinterpretation, imaginary, etc. has been given the flick?

Or having coded the data in this manner, is this distinction in data
representation employed by different interactive identification products,
not really relevant or meaningful?

Sorry about the rambling - just trying to come to grips with what has been
done here...  I am pretty sure it is good stuff once I work out what it all
means...

One vague background concern I have is with things like:

<FEATURE name="Page Author">
    <FEATURE name="name">
       <FEATURE_VALUE>John T. Longino</FEATURE_VALUE>
    </FEATURE>
    <FEATURE name="efg address">
       <FEATURE_VALUE>The Evergreen State College, Olympia WA 98505
USA</FEATURE_VALUE>
    </FEATURE>
    <FEATURE name="email">
       <FEATURE_VALUE>longinoj at elwha.evergreen.edu</FEATURE_VALUE>
    </FEATURE>
</FEATURE>

which seems on the surface to correspond to ye olde library cataloguing
metadata stuff.  Is there a wheel here we do not need to reinvent?

Related to this there are a number of projects around to place using XML to
mark up and display descriptive data and taxonomic treatments and they seem
to inventing rafts of 'feature' names for what appear to be the same things
in terms of blocks onf information.  At the higher and metadata level, is
it too early to talk about rationalizing these?  Being very wary here, not
wanting to open the Pandora's character-list box of worms again...

jim