Relevé extension - recommended new term

[kingenloff]

Am I correct in my understanding that the relevé extension is created and maintained by GBIF? If so, I'd like to recommend adding a new term: coverBareGroundInPercentage. This is often an explicit measure that is captured during vegetation surveys, and, depending on the survey, cannot necessarily be inferred from other shared data.

[tucotuco]

Yes, that is a GBIF invention from 2016. It would be interesting to see the extent to which it is used and if the Humboldt Extension now can supersede it. And if not, what would have to be done to Humboldt to do so.

[kingenloff]

Thus far, approximately 40 datasets use the extension (Salza's is the most recent, I think: https://doi.org/10.15468/pkx4tg), but assuming we see an increase in vegetation surveys published as Event core, I imagine use will increase. Relevé's are very common in vegetation surveys.

Humboldt should not supersede its use, unless you wish to extend the purpose of HE from capturing the sampling context of survey events to include reporting actual data as well.

Are considering deprecation of the Relevé extension? If so, the most logical move is to recommend that data publishers report Relevé data at the appropriate event level using emof. But, if we do want to consider such a move, we should schedule discussions soon as both of the survey and monitoring data publishing guides recommend use of the Relevé extension. And, any discussion should include @mdoering and Salza Palpurina.

[mdoering]

Mostly these are event site measurements. The syntaxonName is a very important and special term though.
And it is far more convenient and less error prone to report all the measurements in one record with fixed term names instead of selecting various measurements and not using a controlled vocabulary. It would also be good to cover that use case in the dwc-dp work.

[timrobertson100]

Regarding the Relevé extension, adding the term seems appropriate since the extension is in use and has been recommended in guidance documents - plus it would do no harm.

I also agree with @mdoering that it’s more important to prioritize the DwC-DP work than comparing with HEE which we know to have some shortfalls due to DwC-A star limitations. That might, e.g. include a vocabulary of these terms for use in assertions (measurements).

[kingenloff]

In addition to the bareGroundInPercentage term, @mdoering do you think it would it be useful to also add a soilTextureClass term (with a controlled vocabulary: sand, loamy sand, sandy loam, loam, silt loam, sandy clay loam, clay loam, silty clay loam, sandy clay, silty, clay, clay, rock, peat)? This seems to be commonly collected Relevé data.

[mdoering]

There are many items people frequently record. Just looking into Turboveg3, which seems to have been the basis for the existing extension terms, I remember from my past:

I assume some are covered by the general Event core.

• plot size
• altitude

But these appear to be missing:

• humus type
• rock type
• soil type
• soil texture
• soil depth
• soil ph
• bare ground % (sum of bare rock, soil
• bare soil %

See also https://www.vegapp.de/tab_obs.html

[spalp]

I also agree with @mdoering that the releve extension follows the db structure in the Turboveg software - however, I the terms are based on those available in version 2, given the time period the extension was developed and that already TV 2 has a function to export to DwC. See also here.

I am not sure what to advise on adding new terms. Phytosociologists record a lot of data and the way they collect it sometimes differs (and differs from what is available in TV3). For example, I do not record '% of bare ground' sensu https://www.vegapp.de/tab_obs.html. but I record separately its two components : 1) bare soil and 2) bare rock, stones and rock gravel. Since in Tuboveg, there is only the field coverRockInPercentage, I report bare rocks, stones and gravel under coverRockInPercentage.
Further, some vegetation scientists have acknowledged that bare soil/bare ground cannot be used as independent predictors for vegetation parameters . Therefore, in the EDGG biodiversity sampling protocol, % bare soil is not recorded but rather the % of fine soil, which is the % of surface excluding the % cover of rocks (coverRockInPercentage), stones and gravel. In the latter case, % of fine soil, coverRockInPercentage, stones and gravel should sum up to 100%. This protocols has been largely used and each year there are at least two field expeditions that produce datasets using this protocol: https://edgg.org/fw/overview

If one wishes to accomodiate all possible protocols, one should increase the list even further:

• Bare Ground (%) - Percent of exposed bare ground not covered by leaf litter (includes bare soil, bare rock and rock gravel)
• Bare Soil (%) - Percent of exposed fine soil (fine soil that is not covered by leaf litter, vegetation or moss)
• Bare Rock (%) - Percent of exposed bare rocks (already in the extension)
  The above three are 'traditionally' used and could be found throughout the traditional literature,

The next three are recorded using the EDGG fieldworkshop concept:

• Cover of stones (%) - percentage cover of stones and rocks (diameter > 63 mm) at the plot surface after virtually removing all vegetation, litter and deadwood
• Cover of gravel - percentage cover of gravel (2−63 mm) at the soil surface after virtually removing all vegetation, litter and deadwood
• Cover of fine soil (%)< 2 mm)

And that is only as regards vegetation and substrate surface. Soil pH has also different ways of being recorded both in the field (how many points, mixed or separate samples, at what depth, etc) and in the lab (in water or in KCl)... many records nutrients in the soil and in plant biomass (N, P, K, Mg, C, etc)... I have such data and I was thinking to use the MeasurementOrFactsextension:
May be for the above one could use MeasurementOrFacts ext. as well?

To conclude, I personally do not mind an extension for vegetation ecologist that accomodates all their possible measures as separate terms. It will definitely save time if the alternateve it so describe measurements using the MeasurementOrFacts. Also, it will be really nice if someone uses this standard definitions to incorporate back in the TV database or any other database for storing releves.

I like the idea to include the soil texture classes but a scenario came to my mind... If hypothetically someone who has collected soil data (but not within vegetation plots/releves) decides to report soil textureusing the MeasurementOrFacts but a vegetation ecologists reports the same measurement usinf the releve extenstion, is that OK? Would not that create issues for the combination of these data later on (mainly due to the lack of knowledge that the same measure could be reported using different terms in different extensions)?

[mdoering]

We could propose to add the following, leaving everything else to the MeasurementsAndFacts extension linked to events:

• coverGroundInPercentage: The cover (%) of bare ground, rounded to the nearest hundredth (2 decimal places). This includes bare rock, gravel and soil.
• coverGravelInPercentage: The cover (%) of bare gravel (2−63 mm) at the soil surface after virtually removing all vegetation, litter and deadwood
• coverSoilInPercentage: The cover (%) of bare gravel (2−63 mm) at the soil surface after virtually removing all vegetation, litter and deadwood
• rockType: Type of rocks underlying the soil, like limestone, granite etc. Ideally according to some classification scheme (like the BGS Rock Classification Scheme)
• soilType: Name of the soil, usually as a category according to some soil classification (like the World Reference Base for Soil Resources)
• soilTexture: Description of the mineral soil relating to sand, silt and clay contents (loamy sand, sandy loam, loam etc.)