Okay, here’s the idea.
There are thousands of dichotomous keys
out there hidden and half-forgotten on shelves of naturalists,
waiting to be recycled into multi-acces keys ( read more about the difference)
It may be simple A4 leaflets to give some of the most common shells of a local shore a name.
Or extensive keys dealing with all species of a taxon in a larger area for scientific purposes.
Lot of the work nowadays focuses on building up the multi-acces keys from the ground,
simply defining a set of features for all specimen in a target set (and at the same time efforts are made to
regenerate dichotomous keys based on these sets…).
This page forms a general introduction with the essentials.
During working with the app several handles for context sensitive help are available.
The idea presented here is to provide entry-forms to
enable the community to digitize the current dichotomous keys in a structured way.
Thus we achieve that:
- The “old” dichotomous keys still are one to one useable,
so this digitizing effort has the direct result of publishing the key
onto the internet. - The conversion into multi-acces keys can be done as a transition: at any desired pace, with every input directly useable.
- The multi-acces keys that are (partly) filled this way will be accessible
in a way that contains the best of these two worlds:
the dialogue works as multi-access where you can click on the applicable features to determin your object, but… the remaining features will be listed in a sort order with the most completely filled feature/choice on top.
Hence if you every time fill in the topmost feature from
the list, you in fact “follow” the original key!
Key factors to the succes of this approach are:
- The use of a blueprint, where all the characters in the key are picked from.
- Multilingual
- A controlled environment where users have all freedom to enter there own keys and blueprints and control who are allowed
to edit or view their work and may submit their work for publication in the public area - A clear policy on how the data is accounted for (source, copyright, author), and easy downloading for all the data the user owns.
The download facility provides an extra backup for the author’s work.
Dichotomous Key Editor (DKE)
Let’s have a look at a fictive key:
| 1. | a. | Flower is yellow… | 2. | ||
| 1. | b. | Flower is blue… | 3 | ||
| 1. | c. | Otherwise… | 6 | ||
| 2. | a. | Flower diameter > 3 cm… | Trollius | ||
| 2. | b. | Flower diameter <= 3 cm… | 5 | Ranunculus | |
| 3. | a. | Flower 2-sided symmetric… | 4 | ||
| 3. | b. | Flower multi-symmetric… | Aquilegia | ||
| 4. | a. | 1. | Flower with hood | ||
| 4. | a. | 2. | Leaves divided…. | Aconitum | |
| 4. | b. | Otherwise… | 17 | ||
| 5. | a. | 1. | Peduncle grooved | ||
| 5. | a. | 2. | Peduncle square | Ranunculus repens | |
| 5. | b. | 1. | Peduncle not grooved | ||
| 5. | b. | 2. | Peduncle rollround | Ranunculus acris | |
| 5. | c. | 1. | Otherwise… | … | |
| 6. | … | … |
Note that this key is only useful within a certain context.
This example has flowering Buttercups in Europe as starting point, and is just an example of a few species.
Some terminology:
-
1, 2, 3…
are called “couplets”
-
1a, 1b, 1c, 2a, 2b, …
are “leads”
- lead 3a consists of two features:
4.a.1.
and
4.a.2.
The dichotomy of the key prescribes that the
within a
are mutually exclusive, so
is true OR
is true.
The parts within a lead are mutually inclusive, so
AND
must both be true to render into Aconitum.
The quality of the determination deteriorates when its successive steps contain
features that are not always the case (e.g. “most of the flowers are red…”).
Therefore all features are qualified in the context of the lead. In
combination with a judgement of the difficulty of each leadpart, this will give
the multi-acces key the opportunity to calculate the
probability whether the determination is correct.
OR-constructs are not allowed among leadparts (to avoid ambuigity in the interpretation for both reader and the dichotomous keys converter). Instead extra leads should be constructed leading to the same point in the table, e.g when violets can be either blue or white we’ll have to construct:
| 5.a.1. | Flower is blue… | 6 | Violet |
| 5.a.2. | Flower is white… | 6 | Violet |
This will render into Violet for either blue OR white flowers (genus Violet further determined in couplet/choice 6).
You might also want to add non-structured text and images in a lead, which is possible. This might pimp your key, but will not help you converting it into a multi-access key.
Instead, all illustrative and explanatory text should as much as possible be added to the feature of the blueprint that is underlying to this part of the key.
Blueprints
Blueprints are an essential concept to structure dichotomous keys into data sets.
Setting up proper blueprints can be a bit demanding:
the author needs to layout the possible characters of the described taxon into a hierarchically correct and yet easy to explore
tree of items. But the succesive entering of keys based on the blueprint should work smoothly and userfriendly.
Blueprints are essentially a key in itself, this time a key of the layout of a group of organism.
Take for example a look at a part of a blueprint for vascular plants:
| 1.a. | leave… | leave | 2 |
| 1.b. | stem… | stem | 8 |
| 1.c. | root… | root | 11 |
| 1.d. | attachments like flowers, bulbs… | attachments | 15 |
| 2.a. | partly enveloping the stem… | sheath |
As you can see such a blueprint looks like a key in itself.
But the construct of the tree is more freely defined, for not all leads need to be mutually exclusive.
And the final “leaves” of this tree are not associated to a taxon (nor to keys), but are attributes of their parent feature,
e.g. when the parent is (flower)”color”, the leaves are “blue”, “yellow”, “white”, etc.
Blueprints form the backbone of any key setup: Every line in a key (lead-part) is built up
with three components: a feature + comparator + child-feature.
E.g. color = blue.
Jumpstart your key by using or copying existing blueprints
The idea is that a blueprint of how a taxon is built forms a stable startingpoint for any key about species within this taxon.
Every key-editing starts with the setup of a blueprint, or the decision to use or copy an existing one.
If there are no existing blueprints available for the desired taxon the editor has no choice then to start its own.
But if there is a blueprint that is already available for reuse, the editor can check its content and decide to use or (if allowed)
to copy it. This not only saves the editor a lot of time, but, more important, the reuse of the same blueprint
enables to compare the keys that are based on it, and enables the users to determine simultaniously with multiple keys
with still exactly the same interface of features.
E.g. think of an extra key for flowering plants in an second region:
when it uses the same blueprint as the key for the first region the user may use both,
thus extending the area with still the same trea of features to deal with.
Since only the features that are used within a key will actually show up in the determination,
there is no good reason for a key-editor not to just use the same blueprint.
Of course there is some governance to be covered here in case a blueprint is made available for use and/or copying.
In short: the (group of) owner(s) of a blueprint at any time are in full control, but on deletion of the entire blueprint
the app will first make a copy for each key that is using this blueprint to ensure no broken links will occur.
A moderator is available in the background to address conflicts (as long as the owner works alone and has never allowed that
his/her keys or blueprints may be copied, he/she can be sure this won’t happen).
Roles, responsibilities, ownership, workgroups
Every end user is free to use multi-acces keys
that are permitted for publication by both the key-owner
and the moderator.
Only the key-owner himself,
the usergroup
-members that were granted contributor rights by the key-owner,
and the moderator get the ability to download the data of a certain key at any time.
In the properties screen (click on the link of your name in the header) the user can add its own workgroups.
Just creating the group means you are working on your own. But you can add trusted other users as members of your group, adressing them view/update rights per key.
Available roles:
- Guest – only able to view keys published by the moderator
- Viewer – as guest, plus viewing rights into otherones keys when allowed by the owner
- Updater – as viewer, plus update rights where allowed by the owner of the key
- Moderator – all rights, to solve issues of any kind
Citing sources, authors and other links
Every lead part is linked to a key, which in turn contains a reference to a source
(basically consisting of a title, author(s) and publisher). Thus every entry to each table is accountable.
In case of reuse of other blueprints (see jumpstarts)
the system keeps track of the origal attributor and the moderator will not allow publication when the data is not properly referred.
This applies for copying keys, taxa and features. The smaller lookup lists like comparators and units are freely copied without referring the original source.
In this way spx tries to endorse the GNU guidelines.
Multilingual
Everybody is expected to enter a key in one language (probably his native).
Every component that makes up a lead part can be translated afterwards, thus adding a translation for the key.
Buttons, navigation
Navigation through the app is done by clicking:
Links. Normally to drill-down the app. Special case: when you pressed a -button you are in a lookup
and the link will pick the item from the list and return it.
for e.g. saving, updating. Although most of the buttons will also be displayed for guests and viewer,
the action behind it may be disabled for authorization reasons.
To edit the properties of an item
To track your path through the app you can either use a -button
or the breadcrumbs on top of the screen (both not always present),
or use the Next and Previous page of your browser. will never save, so use before you go back.
To enhance navigation through bigger sets of data search-dialogues are often available on top of the list they act upon.
Tree-dialogues have and -buttons on top.
Dichotomous Key Converter (SPXDKC)
Specifier (SPX)
Future (2nd phase developments): Graphical interface for the blueprints
Help features
Help is available at the following spots on each page: