Will someone list for us exactly the benefits and disbenefits that will flow
from using XML for a data interchange standard?
Gregor wrote:
>>These issues should be seen quite separately, and that we need both
>>
>>1. A markup language for text documents. This includes:
>> - existing descriptions, captured by OCR or other means, where the
>> markup would be manually (or automated/data mining?)
>> - computer generated natural language descriptions that are
>> published as electronic documents. A new CSIRO package could have
>> a ToNat command that automatically adds the necessary, hidden
>> markup code.
>>2. A data language for new observations, including repeated
>> measurements or repeated observations of categorical data, e.g.
>> shape of multiple leaves in a single specimen. Further, many
>> structures for knowledge managements (data revision, annotation,
>> quality control and assessment) need to be implemented here.
>>
>>The issues overlap, and it would be beneficial to use as much common
>>syntax as possible, but fundamentally I believe them to be quite
>>different.
To which Jim Croft replied:
>Can you explain in more detail why they should be fundamentally different?
>Aren't the differences just a matter a matter of degree, different points
>on a continuum of data as it were? And aren't the basic principles
>applicable across the whole?
We need to explore this a lot more.
I'm talking here about the data language, not the markup language, as it
seems to me there are practical, even if not theoretical, differences.
I can well understand the benefit from marking up a document (a text
description) in XML. But when it comes to straight data, I'm less sure.
By straight data, I mean data that can be represented most concisely as a
matrix, for instance:
Characters:
Leaves
ovate
elliptic
Flowers
blue
yellow
Taxa:
taxon1
taxon2
Data (taxa x states):
0101
1010
(...or a DELTA type disaggregated matrix)
With this type of data, the XML markup becomes considerably more verbose
than the data. Is this a problem?
Over the past couple of days I've partially implemented an export function
to produce Leigh's XDELTA documents (as a simple example of a possible XML
format) for the data in Lucid keys. I have a key to families of flowering
plants of Australia (240 taxa, 166 characters, 600 states). The data I'm
using are simple - basically a score matrix, a list of taxa and a list of
characters. The file sizes in three formats for these data are:
LucID 166 kb
DELTA 240 kb
XML c3 Mb
And this is only the most basic XML!.
Now, perhaps in a few years we'll be carrying terabytes of data in our back
pockets, but I would have thought that file size is important, particularly
if I'm using this as an interchange format and want to email the data to
someone (the xml file compresses very well into a zipfile, it's true).
The following question:
what could we do with such data as XML that we couldn't do with the data as
a simple structured file as above?
Leigh wrote:
>Secondly I might not be generating anything visible at all. I can
>well imagine an application that will take an XML document and
>from the data within produce (say) a taxonomic tree or tress of that
>data. Here I wouldn't use a stylesheet, I'd simply process the
>data directly.
Is direct processing of XML data any easier than direct processing of the
data in a simpler format? Perhaps there will be off-the-shelf parsing tools,
but how much of a benefit will this be?
The problem to my mind is that in current formats, e.g. DELTA and LucID,
much information is implied by context. Thus, in
1010
0101
The taxa and character state numbers (identities) are implied by the
position of the data bit in the matrix. In XML this information is verbosely
explicit.
Is the following true?: once upon a time, computers could represent but not
efficiently analyse or process textual data, hence documents were stored as
text but "data" were stored as matrices etc. Now, XML has blurred the
boundary between these types of information ("textual" and "data") and we're
exploring the implications of that blurring. But are there now no
differences, and no further need for a matrix?
A final point. It seems to me that the discussion so far has been dominated
by computer nuts (no offence intended, we need you!), with relatively little
input from the community of taxonomists whose needs this standard is
supposed to serve. Most of these will be happy to use a well-crafted tool,
but won't want to know the intricacies of XML, and will be put off if things
are not quite straightforward. This is a danger. We may end up with a
wonderful, sophisticated, state-of-the-art, cutting-edge standard that
nobody uses.
Cheers - k
