Managing Botanical Data

By Sandra Schloen, February 2021

Photo compliments of the Tayinat Archaeology Project, SA 1200

Botanical data is a valuable source of information for archaeology projects. Based in the natural world, and subject to scientific analysis, there is the opportunity to standardize and share, to some extent, the practice of representing this data in OCHRE. Botanical samples might be collected in a variety of contexts -- as charcoal samples, from soil samples, from the light fraction of floated material -- and contextualized within baskets, buckets, lots, or pails of soil, or even from within a vessel, for example. For the purpose of this article, it does not matter where or how your botanical samples are contextualized.

When the sample is collected, the Description field may contain a general classification: "olive pit", "grape pip", "seed", "charcoal." It is only much later in the lab that the specimen is properly analyzed and identified: "charcoal" becomes the stalk of a Vitus vinifera specimen. Similarly, naming of botanical samples can be haphazard: "Seed", "Botanical remains #101", etc. Again, it doesn't matter what Name the sample itself is given in OCHRE. A project might use a barcode label, a serial number, an auto-label using an OCHRE Predefinition, or whatever strategy for naming suits its collection process. More important are the classificatory properties assigned to the item. This article demonstrates how to add and leverage taxonomic properties to describe botanical remains.

This article assumes a general familiarity with the Taxonomy category in OCHRE.

The data used as the basis for our case study here is provided courtesy of the Zincirli Expedition. We discuss data entry strategies for recording botanical samples then review relevant OCHRE features for retrieving this data for display and analysis.

Botanical remains

An OCHRE project that does not wish to reinvent the wheel could get a head-start by red-copying the entire Botanical remains branch of the OCHRE Master taxonomy from the OCHRE Master project. This contains a basic list of properties needed to describe a specimen. If additional properties or values are needed by a project, we are generally happy to add items to this list in order to make them available to the community.

Alternatively, a project may choose to red-copy only selected portions of the Botanical remains branch, to allow for more extensive customization. For reasons which will become clear below, the strategy described here requires the use of the Botanical taxon ... relational variable at a minimum.

Botanical remains, in context

At Zincirli, most botanical samples come from soil samples, each logged simply as a "Soil sample," that have been floated to extract the light fraction which contains the botanical material.

