Naming Conventions
Column and table names in FDM follow a deliberate system rather than ordinary English phrasing. Names such as b_id_farm, p_n_rt and a_p_al are compact, prefixed codes that indicate which agronomic domain a value belongs to and, for measured parameters, how it was determined.
The same names are used throughout the stack: in the PostgreSQL database, in the Drizzle schema definition, in the generated TypeScript types, in API payloads and in data exports. A name is therefore a stable identifier rather than a display label, and applications translate it for presentation. This page explains how to read those names, which is useful when interpreting an export, writing a query, or reviewing a schema change.
Domain prefixes
Every domain column in the fdm schema begins with a prefix identifying its domain. The prefixes derive from Dutch agronomic terminology, which is why they are not always mnemonic in English.
| Prefix | Domain | Examples |
|---|---|---|
b_ | Farm, field and business-level data (Dutch bedrijf, farm business) | b_id_farm, b_name_farm, b_id, b_geometry, b_soiltype_agr, b_gwl_class |
b_lu_ | Cultivation data (Dutch landgebruik, land use); a sub-namespace of b_ used for anything describing a crop | b_lu, b_lu_catalogue, b_lu_start, b_lu_end, b_lu_yield, b_lu_variety |
p_ | Fertilizer products and their application (Dutch product) | p_id, p_id_catalogue, p_app_id, p_app_amount, p_app_method, p_n_rt |
a_ | Soil analysis parameters and soil imagery (analysis) | a_id, a_date, a_source, a_p_al, a_som_loi, a_image_type |
m_ | Measures, meaning agronomic practices a farm can adopt | m_id, m_name, m_start, m_end, m_stage_applicability |
l_ | Livestock: animals, herds and barns (under development) | l_id_animal, l_id_herd, l_species, l_birthdate |
f_ | Feed and feed analysis (under development) | f_id_batch, f_dm, f_vem, f_cp |
Only the two audit columns, created and updated, carry no prefix. They are present on every table in the fdm schema and record when a row was inserted and last modified.
The prefix system applies to the fdm schema, which holds the farm data model. The supporting schemas — fdm-authn, fdm-authz and fdm-calculator — store authentication, authorization and cached calculation results, and use plain descriptive names such as principal_id and calculation_hash.
How a name is composed
Identifiers
An asset's own identifier is <prefix>_id where that is unambiguous: b_id for a field, p_id for a fertilizer, a_id for a soil analysis, m_id for a measure. Where the prefix alone would be ambiguous, the entity is appended: b_id_farm, b_id_harvesting, b_id_sampling. Cultivations are the exception and use b_lu as their identifier.
References to a catalogue entry end in _catalogue: p_id_catalogue points at a fertilizer in the fertilizer catalogue, b_lu_catalogue at a crop in the cultivation catalogue. See Catalogues.
Identifiers are 16-character random strings generated by the application, not sequential numbers. They are opaque and carry no meaning.
Names and languages
Human-readable names follow <prefix>_name, optionally with the entity (b_name_farm) and, in catalogues that are published in more than one language, with a language suffix: p_name_nl and p_name_en.
Fertilizer nutrient contents
Nutrient columns on fertilizers follow the pattern p_<element>_<form>, where the element is the chemical symbol and the suffix states which form or fraction is meant.
| Suffix | Meaning | Example |
|---|---|---|
_rt | Total content | p_n_rt total nitrogen, p_p_rt total phosphorus |
_if | Inorganic fraction | p_n_if inorganic (mineral) nitrogen |
_of | Organic fraction | p_n_of organically bound nitrogen |
_fr | Fraction | p_c_fr carbon fraction |
_wc | Working coefficient | p_n_wc nitrogen working coefficient |
The distinction matters agronomically: p_n_rt is what a laboratory reports as total N, while p_n_if is the directly plant-available share and p_n_wc expresses the effective availability used in fertilization planning.
Soil analysis parameters
A soil value is only interpretable together with the extraction or determination method used, so soil columns follow a_<parameter>_<method>. Two phosphorus results from the same sample are not comparable if one is a P-Al determination and the other a P-CaCl2 determination, and FDM therefore stores them in separate columns rather than a single "phosphorus" field.
| Column | Parameter and method |
|---|---|
a_p_al | Phosphorus, ammonium lactate extraction (P-Al) |
a_p_cc | Phosphorus, calcium chloride extraction (P-CaCl2) |
a_p_wa | Phosphorus, water extraction (P-water) |
a_ph_cc | pH, calcium chloride |
a_som_loi | Soil organic matter, loss on ignition |
a_n_rt | Total nitrogen |
a_k_cc, a_mg_cc | Potassium and magnesium, calcium chloride extraction |
a_clay_mi, a_sand_mi, a_silt_mi | Texture fractions, mineral analysis |
Common method suffixes are _al (ammonium lactate), _cc (calcium chloride), _wa (water), _ox (oxalate), _co (cobalt hexamine), _loi (loss on ignition), _rt (total) and _mi (mineral fraction). See Soil Analyses for the full parameter list.
Table names
Table names reflect the Asset–Action model.
- Assets — entities that exist in their own right — are plural nouns:
farms,fields,fertilizers,cultivations,harvestables,measures. - Actions — dated events involving those assets — are named
<asset>_<verb>ing:field_acquiring,fertilizer_applying,cultivation_starting,cultivation_harvesting,soil_sampling,measure_adopting. - Catalogues — reference data shared across farms — are named
<asset>_catalogue:fertilizers_catalogue,cultivations_catalogue,measures_catalogue.
The gerund form of action tables is intentional: the row records that an event took place, not a property of the asset. A field's relationship to a farm, for example, is held in field_acquiring together with the date of acquisition and the tenure type, because that relationship has a beginning and can end.
Conventions that apply to every table
Audit timestamps. Each table carries created and updated, both timestamps with time zone.
Lifecycle instead of deletion. Assets are ended rather than removed, so that the recorded history remains valid. Ending is itself an action with its own table: field_discarding holds b_end, cultivation_ending holds b_lu_end, fertilizer_picking records when a fertilizer stock was taken out of use. Validity periods use the prefix of their domain: b_start/b_end, b_lu_start/b_lu_end, m_start/m_end. The end dates of fields (b_end) and measures (m_end) are the last day of the period, inclusive, in Europe/Amsterdam. fdm-core stores them as entered and returns an end date on 1 January as the end of 31 December of the previous year (see Fields).
Coded values. Columns with a fixed set of options store stable machine codes, with the human-readable label supplied separately by the application. Where a national code list exists it is used unchanged, such as nl_01 and nl_02 for land tenure types and HC010 and HC020 for harvest categories. Codes are therefore stable across releases and translations.
Units. Numeric values are stored in a fixed unit per column, documented in the schema and in Database Schema; for example fertilizer application amounts are recorded in kg per hectare. Values are stored in PostgreSQL as numeric rather than as floating-point columns.
Measured values only. FDM stores what was observed or applied, not values derived from it. A seasonal nitrogen total is not a column; it is computed from the individual fertilizer_applying records by fdm-calculator. This keeps the underlying records auditable and allows calculation methods to change without rewriting historical data.
Related pages
- The Asset–Action Model — the reasoning behind the split between assets and actions
- Database Schema — the complete table and column reference
- Extending the Schema — how to apply these conventions when contributing a change