The schema infiltration contains tables for the in-field single ring (Beerkan method, Lassabatère et al., 2006) water infiltration rate test, commonly abbreviated as BEST – Beerkan Estimation of Soil Transfer parameters.

BEST is a physical, yet simple method; the infiltration test is performed using water vessels filled to a default volume, sequentially poured into a single ring with water depth restricted to a maximum of 1 cm. The infiltration rate is measured by the time it takes for each water volume in the sequence to be swallowed - until a stable time interval is reached. The method also requires information of soil particle size distribution, initial and final soil water content and dry soil bulk density.

From the BEST test the water retention curve, including field capacity and wilting point can be determined, and the hydraulic conductivity estimated. The retention curve (the relation between water content and water potential) differs between wetting and a drying cycles (an effect called hysteresis). The BEST method only gives the wetting cycle water retention curve.

The schema infiltration contains tables for filling in test data directly in the field, with the alternative to automatically calculate the soil hydraulic properties from the captured data. It is also possible to note the infiltration rates in another media and then use a third party solution to calculate the soil hydraulic properties and fill in only the results.

The schema infiltration is built along the same principles as the other schemas for derived soil properties. The sampleid and userid are derived from other schemas and registered together with other metadata for each infiltration in the table infiltrationmeta. Each infiltration test is given a unique (SERIAL) id, that is then used for linking to the (optional) test data (table: infiltrationrate) and the results (tables: soilwaterretention and hydraulicconductivity).

The texture data is assumed to be the same before and after the infiltration test and resides in the schema wetlab. The sample point soil moisture content (default given as vol/vol) resides in the schema samples. For the infiltration rate test to be complete, also the soil moisture content after the test is just finished need to be added (table: soilmoisture in this schema). The user can choose to also add the initial soil water content in this schema (table: soilmoisture). If not inserted, the initial soil water content is taken from the schema samples. The default method for defining soil moisture is to use a volume precise soil cylinder and weigh it both when wet and after drying. A simpler and quicker, but presumably less accurate, method is to use a soil penetrometer. The method used should be registered in the soilmoisture table. A predefined catalog lists all possible methods and only listed methods are accepted.

DBML

// Use DBML to define your database structure
// Docs: https://dbml.dbdiagram.io/docs
// Tool: https://dbdiagram.io/d

Project project_name {
  database_type: 'PostgreSQL'
  Note: 'AI4SH schema for infiltration test'
}

Table users.user {
  userid SERIAL
}

Table samples.sample_event {
  sampleid SERIAL
}

TABLE infiltrationmeta {
  sampleid INTEGER [pk]
  userid INTEGER
  topsoil Boolean [pk, DEFAULT: TRUE]
  repetition SMALLINT [pk, DEFAULT:1]
  ringdiameter REAL
  waterunit REAL
  infiltrationid SERIAL
}
// ringdiameter in cm
// waterunit of pouring vessel in ml
// topsoil (true) represents 0-20 cm, subsoil (false) represents 20-50 cm.

Table soilmoisture {
  infiltrationid INTEGER [pk]
  postwetting BOOLEAN [pk, NOT NULL]
  soilmoisture REAL [NOT NULL]
  smunit TEXT [DEFAULT: "vol vol-1"]
  method TEXT [DEFAULT: "cylinder"]
}
// postwetting:
// TRUE for post wetting conditions
// FALSE for initial soil moisture conditions

TABLE smmethod {
  method TEXT [pk]
  description TEXT
  reference TEXT
  url TEXT
}
// e.g: cylinder100, cylinder250, penetrometer

TABLE infiltrationrate {
  infiltrationid INTEGER [pk]
  infiltrationsequence SMALLINT [NOT NULL]
  infiltrationtime REAL [NOT NULL]
}
// infiltrationtime in seconds

Table hydraulicconductivity {
  infiltrationid INTEGER [pk]
  saturatedconductivity REAL
}

Table soilwaterretention {
  infiltrationid INTEGER [pk]
  hysteresiswetting BOOLEAN [DEFAULT: TRUE]
  fieldcapacity REAL
  wilitingpoint REAL
}
// The BEST methdod gives the wetting cycle soil water retention
// If another method is used for drying cycle soil water retention
// hysteresiswetting should be set to FALSE

Table soilwaterretentioncurve {
 infiltrationid INTEGER [pk]
  hysteresiswetting BOOLEAN [DEFAULT: TRUE]
  watercontent REAL
  waterpotential REAL
}
// The BEST methdod gives the wetting cycle soil water retention
// If another method is used for drying cycle soil water retention
// hysteresiswetting should be set to FALSE

Ref: "samples"."sample_event"."sampleid" - "public"."infiltrationmeta"."sampleid"

Ref: "users"."user"."userid" - "public"."infiltrationmeta"."userid"

Ref: "public"."infiltrationmeta"."infiltrationid" - "public"."soilwaterretention"."infiltrationid"

Ref: "public"."soilwaterretention"."infiltrationid" - "public"."hydraulicconductivity"."infiltrationid"

Ref: "public"."infiltrationmeta"."infiltrationid" - "public"."soilmoisture"."infiltrationid"

Ref: "public"."soilmoisture"."infiltrationid" - "public"."infiltrationrate"."infiltrationid"

Ref: "public"."infiltrationrate"."infiltrationid" - "public"."soilwaterretentioncurve"."infiltrationid"

Ref: "public"."soilmoisture"."method" - "public"."smmethod"."method"

Figure

The schema ise contains tables for in-field/in-kitchen/in-lab Ion Selective Electrode (ISE) analysis. For AI4SH, only pH will be analysed using ISE, but can be done both in-field and in-kitchen. As the ISE instruments used with AI4SH is an extension of one of the spectrometers to be tested, the ISE can be done using any of the three sample preparations also used for spectral analysis (schema.table: spectra.samplescan):

• NO (no prep = in field analysis),
• MX (mixed = in kitchen analysis of wet mixed subsamples), or
• DS (dried & sieved = in kitchen/laboratory analysis).

The schema ise is built along the same principles as the other schemas for laboratory derived soil properties, wetlab and edna. The sampleid and userid are derived from other schemas and registered together with other metadata for each ISE analysis in the table isemeta. Each ISE analysis is given a unique (SERIAL) id, that is then used for linking to the results (table: ise).

