Keys to Nature
Project
Project Background

Our digital roots

The project originated with a small group of individuals-Pat Leacock, Gayle Tonkovich, Bil Alverson, Greg Mueller, Laurel Ross, and other colleagues who worked on the vPlants project (www.vplants.org)-who wanted to increase the visibility and use of the great resources that vPlants has to offer.

As of July 2008, vPlants offers web-searchable data for ca. 72,000 plant and fungal specimens collected in the Chicago Region, with over 50,000 images of these specimens.



vPlants also offers "species pages," each of which provides a description of the species (e.g., leaves, flowers, fruits), its flowering times and habitats, ecology, and conservation status, as well as tips for distinguishing it from similar species. (At present there are over 1,300 species pages posted on line, with at least 400 to come, soon.) Many species pages offer color photographs of the living plant or fungal species, as well.



However, at present you can only find data on a particular species by knowing its scientific or common name, or by searching for the name of the person who collected a specimen, or a county or other place name of where it was collected. Unfortunately, you cannot search based on characters, so you can't ask questions like this: What is that red-flowered plant with opposite leaves I collected in the woods in July?

Keys to Nature was born in response to this need for modern identification tools.

Technology choices

In the spring of 2007, we reviewed many of the available web-based tools for identifying plants and fungi. Some of the best are electronic "synoptic" keys (also called multi-access or multiple-entry keys), in which the user gets to choose the order of the characters of focus in the identification process. For example, see the Electronic Field Guide Project (http://efg.cs.umb.edu/efg/) and Discover Life (www.discoverlife.org). These synoptic keys require a web-enabled database as an infrastructure.

In contrast, "guided keys" (also known as single-access keys) lead the user through the identification process by considering characters in a specific, presumably wisely chosen, order. These were the standard when keys were delivered only in print media. For example:
  • 1. Stipules or stipule scars present - 2.
    • 2. Leaves 3-lobed; teeth without sharp, dark tips - Physocarpus opulifolius
    • 2. Leaves unlobed; teeth tipped with sharp, brown or black tips - 3.
      • 3. Leaves oval-shaped, to over 2 cm wide, and densely hairy; found throughout the region - Ceanothus americanus
      • 3. Leaves narrow, less than 2 cm wide, smooth above but slightly hairy below; in sand prairies along Lake Michigan - Ceanothus herbaceus
  • 1. Without stipules or stipule scars - 4.
    • 4. Leaves with tiny, disc-shaped yellow glands underneath (stems without spines, flowers yellow, ripe fruits black) - Ribes americanum
    • 4. Leaves without yellow glands underneath - 5.
      • 5. Flowers in racemes, i.e., borne on a long, hanging stalk of 5 to many flowers; stems without spines and without thorns at nodes - Ribes triste
      • 5. Flowers axillary, in clusters of 1 - 4 arising from stem at base of leaves; stems sometimes with spines and nodes usually with thorns) - 6.
        • 6. Calyx lobes shorter than the tube (the bottom part of the calyx where the lobes are fused together); berries usually prickly - Ribes cynosbati
        • 6. Calyx lobes as long or longer than the tube; berries usually smooth - 7.
          • 7. Stamens much longer than petals ("long exerted"); flowers long and narrow, whitish - Ribes missouriense
          • 7. Stamens more or less equal to the petals in length ("included"); flowers greenish or purplish - Ribes hirtellum
We decided to use guided keys, and an HTML infrastructure, for several reasons.
  • They allow us to tap the expertise of professionals and citizen-scientists in the Chicago Region in a way that "unguided" multi-access keys do not: knowledgeable authors can use their experience to guide our attention to the characters that they believe matter most.
  • We envision this process as one involving many, independent participants who volunteer their time and expertise with the reward of seeing their knowledge on the web for others to use (as well as the opportunities for feedback and collaboration). The set of keys can be built up as time and expertise allow, without resources to build a comprehensive, consensus-built database.
  • We at The Field Museum have some constraints on our ability to host web-enabled databases that can be accessed by users outside of the Museum. We were attracted to the excellent open-source technologies of the Electronic Field Guide Project (http://efg.cs.umb.edu/efg/), but we capitulated to our institutional constraints on implementation of an EFG server. No such constraints exist for web-servers at the Museum.
  • We needed to create a simple, low-tech mechanism that was easy on the Keys staff, authors, and users, so eliminating the need for a database was the first step. Building an HTML-based mechanism was the next.
  • Finally, HTML is very portable and doesn't require an internet connection or local database to run, so you can haul our keys into the field with you.

Nesting, and hybridizing keys and picture guides

Also during the spring of 2007, one of us (P. Leacock) noted that many traditional, print-format keys were "nested." That is, there would often be a top-level key that would lead to several, large groups of species. Then, users would arrive at an identification via one or more additional set of nested keys, each more specific and tailored to the species it included. This was significant for us because we realized that not only could we nest keys, as had been done traditionally, but we could mix and match different types of keys, as well as other kinds of resources for identification, at different levels of the process.

Picture guides (often picture-only guides) are a non-key resource for identification. For example, Robin Foster's group at The Field Museum produces Rapid Color Guides for identification of plants and animals, primarily tropical (http://fm2.fieldmuseum.org/plantguides/rcg_intro.asp). These began as print-format guides, laminated for use in the field, and evolved to both print-format and electronic forms. For a group of interest (like frogs of a region, or palms of a particular national park), they promote identification with a set of pictures showing characteristic images of each species—akin to a multi-entry key with the characters provided by the images themselves.

We first envisioned using picture guides at the top-level of an identification process—to lead users to groups of species based on general characteristics—and then jump to the next, nested layer of identification, i.e., illustrated, guided keys that could be produced with the Keys to Nature Project. We later realized that picture guides also are a good fit at the branch tips (terminal nodes) of a key, which sometimes end in small groups of species (for example, see our guide to common shrubs of the Chicago Region). The luxury of using digital formats, rather than print, means that we can keep everything flexible and very modular.

In sum, we concluded that there was no "best" type of identification tool—dichotomous, polytomous, or multi-entry/synoptic keys or picture guides. Our vision for the Keys to Nature Project is that it should provide a web-based infrastructure to do the following:
  • Use nested sets of keys and guides rather than a single, databased, "synoptic" key for everything.
  • For each level, use the type of key or guide most workable for that group of organisms.
  • Hybridize keys and guides, when useful; the formats can blend into each other.
  • Make the process very image-rich.

Why Keys to Nature is an experiment

Aside from the traditional arguments over single-access versus multi-access keys, we need to assess the plusses (easy, fast, cheap, hopefully useful) versus the potential downsides of our HTML-based keys. For example, once a key is built in HTML, is it brittle? That is, how difficult in practice will it be to add or subtract species from a key, to create a new revision of a key, to extend branches of a key to more finely distinguish between members of a terminal group, to attach independent keys into larger composite keys, or to combine two independent into a single key?

Wish us luck, then, and please participate as a user, or author, of our web-based keys!