The Soil sample item is contextualized within the Pail (P15-55.68#26) with which it is associated; the Pail in turn is contextualized within the Locus of excavation (L15-3012). The Soil sample is given a unique serial# by the archaeobotanist when it is processed (FS2015-043). The Light Fraction that was floated is given the same name as the corresponding Soil sample, but with the suffix LF (FS2015-033 LF).

Each item in context is described by appropriate Properties, Notes, and Events as illustrated below.

The Soil sample (FS2015-043)

The Light Fraction (FS2015-043 LF)

Botanical remains, itemized

Notice in the example above that there were 8 separate species of identifiable botanical remains, each with a corresponding quantity. Each identifiable species needs to be represented by its own database item. This will be important for doing quantitative analysis using this data. The same logic applies to a charcoal sample that might have a mix of species -- separate out each species into its own subitem.

When the item is logged in the field, usually by a non-specialist, it is typically given a stub entry with very little information. Once the specialist has analyzed the specimen, the identification of Quantity, Botanical taxon, and Plant organ are added. Generally we add this new information to the same, original observation, as it does not rise to the level of a new observation. However, be sure to note the specialist as the Observer (often in addition to the field excavator who recorded it initially).

Botanical remains, identified by taxon

The Botanical taxon property is a relational variable that targets an alphabetical list of Families, Genera, and Species that have been catalogued in the OCHRE taxonomy. Use the dynamic pick-list, provided by the chevron button, to select the most specific level of taxon identification for that item. Sometimes the specialist can only identify the Family; pick the Family from the list and leave it at that. If you also know the Genus, do not pick the Family, but pick the Genus instead. If the specimen is identified to the level of the Species choose that instead of the Family or Genus. OCHRE will use the hierarchical taxonomy to infer Family and Genus if Species is given (examples to follow below). This approach makes data entry simple -- one property that targets the most specific taxonomic identification.

[Previously, it was necessary to enter the full hierarchical structure of the taxonomic identification: Family -> Genus -> Species. This is no longer necessary due to the use of the relational property Botanical taxon which targets the appropriate Value directly.]

Depending on what features your project is recording, create a Predefinition in the usual way for data entry of botanical specimens.

Naming Botanical remains

The Predefinition used by the Zincirli project is configured to auto-label the item using the Value-only of the Botanical taxon property. But notice in the example above that the archaeobotanist has taken some liberties with the naming conventions. This is a matter to discuss with your project team. The Botanical taxon identification is based on a controlled vocabulary, so OCHRE will not depend on Names of items for searching, etc., but it is good practice to establish and conform to a set of naming protocols for your project.

Botanical remains, cross-registered

At Zincirli, a charcoal sample of significance might be recorded in OCHRE first as a Registered item using the protocols established by the registrar. Only later is it given to the archaeobotanist for analysis.

There is no problem recording a sample as both a Registered item and a Botanical remains. Name it appropriately, taking advantage of the Alias option if needed, and assign the Properties pertaining to each classification. (Note, however, that an item assigned as a Botanical remains does not also need Material = Botanical as a property.)

Cross-registration of an item as BOTH a Registered item AND a Botanical remains

Other data entry issues

If the identification is uncertain ... In this case, use the "?" checkbox to mark the Botanical taxon selection as uncertain. If the Botanical taxon variable from the OCHRE master project is being used, and if it is specified for use in auto-labeling, OCHRE will automatically prefix the auto-label with "cf. " per convention; e.g. "cf. Vitis vinifera."

If there are multiple uncertain identifications ... In this case, repeat the Botanical taxon identification as needed to capture the possible identifications, marking each one as uncertain. Adjust the item Name as you wish, manually; in the example above, the archaeobotanist at Zincirli has used "Triticum aestivum/durum."
If the identification is confident as to Genus, but not Species ... In this case, assign the Genus as the value of the Botanical taxon property, since this is the most specific level at which the specimen can be identified. Feel free to use the "sp." abbreviation, by convention, in the Name of the item if you wish; e.g. "Lolium sp."

In all cases, use the Comment option of each property for clarification or additional notes as needed.

Note, too, that we do not include separate property values that use the conventional notations of "cf." or "sp." The Botanical taxon list will remain a controlled list without such variations so that we can query, aggregate, and do analysis reliably. Use of the conventional notation in the Name of any given sample is fine, however, as we have illustrated above.

Botanical remains, Analysis

In the above discussion, we recommend tagging each Botanical remains specimen based on the most-specific Botanical taxon that can be identified. Sometimes this is a Species. Other times, it may be at the level of a Genus, or even of a taxonomic Family. But for each Value assigned, OCHRE knows at which level it participates in the overall hierarchy of Botanical remains.

Say, for example, that an item is tagged as the Species Pistacia palaestina. OCHRE already knows that this item belongs to the Genus Pistacia, and to the Family Anacardiaceae. Items do not need to be tagged, redundantly, at each level of the botanical taxonomy. By specifying the most specific taxonomic identification, OCHRE already has a lot of inherited information to use for further analysis.

Creating a table with Family - Genus - Species

Even though we have not entered Family and Genus specifically as properties of the Botanical remains item, OCHRE can categorize these items by Family and Genus and display the results in a table.

Begin by running a Query in the usual way to find the Botanical remains of interest and save the results in a Set.

Botanical remains, organized by Family - Genus - Species

On the Table Columns tab, use the Link Manager in the usual way to select the Properties of interest. Pick the Family, Genus, and Species Variables from the OCHRE Master Taxonomy branch:

Location or object type > Botanical remains > Family (<unassigned>) > Genus (<unassigned>) Species

Once these variables are linked in the Table Columns/Tags pane, select each in turn and apply the paperClip-! button. This tells OCHRE to "Consider other taxonomic paths to find values for this column variable." When the Table is created, OCHRE will use the value of the Botanical taxon property explicitly assigned to each item, and retrieve its corresponding Family, Genus, and Species values based on its taxonomic context, adding these values to the appropriate table column.

Creating a Table specification that includes Family, Genus and Species

DBA note: if the Botanical remains branch of the OCHRE master taxonomy is not red-copied into the local project in exactly the same context as it is in the OCHRE master project, then be sure to use the Taxonomy branch from the OCHRE master project in the Link Manager when making the Table column specification.

Querying based on Family - Genus - Species

Even though we have not entered Family and Genus specifically as properties of the Botanical remains item, OCHRE can also Query based on Family or Genus.

Is or is contained by ...

In the simplest case, use the Botanical taxon... property along with the is or is contained by query operator. In this example, OCHRE will find all items identified by the Vitaceae Family directly, or by any Genus or Species within the Vitaceae Family.

Finding all items within the Family Vitaceae

[DBA note: to configure the is or is contained by query for the front-end, use the Botanical taxa Property Values hierarchy from the OCHRE master project as the target of the is-or-is-contained-by operator. On the View, OCHRE will generate the chevron pick-list from this hierarchy and make it available to the user for a selection.]

Select from ...

A more sophisticated query uses OCHRE's advanced query options along with the select from query operator. Start by adding a query to the "Public query hierarchy" used for the front-end View, which allows for more advanced query features.

Finding all items within any selection of Families

On the Query Properties Criteria tab, use the Botanical taxon Variable to target the Family Value from the OCHRE master taxonomy.

Set the Query Type to "Pick hierarchy."

View this Query on the front-end Queries pane. The select from operator instructs OCHRE to create a hierarchical pick-list from which the user can make any number of selections. The selected items will be used to constrain the query results.

Creating a Query that allows hierarchical selection of Family, Genus and Species

Analysis based on secondary hierarchy

Since we are targeting specific Botanical taxa Values using the Botanical taxon relational property, re-organizations of those Botanical taxa Values can provide other opportunities for analysis, without requiring additional data entry. Analysis based on a secondary classification of Species into Botanical categories is shown here. This makes the Botanical category available in the following ways:

as a column in a Table specification (see the sample table column specification above)
for use with the query operator is or is contained by
for use with the advanced query based on select from (as illustrated above for Family)

Note that individual Botanical remains items do not need to have the Botanical category property added. We get this information for free, in effect, due to the re-organization of the original Species values into a secondary hierarchy based on category.

Species are secondarily organized into categories for analysis

The select from operator can be applied to any variable (Botanical category) that re-classifies existing values (Species) into an alternate organization

Project Administrator Notes

If new Species (or Families or Genera) are needed please contact the OCHRE Data Service. We will add them to our master taxonomy so that they become available to the community. We request that you do not create separate lists of common botanical species in your own projects.
Individual projects do not need the full taxonomic branch (red-)copied into their own projects, nor the alphabetical list of Botanical taxa Values. These can remain entirely within the OCHRE master project. However, many projects find it useful to have a red-copy in their project taxonomy for reference.
If you want to reorganize Species, for example, into secondary classifications, you will find the master list of values in the OCHRE Property Values category in the hierarchy Botanical taxa; you can borrow them from there for re-classification within a separate branch of your own project taxonomy.

DBA Notes

Currently, the only special processing based on the specific Botanical taxon Variable is that of auto-labeling uncertain items as "cf."
To add new Family/Genus/Species entries: insert them in the proper hierarchical context within the Family-Genus-Species branch of the OCHRE master taxonomy, then move the newly added Values from the Property Values Inbox to the Botanical taxa hierarchy, re-sorting the list. Contextualize any new Species within the Botanical category branch too.
The query based on the select from operator is generally used with a self-recursing Variable such as Botanical category. To create the hierarchy needed among the Family -> Genus -> Species properties, we use a (loose) Link on the Links pane of each Variable to point to the next one in sequence. OCHRE will drill-down this tree of Variables until it finds qualifying Values. The current hierarchical structure is articulated in the <unassigned> branch within Botanical remains starting at "Order" and is as follows:
- - Order -> Sub-family -> Family -> Tribe -> Genus -> Section -> Species -> Species
  - To add a new level to this hierarchy, create a new Variable to represent it, then adjust the pointers (Links) on the relevant items to establish the drill-down sequence.
    - Note that instances of Families do not all need to involve all possible levels. Currently, in most cases, only the Family - Genus - Species sequence is used, and the intervening levels are skipped. Within each level, however, the hierarchical structure needs to be the same length. That is, if Tribe is added for one Genus within a Family, it should be added for ALL Genera within that family, otherwise the drill-down sequence will be interrupted along that branch.
    - Note that re-ordering the sequence of taxon levels (e.g. adding an intervening level, say a Tribe between a Family and a Genus) will not impact the data that has been entered on the Botanical remains items since only the most specific level is targeted in each case.

Google Sites

Report abuse