The actual ISE results are thus stored in the table ise.

DBML

// Use DBML to define your database structure
// Docs: https://dbml.dbdiagram.io/docs
// Tool: https://dbdiagram.io/d

Project project_name {
  database_type: 'PostgreSQL'
  Note: 'AI4SH schema for infiltration test'
}

Table users.user {
  userid SERIAL
}

Table samples.sample_event {
  sampleid SERIAL
}

TABLE isemeta {
  iseeid INTEGER [pk]
  sampleid INTEGER [pk]
  prepcode CHAR[2] [pk]
  userid INTEGER
  topsoil Boolean [pk, DEFAULT: TRUE]
  repetition SMALLINT [pk, DEFAULT:1]
  analysistimestamp timestamp
  isecalib integer
  iseanalysisid SERIAL
}

Table iseprobe {
  brand TEXT [pk]
  model TEXT [pk]
  quantity REAL [pk]
  unit TEXT
  iseid SERIAL
}

Table isecalibration {
  iseid INTEGER [pk]
  dt TIMESTAMP [pk]
  refvalue REAL
  obsvalue REAL
  isecalib SERIAL
}

Table iseanalysisresults {
  iseanalysisid INTEGER [pk]
  quantity TEXT
  value REAL
}

Figure

The schema enzymes contains tables for recorded enzymatic activity using the Soil Enzyme Activity Reader (SEAR) developed by Digit-Soil AG. Each read records the activity of 5 different enzymes, with 5 replicas of each enzyme.

The schema enzymes is built along the same principles as the other schemas for laboratory derived soil properties, wetlab and edna. The sampleid and userid are derived from other schemas and registered together with other metadata for each SEAR analysis in the table eeameta. Each SEAR analysis is given a uique (SERIAL) id, that is then used for linking to the results (table: eea [extracellular enzymatic activity]).

The actual SEAR results are thus stored in the table eea, with each individual enzyme in a separate record. The enzyme is registered using a 3 letter code, expanded in the support table enzymecode.

DBML

/// Use DBML to define your database structure
// Docs: https://dbml.dbdiagram.io/docs
// Tool: https://dbdiagram.io/d

Project project_name {
  database_type: 'PostgreSQL'
  Note: 'AI4SH schema for enzyme data'
}

Table users.user {
  userid SERIAL
}

Table samples.sample_event {
  sampleid SERIAL
}

Table eeameta {
  eeaanalysisid SERIAL [pk]
  userid INTEGER
  sampleid INTEGER
  analysisdate date
  sampletemperature REAL  
}

Table enzymecode {
  enzymecode char(3) [pk]
  enzymefull TEXT
  info TEXT
}
// enzymecodes
//  GLA: Chitinase/ β-glucosaminidase,
//  GLU: β-Glucosidase,
//  PHO: phosphatases (Phosphomonesterases),
//  XYL: β-Xylosidase,
//  LEU: Leucine- aminopeptidase.

Table eea {
  eeaanalysisid INTEGER [pk]
  enzymecode char(3) [pk]
  measurement_pmol_min REAL
  measurement_std_err REAL
  is_valid BOOLEAN
  not_valid_reason TEXT
}

Ref: "samples"."sample_event"."sampleid" - "public"."eeameta"."sampleid"

Ref: "public"."eeameta"."eeaanalysisid" - "public"."eea"."eeaanalysisid"

Ref: "public"."enzymecode"."enzymecode" - "public"."eea"."enzymecode"

Ref: "users"."user"."userid" - "public"."eeameta"."userid"

Figure

Penetrometers are field probes that are pushed into the soil. Modern penetrometers record different soil properties using microelectronic controllers and can indirectly observe physical, chemical and biological properties. There are even penetrometers with built-in spectral sensors that can record the soil profile spectra as the penetrometer is pushed into the soil. In AI4SH only a simple type of steel pinned penetrometers are used (figure 1).

The soil properties that can be observed with the AI4SH adopted soil penetrometers include:

• soil moisture,
• temperature,
• electric conductivity,
• salinity,
• epsilon,
• nitrogen (N),
• phosphorus (P),
• potassium (K), and
• pH.

A main reason for applying soil penetrometers as part of AI4SH is that soil moisture is a required parameters for interpreting and modelling soil spectra acquired from wet (non-dried) samples. As salinisation is a severe soil health problem, also the direct field observations of electric conductivity, salinity and epsilon are of interest. The probing of NPK and pH are more indicative, but as these chemical soil properties can be captured simultaneously with those of primary interest, they are also included in the database schema penetrometer.

As with spectrometers, each individual penetrometer has a slightly different response and thus needs an individual calibration. The table penetrometer is for registering each individual instrument, the table penetrometertypes for registering the physical quantities and units observed by each type of (brand+model) of penetrometer, and the table penetrometercalib for storing the (optional) calibration settings.

The meta data for each penetrometer observation is stored in the table probemeta. The table is prepared for accepting multiple observations for each single sample (field: proberepeat). Observations can be done either in the field or using mixed (wet) samples, recorded in the field subsample with a single letter (M, C, N, E, S, W for Mixed, Central, North, East, South and West). The alternative options for penetrometer observations leads to a metadata table with a large number of primary keys (pk):

• penetrometerid (the probe)
• sampleid (the sample event)
• topsoil (topsoil or subsoil)
• subsample (Mixed, Central, North, East, South or West)
• scanrepeat (sequence from 1 to maximum 9)

The actual observation data is saved in the table penetrometerobs. The link between probemeta and penetrometerobs is a unique (SERIAL) id set for each individual observation (obsid). The link to the penetrometer is also via a SERIAL id (penetrometerid). As for other schemas, the user responsible is linked to each observation via the userid.

DBML

// Use DBML to define your database structure
// Docs: https://dbml.dbdiagram.io/docs
// Tool: https://dbdiagram.io/d

Project project_name {
  database_type: 'PostgreSQL'
  Note: 'AI4SH schema for penetrometer data'
}

Table users.user {
  userid SERIAL
}

Table samples.sample_event {
  sampleid SERIAL
}

Table penetrometer {
  brand TEXT [pk]
  model TEXT [pk]
  serialnumber TEXT [pk]
  penetrometerid SERIAL
}

Table penetrometertypes {
  brand TEXT [pk]
  model TEXT [pk]
  quantity TEXT [pk]
  unit TEXT
}

