SDD Specifications Document

Kevin Thiele kevin.thiele at PI.CSIRO.AU
Mon Mar 6 09:46:34 CET 2000


>1. Collation rules. These are currently unspecified. Any objections
>if I leave them out of an attempt to express these in XML? We
>can revisit and revise this portion as time goes on.

I think it's an important thing to try to implement this part, as it's a
fundanmental part of the structure but also new and difficult and we need to
give people a chance to comment & revise. The three main aspects of the
draft standard as documented are
1. The ability (but not necessity) to attribute every data element to a source
2. The ability to collate data from lower-level (e.g. real-data) to
higher-level (e.g. synthesized) sources
3. The open-ended hierarchical structure for character and taxon lists.

I haven't given a lot of thought to how the collation rules would work in
practice. The basic idea is this. Suppose you have one treatment that stores
base data (measurements etc) for observed specimens of your taxa, then
another treatment that wants to collate parts of these data to a taxon-level

e.g. One file has

Character = "Spore length (um)"
        Taxon =  "Macrolepiota clelandii"
                Specimen = "CANB4545601"
                        Value = 15
                        Value = 18
                Specimen = "CANB233976"
                        Value = 16

The higher-level file wants to collate from this
Character = "Spore length (um)
        Taxon = "Macrolepiota clelandii"
                Minvalue = 15
                Maxvalue = 18

The collation necessary here is simple - "Find the limits of the range".
Other simple rules may be "Find the limits and mean", "Find the limits and
25% quartiles" etc. For multistate characters the most common rule will be
an additive one - "collect all values for the character and concatenate them":

Character = "Petal colour"
        Taxon =  "Lilium turkestanicum"
                Specimen = "CANB4545601"
                        Value = "Pink"
                Specimen = "CANB233976"
                        Value = "Purple"

Now, I don't know what's the best way of formulating the rules. Would you
simply have a set of standard names for rules as above, then leave it to the
processing program to do the work, or can the whole thing be embedded in the
XML (so that looking at the higher-level treatment with an XML interpreter
would show you the collated data)?

If the rules need to be formulated rather then just named the challenge is
to do it in such a way that an XML parser could do the collation, and a
klutz taxonomist could create their own if an existing one is not sufficient.

Is this possible or am I talking out of my stovepipe?

>2. Collated Character source. I see these as essentially
>a drill down mechanism that further identifies a 'bottom-level'

The necessary thing is to identify a path to the treatment that contains the
data for collation, and the taxa of the lower-level treatment that will
provide the data for a taxon in the current treatment. In the example above
it's perhaps deceptively simple, because the target taxa in the lower-level
treatment (in this case, the specimens) are nested within a taxon with the
same name as the current taxon in the higher-level treatment (Macrolepiota
clelandii or Lilium turkestanicum). This is perhaps the easiest way to do it
(thinking aloud now) - require that the taxon of interest exist somewhere in
the taxon hierarchy in both treatments, then step one down in in the
lower-level treatment to find the elements of interest. Does any of this
make sense to anyone - I'd quite like some support here, if anyone's still
out there.

>Is it reasonable to include character dependencies 'upwards'?

Don't know - I need to think about this more. There may be a problem if you
mix and match "up" and "down" dependency definitions. The thing is to choose
the one that will be most easily defined.

>Am I right in believing that multiple character sets could drill
>down into the same source (perhaps produced by different
>organisations, researchers, techniques). In this case, is
>there a principal source for going back upwards? It seems
>unfair to expect a treatment to keep track of all other treatments
>which point to it (I may be infering too much here).

I think you may be off the track (or I may be). A character dependency is a
property of a character or a state (depending whether it's an up or down
dependency). It should be internal to a treatment, so there's no "keeping
track" to worry about.

>3. Why should characters only have properties at the lowest level?
>What is the 'lowest level' given that drill-down can occur? Could
>you outline the reasoning here?

You're right - characters at higher levels may have properties also e.g.


It may be worth providing notes, illustrations etc for "Leaves" so basic
information can be moved up the hierarchy. Similarly, an "up" dependency set
to "Leaves" would apply to all lower-level character items.

>4. Its possible to provide a Character list internally to the
>treatment or reference an external one. Will it be a requirement
>that both could be used (i.e. combine the internal and external lists.)

Yes. The way I see it an external character list is a resource, but not a
constraint. If one is referenced a treatment builder should also be able to
1. define their own internal characters,
2. perhaps pick and choose amongst the characters from the referenced list,
rather than have to use them all.
I think such flexibility is necessary if lexica are to grow.


Cheers - k

More information about the tdwg-content mailing list