Progressive Revelation

[Kevin Thiele]

At 15:30 24/02/00 +1100, Eric Zurcher wrote:

>6) I'm intrigued by the notion of a "Progressive Revelation model"
>(footnote 5). It sounds terribly theological - or perhaps that's
>Thiele-logical? (my apologies to Kevin, but I really can't resist bad puns).

I'm often accused of teleology, but rarely of theology.

Progressive Revelation is perhaps a new way of handling holes in data
matrices for random-access keys. The background is this:

The simplest data structure for a random-access key is a fully populated
matrix i.e. all taxa are scored for all characters/states. Works well
sometimes, especially if the taxa are highly comparable e.g. the species of
a genus or the genera of a family.

This structure is problematic sometimes though, for two reasons. Firstly and
most simply, you may not have data for all taxa, and need to leave holes in
the matrix. Solution is simple - fill the holes with ?s and allow for this
in the key program. But it often also happens that some characters are
simply inapplicable to some taxa, or (worse) are non-ambiguous for some taxa
but ambiguous for others. For instance, stipules don't occur in monocots,
stipule-like structures sometimes do but if you try scoring stipule
characters as defined for dicots against monocots you run into all sorts of
strife because of ambiguity of context. LucID can handle this to some extent
using the "present by misinterpretation" score, but the problem is in the
character definition, not the score.

Sometimes a better way to handle such circumstances using LucID is to break
the key up into a hierarchically nested set of keys & subkeys. For instance,
you want to create a key to grass species of Australia but there are many
special characters needed for identifying Poa species that are either
inapplicable to or ambiguous with respect to the remaining grasses. So put
Poa as a genus in the top-level key and attach to it a subkey to Poa species
in which you can optimise your character definitions for the Poas. There are
some disadvantages to this but often the advantages (in having an optimised
rather than generalised and suboptimal character list) outweigh the
disdvantages.

But there may be another solution - Progressive Revelation. As far as I know
no-one's done this yet, but I think it has merit. It would work like this.

Create a key to all grass species so you're working with a list of all taxa
at species level including all the Poa species. The character list has two
classes of characters - ones that are scored over all taxa (these will be
the easily generalised characters) and ones that are scored for only a
subset of taxa (the characters that are highly specific and/or not easily
generalisable). When the key program starts it splashes up the generalised
characters only. But if after answering some characters you end up with only
Poas, the program finds and adds to the character list the Poa-specific
characters. Characters are progressively revealed as you proceed through the
key, with as much depth as necessary - e.g. you may come down to a species
complex of alpine Poas and presto! some characters appear that are just the
ticket to separate them.

Might work.

This seems to me to be a more natural way of approaching both the building
and running of a key. In some ways it's like a hybrid between a traditional
random-access key and a traditional nested hard-copy key, but it has more
flexibility than either.

In the context of natural-language descriptions (and more controversially)
it would also provide a challenge to what to me is the Universalist furphy
that all descriptions should be strictly comparable!

I've included these ideas into the SDD Specification because I think this
may be one for the future.

Cheers - k

ps Eric - if you incorporate these ideas into DELTA we'll need to make an
arrangement regarding due acknowledgement and royalties :-)