Table penetrometercalib {
  penetrometerid INTEGER [pk]
  quantity TEXT [pk]
  gain REAL [DEFAULT: 1]
  offset REAL [DEFAULT: 0]
}

TABLE probemeta {
  penetrometerid INTEGER [pk]
  sampleid INTEGER [pk]
  topsoil Boolean [pk]
  subsample char(1) [pk]
  proberepeat char(1) [pk]
  userid INTEGER
  obsid SERIAL
}
// topsoil (true) represents 0-20 cm, subsoil (false) represents 20-50 cm.
// subsample can be M (mixed), C (central), N (north), E (east), S (south) of W (west).
// proberepeat is a simple numbering starting a 1 to a maximum 0f 9 repeats for the same sample

TABLE penetrometerobs {
  obsid INTEGER [pk]
  quantity TEXT [pk]
  obsmean REAL
  obsstd REAL  
}

REF: samples.sample_event.sampleid - probemeta.sampleid

REF: users.user.userid - probemeta.userid


REF: "public"."penetrometer"."penetrometerid" - "public"."probemeta"."penetrometerid"

REF: "public"."penetrometertypes"."brand" - "public"."penetrometer"."brand"

REF: "public"."penetrometertypes"."model" - "public"."penetrometer"."model"

REF: "public"."penetrometer"."penetrometerid" - "public"."penetrometercalib"."penetrometerid"

Ref: "public"."probemeta"."obsid" - "public"."penetrometerobs"."obsid"

Ref: "public"."penetrometertypes"."quantity" - "public"."penetrometerobs"."quantity"

Ref: "public"."penetrometertypes"."quantity" - "public"."penetrometercalib"."quantity"

Figure

The schema wetlab contains tables for different laboratory analysis methods and results. The default soil properties included in the table are the physico-chemical quantities that are collected as part of the European Statistical Office (EUROSTAT) Land Use and Coverage Area frame Survey (LUCAS). The LUCAS sampling is structured in 5 different modules of which 3 are reflected in the AI4SH schema wetlab. The remaining 2 LUCAS modules are covered by the AI4SH schemas macrofauna and edna, and samples, as outlined below.

LUCAS module 1 Physico-chemical quantitative properties and analysis methods include:

The translation between the LUCAS (ISO) methods and the USDA methods as coded in the Open Soil Spectral Library (OSSL) are given below - NOTE ALL NEEDS CONFIRMATION.

Additional methods can be added by following the same principles of identifying the quantity, ISO-method and reporting units - and combining these into the unique quantcode. The table below illustrates how to define soil nitrogen species analysed from dried samples (ISO 14255:1998).

All properties that are to be laboratory analysed must be listed in the table labanalysismethod. The default methods to apply are the 13 physico-chemical methods listed in LUCAS module 1 (above).

The table methodtransfer is a support table for linking the ISO coded methods as defined by LUCAS to any other coding system. By default the USDA coding system as expressed in the Open Soil Spectral Library (OSSL) should be added. But also other, country specific, standards can be entered.

The sample to analyse is always the mixed sample from each sample event, where either only the topsoil (0-20 cm) or both the topsoil and subsoil (20-50 cm) are analysed. If both are analysed, two metadata records (table labanalysismeta) must be created for the same sampleevent. The metadata should also include the name and contact of the (certified/centralised) laboratory that analysed the sampleevent. The schema thus also contains a table for registering the laboratories used by AI4SH (laboratory).

The actual laboratory results, for quantities and units as defined in the table labanalysismethod, are registered in the table labanalysisresults. As the analysis actually done varies for each pilot/site/sample point, the table is built up for registering single analysis results against the analysismeta (linked using the common field labanalysisid).

DBML

// Use DBML to define your database structure
// Docs: https://dbml.dbdiagram.io/docs
// Tool: https://dbdiagram.io/d

Project project_name {
  database_type: 'PostgreSQL'
  Note: 'AI4SH schema for wet laboratory data'
}

Table users.user {
  userid SERIAL
}

Table samples.sample_event {
  sampleid SERIAL
}

Table labanalysismethod {
  quantity TEXT [pk]
  isocode TEXT [pk]
  unit TEXT  
  lucasmodule CHAR(1)
  quantcode TEXT
  default Boolean
}
// default is True for the LUCAS module 1 13 physico-chemical properties, and false for all other quantities.
// The quantcode is a combination of "quantity"."isocode"."unit"

TABLE labanalysismeta {
  laboratorieid INTEGER [pk]
  sampleid INTEGER [pk]
  topsoil Boolean [pk]
  analysisdate date
  userid INTEGER
  labanalysisid SERIAL
}
// topsoil (true) represents 0-20 cm, subsoil (false) represents 20-50 cm.

TABLE labanalysisresults {
  labanalysisid INTEGER
  quantcode TEXT
  value REAL
}

Table laboratory {
  labname TEXT [pk]
  labadress TEXT [pk]
  labcountry char(2)
  laburl TEXT
  labcontact TEXT
  laboratorieid SERIAL
}

Table methodtransfer {
  quantcode TEXT [pk]
  coountry TEXT [pk]
  countyrcode TEXT
  info TEXT
  gain REAL [DEFAULT: 1]
  offset REAL [DEFAULT: 0]
}

Ref: "public"."laboratory"."laboratorieid" - "public"."labanalysismeta"."laboratorieid"

Ref: "samples"."sample_event"."sampleid" - "public"."labanalysismeta"."sampleid"

Ref: "users"."user"."userid" - "public"."labanalysismeta"."userid"

Ref: "public"."labanalysismeta"."labanalysisid" - "public"."labanalysisresults"."labanalysisid"

Ref: "public"."labanalysismethod"."quantcode" - "public"."methodtransfer"."quantcode"

Ref: "public"."labanalysismethod"."quantcode" - "public"."labanalysisresults"."quantcode"

Figure

The schema spectra contains tables for:

• individual instruments (spectrometer),
• metadata for each spectral scan (scanmeta), and
• spectral reflectance mean and standard deviation for each scan (reflectancescan).

Spectrometers are individually calibrated precision instruments. The spectral sensor units of spectrometers of the same brand and model do not record exactly the same wavelengths. Thus each individual sensor applied must be registered together with the wavelengths (expressed in nano-metres) that it records. This information is residing in the table spectrometer.

