Code-lists for observation results in Soil Theme

[ldesousa]

In the soil domain there are properties for which observation results are bounded by a controlled set of classes. For instance, the FAO Guidelines for Soil Description define the following result classes for the property "Plasticity" (Table 56, page 49):

• Non-plastic
• Slightly plastic
• Slightly plastic to plastic
• Plastic
• Plastic to very plastic
• Very plastic

Each of these classes are determined by specific actions the soil surveyor conducts in the field.

What is the policy/guidance regarding this kind of code-lists? Is each provider expected to set up its own code-list repository? Or is the INSPIRE registry open to expansion for this purpose?

Thank you.

[KathiSchleidt]

I'd say the starting point for such an activity would be the creation of the ObservableProperty codelists. All ObservableProperties that provide a categorization as a result should have an additional result codelist as you proposed. However, to my memory, we're still missing the base Plasticity ObservableProperty.
One thing that should be explored is if the INSPIRE Re3gistry can provide a link from the ObservableProperty to the codelist providing the result categories. Maybe the JRC Re3gistry experts can provide some information on this?

[heidivanparys]

The INSPIRE code list repository does not contain code lists that are governed outside INSPIRE, see also the landing page at https://inspire.ec.europa.eu/codelist, and see the section 5.2.4.4. Governance in the data specification. It is the FAOs responsibility to publish their code lists in a format suitable for machine readable communication.

When looking at the document referenced, I can see that the FAO does define code values (NST, SST, etc.), they're just not HTTP-URI's. If the data model and the encoding allow it, using those exact code values would be my recommendation. Semantic interoperability (everybody using the same code values) and reuse (FAO has take the effort to create these code values) is more important than semantic web enabled code values, especially if the latter implies everybody creating their own HTTP-URIs and thus impeding semantic interoperability.

Note: I am not familiar with the Soil specification and existing encodings, so I don't know whether using the short code values is possible right now.