Data sheet
The data sheet (by default named checklist) is the heart of your project. Each row represents one taxon or one occurrence, populated with columns that define its place in the taxonomy and any additional data you want to record and display. The sheet is format-free - the app reads only cell values, not colors, fonts, or formulas.
Throughout this documentation, data sheet is the generic term for this sheet - regardless of what it is actually named in your workbook. The default name checklist can be changed to anything you like: record the new name in the Customization table → Data sheet names. You may see checklist used as a concrete example in places across this guide; wherever it appears, substitute whichever name you have chosen.
That setting also accepts a comma-separated list of sheet names. If you supply several (e.g. higher_plants, bryophytes, lichens), NaturaList merges all of those sheets at compile time exactly as if they were a single sheet - the published checklist presents a unified result. This is useful for large collaborative projects where different contributors maintain separate sheets for different taxonomic groups, keeping everyone's work clearly bounded without affecting the output. All layout and column conventions described on this page apply equally to every sheet in the list.
Basic layout
Row 1 holds the column headers; every column needs a unique header name. Rows 2 onwards hold one row per taxon or occurrence.
Column naming and data paths
Column names are case-insensitive - Species, species, and SPECIES are treated as the same column. Keep names to plain letters (a–z, A–Z) and optionally digits; dots and hashes carry special meaning for structured data, as described below.
The concept of a data path generalises column names to describe structured and list data:
| Pattern | Meaning | Example headers |
|---|---|---|
name | Simple single value | redlist |
name.subfield | Named property of a value | species.name, species.authority |
name# | Array - one column per item | habitat1, habitat2, habitat3 |
name#.subfield | Named property within each array item | synonym1.name, synonym1.authority, synonym2.name, synonym2.authority |
In the meta sheets (nl_content and nl_appearance), the # character is written literally to mean every numbered item in that array. In the data sheet, each item has its sequential number: habitat1, habitat2, and so on.
Sub-fields (name.subfield) group related properties under a shared base name. A taxon name and its authority are a typical example - two distinct values that belong together:
| species | species.authority |
|---|---|
| Litoria aurea | (Lesson, 1829) |
| Pelamis platura | (Linnaeus, 1766) |
Arrays (name#) record multiple values of the same kind for one taxon - several habitat types, several photos, and so on. There are two equivalent encodings. The multi-column form gives each value its own column:
| habitat1 | habitat2 | habitat3 |
|---|---|---|
| Forest | Grassland | |
| Wetland | Forest | Desert |
The app collects all non-empty cells for each row into an ordered list. Gaps are skipped; there is no enforced maximum. The pipe-separated form encodes the same data in a single cell:
| habitat |
|---|
| Forest | Grassland |
| Wetland | Forest | Desert |
Both produce identical output in the published app. Prefer multi-column when editing data by hand or when you want to filter on individual values in your spreadsheet editor; prefer pipe-separated when generating or updating data programmatically (see Scripted data integration).
Structured arrays (name#.subfield) combine both patterns - multiple items, each with their own named properties. Synonyms are a natural example: a taxon may have several, and each carries both a name and an authority:
| synonym1.name | synonym1.authority | synonym2.name | synonym2.authority |
|---|---|---|---|
| Rana aurea | Lesson, 1829 | Cyclorana aurea | (Lesson, 1829) |
| Hyla caerulea | White, 1790 |
For how the synonym# path and its sub-fields are referenced in the meta sheets, see Referencing structured columns below.
Multilingual columns
Append :langcode to any column header to make it language-specific:
distributionNote:en | distributionNote:fr |
|---|---|
| Old world temperate forests | Forêts tempérées d'Europe occidentale |
When a user views the project in French, the :fr column is used; when viewing in English, :en is used. A plain column without a language suffix is treated as the default language (whichever language is first in the Supported Languages table on nl_appearance) and will appear in all translations.
The fallback chain is: language-specific column → default-language column. If neither exists, the field is empty for that taxon.
Not every column type supports multilingual variants. Those which do and don't are clearly indicated in the reminder of this guide.
Taxon columns
Taxon columns hold the names of taxonomic units. You have three options for encoding name and authority described in taxon.
Custom data columns
Everything that is not a taxon level is a custom data column. These are free-form columns whose meaning, formatting, and display are controlled entirely through the Custom data definition table. Nothing is predefined - you design the columns your project needs. See Custom data definition table for how to configure each column.