A unique feature of the spectral sampling is that it can be done in the field, at home (kitchen lab) and in laboratories. The AI4SH sampling framework is built to accommodate all three types of spectral scans. In the table scanmeta the field prepcode can take one of the following three values:

• NO (no prep = in field scanning),
• MX (mixed = in kitchen scanning of wet mixed subsamples), or
• DS (dried & sieved = in laboratory scanning).

Further, spectral scanning is a rapid procedure and it is common to do repeated scans for a single sample, and each scan of the same sample is given a sequential number in the field scanrepeat. The in-field scanning (prepcode = NO) can also be done at either a single pit (i.e. the central position) or including the perimeter pits in North, West, South and East. In the table scanmeta this is encoded in the field subsample using a single letter (M, C, N, E, S, W for Mixed, Central, North, East, South and West) The many options for spectral scanning leads to a metadata table with a large number of primary keys (pk):

• spectrometerid (the sensor)
• sampleid (the sample event)
• topsoil (topsoil or subsoil)
• subsample (Mixed, Central, North, East, South or West)
• scanrepeat (sequence from 1 to maximum 9)
• prepcode (NO [none], MX [mixed] or DS [dried & sieved])

Soil spectral analysis uses a technique called diffuse reflectance spectroscopy, where the reflecactance of the soil is compared to a standardised white reference. The value of the reflectance for each wavelength of the recorded spectra should thus be between 0 and 1 (at least reflecting some light and not ore than than a white reference surface). Sometime the absorbance (1/reflectacne) is registered instead of reflectance.

In the AI4SH database the reflectance (not absorbance) must be registered. If the spectral sensor applied records by default requires a white reference and directly produces reflectance that is the data to register. If the spectrometer, however, captures the white reference and the soil characteristcs separately (i.e. as digital numbers), the reflectance must be calculated before entered.

The actual spectral data, i.e. the soil diffuse reflectance expressed as a fraction between 0 and 1 for each wavelength, is saved in the table reflectancescan. The link between scanmeta and reflectancescan is a unique (SERIAL) id set for each individual scan (scanid). The link to the spectrometer is also via a unique SERIAL id (spectrometerid). As for other schemas, the user responsible for the scanning is linked to each scan via the userid.

The schema spectra is written for registering unique wavelengths with each instrument and the reflectance as compared to a white reference. Each reading in each scan should consequently have a value between 0 and 1. For each scan the number of erroneous values are compiled and registered in the table scanmeta:

• non recoded values (nafreq),
• negative values (negfreq),
• values extending 1 (extfreq).

DBML

// Use DBML to define your database structure
// Docs: https://dbml.dbdiagram.io/docs
// Tool: https://dbdiagram.io/d

Table users.user {
  userid SERIAL
}

Table samples.sample_event {
  sampleid SERIAL
}

Table spectrometer {
  brand TEXT [pk]
  model TEXT [pk]
  serialnumber TEXT [pk]
  wavelenghts REAL[]
  spectrometerid SERIAL
}

TABLE scanmeta {
  spectrometerid INTEGER [pk]
  sampleid INTEGER [pk]
  topsoil Boolean [pk]
  subsample char(1) [pk]
  scanrepeat char(1) [pk]
  prepcode CHAR(2) [pk]
  userid INTEGER
  scanid SERIAL
  nafreq REAL
  negfreq REAL
  extfreq REAL
}
// topsoil (true) represents 0-20 cm, subsoil (false) represents 20-50 cm.
// subsample is only for prepcode NO and can be C (central), N (north), E (east), S (south) of W (west). Default is M (mixed)
// scanrepeat is a simple numbering starting a 1 to a maximum of 9 repeats for the same sample

TABLE reflectancescan {
  scanid INTEGER
  signalmean REAL[]
  signalstd REAL[]  
}

TABLE sampleprep {
  prepcode CHAR(2) [pk]
  sampleprep text
  info TEXT
  url TEXT
}
// sampleprep alternatives: "NO", "MX", "DS"

REF: samples.sample_event.sampleid - scanmeta.sampleid

REF: users.user.userid - scanmeta.userid

REF: scanmeta.scanid - reflectancescan.scanid

Ref: "public"."spectrometer"."spectrometerid" < "public"."scanmeta"."spectrometerid"

Ref: "public"."sampleprep"."prepcode" < "public"."scanmeta"."prepcode"

Figure

eDNA will be centrally analysed within AI4SH and the analysis data entered after the laboratory analysis is completed. The AI4SH database will only hold deduced taxa and predicted functions, the complete sequence data will be stored with the European Nucleotide Archive or an equivalent facility. The method applied for eDNA analysis is called metabarcoding and is built up as a pipeline of several steps - all of which need to be recorded in the AI4SH database. As the costs are comparably high, eDNA analysis will be limited to a few pilots and not all points at these selected pilots.

eDNA

eDNA is a method for estimating biodiversity and the occurrence of both different taxa and dominating biological functions (e.g. aerobic/anaerobic, processes in the nitrogen cycle). The eDNA analysed as part of AI4SH will be divided in the following taxonomic domains:

• Bacteria,
• Archaea, and
• Eukarya.

Eukarya will be analysed at higher taxonomic resolution, including for instance the sub-groups:

• Fungus (yeasts, moulds and mushrooms subgroup),
• Protists (polyphyletic subgroup),
• Tardigrade (micro animal subgroup),
• Naematode (roundworm subgroup),
• Arthropod (exoskeleton clad animal subgroup),
• Annelid (segmented worm subgroup)
• Rotifer (wheel animal subgroup)

As a baseline the listed taxonomic groups will be recorded using two indexes:

• richness (total number of species), and
• Shannon’s diversity index.

In addition bacteria and fungi (and potentially other taxonomic groups) will be divided into predictive functional categories.

Bacterial predicted functions:

• chemoheterotrophs,
• N-fixers, and
• human pathogenes.

Fungal predicited functions:

• Ectomycorrhizal,
• Arbuscular mycorrhizal,
• saprotrophs, and
• plant pathogens.

Most of the listed eDNA attributes above require customised pipelines for the metabarcoding. This causes the meatabarcoding pipeline to be linked to the results instead of the sample (i.e. several pipelines will be applied to each sample).

In addition the overall community dissimilarity will be recorded as a metadata (as it does not reveal any taxa or function).

Outline 2

The tables of the schema edna follows the principles of the schema wetlab.

The sample to analyse is always the mixed sample from each sample event, where either only the topsoil (0-20 cm) or both the topsoil and subsoil (20-50 cm) are analysed. If both are analysed, two metadata records (table ednaanalysismeta) must be created for the same sampleevent. The metadata should also include the name and contact of the (certified/centralised) eDNA laboratory that analysed the sample, and the archive and accession code/id for the original sequence data.

The schema thus also contains tables for registering the laboratories used by AI4SH (laboratory) and the nucleotide sequence archives (nucleotidesequencearchive) where the full sequence data are stored.

Because the eDNA analysis includes both taxa and function, there are two separate support tables that list the possible forms (table: taxa) and functions (table: function) to register. The support tables must be filled beforehand by the specialists responsible. Only entries recorded in the support tables will then be allowed in the two tables holding the final analysis results, taxaheterogenity and functionabundance. Each entry into the support tables (taxa and function) must also record the status of each entry - revealing if it is Compulsory (C), Recommended (R), Optional(O), Experimental(E) or Pending(P).

As stated above, the methods composing the metabarcoding pipeline differs dependent on taxa and functions. Each unique combination of methods building up a pipeline must be registered in the table metabarcodingpipeline.

The generic steps forming the metabarcoding pipeline include:

• extraction,
• amplification,
• purification,
• sequencing, and
• bioinformatic treatment.

For each of the five steps only a code is entered in the table metabarcodingpipeline, with all methodological details cataloged in five support tables (see DBML code below).

The last step, bioinformatic treatment, requires a database against which the identified sequences are compared and the taxa/functions identified. The method steps above and the database employed all influence the identified taxa, and should be registered with each analysis result. Each combination of the five (5) process step plus the nucleotide library used must be registered. When registering, the combination is given a unique SERIAL id that must then follow each result (taxa and function) where this precise pipeline is applied. If one process (or the nucleotide library) is changed, a new SERIAL id must be registered and linked to the result using this alternative (updated) chain of process methods. It is thus possible to analyse the same sample using two different pipelines (e.g. by just running the same sequence against an updated version of the nucleotide library) and then register two different results. Thus it is also possible to compare the results of employing 2 different pipelines, e.g. for evaluating different methods.

As the transport and storage of soil samples influence the results, there is a special table for registering the sample logistics at the laboratory side of the logistics chain, samplelogistics. The handling associated with the field sampling side is recorded in the schema samples.

Idea and objective

Both the taxa (along with richness and Shannon’s diversity) and the functions are to some extent arbitrarily selected and defined. To allow other taxa and functions to be added, the schema edna is built up around support tables for taxa and functions. As stated above, the main table for recording biodiversity, taxaheterogenity, and functions, functionabundance, can only be inserted with taxa and functions defined in the support tables. This ensures that all added records are consistent while also allowing for novel taxa and functions to be added.

DBML

// Use DBML to define your database structure
// Docs: https://dbml.dbdiagram.io/docs
// Tool: https://dbdiagram.io/d

Project project_name {
  database_type: 'PostgreSQL'
  Note: 'AI4SH schema for eDNA'
}

Table users.user {
  userid SERIAL
}

Table samples.sample_event {
  sampleid SERIAL
}

Table samplelogistics {
  sampleid INTEGER
  preservation TEXT
  transport TEXT
  transportduration SMALLINT
  storage TEXT
  storageduration SMALLINT
}

Table metabarcodingpipeline {
  extractioncode CHAR[2] [pk]
  amplificationcode CHAR[2] [pk]
  purificationcode CHAR[2] [pk]
  sequencingcode CHAR[2] [pk]
  sequencereferencelibrarycode CHAR[2] [pk]
  bioinformatictreamentmentcode CHAR[2] [pk]
  ednapipelineid SERIAL
}

Table extraction {
  extractioncode CHAR[2] [pk]
  method TEXT
  url TEXT
}

Table amplification {
  amplificationcode CHAR[2] [pk]
  method TEXT
  url TEXT
}

Table purification {
  purificationcode CHAR[2] [pk]
  method TEXT
  url TEXT
}

Table sequencing {
  sequencingcode CHAR[2] [pk]
  method TEXT
  url TEXT
}

Table sequencereferencelibrary {
  sequencereferencelibrarycode CHAR[2] [pk]
  version TEXT
  url TEXT
}

Table bioinformatictreamentment {
  bioinformatictreamentmentcode CHAR[2] [pk]
  version TEXT
  url TEXT
}

TABLE nucleotidesequencearchive {
  databasename TEXT [pk]
  proprietor TEXT [pk]
  databaseurl TEXT [pk]
  info TEXT
  nucleotidesequencearchive SERIAL
}
// AI4SH will primarily use

TABLE ednaanalysismeta {
  laboratorieid INTEGER [pk]
  sampleid INTEGER [pk]
  topsoil Boolean [pk]
  analysisdate date
  userid INTEGER
  nucleotidesequencearchive INTEGER
  accessionid TEXT
  accessionurl TEXT
  labanalysisid SERIAL
  dissimilarity REAL
}
// topsoil (true) represents 0-20 cm, subsoil (false) represents 20-50 cm.

Table taxa {
  taxa TEXT [pk]
  domain TEXT
  subgroup TEXT
  statuscode CHAR(1)
  info TEXT
}
// support table listing taxa to add

Table status {
  statuscode CHAR(1)
  status TEXT
}
//  Support table for support tables taxa and function
// C:Compulsory; R:Recommended; O:Optional; E:Experimental; P:Pending;

TABLE taxaheterogenity {
  labanalysisid INTEGER [pk]
  ednapipelineid INTEGER [pk]
  bioinformatictreatmentdate date [pk]
  taxa TEXT [pk]
  richness REAL
  shannon REAL
}

Table function {
  function TEXT
  taxa TEXT
  functiontaxa TEXT [pk]
  statuscode CHAR(1)
  info TEXT
}
// support table with drop down alternatives for function to add

TABLE functionabundance {
  labanalysisid INTEGER [pk]
  ednapipelineid INTEGER [pk]
  bioinformatictreatmentdate date [pk]
  functiontaxa TEXT [pk]
  abundance REAL
}

Table laboratory {
  labname TEXT [pk]
  labadress TEXT [pk]
  labcountry char(2)
  laburl TEXT
  labcontact TEXT
  laboratorieid SERIAL
}

Ref: "public"."laboratory"."laboratorieid" - "public"."ednaanalysismeta"."laboratorieid"

Ref: "samples"."sample_event"."sampleid" - "public"."ednaanalysismeta"."sampleid"

Ref: "users"."user"."userid" - "public"."ednaanalysismeta"."userid"

Ref: "public"."taxa"."taxa" - "public"."taxaheterogenity"."taxa"

Ref: "public"."function"."functiontaxa" - "public"."functionabundance"."functiontaxa"

Ref: "public"."ednaanalysismeta"."labanalysisid" - "public"."taxaheterogenity"."labanalysisid"

Ref: "public"."ednaanalysismeta"."labanalysisid" - "public"."functionabundance"."labanalysisid"

Ref: "public"."nucleotidesequencearchive"."nucleotidesequencearchive" - "public"."ednaanalysismeta"."nucleotidesequencearchive"

Ref: "public"."function"."statuscode" - "public"."taxa"."statuscode"

Ref: "public"."taxa"."statuscode" - "public"."status"."statuscode"

Ref: "public"."samplelogistics"."sampleid" - "samples"."sample_event"."sampleid"

Ref: "public"."metabarcodingpipeline"."ednapipelineid" - "public"."taxaheterogenity"."ednapipelineid"

Ref: "public"."metabarcodingpipeline"."ednapipelineid" - "public"."functionabundance"."ednapipelineid"

Ref: "public"."extraction"."extractioncode" - "public"."metabarcodingpipeline"."extractioncode"

Ref: "public"."purification"."purificationcode" - "public"."metabarcodingpipeline"."purificationcode"

Ref: "public"."amplification"."amplificationcode" - "public"."metabarcodingpipeline"."amplificationcode"

Ref: "public"."sequencing"."sequencingcode" - "public"."metabarcodingpipeline"."sequencingcode"

Ref: "public"."sequencereferencelibrary"."sequencereferencelibrarycode" - "public"."metabarcodingpipeline"."sequencereferencelibrarycode"

Ref: "public"."bioinformatictreamentment"."bioinformatictreamentmentcode" - "public"."metabarcodingpipeline"."bioinformatictreamentmentcode"

Figure

The schema moulder only contains a single table, for recording the results of the Moulder: Soil aggregates open source app. Results from the older versions of the app, called slakes can also be registered in the schema.

The soil sampling, including extraction method, depth, classification, photos etc., are recorded in the schema samples. The landscape (above ground) characteristics and the cultivation methods and its history are covered in the sites, landscape and landsites schemas.

Moulder (slakes)

Moulder: Soil aggregates is an open source mobile app available on Google Play and Apple App Store.

The measurement of the soil aggregate stability rely on the mobile phone camera. The light settings to separate the soil aggregrates from the background can be tricky and you might need to try different light conditions before the app is able to separate the soil aggregates from the (white) background.

The app records the results in a folder under documents on your phone. The path to the folder of your results depend on whether you used moulder or slakes:

./documents/slakes/SoilHealthTestResultsExport_YYYY-MM-DD_HH-MM_SS

Each experiment generate a set of csv files with the results and also the images used for the analysis:

|____ImageData.csv
|____Sample_hdd_YYYY-MM-DD_hh-mm_ss
| |____Initial_mask.jpg
| |____Final_crop.jpg
| |____Initial_bw.jpg
| |____Second_crop.jpg
| |____Second_bw.jpg
| |____Description.csv
| |____Initial_crop.jpg
| |____Final_mask.jpg
| |____Initial_original.jpg
| |____Second_mask.jpg
| |____Final_original.jpg
| |____Second_original.jpg
| |____Final_bw.jpg
|____SampleSummary.csv

slakes generates 3 csv documents:

• SampleSummary.csv
• ImageData.csv
• Sample_hdd_YYYY-MM-DD_hh-mm_ss/Descriptions.csv

The only data that is transferred to the database is the Aggregate Stability Index (ASI) from the file SampleSummary.csv:

Aggregate Stability Index Values

Sample Name,Time Stamp,Aggregate Stability Index,Error State
sample-name,03/22/2024 09:55,0.48,None

or in more readable tabular form:

DBML

// Use DBML to define your database structure
// Docs: https://dbml.dbdiagram.io/docs
// Tool: https://dbdiagram.io/d

Project project_name {
  database_type: 'PostgreSQL'
  Note: 'AI4SH schema for moulder measurements'
}

Table users.user {
  userid SERIAL
}

Table samples.sample_event {
  sampleid SERIAL
  siteid INTEGER [pk]
}

Table moulder {
  sampleid INTEGER [pk]
  topsoil Boolean [pk]
  userid INTEGER
  app_version_moulder BOOLEAN
  aggregate_stability_index float
  description TEXT
}
// topsoil (true) represents 0-20 cm, subsoil (false) represents 20-50 cm.

REF: samples.sample_event.sampleid - moulder.sampleid
REF: users.user.userid - moulder.userid

Figure

The schema microbiometer only contains a single table, for recording the results of the Microbiometer^TM soil sampling kit.

The soil sampling, including extraction method, depth, classification, photos etc., are recorded in the schema samples. The landscape (above ground) characteristics and the cultivation methods and its history are covered in the sites, landscape and landsites schemas.

Microbiometer

The Microbiometer^TM is a commercial soil sampling kit for estimating the soil microbial biomass and fungal to bacterial ratio. The measurements takes about 20 minutes and requires a smartphone, and the Microbiometer soil test kit.

The procedure for estimating bacteria and fungi includes mixing a small soil sample with a reagent and then use a template colour chart for evaluation using an app that interpreters the colour change of your soil sample through the camera of a smartphone. The full procedure takes about 20 minutes. If you subscribe and register an account you can save the results in an online database. For use with AI4SH the results need to be accessible for use with other in-situ data, and the AI4SH in-situ database thus contains a schema for storing microbiometer data.

MicroBiometerTM expresses test results as a number between 0 and 100.

DBML

// Use DBML to define your database structure
// Docs: https://dbml.dbdiagram.io/docs
// Tool: https://dbdiagram.io/d

Project project_name {
  database_type: 'PostgreSQL'
  Note: 'AI4SH schema for microbiometer measurements'
}

Table users.user {
  userid SERIAL
}

Table samples.sample_event {
  sampleid SERIAL
  siteid INTEGER [pk]
}

Table microbiometer {
  sampleid INTEGER [pk]
  topsoil Boolean [pk]
  userid INTEGER
  bacteria_ratio float
  fungi_ratio float
  extra_reagent_required BOOLEAN [DEFAULT false]
  description TEXT
}
// topsoil (true) represents 0-20 cm, subsoil (false) represents 20-50 cm.

REF: samples.sample_event.sampleid - microbiometer.sampleid
REF: users.user.userid - microbiometer.userid

Figure

Macrofauna observations will neither be taken at all pilots, nor at all sites/points at the pilots where it will actually be included. Whether or not to do a macrofauna analysis at a particular sample point is defined in the sites schema (table: sites.point_insitu_methods).

The default method for macrofauna analysis is to excavate a soil monolith of 25 * 25 cm and hand sort the macrofauna separately from two different layers:

• litter (on top of the actual soil profile),
• top soil (0-20 cm).

The alternative is to pour either mustard oil of mustard water over the soil surface, usually also 25 * 25 cm, and just capture and observe the earthworms that crawl up. The registration of the excavation method is done in the schema samples and then linked via the sampleid.

Each sample point where a macrofauna analysis is performed can be be linked to a special photo showing the detailed ground conditons - preferable with a frame laid out to indicate the exact area (i.e. the 25 * 25 cm square). Such monolith photos are registered in the table monolith_photo. Monolith photos can be registered for each layer.

In addition to the excavation method, the observation of macrofauana also requires a tool/method for extracting the creatures from the soil, i.e. an extraction_method. Applying mustard to the soil surface accomplishes excavation and extraction in one single process. But for the default method of excavation a soil monolith a second step of extraction is required. Default is to use hand-sorting, but alternatively applying heat can also be used. The exact method to apply for any sample must be pre-registered in the catalog extraction_method, and selected using a drop-down list.

The table for recording macrofauna (observation) contains columns for layer, taxa, life_cycle_stage_code, n_specimen (number of specimens) and g_total (total biomass of taxa in grams), and the sampleid (linking to the sample event and further up the chain to the sample point, site and pilot). Each new record in the table observation is given a new (SERIAL) id, observationid. Photographs of the taxa represented in an observation can then be linked using the observationid and registered in the table taxa_photo. Any number of photos can be linked to the same observationid as long as caption field differs.

The identification of taxa is by default manual, but semi-automated or fully automated methods using 2D or 3D images is tested as part of AI4SH. Thus each taxa result (table: observation) must be accompanied with the identification method applied. As the image based identification is under development, the support table for defining the identification method, identification_method, includes columns for defining both the camera and light setup and the substrate used as background.

The landscape (above ground) characteristics and the cultivation methods and its history are covered in the landscape, landstate and weather schemas. The analyser of the macrofauna must be registered separately, by linking to the users schema.

Idea and objective

The schema macrofauna is one of several sibling schemas for registering in-situ data analysis results. For all of these siblings, information on the sample point (pilot, site), are linked via the schema sites. Information on the sampling event is linked via the samples schema.

To insert a macrofauna observation into the observation tables, the taxa to insert must be registered in the taxa_stage table. All insertions should use the latin name (regardless of the taxonomic level) and no manual entry should be allowed. The only way to enter a taxa should be via a drop down menu listing all allowed entries. To support the field observer the table storing all the allowed taxa could also have vernacular names. But only to support searching for the observation - once entered into the database it should automatically be the latin name regardless of how the observer identified the taxa.

The initial default taxa to use are listed separately below. New taxa should only be allowed for expert users to add.

To allow the comparison of manual, semi-automated and fully automated macrofauna identification methods, the table identification_methods is used for defining the precise identification method. Each recorded taxa from the two default layers (litter and topsoil) are registered in the table observation and must be linked to an identification method. This allows cross-comparison of different image based setups, both against each other and vis-a-vis the manual identification, at a taxa level.

Macrofauna wiki page

https://animaldiversity.org

DBML

// Use DBML to define your database structure
// Docs: https://dbml.dbdiagram.io/docs
// Tool: https://dbdiagram.io/d

Project project_name {
  database_type: 'PostgreSQL'
  Note: 'AI4SH schema for macrofauna measurements'
}

Table users.user {
  userid SERIAL
}

Table samples.sample_event {
  sampleid SERIAL
}

Table sampling_technique {
  sampleid INTEGER [pk]
  userid INTEGER
  sample_dim_cm_x smallint [default: 25]
  sample_dim_cm_y smallint [default: 25]
  sample_dim_cm_z smallint [default: 20]
  extraction_method TEXT [default: "hand_sorting"]
  litter_layer boolean [default: True]
  topsoil_layer boolean [default: True]
}

Table extraction_method {
  extraction_method TEXT [pk]
}
// extraction_method alternatives: "hand_sorting", "mustard_oil", "mustard_powder"

Table identification_method {
  approach TEXT [pk]
  substrate TEXT [pk]
  camera TEXT [pk]
  setup TEXT [pk]
  lightsource TEXT [pk]
  methodcode SERIAL
}
// approach alternatives: "manual", "image"
// substrate alterantives: "NA", "whitepaper", "whitecloth", "mirror", "glass", "shoebox"
// camera alternatives: "NA", "singlemobile", "dualmobile", "singlesystemcamera", "dualsystemcamera", "3Dscan"
// setup alternatives: "NA", "handheld", "singletripod", "dualtripod", "3Dscan"
// lightsource alternatives: "NA", "outdoo", 'indoor', "flash", "singlelamp", "duallamp", "3Dscan"

Table observation {
  sampleid INTEGER [pk]
  methodcode INTEGER [pk]
  taxa TEXT [pk]
  layer TEXT [pk]
  life_cycle_stage_code CHAR[1] [pk]
  n_specimen SMALLINT
  g_total REAL
  observationid SERIAL
}

Table monolith_photo {
 sampleid INTEGER [pk]
 layer TEXT [pk]
 photoid TEXT
 photourl TEXT
}

Table monolith_depth {
 sampleid INTEGER [pk]
 layer TEXT [pk]
 top SMALLINT
 bottom SMALLINT
}

Table taxa_photo {
 observationid INTEGER [pk]
 caption TEXT [pk]
 photoid TEXT
 photourl TEXT
}

Table life_cycle_stage {
  life_cycle_stage_code CHAR[1] [pk]
  life_cycle_stage VARCHAR(16)
}
// life_cycle_stage alternatives:  A=adult, C=cocoon, L = Larvae, J=juvenile, N= Nymph, E= Egg, P=Pupa,

Table taxa_stage {
  taxa TEXT [pk]
  taxa_alternative TEXT [pk]
  life_cycle_stage_code CHAR(1) [default: 'A', pk]
  common_english_name TEXT[]
  taxonomic_level TEXT [pk]
  class TEXT
  order TEXT
  family TEXT
  genus TEXT [default: 'NA']
  species TEXT [default: 'NA']
  info TEXT
  url TEXT
}

Table taxonomic_level {
  taxonomic_level TEXT
}
// taxonomic_levels alternatives:  Species, Genus, Family, Order, Class, Phylum, Kingdom, Domain

REF: samples.sample_event.sampleid - sampling_technique.sampleid

REF: users.user.userid - sampling_technique.userid

REF: sampling_technique.sampleid - observation.sampleid

Ref: sampling_technique.extraction_method - extraction_method.extraction_method

Ref: identification_method.methodcode - observation.methodcode

Ref: "public"."observation"."taxa" - "public"."taxa_stage"."taxa"

Ref: "public"."observation"."life_cycle_stage_code" - "public"."taxa_stage"."life_cycle_stage_code"

Ref: "public"."taxa_stage"."life_cycle_stage_code" - "public"."life_cycle_stage"."life_cycle_stage_code"

Ref: "public"."taxa_stage"."taxonomic_level" - "public"."taxonomic_level"."taxonomic_level"


Ref: "public"."sampling_technique"."sampleid" < "public"."monolith_photo"."sampleid"


Ref: "public"."observation"."observationid" < "public"."taxa_photo"."observationid"

Ref: "public"."observation"."sampleid" < "public"."monolith_depth"."sampleid"

Initial taxa to use for the macrofauna registration, their taxonomic levels and common English names. Note that some entries are overlapping in such way that a lower hierarchical level (e.g. family) is a breakout from a higher level (e.g order).

// taxa: Dermaptera
// alternative_taxa: acari
// code: -
// taxa_system_level: order
// common_english_name: ['earwigs']
// phylum: Arthropoda
// class: insecta
// order: Dermaptera
// family: NA

// taxa: Acarina
// alternative_taxa: acari
// code: AR
// taxa_system_level: order
// common_english_name: ['mites','ticks']
// class: arachnida
// order: acarina

// taxa Araneidae
// alternative_taxa: NA
// code: -
// taxa_system_level: family
// common_english_name: ['orb-weaver spiders']
// class: arachnida
// order: araneidae
// family: araneidae

// taxa: blattaria
// alternative_taxa: blattodea
// code: BL
// taxa_system_level: order
// common_english_name: ['cockroach']
// phylum: Arthropoda
// class: insecta
// order: Blattaria
// family: NA

// taxa chilopoda
// alternative_taxa: NA
// code: CH
// taxa_system_level: class
// common_english_name: ['centipedes']
// class: chilopoda
// order: NA
// family: NA

// taxa: Coleoptera
// alternative_taxa: NA
// code: CO
// taxa_system_level: order
// common_english_name: ['beetle']
// phylum: Arthropoda
// class: insecta
// order: Coleoptera
// family: NA

// taxa: Collembola
// alternative_taxa: NA
// taxa_system_level: class
// common_english_name: ['springtales']
// phylum: Arthropoda
// class: collembola
// order: NA
// family: NA

// taxa: Dictyoptera
// alternative_taxa: NA
// taxa_system_level: genus
// common_english_name: ['net-winged beetles']
// phylum: Arthropoda
// class: insecta
// order: Coleoptera
// family: Lycidae
// Genus: Dictyoptera

// taxa: Diplopoda
// code: DI
// alternative_taxa: NA
// taxa_system_level: class
// common_english_name: ['millipede']
// phylum: Arthropoda
// class: Diplopoda
// order: NA
// family: NA
// Genus: NA

// taxa: Diploura
// alternative_taxa: Diplura
// taxa_system_level: order
// common_english_name: ['two-pronged bristletails']
// phylum: Arthropoda
// class: Diplura
// order: NA
// family: NA
// Genus: NA

// taxa: Diptera
// alternative_taxa: NA
// code: DI
// taxa_system_level: order
// common_english_name: ['fly']
// phylum: Arthropoda
// class: insecta
// order: Diptera
// family: NA
// Genus: NA

// taxa: Gasteropoda
// alternative_taxa: Gastropoda
// code: GA
// taxa_system_level: class
// common_english_name: ['slugs', 'snails']
// phylum: Mollusca
// class: Gasteropoda
// order: NA
// family: NA
// Genus: NA

// taxa Hemiptera
// alternative_taxa: NA
// code: HM
// taxa_system_level: order
// common_english_name ['true bugs']
// phylum: Arthropoda
// class: insecta
// order: Hemiptera
// family: NA
// Genus: NA

// taxa Hymenoptera
// alternative_taxa: NA
// code: -
// taxa_system_level: order
// common_english_name ['sawfiles','wasps','bees','ants']
// phylum: Arthropoda
// class: insecta
// order: Hymenoptera
// family: NA
// Genus: NA

// taxa Formicidae
// alternative_taxa: NA
// code: AN
// taxa_system_level: order
// common_english_name ['ants']
// phylum: Arthropoda
// class: insecta
// order: Hymenoptera
// family: Formicidae
// Genus: NA

// taxa Lepidoptera
// alternative_taxa: NA
// code: LE
// taxa_system_level: order
// common_english_name ['butterflies']
// phylum: Arthropoda
// class: insecta
// order: Lepidoptera
// family: NA
// Genus: NA

// taxa: Termite
// alternative_taxa: NA
// code: TE
// taxa_system_level: family
// common_english_name: ['termite']
// phylum: Arthropoda
// class: insecta
// order: Blattodea
// family: Termite
// Genus: NA

Figure