Sage Journals: Discover world-class research

Abstract

Established in 2012 by members of the Food and Agriculture Organisation of the United Nations, the Global Soil Partnership (GSP) is a global network of stakeholders promoting sound land and soil management practices towards a sustainable world food system. However, soil survey largely remains a local or regional activity, bound to heterogeneous methods and conventions. Recognising the relevance of global and trans-national policies towards sustainable land management practices, the GSP elected data harmonisation and exchange as one of its key lines of action. Building upon international standards and previous work towards a global soil data ontology, an improved domain model was eventually developed within the GSP, the basis for a Global Soil Information System (GloSIS). This work also identified the Semantic Web as a possible avenue to operationalise the domain model. This article presents the GloSIS web ontology, an implementation of the GloSIS domain model with the Web Ontology Language (OWL). Thoroughly employing a host of Semantic Web standards (Sensor, Observation, Sample, and Actuator ontology (SOSA), Simple Knowledge Organisation System (SKOS), GeoSPARQL, QUDT), GloSIS lays out not only a soil data ontology but also an extensive set of ready-to-use code-lists for soil description and physico-chemical analysis. Various examples are provided on the provision and use of GloSIS-compliant linked data, showcasing the contribution of this ontology to the discovery, exploration, integration and access of soil data.

Keywords

soil sustainability semantic model SOSA/SSN SKOS GloSIS

1. Introduction and Motivation

1.1. The Importance of Soils and Related Risks

Human population has more than tripled since the end of World War II (United Nations, 2019). This growth has been accompanied by the densification of urban areas, with the share of population living in cities doubling, having surpassed 50% in 2010 (Desa, 2018). Supporting this population has required unprecedented growth in food production. Nevertheless, dramatic increases in food output per unit area have meant an expansion of global agricultural area by just 30% in the past seven decades (Ramankutty et al., 2018). Albeit a success, this transformation and expansion of food production systems have placed unprecedented stress on soils. These are non-renewable natural resources that, if mismanaged, can rapidly degrade to a non-productive state. Soils around the globe are presently impacted by the over-use of fertilisers, chemical contamination, loss of organic matter, salanisation, acidification, and outright erosion (Kopittke et al., 2019). These trends pose serious risks not only to food supply, but also to ecosystems, as they provide a myriad of services at the local, landscape, and global levels (Banwart et al., 2014; FAO and ITPS, 2015; UNEP, 2012).

Addressing these risks often requires a holistic approach, with policies and practices envisioned at a global scale. For instance, the reduction of soil erosion through land rehabilitation and development (Borrelli et al., 2017; WOCAT, 2007), the protection of food production (FAO et al., 2018; Soussana et al., 2017; Springmann et al., 2018), or the preservation of biodiversity (Barnes, 2015; IPBES, 2019; van der Esch et al., 2017) and human livelihood (Bouma, 2015). However, the data necessary to develop such policies is collected, analysed, and represented at local scales, as these remain primarily region- or country-specific activities. The data harmonisation necessary towards the sustainable use of soils at the global scale thus remains a challenge (Global Soil Partnership, 2017a).

1.2. Global Soil Partnership (GSP) and its Goals

The GSP was established in 2012 by members of the Food and Agriculture Organisation of the United Nations (FAO) as a network of stakeholders in the soil domain. Its broad goals are to raise awareness of the importance of soils in attaining a sustainable agriculture and to promote good practices in land and soil management. The GSP involved the majority of the world’s national soil information institutions, gathered around the International Network of Soil Information Institutions.

The GSP defined five pillars of action, structuring its activities:

–
Pillar 1 – Soil management – promote the sustainable management of soil resources for soil protection, conservation, and productivity.
–
Pillar 2 – Awareness raising – encourage investment, technical cooperation, policy, education, and awareness.
–
Pillar 3 – Research – promote targeted soil research and development, considering synergies with related productive, environmental, and social development.
–
Pillar 4 – Information and data – enhance the quantity and quality of soil data and information: data collection (generation), analysis, validation, reporting, monitoring, and integration with other disciplines.
–
Pillar 5 – Harmonisation – targeting methods, measurements, and indicators for the sustainable management and protection of soil resources.

The Action Plan for Pillar 5 (Global Soil Partnership, 2017a) acknowledges various difficulties with the harmonisation of soil data. In most cases, these data are collected and curated by national or regional institutions, focused on their local context, largely abstracted from international or global concerns. This lack of homogeneity severely limits the availability and use of soil data. The transfer of data, methods, and practices between regions or from global to local initiatives is thus prone to hurdles and errors, putting at risk sustainable soil management goals.

Among the key priorities towards harmonisation identified in the Action Plan for Pillar 5 is the development of a soil information exchange infrastructure. This is broadly defined as “[…] a conceptual soil feature information model provid[ing] the framework for harmonisation such that the efficient exchange and collation of globally consistent data and information can occur.” Data exchange is put forth both as an essential component of soil data harmonisation and as a vector to that end, facilitating data integration, analysis, and interpretation.

In the Action Plan for Pillar 4 (Global Soil Partnership, 2017b), the GSP lays out the guidelines for the development of an authoritative global soil information. This system is envisioned as fulfilling three main functions:

–
answer critical questions at the global scale;
–
provide the global context for more local decisions;
–
supply fundamental soil data to understand Earth-system processes to enable management of the major natural resource issues facing the world.

Draft implementation guidelines are laid out in the Action Plan for Pillar 4, pointing to a federated system in which soil institutions provide access to their data through web services, all compliant with a common data exchange specification. The latter is leveraged on the outcome of Pillar 5, concerning the exchange of soil profile observations and descriptions, laboratory and field analytical data, plus derived products such as digital soil maps. Soil data exchange is thus set at the core of GSP, an unavoidable stepping stone to achieve its goals. As set out in the Action Plan for Pillar 5: “Pillar 5 is a basic foundation of Pillar 4, and an enabling mechanism for all GSP pillars providing and using global soil information.”
1.3. International Consultancy Towards a Global Soil Information Exchange

In 2019, the GSP launched a call for an international consultancy to assess the state-of-the-art in soil information exchanges and propose a path towards its operationalisation in line with the goals of Pillar 5. The results of this consultancy are gathered in Rezník and Schleidt (2020). In this work, a detailed set of requirements was inventoried, sourced from meetings and interviews with various GSP stakeholders. Among them is the will to re-use existing models and exchange mechanisms as much as possible, and assess the suitability of each regarding implementation (with Pillar 4 in view).

The consultancy identified relevant similarities between previous models targeting soil data exchange: Australian and New Zealand Soil Mark-up Language (ANZSoilML; Simons et al., 2013), INSPIRE Soil Theme (Soil ITWG, 2013), the ISO 28258 (ISO 28258:2013, 2013) standard, and the model developed during the OGC Soil Interchange Experiment (OGC Soil IE; OGC 16-088r1, 2016). All of these models re-use the Observations and Measurements (O&M) domain model (Cox, 2011b), an umbrella specification for the observations of natural phenomena, adopted by ISO as a standard (ISO 19156:2011, 2011). The relational data models of the World Soil Information Service (WoSIS; Batjes et al., 2024) and the Soil and Terrain programme (SOTER; Oldeman & Van Engelen, 1993) were also considered by the consultancy, even though they do not share the same O&M abstraction. However, since these databases collect sizeable soil data in a harmonised manner, they provided insight on aspects such as the code-lists necessary to operationalise a soil data exchange.

The ISO 28258 model was selected as the most suitable starting point to operationalise the sought for exchange mechanism. The model was augmented with container classes encapsulating the Guidelines for Soil Description issued by the FAO (Jahn et al., 2006), an abstraction of the code-lists necessary for the exchange. The resulting model is documented as a UML class diagram. Regarding implementation, the consultancy concluded on the suitability of both XML and RDF. XML was early on put forth as an implementation vehicle for O&M (Cox, 2011a), whereas the more recent publication of the Sensor, Observation, Sample, and Actuator ontology (SOSA; Janowicz et al., 2019), an RDF-based counterpart to O&M, presents a clear path to an implementation on the Semantic Web.

1.4. Document Structure

This article starts by briefly reviewing previous models that tackled soil information exchange (Section 2). Section 3 presents the methodology, followed by the specification of the Global Soil Information System (GloSIS) web ontology, up to the maintenance aspects. Section 4 presents some example applications of the ontology, including methods for the discovery and access of soil data based on GloSIS. The article closes with considerations on future work in Section 5. All RDF assets composing the GloSIS web ontology, as well as its documentation, are available at a public software repository.¹ Table 1 summarises the prefixes and corresponding namespaces used in the ontology and throughout this article.

Table 1.
Namespaces.

rdf http://www.w3.org/1999/02/22-rdf-syntax-ns#

glosis_sp http://w3id.org/glosis/model/siteplot/

glosis_pr http://w3id.org/glosis/model/profile/

glosis_lh http://w3id.org/glosis/model/layerhorizon/

glosis_cl http://w3id.org/glosis/model/codelists/

glosis_proc http://w3id.org/glosis/model/procedure/

ssn http://www.w3.org/ns/ssn/

sosa http://www.w3.org/ns/sosa/

qudt http://qudt.org/schema/qudt/

unit http://qudt.org/vocab/unit/

xsd http://www.w3.org/2001/XMLSchema#

rdfs http://www.w3.org/2000/01/rdf-schema#

gn http://www.geonames.org/ontology#

nuts http://nuts.geovocab.org/id/

gsp http://www.opengis.net/ont/geosparql#

geof http://www.opengis.net/def/function/geosparql/

iso28258 http://w3id.org/glosis/model/iso28258/2013#

iso19115-1 http://def.isotc211.org/iso19115/-1/2018/CitationAndResponsiblePartyInformation#

cap-parcel http://lpis.ec.europa.eu/registry/applicationschema/cap-iacs-parcel#

lcc-cr https://www.omg.org/spec/LCC/Countries/CountryRepresentation/

skos http://www.w3.org/2004/02/skos/core#

foaf http://xmlns.com/foaf/0.1/

2. Background and Related Work

The GloSIS domain model and web ontology follow on the steps of various earlier attempts at a framework for the exchange of soil data and knowledge. This section reviews the most relevant.

2.1. SOTER

The Global and National Soils and Terrain Digital Databases (SOTER) was an initiative of the International Society of Soil Science, in cooperation with the United Nations Environment Programme, the International Soil Reference and Information Centre (ISRIC), and the FAO (FAO of the United Nations Land and Water Division , 1993). It was the first attempt to create a digital soil resource of global reach, making use of what were then emerging technologies, such as Relational Database Management Systems and Geographic Information Systems (GIS). Whereas primarily targeting the production of digital maps for decision support, the SOTER initiative possibly embodied the first global digital vocabulary of soil properties and characteristics, assessed in situ, as well as via laboratory measurements. Albeit lacking an abstract formalisation (SOTER pre-dates both UML and Web Ontology Language (OWL)), the ancient SOTER databases remained a reference to the development of subsequent soil information models.

2.2. ISO 28258

The international standard “Soil quality – Digital exchange of soil-related data” (ISO number 28253) resulted from a joint effort by the ISO technical committee “Soil quality” and the technical committee “Soil characterisation” of the European Committee for Standardisation (CEN). Recognising a need to combine soil with other kinds of data, this standard set out to produce a general framework for the exchange of soil data, recognising the need to combine soil with other kinds of data.

ISO 28258 is documented with a UML domain model, applying the O&M framework to the soil domain. It abstracts familiar concepts in soil science such as Site, Plot, Profile, Horizon, Layer, or SoilSpecimen. An XML exchange schema is derived from this domain model, further adopting the Geography Markup Language (GML) for the encoding of geo-spatial information. The standard was conceived as an empty container, lacking any kind of controlled content. It is meant to be further specialised for actual use (possibly at a regional or national scale).

2.3. Australian and New Zealand Soil Mark-up Language (ANZSoilML)

The ANZSoilML (Simons et al., 2013) results from a joint effort by CSIRO in Australia and New Zealand’s Manaaki Whenua to support the exchange of soil and landscape data. Its domain model was possibly the first application of O&M to this domain, targeting the soil properties and related landscape features specified by the institutional soil survey handbooks used in Australia and New Zeeland (Milne et al., 1995; National Committee on Soil and Terrain, 2009). This model outlines a hierarchy of observable features, including the concepts SoilSurface, SoilHorizon, Soil, and SoilProfile. The description of soil composition imports concepts from GeoSciML (Sen & Duffy, 2005).

ANZSoilML is formalised as a UML domain model from which an XML schema is obtained, relying on the ComplexFeature abstraction that underlies the SOAP/XML web services specified by the OGC. A set of controlled vocabularies was developed for ANZSoilML, providing values for categorical soil properties and laboratory analysis methods. However, these were never made mandatory, and the model is open to be used with alternative vocabularies. More recently, these vocabularies were transformed into RDF resources to be managed with modern Semantic Web technologies.

2.4. The Soil Theme in INSPIRE

The INSPIRE directive of the European Union came into force in 2007 with the goal of creating a spatial environmental data infrastructure for the Union. A detailed data specification for the soil theme was published by the European Commission in 2013 (Soil ITWG, 2013), supported by a detailed domain model documented as a UML class diagram. The model provides more depth for soil inventory data, relying heavily on O&M in the specification of soil properties observations (both numerical and descriptive). The features of interest identified in this model match familiar concepts in soil surveying: SoilBody, SoilSite, SoilPlot, SoilProfile, SoilLayer, and SoilHorizon (vide Figure 1).

Figure 1.

Visual Representation of the Main Feature of Interest in the INSPIRE Domain Model (Soil ITWG, 2013). Image Re-Used According to Decision 2011/833/EU of the European Commission.

While the domain model is documented as UML, there is no enforcing policy from the European Commission regarding its implementation. Guidelines have been published by the INSPIRE Maintenance and Implementation Group on possible implementation technologies, such as GeoPackage.² An infrastructure has been put in place to register the code-lists of all INSPIRE themes, currently maintained by the Joint Research Centre.³ In the Soil Theme, code-lists are mostly composed of broad concepts that must be further redefined by member states. The European Commission has set up a dedicated platform named INSPIRE Geoportal⁴ that works as a single access point to INSPIRE-compliant data services provided by the EU member states.

2.5. OGC Soil IE

The Working Group on Soil Information Standards (WGSIS) of the International Union of Soil Sciences (IUSS) acknowledged the parallel efforts of Oceania (ANZSoilML), Europe (INSPIRE), and ISO towards the implementation of a soil information exchange mechanism. However, from the perspective of the WGSIS, these concurrent initiatives were leading to a dispersed landscape in need of consolidation. Under the auspices of the OGC, the WGSIS set out the Soil Interoperability Experiment (SoilIE), aiming to reconcile the existing soil information domain models into a single exchange paradigm. As with previous efforts, SoilIE relied heavily on O&M to express the aspect of soil sampling and analysis, but going into considerably more detail. In a complex structure of sub-models, the SoilIE domain model specifies a large number of features, some similar to other models (e.g. Site, Plot, SoilProfile, Layer, and Horizon) plus more particular ones, such as SoilFeature, Soil, Component, or Station.

Contrary to the “empty shell” approach of ISO 28258, SoilIE went on to define in detail the soil properties subject to exchange. To this end, the experiment relied primarily on the FAO Guidelines for Soil Description (Jahn et al., 2006), with additional guidance from the USDA Field Book for Describing and Sampling Soils (Schoeneberger et al., 2012). The experimental implementation took a hybrid approach. The domain model was encoded as an XML schema (known as SoilIEML) following the principles laid out in ISO 19136 (ISO 19136:2007, 2007), which depend on GML for geo-spatial features. This XML schema was the basis for a series of OGC-compliant web services (Web Feature Service in particular). The Simple Knowledge Organisation System (SKOS) was selected as the preferred vehicle for controlled content (e.g. code-lists). The integration of the Semantic Web-based SKOS with the XML schema proved problematic, with XLINK attributes eventually used to refer to SKOS-based URIs. Bespoke URI resolution services were set up to de-reference SKOS concepts. This approach showcased the use of a soil information schema as an actual exchange mechanism and not as a prescription for data structuring by providers.

3. Ontology Specification and Implementation

3.1. Methodology

The GloSIS web ontology was built following the NeOn methodology (Gomez-Perez & Suárez-Figueroa, 2009), and following an iterative-incremental model for the continuous improvement and extension of the ontology through multiple iterations. NeOn identifies various scenarios for building ontologies and ontology networks. In particular, the following scenarios were used:

–
From specification to implementation, which comprises the core activities that have to be performed in any ontology development.
–
Reusing and re-engineering non-ontological resources (NORs), which identifies relevant NORs, transforms them into ontologies and reuses them to build the target ontology. This is further described in section 3.3.1.
–
Reusing ontological resources, which reuses existing ontological resources for building ontology networks. This is further described in section 3.3.2.
–
Reusing ontology design patterns, which reuses Ontology Design Patterns (ODPs) to reduce modelling difficulties, to speed up the modelling process, or to check the adequacy of modelling decisions. Two main patterns were reused: (i) the SOSA, which is a revised and expanded version of the Stimulus Sensor Observation ODP⁵; (ii) the OWL and SKOS pattern to model different parts of the same conceptualisation side by side (Formal/Semi-Formal Hybrid – Part OWL, Part SKOS), as described.⁶ In particular, this pattern was used for the code-list definitions, which are also in alignment with the ISO/IS 19150-2 (rules for developing ontologies in the OWL), and with the common practice of different standards.⁷

For more detailed information, please refer to the GloSIS repository wiki.⁸
3.2. Requirements

The GloSIS domain model shall, as far as possible, support the general requirements listed below; these requirements have been gleaned from the various inputs received as well as the discussions to date. The requirements presented below have been defined in line with the principles of software engineering.

–
Re-use existing standardisation efforts to avoid developing a completely new model. $$
Re-use ANZSoilML as a reference to integrate relevant soil concepts.
$$
Re-use ISO 28258 as the base model.
$$
Integrate relevant soil concepts from the OGC Soil Interoperability Experiment.
$$
Integrate relevant soil concepts from the SOTER/ISRIC model.
$$
The resulting model should be simple and easy to use.

–
Support the properties pertaining to soil body as defined in the UN FAO Guidelines for soil description in a generic way. $$
Design a generalised mechanism providing data users an insight with respect to what properties are available that pertain to a specific soil body. $$
code-lists/vocabularies (ontologies) shall be developed for linking the domain model with explicit soil body properties.
$$
Include code-lists/vocabularies (ontologies), but in a way that they can be added/modified/deleted without changing the domain model itself.
$$
AGROVOC terms should be used as a reference to avoid duplication of terms.

$$
The model shall specify the main “groups” of soil body properties according to the UN FAO guidelines for soil description.

–
The model shall support the properties inventoried by the GSP in the report “Specifications for the Tier 1 and Tier 2 soil profile databases of the Global Soil Information System (GloSIS)” (Batjes et al., 2019).
–
Determine which concepts (observed properties) should be considered as attributes (if any) and which should be modelled as observations (as access to measurement metadata may be required).
–
The model shall include a concept to indicate the observed properties available on the soil features.
–
A platform agnostic soil domain model, that is, abstract specification (in the terms of the Open Geospatial Consortium), should be elaborated to provide a common basis for all ongoing and future developments.
–
Provide mappings between the newly developed model and all existing data-exchange models.
Finally, the model should provide the basis to allow the publication and harmonisation of soil-related data following the Linked Data principles, enabling the provision of an integrated view over various (previously disconnected) datasets. This, in addition to the requirements for creating and linking code-lists/vocabularies, the provision of mappings, and the reuse of existing standards, led to the development of the model in the form of an ontology.
3.3. Conceptualisation and Implementation

The GloSIS domain model, initially realised as a UML model, was used as the basis to derive the target ontology. The model is composed of two main class types: the container classes, which are abstract classes used only for grouping observations (measurements) in a more readable manner, and spatial object types, which are the main GloSIS classes. The spatial object types are connected to the related observations via the connection with the container classes. Each of these two main types of classes was transformed and post-processed to generate the final ontology.

Based on the requirements described in Section 3.2, ISO 28258:2013 Soil quality – Digital exchange of soil-related data incl. Amd 1 (ISO 28258) was used to represent the top-level structure of the GloSIS web ontology. In order to better understand the steps taken for this task, one must first understand the basic structure of ISO 28258. At the most abstract level, the two core components of ISO 28258 pertain, on the one hand, to a set of spatial object types describing soil objects as well as artefacts generated by soil sampling, on the other hand, various observations or measurements of physicochemical properties on these objects. When extending this model for a specific usage area, one must determine if the information being extended is of a more static type, and thus should be appended to the spatial object type, or of a more dynamic nature, or also a value that can be determined via vastly different methodologies, and thus should be provided as an observation on the spatial object type.

The initial challenge in creating the GloSIS web ontology was identifying which spatial object types are required for the provision of the necessary information. Based on the GloSIS data requirements, the following spatial data types were identified: (i) site, (ii) plot, (iii) surface, (iv) sample, (v) specimen, (vi) profile, (vii) horizon, (viii) layer, and (ix) grid.

In a second step, the information requirements for each of these spatial object types were agreed upon with the experts, while the basis was provided by the FAO Guidelines for Soil Description (Jahn et al., 2006) and the GSP report “Specifications for the Tier 1 and Tier 2 soil profile databases of the Global Soil Information System” (Batjes et al., 2024). For this purpose, a spreadsheet was created with a row for every possible soil property, a column for each of the spatial object types. This matrix guided all further modelling work. Based on the understanding of the information requirements for each of these spatial object types, a decision had to be reached on how this information would be linked to the spatial object types. Based on the constraints laid down by ISO 28258, there were two main options available:

provide this information as an attribute of a specialised spatial object type; and

provide this information as an O&M observation referencing a specialised spatial object type.

While the first option is simpler to implement, the second allows for far more flexibility and precision pertaining to the information content. This is of particular relevance in the GloSIS context, as the model must support a very heterogeneous data provider community; one cannot mandate how data is to be ascertained, instead being grateful that data is available at all. Thus, we believe that through the wide use of the O&M model, we can allow for well-structured provision of both data as we wish it to be, following the agreed methods and procedures, as well as other available data, whereby derivations from the agreed methods and procedures can be properly documented.

Once the GloSIS model was finalised and implemented as a UML model (as mentioned above), the final ontology was generated in two major steps: first the UML model was transformed into an OWL ontology, and then the output was aligned with SOSA/SSN and O&M. Based on the acquired knowledge and previous experience (e.g., FOODIE project), a semi-automatic transformation process was carried out with the help of the ShapeChange tool.⁹ ShapeChange enables the generation of an ontology following the ISO/IS 19150-2 standard, which defines rules for mapping ISO geographic information from UML models to OWL ontologies.

The output ontology generated by ShapeChange provided a good starting point to produce the final GloSIS web ontology, but it required substantial post-processing tasks, as described in the following sections.

3.3.1. Reusing and Reengineering Non-Ontological Resources

The GloSIS UML model,¹⁰ was released as an Enterprise Architect project.¹¹ The project had to be modified before a successful transformation using ShapeChange could be carried out. In particular, it was necessary to add an ApplicationSchema in the Stereotype of each package and assign the targetNamespace property to the GloSIS namespace: https://w3id.org/glosis/model . This change was applied to all GloSIS packages, namely: CodeLists, General, Layer-Horizon, Observation, Profile, Site-Plot, and Surface, and thereafter they were saved as XMI 1.0 (XML Metadata Interchange).¹² The model complexity required publishing each package to a separate XMI 1.0 file.

The next step required providing missing DataTypes information manually, such as:

–
OM_CategoryObservation,
–
OM_Measurement,
–
OM_TruthObservation,
–
OM_ComplexObservation,
–
CharacterString.

The primary mechanism for providing arguments to ShapeChange is the configuration file. The GloSIS implementation re-used the default configuration provided with ShapeChange for testing purposes.¹³ The vanilla configuration file had to be adjusted for GloSIS transformation needs. Some of the most notable modifications included: –
Removing inputs=“TRF” from <TargetOwl> node, as no transformer was used.
–
Adjusting URIbase value.
–
Adding source targetParameter.
–
Adding namespaces of additional vocabularies used in the customised transformation rules, such as¹⁴ : ssn, sosa, lcc-cr, iso19115-1, qudt, and foaf.
–
Introducing some additional mapping rules: 1.
OM_CategoryObservation $\to$ sosa:ObservableProperty
2.
OM_Measurement $\to$ sosa:Observation
3.
CountryCodeValue $\to$ lcc-cr:Alpha2Code
4.
DQ_PositionalAccuracy $\to$ ssn:Property
5.
CI_ResponsibleParty $\to$ foaf:Agent
6.
TM_Instant $\to$ xsd:dateTime

–
Introducing some new encoding rules.

Once the configuration was completed, the transformation was carried out by invoking the ShapeChange processor in the command line with the customised config file as an input.

The crude result of the transformation contained all container classes from the UML model (see Figure 2) represented as subclasses of gsp:Feature and their relationship to spatial data types. Alongside were the properties in the container classes, also known as container types, which were identified by the name of the container class and the name of the property separated by a dot, for example, the property surfaceAge in the container class LandFormInfo is identified as “LandFormInfo.surfaceAge.” All container types were modelled as Object Properties (see Listing 1) with inchoate and shallow connections to the SOSA/SSN taxonomy.
Figure 2.
Plot Spatial Object Type Overview, Where Green Boxes Refer to Container Classes, Dark Grey to ISO28258 Spatial Object Types and Light Grey to GloSIS Spatial Object Types (Full Size Diagram Available at: https://github.com/glosis-ld/glosis/wiki/Full-resolution-images).

After the transformation, the spatial object types were represented as subclasses of gsp:Feature (see Listing 2) and connections between those classes and container classes were represented as object properties with range and domain (see Listing 3).

3.3.2. Reusing Ontological Resources

SOSA/SSN is a lightweight but self-contained core ontology. It has already been used in GloSIS as the base model to represent observations. Nonetheless, various DataType elements present in the UML representation required a more complex approach.

The post-processing part required cleaning the ontology at first. Namely, removing container classes alongside the pointers between them and spatial object types. Secondly, the development of object properties while aligning them to SOSA/SSN, considering their data type. The latter was a complex task that is presented with regard to DataType elements. CharacterString was the simplest of these. All container types that were associated with it were modelled as owl:DataTypeProperty, with a range of simple string and literal definitions (see Listing 4).

There was considerably more variability with post-processing various observation types and measurements. All of them were represented as subclasses of sosa:Observation (see Listing 5).

Moreover, they were restricted by constraining the various owl properties. A feature of interest restriction was applied uniformly across all observations, connecting them to the spatial object type(s) (see Listing 6).

The result restriction is represented differently depending on the type. The string is represented with sosa:hasSimpleResult (see Listing 7).

In the case of the result being an auxiliary class containing a code-list, the model would incorporate sosa:hasResult instead. The code-list class is referenced with the owl:someValuesFrom object property, leaving observation instances open to use with other code-lists (see Listing 8). This is one of the flexibility mechanisms allowing data providers to exchange controlled content that may not feature directly in the ontology.

Numerical results requiring restrictions such as units of measure (mostly those related to physico-chemical observations) leverage the QUDT ontology. In particular, sub-classes of qudt:QuantityValue provide the hook for these restrictions (see Listing 9).

Each code-list is modelled using a class and a concept scheme. The concept scheme is defined as an individual of type skos:ConceptScheme, while the class is defined as a subclass of skos:Concept (see Listing 10). Both elements are pointing to each other via rdfs:seeAlso object property. Then, each code-list value is modelled as an individual of the defined class and skos:Concept, and in the scheme of the associated ConceptScheme individual. Furthermore, the class includes an enumeration of all the code-list value individuals as a Collection.¹⁵

In order to facilitate the reuse, extension, and maintenance, code lists were modelled in a separate module.

If the result is a numerical value, the model uses the sosa:hasResult restriction, similar to the code-list approach (see Listing 11). The auxiliary class that we link to the observation represents a numeric value type (integer, float, boolean). The class itself is defined as a subclass of qudt:QuantityValue, and it is restricted by constraining the properties qudt:numericValue and qudt:unit to a particular numeric type (e.g., xsd:integer) and unit of measurement (e.g., per cent), respectively.

Finally, the last restriction is linking the observation with the observed soil property, defined as an instance of sosa:ObservableProperty (see Listing 12).

There are a few cases where sosa:observedProperty links the observation with a code-list (see Listing 13).

In those cases, the code-list for the observed soil property is created based on the same approach as the one presented for the result. The only difference is that the class representing the corresponding code-list is also defined as a subclass of sosa:ObservableProperty.

The transformation performed by ShapeChange resulted in spatial object types being represented only as subclasses of geosparql Feature¹⁶ (see Listing 2). One of the post-processing goals was to enrich these classes and remove redundant connections between spatial object types and container classes (see Listing 3). To achieve that, the spatial object types were then aligned with the ISO 28258 standard. As there is no web ontology available for such a standard, an additional module for modelling the relevant parts of this standard was created manually. All properties directly associated with the spatial object types were captured as data type or object type properties and restricted with range and cardinality (see Listing 14).

3.3.3. Introduction of Procedure Code-Lists

A long-standing issue in the semantics of soil science is the conflation of soil properties and laboratory analysis concepts. Ad hoc soil datasets often commingle in a single item the soil property, the laboratory process used to assess it, and, on occasion, even the units of measure. The OGC SoilIE (OGC 16-088r1, 2016) identified this as a major hindrance to the correct exchange of soil information. Some of the soil properties inventoried in the GloSIS domain model yielded this problem.

In order to address this and further exemplify the rich use of the resulting GloSIS web ontology, a thorough inventory of physico-chemical analysis processes was gathered. The primary source of this inventory was the Africa Soil Profiles Database (Leenaars et al., 2014), with further insight gathered from the WoSIS database and procedures manual (Batjes et al., 2024). This information was gathered in a simple spreadsheet, adding also bibliographic references and existing online resources detailing each laboratory process.

A small transformation was created to produce a new module in the GloSIS web ontology from the spreadsheet described above, following on the framework applied with the ShapeChange transformation and making use of the SOSA/SSN and SKOS Web ontologies. Each laboratory process is expressed both as an instance of sosa:Procedure and of skos:Concept. The SKOS ontology is employed not only to formalise the description of the procedure, but also to build a hierarchical structure between less or more detailed laboratory methods (applying the skos:broader and skos:narrower predicates). Listing 15 provides an example with a classical laboratory process to assess total nitrogen content in the soil. The SOSA/SSN ontology provided the means to relate procedures with soil properties, through the enrichment of sosa:Observation classes with sosa:usedProcedure object properties. As in the case of controlled code-lists, the ranges of these object properties are left open to alternative use with owl:someValuesFrom predicates. The diagram in Figure 3 presents these relationships in visual form.

Figure 3.

Schematics of a GloSIS Observation. Blue: GloSIS Classes; Orange: External Classes; Yellow: GloSIS Instances.

3.4. Ontology Overview

Considering readability and having in mind the best software development practices (e.g., “Do not Repeat Yourself”), the ontology was implemented following a modular approach as a networked ontology, facilitating its reusability, extensibility, and maintainability. For instance, all code-lists were implemented within the “code-list” module and observations referenced across multiple modules were moved into a separate module called the “common module.” Additionally, as mentioned above, one of the most crucial aspects of post-processing was to align all the spatial object types with the ISO 28258 standard. That task was far from straightforward, since there is no existing ontology for this standard that could be used as a reference. Therefore, the “iso28258” module was created to introduce ISO features that were indispensable for connecting the GloSIS web ontology with an ISO 28258 standard. For this task, it was necessary to rely on the documentation of the standard. Additionally, this module includes alignment between elements in different ISO standards and other ontologies relevant to GloSIS. Some of these alignments include the definition of the following classes to be equivalent:

The GloSIS classes are connected to the “iso28258” module and other ISO classes through inheritance as depicted in Figure 4.

Figure 4.

GloSIS Web Ontology – Connection Between Spatial Object Types and ISO 28258.

There are a few important notes that complement the depicted diagram. First, iso19156_GFI:GFI_Feature is an equivalent of gsp:Feature. Secondly, sosa:FeatureOfInterest inherits from iso19156_GFI:GFI_DomainFeature. Finally, the alignment between the SOSA/SSN ontology and ISO 19156: sosa:Sample is equivalent to iso19156_SF:SF_SamplingFeature, and sosa:Observation corresponds to iso19156_OB:OM_Observation. Those alignments are explicitly stated in the “iso28258” ontology module.

3.4.1. Ontology Modules

The current version of the ontology consists of 12 modules. This modular approach allows for the introduction of new extensions and modules whenever they are needed. Contents of the ontology (release v1.5.1):

–
glosis_main: master module that imports all the components, making the ontology simpler to use.
–
iso28258: contains all ISO 28258 elements necessary to represent GloSIS, along with the mappings between ISO ontologies, SOSA/SSN, and GeoSPARQL.
–
glosis_layer_horizon: contains all classes and properties to describe the domain of soil with a certain vertical extension, which is a layer (developed through non-pedogenic processes, displaying an unconformity to possibly over- or underlying adjacent domains) or a horizon (more or less parallel to the surface and is homogeneous for most morphological and analytical characteristics, developed in a parent material through pedogenic processes or made up of in situ sedimented organic residues of up-growing plants (peat)).
–
glosis_siteplot: contains the classes and properties to describe soil sites (a defined area which is subject to a soil quality investigation) and soil plots (an elementary area where individual observations are made and/or samples are taken).
–
glosis_profile: contains the classes and properties to describe a soil profile, which is a describable representation of the soil that is characterised by a vertical succession of horizons or at least one or several parent material layers. Soil profile is an ordered set of soil horizons and/or layers.
–
glosis_surface: contains the classes and properties to describe soil surfaces (a subtype of a plot with surface shape. Surfaces may be located within other surfaces).
–
glosis_observation: contains the spatial object type to describe the observation process, which is a subtype of OM_Process, and it is used to generate the result of the observation.
–
glosis_procedure: contains the code-lists identifying laboratory processes employed to assess physico-chemical soil properties.
–
glosis_common: contains all classes and properties that are used among multiple modules.
–
glosis_cl: contains all the code-lists.
–
glosis_unit: module that introduces additional units of measurement that are absent from the QUDT ontology.

3.4.2. Use of Permanent Identifiers

In line with best practices, the GloSIS web ontology has been implemented and released using persistent and resolvable identifiers, allowing access to the ontology on the Web via its URI and ensuring the sustainability of the ontology over time. In particular, the W3ID service for persistent identifiers has been used. The service supports content negotiation, for example, to retrieve an HTML page with the ontology documentation or the ontology source in some RDF serialisation format (e.g., Turtle and RDF/XML), depending on the client.

The base URI of the GloSIS web ontology is https://w3id.org/glosis/model . When accessed from a web browser, this URI redirects to the GloSIS documentation entry page; otherwise, it redirects to the GloSIS main module source in RDF Turtle serialisation format, which is the only one needed to load the full ontology in an application or ontology editor. Similarly, each individual module is accessible via permanent URIs in the form: https://w3id.org/glosis/model/{module_name}, which redirect the client to the ontology module documentation page or to the ontology module source in RDF, depending on the client. Furthermore, the ontology terms are also resolvable and, except for the code-list terms, their URIs redirect to the term section in the corresponding module documentation page, or to the corresponding ontology module source in RDF, depending on the client. Regarding the GloSIS code-lists (concept schemes), in collaboration with the OGC, they have been uploaded and made available via the OGC Rainbow service (also known as definition server). Hence, the URIs of code-lists and their concepts redirect to their definition in the OGC server (e.g., http://w3id.org/glosis/model/codelists/physioChemicalPropertyCode-pH ).

3.4.3. Documentation

The various modules of the GloSIS web ontology are documented with a series of HTML pages automatically generated by the Wizard for Documenting Ontologies (WIDOCO; Garijo, 2017). Written in Java, this software is able to inspect a Web ontology and generate human-friendly documentation for all its classes, data types, and data properties, in a well-organised structure. The output documents apply internal HTML links to facilitate navigation among the different sections. It also integrates with WebVOWL (Lohmann et al., 2014) for automatic diagram generation.

WIDOCO is also able to extract some metadata from the ontology, in order to document its authorship, provenance, and licensing. However, it is not able to fully process predicates from the multiple metadata ontologies in use today (Doublin Core, VCard, Schema.org, etc.). Instead, WIDOCO makes available a configuration file in which metadata can be declared to be included at generation time. This configuration file contains important metadata such as authors, contributors, and their respective affiliations. Considering the number and varied nature of modules in the GloSIS web ontology, it was deemed impractical to maintain a WIDOCO configuration file for each. Such practice would lead to redundancy with the metadata triples already included in the ontology modules themselves.

A small program was developed to address the issue above. It inspects the metadata triples declared in an ontology module and then produces a specific configuration file for WIDOCO. This program, included in the GloSIS repository,¹⁷ is able to identify various predicates from the Dublin Core Terms ontology, plus schema:affiliation and foaf:name. Documenting GloSIS thus becomes a two-step process: first, generate the metadata configuration for WIDOCO and then generate the final HTML documents with WIDOCO itself.

This HTML documentation¹⁸ is also accessible through the W3ID dereferencing mechanism (opening the base ontology URI from a web browser). Making use of content negotiation mappings, the user is presented with the HTML documentation when accessing GloSIS resources directly with a web browser. Otherwise, application access to GloSIS returns the ontology RDF documents.

3.5. Maintenance

GloSIS uses semantic versioning¹⁹ to denote code changes. This means that version numbers have meanings. The goal is to communicate to the user what can be expected from the changes that were made. The general convention looks as follows: MAJOR.MINOR.MICRO Incrementing the MICRO number means that some bugs were fixed, but there are no additional concepts, and the existing ontology should still work without changes.

Incrementing the MINOR number means that there are some new concepts introduced, or perhaps there was an extension of an existing one.

Finally, incrementing the MAJOR means that the project was updated with significant changes, perhaps a new module was introduced, or there were other major changes in class relationships.

Besides versioning, GloSIS also has releases. Each release presents updated code that is usable and tested. The GloSIS repository does have a simple utility Python tool to update the version together with the version IRI for each module.

Furthermore, the GloSIS repository also includes two automation tools enabling the transformation from CSV files to OWL ontology and vice versa. These tools simplify the maintenance of code lists, which are available as CSV to enable experts to contribute more easily. For more information, please refer to the project repository wiki.²⁰

4. Applications of the Ontology

This section showcases the use of the GloSIS web ontology to represent and query some exemplary soil datasets. First, this section shows the applicability of the ontology by using it to publish widely known open datasets from Europe and beyond as Linked Data, which are publicly available via the FOODIE endpoint.²¹ The generation and publication of the linked datasets was carried out using a Linked Data Pipelines tool, developed in the context of different projects (e.g., SIEUSOIL, DEMETER, and OPEN IACS), which enables the fetching, preparation, transformation, integration, and publication of linked data in a triplestore.²² In short, the tool requires a mapping configuration file that specifies how the elements in the source dataset should be transformed to elements in the target ontology (in this case, GloSIS). For further information about the tool, please refer to its repository on GitHub. Next, this section presents some examples for data retrieval using SPARQL queries over data generated and stored based on the GloSIS web ontology. These queries show not only how to retrieve data from the original sources, but also how to exploit the linked data. Finally, this section introduces a semantic REST API that is built on top of the GloSIS web ontology and facilitates data exploration. This API allows for different applications to consume easily linked data, without the need to know SPARQL, RDF, and other semantic technologies.

4.1. LUCAS 2015 Topsoil Dataset

The LUCAS Programme is an area frame statistical survey organised and managed by Eurostat (the Statistical Office of the EU) to monitor changes in land use and land cover over time across the EU (Jones et al., 2020). Since 2006, Eurostat has carried out LUCAS surveys every three years. The surveys are based on the visual assessment of environmental and structural elements of the landscape in georeferenced control points. The points belong to the intersections of a $2 \times 2$ km regular grid covering the territory of the EU. This results in around 1 million georeferenced points. In every survey, a subsample of these points is selected for the collection of field-based information.

In 2015, the LUCAS survey was carried out in all EU-28 Member States. In total, 27,069 locations were selected for sampling. Samples were eventually collected from 23,902 locations, of which 22,631 were in the EU. Soil samples were collected from a depth of 20 cm following a common sampling procedure. After the removal of samples that could not be identified, the LUCAS 2015 Soil dataset has 21,859 unique records with soil and agro-environmental data.

The dataset includes the identification code Point_ID of the samples and data of physical and chemical properties for each sample. These properties include: Coarse fragments, clay, silt, sand, pH in CaCl $_{2}$ and in H $_{2}$ O, electrical conductivity, organic carbon, carbonates, phosphorus, total nitrogen, and extractable potassium. Furthermore, each sample includes the elevation at which the soil sample was taken, the land cover class, the land use class, and the NUTS codes (levels 0, 1, 2, and 3) for the country and the location where the sample was taken. The complete LUCAS topsoil 2015 dataset was transformed into Linked Data and is also available at the FOODIE endpoint, within a knowledge graph with the URI (http://w3id.org/glosis/open/LUCAS/topsoildata/). Note that the graph URI does not resolve; it is just the identifier of the graph in the triplestore. However, for the purpose of visualising the data, the Virtuoso triplestore faceted browser²³ can be used, for example, to display the observations made by a LUCAS Topsoil Surveyor.²⁴

The following listings present one sample of the dataset represented according to the GloSIS web ontology. Listing 16 presents the Site instance and its geolocation, representing the location where the sample was collected.

Listing 17 presents the profile and profile element (layer) instance associated with the site.

Listing 18 presents an observation instance associated with the site.

Listing 19 presents two of the observation instances associated with the layer.

4.2. Soil Respiration Database (SRDB)

The Global SRDB is a compilation of field-measured soil respiration (RS, the soil-to-atmosphere CO $_{2}$ flux) observations. Originally created over a decade ago, its latest version (V5) (Jian et al., 2021) has restructured and updated the global RS database, including new fields to include ancillary information (e.g., RS measurement time, collar insertion depth, and collar area). The updated SRDB-V5 aims to be a data framework for the scientific community to share seasonal to annual field RS measurements, and it provides opportunities for the biogeochemistry community to better understand the spatial and temporal variability in RS, its components, and the overall carbon cycle. The database is publicly available with detailed documentation.²⁵

Each record in the database includes fields regarding the record metadata, site data, measurement data, annual and seasonal RS fluxes, and ancillary pools and fluxes. For this transformation, we used only a subset of the site data fields, including latitude, longitude, elevation, soil bulk density, sand ratio value, silt ratio value, and clay ratio value. The SRDB subset was transformed into linked data and is also available at the FOODIE endpoint, within the knowledge graph with the URI (http://w3id.org/glosis/open/srdb/). Note that the graph URI does not resolve; it is just the identifier of the graph in the triplestore. However, for the purpose of visualising the data, the Virtuoso triplestore faceted browser²⁶ can be used, for example, to display SRDB observations regarding soil type.²⁷

The following listings present one sample record of the SRDB dataset represented according to the GloSIS web ontology. Listing 16 presents the site instance and its geolocation, representing the location of the sample.

Listing 17 presents the profile and profile element (layer) instance associated with the site.

Listing 22 presents a few observation instances associated with the soil layer.

4.3. The WoSIS RDF Service

The WoSIS is the result of a decade’s effort towards a harmonised soil observation dataset at the global scale (Batjes et al., 2024). WoSIS has at its core a relational database containing information on more than 200,000 geo-referenced soil profiles, originating from 180 different countries. The number of individual soil horizons characterised in this database borders on 900,000, for which almost 6 million individual observation results are recorded. Source datasets are subject to a process of rigorous quality control and harmonisation in order to be added, resulting in a globally consistent dataset, directed at digital soil mapping and environmental application at large scales.

A pilot was conducted to set up a GloSIS-compliant RDF service with WoSIS as a data source. This pilot considered, in the first place, ontological alignment. The WoSIS data model follows a substantially different pattern from those found in soil ontologies (vide Section 2). For instance, WoSIS does not sport an entity ontologically similar to the GL_Plot class, whereas its profile entity, a handle for the geo-location of a soil investigation, is closer to GL_Site than GL_Profile. The WoSIS data model is also foreign to the O&M pattern, including an attribute entity that can correspond to both the ObservableProperty and Procedure classes in SOSA/SSN. These ontological differences required an ad hoc alignment, mapping individual WoSIS attributes to specific GloSIS properties, observations, and procedures.

These mappings were encoded in the external schema of the WoSIS relational database as a set of views. These views also perform a transformation to RDF, producing triples expressed in the Turtle language. Listing 23 provides a snippet of one of these views, creating instances of the GL_Profile class. The database primary keys are used to compose a URI for each instance, the PostGIS function ST_AsText is used to obtain the Well-Known Text (WKT) literal matching the GeoSPARQL hasGeometry object property. Listing 24 shows a sample output of this view, including the Turtle URI abbreviations. Similar views were created to produce RDF for soil layers, soil properties, observations, procedures, and results.

Metadata was added with predicates from the Dublin Core, VCard, and DCat web ontologies.

A set of triples produced by these RDF transformation views was deployed to the Virtuoso triplestore, accessible through a SPARQL endpoint²⁸ and the Virtuoso Faceted Browser.²⁹ This pilot RDF service showcases the transformation of a traditional soil observation dataset into a GloSIS-compliant knowledge graph. It exemplifies the geo-location of soil profiles with GeoSPARQL, their composition with soil horizons and respective characterisation with observations of physico-chemical properties.

4.4. Data Discovery and Access

This section presents two different approaches to discover and access data represented according to the GloSIS web ontology (from the examples presented in the previous sections). First, the section introduces a set of exemplary SPARQL/GeoSPARQL queries that provide guidance on the interaction with a triplestore serving GloSIS-compliant linked data. Then, the section presents an example REST API that allows simplified programmatic access to such data, abstracting all the details on how data is represented or how to interact with semantic data via SPARQL queries.

A key advantage of producing and publishing GloSIS-compliant linked data is the possibility to access soil-related data from different sources in an integrated manner, as well as to discover and establish links between them, and with other relevant open datasets available in the Linked Open Data (LOD) cloud, for example, FADN, NUTS, AGROVOC, etc.

4.4.1. SPARQL Queries

The GloSIS repository wiki includes four exemplary queries, which can be tried out against the LUCAS dataset described in Section 4.1.

The first query³⁰ retrieves the average value for the total nitrogen soil property in the top soil of a certain spatial area. Starting from the glosis_lh:NitrogenTotal observation, the query identifies the related result, layer, soil profile, and respective geometries. FILTER clauses are then used to restrain the selection to soil layers above 30 cm depth that are part of profiles within a geodesic bounding box. Finally, the AVG operator is employed to obtain the average nitrogen value.

The second query³¹ exemplifies the benefits of linked data, and the rich axiomatisation of the GloSIS web ontology. The query retrieves the average value for the pH soil property, measured using a specific procedure in the topsoil of a certain NUTS region. Similar to the previous query, it starts by retrieving the values of PH observations (glosis_lh:PH), but it retrieves only those measured using a specific procedure, namely in a soil/water solution (glosis_proc:pHProcedure-pHH2O). Then, the query retrieves the site location where the observations were measured, and filters the result to include only those taken in Poland. The last part requires retrieving first, in a subquery, the geometry of Poland from the NUTS dataset.

The third query³² exemplifies the benefits of code lists and semantic inferencing. The query retrieves the total number of survey points (from LUCAS) over land use with specific type/supertype (e.g., PRIMARY SECTOR) that have nitrogen total higher than a certain threshold (e.g, 2). The query leverages the taxonomic relationships in the code list for land use (used in LUCAS) to retrieve observations with land use type at any level under the one specified by the user.

Finally, the fourth query³³ exemplifies even further the benefits of linked data, and particularly how the GloSIS web ontology provides the basis to enable an integrated access to multiple soil data sources available in different triplestores. The federated query retrieves NitrogenTotal observations, which have a value over the specified threshold, from two different endpoints (FOODIE and ISRIC), and returns them in an integrated result set.

4.4.2. Semantic REST API

Although the native language to access the RDF data generated based on the model is SPARQL, in order to facilitate the access and consumption of data by potential services/applications, a REST API is created. The REST API returns simple JSON data, which is one of the most popular formats used by Web services to produce/consume data. The API is implemented using GRLC³⁴ that translates SPARQL queries stored in a Git repository³⁵ to a REST API on the fly.

Hence, using as a starting point, the SPARQL from the previous section, we created the following API methods:

–
/avg_nitro_for_geo – retrieves the average NitrogenTotal value in a specific geospatial region. The input parameter is the geospatial region of interest, expressed in WKT OGC standard format.
–
/avg_physioChemical_property_for_NUTS – retrieves the average value for a specified physioChemical soil property, in a specified NUTS region code. The input parameters are the NUTS code (e.g., PL, PL41, LT, and NO) and the physioChemical soil property, which can be selected from the predefined list of possible types coming from the GloSIS web ontology.
–
/avg_physioChemical_property_for_geo – same as the previous endpoint, but instead of having as input a NUTS region code, it expects the geospatial region of interest, expressed in WKT format.
–
/avg_physioChemical_property_procedure_for_NUTS – retrieves the average value for a specified physioChemical soil property, measured using a specified procedure, in a specified NUTS region code. The input parameters are the NUTS code, the physioChemical soil property, which can be selected from the predefined list of possible types coming from the GloSIS web ontology, and the procedure used for the measurement. This procedure also comes from the GloSIS web ontology, and the available options can be retrieved using the physioChemical_procedures method.
–
/federated_soil_observations_for_property – retrieve observations for a specified physioChemical soil property that have a value over a specified threshold (e.g., 2) from multiple data sources (foodie and isric). The input parameters are the threshold number and the physioChemical soil property, which can be selected from the predefined list of possible types coming from the GloSIS web ontology.
–
/physioChemical_procedures – retrieves the procedures available in the GloSIS ontology for a specified physioChemical soil property. The input is the physioChemical soil property, which can be selected from the predefined list of possible types coming from the GloSIS web ontology.
–
/total_survey_points_lu_prop_value – retrieves the total number of survey points, for a specified physioChemical soil property with value over a specified threshold (e.g., 2), measured in a land use of specified type (e.g., AGRICULTURE, FORESTRY, “PRIMARY SECTOR,” etc.).

5. Future Work

5.1. Ontological Extensions

As it stands, the ontology currently spans soil data exchange in the same breadth as previous initiatives. The focus rests primarily with soil investigations conducted on the field, including the collection of physical samples later to be analysed with wet chemistry methods in a laboratory. There are, though, advancements in the domain that beg for consideration in a soil data ontology.

Modern instruments allow the collection of high-resolution reflectance spectra from soil samples, an activity known as soil proximal sensing. From these spectra, estimates of physico-chemical properties can be obtained by statistical models, with relatively high accuracy (Viscarra Rossel et al., 2011). Soil spectroscopy instruments are also becoming increasingly relevant in field work, avoiding expensive activities of sample transport and laboratory analysis (Chang et al., 2001). The SOSA ontology already contains assets (such as the Instrument class) providing a base framework to extend the GloSIS web ontology to proximal sensing. But further investigation is necessary on how best to encode reflectance spectra in a Semantic Web paradigm and reference statistical models.

Another field under active research is the estimation and inventory of measurement uncertainty. Such information is traditionally absent from soil data sources, even though uncertainties stemming from field work and laboratory procedures are known to be relevant (Libohova et al., 2019). In downstream activities relying heavily on soil data, such as digital soil mapping, and further into decision support, measurement uncertainty is capital in conveying an accurate characterisation and fidelity of resulting products. Since neither O&M nor SOSA consider measurement uncertainty, this remains an open field of research.

Finally, a note on soil classification systems. The GloSIS web ontology proposes a completely liberal approach, providing simple text data properties without supporting controlled content. The user can therefore use any classification system and even combine various systems. While there are merits to this approach, an alternative pattern with controlled content can be argued for. The World Resource Base of soil resources (WRB) would be the obvious choice for such content, as the only soil classification/description system developed for the world as a whole. However, the WRB system poses its own set of challenges. On overage, it is updated every 5 years, without backwards compatibility. Therefore, a soil classified as Vertisol in the 2015 edition might be in a different class in the 2014 edition, yet another still in the 2007 edition and so forth. The INSPIRE Soil Theme opted for the 2007 edition of the WRB (currently legally binding), essentially deterring classification with later versions. In order for a system such as the WRB to be adopted as controlled content, a different evolution paradigm is necessary, taking into account the requirements of digital data exchange. Engagement with the WRB work group of the IUSS towards this end is indispensable.

5.2. Operational Improvements

A future goal is to use the transformer tool as a component in continuous integration (CI) and continuous delivery (CD). That would allow us to automatically re-generate and deploy a new version of the ontology each time a change to the code-lists or procedures is recorded in the supporting spreadsheets. This future improvement can also include automation of other modules, which would allow making changes to the whole ontology content by contributors not familiar with RDF languages.

Also facilitating the use of the ontology is the setup of an online browsing service. This can be particularly worthwhile for the use of code-lists, which are somewhat extensive. Since code-lists are encoded with SKOS, some obvious options open in this regard. SKOSMOS (Suominen et al., 2015) is a web application for the publication of controlled vocabularies based on SKOS, providing powerful navigation functionalities. An alternative is the ONKI web service (Tuominen et al., 2009), a large platform that allows free upload of SKOS-based vocabularies. ONKI automatically provides APIs and web widgets for the resources uploaded.

5.3. Human Factors and Education

The GloSIS web ontology is one further step in a long lineage of soil ontologies. While it presents clear advances in content and format (not the least by embracing the Semantic Web), by themselves, these do not guarantee its complete success. Previous efforts did not always manage to fully engage the soil data provision community, and those that did so were invariably legally enforced. It is therefore capital to keep human factors of ontology use in consideration.

The CI/CD mechanism described above is one step in that direction, by facilitating the dialogue between computer scientists and soil scientists (likely unfamiliar with the innards of the Semantic Web). Providing a simple file format mirroring the actual ontology can be critical to engage and involve domain experts.

To further facilitate engagement with the wider community of soil scientists and soil data provision institutions, the establishment of an “Ontology Steering Committee” can be decisive. This body could mirror the governance paradigm employed in Open Source projects (German, 2003; Riehle, 2011), an assembly of computer scientists and soil scientists collectively guiding ontology development. The actual structure and rules of such a body are beyond the scope of this manuscript; however, other concepts from the Open Source community, such as “Request For Change” (Canfora & Cerulo, 2005), can provide the necessary templates. Towards this end, engagement with organisations such as the Soil Standards Working Group of the IUSS, or the Soil Ontology and Informatics Cluster of ESIP³⁶ can be paramount

Daniel (2019) points to ontology as one of the remaining gaps in data science research and education. Its absence is understood to compromise most stages of the research process, starting with data collection and on to the rigour of the outcome. However, ontologies and the Semantic Web in general have already been applied in the educational context to a large swathe of domains (Jensen, 2019). The introduction of soil ontology to soil science and soil data curricula appears therefore, as a natural development. With its extensive code-lists and standards-based lineage, GloSIS is a strong candidate for practical application in education. Such development would not only render the use of ontologies commonplace, but also train a new generation of soil scientists themselves capable of evolving ontology in their domain.

Glossary

–

Domain model: a formal representation of a knowledge domain with concepts, relationships, data types, individuals, rules, and in some cases behaviour. A domain model is usually expressed through a modelling or knowledge representation language such as UML or OWL.

–

Data model: an abstraction meant to structure data. It uses formalisations such as objects, relations, entities, attributes, or tables. A data model is often a logical or physical implementation of a domain model. The term “logical domain model” is used to signify a semantic data representation, akin to the “domain model” concept.

–

Ontology: sub-discipline of metaphysics concerned with existence and the nature of reality.

–

ontology: an abstract asset created by applying ontology principles to a computer or information science context. A formal representation and definition of the categories, properties, and relations that substantiate a domain of discourse.

–

Web ontology: a domain model expressed with Semantic Web standards, particularly the OWL.

–

FeatureOfInterest: A concept common to O&M and SOSA, representing a thing whose property is being estimated or calculated in the course of an observation to arrive at a result.

–

SamplingFeature: A core concept of O&M, acknowledging the common need to sample the ultimate feature of interest before a measurement can be obtained. Measuring station, specimen, transect, and section are examples of sampling features.

–

Sample: A concept found in SOSA and other standards representing a subset or an extract from a feature of interest on which an observation is performed. Typically necessary when observations of the feature of interest in situ are not possible.

–

Spatial data type: a data type expressed with geographic or cartographic coordinates, meant to represent points, lines or areas on the surface of the Earth.

–

Spatial object: a physical or concrete entity that may be sited (or at least delimited) on the surface of the Earth.

–

Spatial object type: class of spatial objects having common characteristics. It may also be referred to as a spatial object class.

Footnotes

Acknowledgements

The work in this paper has been supported by and partially carried out in the scope of the SIEUSOIL and EJP SOIL projects and by ISRIC – World Soil Information. EJP SOIL and SIEUSOIL has received funding from the European Union’s Horizon 2020 research and innovation programme. The EJP SOIL Grant agreement No is 862695, the SIEUSOIL Grant agreement No is 818346. ISRIC – World Soil Information supports the soil community with soil, soil data, soil data exchange standard development to support soil data, information and knowledge provisioning at global, national and sub-national levels for application into sustainable management of soil and land.

Funding

The authors disclosed receipt of the following financial support for the research, authorship, and/or publication of this article: The work in this paper has been supported by and partially carried out in the scope of the SIEUSOIL and EJP SOIL projects and by ISRIC – World Soil Information. EJP SOIL and SIEUSOIL have received funding from the European Union’s Horizon 2020 research and innovation programme. The EJP SOIL Grant agreement No is 862695, the SIEUSOIL Grant agreement No is 818346. ISRIC – World Soil Information supports the soil community with soil, soil data, soil data exchange standard development to support soil data, information and knowledge provisioning at global, national and sub-national levels for application into sustainable management of soil and land.

Declaration of Conflicting Interests

The authors declared no potential conflicts of interest with respect to the research, authorship and/or publication of this article.

Notes

References

Banwart

Black

Cai

Gicheru

Joosten

Victoria

Milne

Noellemeyer

Pascual

Nziguheba

Vargas

Bationo

Buschiazzo

de Brogniez

Melillo

Richter

Termansen

van Noordwijk

Goverse

, …, Montanarella

(2014). Benefits of soil carbon: Report on the outcomes of an international scientific committee on problems of the environment rapid assessment workshop. Carbon Management, 5(2), 185–192. https://doi.org/10.1080/17583004.2014.913380

Barnes

(2015). Aichi targets: Protect biodiversity, not just area. Nature, 526(7572), 195–195. https://doi.org/10.1038/526195e

Batjes

N. H.

Calisto

de Sousa

L. M.

(2024). Providing quality-assessed and standardised soil data to support global mapping and modelling (WOSIS snapshot 2023). Earth System Science Data, 16(10), 4735–4765. https://doi.org/10.5194/essd-16-4735-2024, 2024

Batjes

Kempen

van Egmond

(2019). Tier 1 and Tier 2 data in the context of the federated global soil information system (GLOSIS). Technical report 2019/01. ISRIC – World Soil Information. https://doi.org/10.17027/isric-dcmkd4-g431

Borrelli

Robinson

D. A.

Fleischer

L. R.

Lugato

Ballabio

Alewell

Meusburger

Modugno

Schütt

Ferro

Bagarello

Oost

K. V.

Montanarella

Panagos

(2017). An assessment of the global impact of 21st century land use change on soil erosion. Nature Communications, 8(1), 2013. https://doi.org/10.1038/s41467-017-02142-7

Bouma

(2015). Engaging soil science in transdisciplinary research facing “wicked” problems in the information society. Soil Science Society of America Journal, 79(2), 454–458. https://doi.org/10.2136/sssaj2014.11.0470

Canfora

Cerulo

(2005). Impact analysis by mining software and change request repositories. In 11th IEEE international software metrics symposium (METRICS’05) (pp. 9–29). IEEE. https://doi.org/10.1109/METRICS.2005.28

Chang

C. W.

Laird

D. A.

Mausbach

M. J.

Hurburgh

C. R.

(2001). Near-infrared reflectance spectroscopy–principal components regression analyses of soil properties. Soil Science Society of America Journal, 65(2), 480–490. http://dx.doi.org/10.2136/sssaj2001.652480x

Cox

(2011a). Observations and measurements-xml implementation. Version 2.0. Technical report. https://portal.ogc.org/files/?artifact_id=41510

10.

Cox

(2011b). OGC abstract specification geographic information – observations and measurements. Technical report, Open Geospatial Consortium. https://doi.org/10.13140/2.1.1142.3042

11.

Daniel

B. K.

(2019). Big data and data science: A critical review of issues for educational research. British Journal of Educational Technology, 50(1), 101–113. https://doi.org/10.1111/bjet.12595

12.

Desa

(2018). World urbanization prospects 2018. United Nations Department for Economic and Social Affiars. https://www.un.org/development/desa/pd/news/world-urbanization-prospects-2018

13.

FAO and ITPS (2015). Status of the world’s soil resources (SWSR) – main report. Food and Agriculture Organization of the United Nations and Intergovernmental Technical Panel on Soils. http://www.fao.org/3/a-i5199e.pdf

14.

FAO, IFAD, UNICEF, WFP & WHO (2018). The state of food security and nutrition in the world 2018. Building climate resilience for food security and nutrition. Report. FAO. http://www.fao.org/3/I9553EN/i9553en.pdf

15.

FAO of the United Nations Land and Water Division (1993). Global and national soils and terrain digital databases (SOTER): Procedures manual, Vol. 74. Food & Agriculture Organisation. https://books.google.pl/books?id=Q4zk4Efcai8C

16.

Garijo

(2017). Widoco: A wizard for documenting ontologies. In International semantic web conference (pp. 94–102). Springer. https://doi.org/10.1007/978-3-319-68204-4_9

17.

German

D. M.

(2003). The gnome project: A case study of open source, global software development. Software Process: Improvement and Practice, 8(4), 201–215. https://doi.org/10.1002/spip.189

18.

Global Soil Partnership (2017a) Plan of action for pillar five of the global soil partnership. Technical report, GSP – Global Soil Partnership. https://openknowledge.fao.org/handle/20.500.14283/az922e

19.

Global Soil Partnership (2017b) Plan of action for pillar four of the global soil partnership. Technical report, GSP – Global Soil Partnership. https://openknowledge.fao.org/handle/20.500.14283/az921e

20.

Gomez-Perez

Suárez-Figueroa

M. C.

(2009). Neon methodology for building ontology networks: A scenario-based methodology. Proceedings of the International Conference on Software, Services & Semantic Technology, Sofia, 28-29 October 2009. https://oa.upm.es/5475/1/INVE_MEM_2009_64399.pdf

21.

IPBES (2019) Global assessment report on biodiversity and ecosystem services of the intergovernmental science-policy platform on biodiversity and ecosystem services. E. S. Brondizio, J. Settele, S. Díaz, & H. T. Ngo (Eds.), IPBES secretariat, Bonn, Germany. 1148 pages. pp 954-956. https://doi.org/10.5281/zenodo.3831673

22.

ISO 19136:2007 (2007) Geographic information – geography markup language (GML). Standard, International Organization for Standardization, Geneva, CH. https://www.iso.org/standard/32554.html.

23.

ISO 19156:2011 (2011) Geographic information – observations and measurements. Standard, International Organization for Standardization, Geneva, CH. https://doi.org/10.13140/2.1.1142.3042

24.

ISO 28258:2013 (2013) Soil quality – digital exchange of soil-related data. Standard, International Organization for Standardization, Geneva, CH. https://www.iso.org/standard/44595.html

25.

Jahn

Blume

Asio

Spaargaren

Schad

(2006). Guidelines for soil description. FAO. https://library.wur.nl/WebQuery/wurpubs/355777

26.

Janowicz

Haller

Cox

S. J.

Le Phuoc

Lefrançois

(2019). SOSA: A lightweight ontology for sensors, observations, samples, and actuators. Journal of Web Semantics, 56, 1–10. https://doi.org/10.1016/j.websem.2018.06.003

27.

Jensen

(2019). A systematic literature review of the use of semantic web technologies in formal education. British Journal of Educational Technology, 50(2), 505–517. https://doi.org/10.1111/bjet.12570

28.

Jian

Vargas

Anderson-Teixeira

Stell

Herrmann

Horn

Kholod

Manzon

Marchesi

Paredes

Bond-Lamberty

(2021). A restructured and updated global soil respiration database (SRDB-V5). Earth System Science Data, 13(2), 255–267. https://doi.org/10.5194/essd-13-255-2021

29.

Jones

Fernandez-Ugalde

Scarpa

(2020). Lucas 2015 topsoil survey. Presentation of dataset and results, EUR 30332 EN. Publications Office of the European Union. https://doi.org/10.2760/616084

30.

Kopittke

P. M.

Menzies

N. W.

Wang

McKenna

B. A.

Lombi

(2019). Soil and the intensification of agriculture for global food security. Environment International, 132, 105078. https://doi.org/10.1016/j.envint.2019.105078

31.

Leenaars

Van Oostrum

Ruiperez

(2014). Africa soil profiles database – Version 1.2. Technical report, ISRIC – World Soil Information. https://www.isric.org/sites/default/files/isric_report_2014_01.pdf.

32.

Libohova

Seybold

Adhikari

Wills

Beaudette

Peaslee

Lindbo

Owens

(2019). The anatomy of uncertainty for soil pH measurements and predictions: Implications for modellers and practitioners. European Journal of Soil Science, 70(1), 185–199. https://doi.org/10.1111/ejss.12770

33.

Lohmann

Link

Marbach

Negru

(2014). Webvowl: Web-based visualization of ontologies. In International conference on knowledge engineering and knowledge management (pp. 154–158). Springer. https://doi.org/10.1007/978-3-319-17966-7_21

34.

Milne

Clayden

Singleton

Wilson

(1995). New Zealand soil description handbook (Revised edition). Manaaki Whenua Digital Library. https://doi.org/10.7931/DL1JG6

35.

National Committee on Soil and Terrain (2009). Australian soil and land survey field handbook 1 (3rd ed.). CSIRO PUBLISHING. http://dx.doi.org/10.1111/j.1442-9993.2012.02363.x

36.

OGC 16-088r1 (2016) OGC soil data interoperability experiment. Engineering report, Open Geospatial Consortium. http://www.opengis.net/doc/PER/OGC-Soil-IE

37.

Oldeman

Van Engelen

(1993). A world soils and terrain digital database (SOTER) – an improved assessment of land resources. Geoderma, 60(1–4), 309–325. https://doi.org/10.1016/0016-7061(93)90033-H

38.

Ramankutty

Mehrabi

Waha

Jarvis

Kremen

Herrero

Rieseberg

L. H.

(2018). Trends in global agricultural land use: Implications for environmental health and food security. Annual Review of Plant Biology, 69, 789–815. https://doi.org/10.1146/annurev-arplant-042817-040256

39.

Rezník

Schleidt

(2020). Data model development for the global soil information system (GloSIS). Technical report, GSP – Global Soil Partnership.

40.

Riehle

(2011). Controlling and steering open source projects. Computer, 44(07), 93–96. http://dx.doi.org/10.1109/MC.2011.206

41.

Schoeneberger

P. J.

Wysocki

D. A.

Benham

E. C.

(2012). Field book for describing and sampling soils. Government Printing Office. https://www.nrcs.usda.gov/sites/default/files/2025-05/Field-Book-for-Describing-and-Sampling-Soils-Ver4.pdf

42.

Sen

Duffy

(2005). GeoSciML: Development of a generic geoscience markup language. Computers & Geosciences, 31(9), 1095–1103.

43.

Simons

Wilson

Ritchie

Cox

(2013). ANZSoilML: An Australian–New Zealand standard for exchange of soil data. In EGU General Assembly Conference Abstracts. EGU. pp. EGU2013-6802.

44.

Soil ITWG (2013) D2.8.III.3 INSPIRE data specification on soil – draft guidelines. Standard, European Commission Joint Research Centre. https://inspire-mif.github.io/technical-guidelines/data/so/dataspecification_so.pdf

45.

Soussana

J. F.

Lutfalla

Ehrhardt

Rosenstock

Lamanna

Havlík

Richards

Wollenberg

Chotte

J. L.

Torquebiau

Ciais

Smith

Lal

(2017). Matching policy and science: Rationale for the ‘4 per 1000 – soils for food security and climate’ initiative. Soil and Tillage Research, 188, 3–15. https://doi.org/10.1016/j.still.2017.12.002

46.

Springmann

Clark

Mason-D’Croz

Wiebe

Bodirsky

B. L.

Lassaletta

de Vries

Vermeulen

S. J.

Herrero

Carlson

K. M.

Jonell

Troell

DeClerck

Gordon

L. J.

Zurayk

Scarborough

Rayner

Loken

Fanzo

, …, Willett

(2018). Options for keeping the food system within environmental limits. Nature, 562, 519–525. https://doi.org/10.1038/s41586-018-0594-0

47.

Suominen

Ylikotila

Pessala

Lappalainen

Frosterus

Tuominen

Baker

Caracciolo

Retterath

(2015). Publishing SKOS vocabularies with Skosmos. Manuscript submitted for review. June 2015. https://skosmos.org/publishing-skos-vocabularies-with-skosmos.pdf

48.

Tuominen

Frosterus

Viljanen

Hyvönen

(2009). ONKI SKOS server for publishing and utilizing SKOS vocabularies and ontologies as services. In European semantic web conference (pp. 768–780). Springer. http://dx.doi.org/10.1007/978-3-642-02121-3_56

49.

UNEP (2012) The benefits of soil carbon – managing soils for multiple, economic, societal and environmental benefits. In UNEP year book 2012: Emerging issues in our global environment (pp. 19–33). United Nations Environmental Programme. http:www.unep.org/yearbook/2012

50.

United Nations (2019). World population prospects 2019. Vol (ST/ESA/SER.A/424). Department of Economic and Social Affairs: Population Division. https://www.un.org/development/desa/pd/news/world-population-prospects-2019-0

51.

van der Esch

Brink

Bt.

Stehfest

Bakkenes

Sewell

Bouwman

Meijer

Westhoek

van den Berg

(2017). Exploring future changes in land use and land condition and the impacts on food, water, climate change and biodiversity: Scenarios for the UNCCD Global Land Outlook. Policy report. UNCCD. https://research.wur.nl/en/publications/exploring-future-changes-in-land-use-and-land-condition-and-the-i

52.

Viscarra Rossel

Adamchuk

Sudduth

McKenzie

Lobsey

(2011). Chapter five – proximal soil sensing: An effective approach for soil measurements in space and time. In D. L. Sparks (Ed.), Advances in agronomy (vol. 113, pp. 243–291). Academic Press. https://doi.org/10.1016/B978-0-12-386473-4.00005-1

53.

WOCAT (2007) Where the land is greener: Case studies and analysis of soil and water conservation initiatives worldwide. CTA, UNEP, FAO and CDE. https://wocat.net/documents/87/where_the_land_is_greener_WEB.pdf

rdf	http://www.w3.org/1999/02/22-rdf-syntax-ns#
glosis_sp	http://w3id.org/glosis/model/siteplot/
glosis_pr	http://w3id.org/glosis/model/profile/
glosis_lh	http://w3id.org/glosis/model/layerhorizon/
glosis_cl	http://w3id.org/glosis/model/codelists/
glosis_proc	http://w3id.org/glosis/model/procedure/
ssn	http://www.w3.org/ns/ssn/
sosa	http://www.w3.org/ns/sosa/
qudt	http://qudt.org/schema/qudt/
unit	http://qudt.org/vocab/unit/
xsd	http://www.w3.org/2001/XMLSchema#
rdfs	http://www.w3.org/2000/01/rdf-schema#
gn	http://www.geonames.org/ontology#
nuts	http://nuts.geovocab.org/id/
gsp	http://www.opengis.net/ont/geosparql#
geof	http://www.opengis.net/def/function/geosparql/
iso28258	http://w3id.org/glosis/model/iso28258/2013#
iso19115-1	http://def.isotc211.org/iso19115/-1/2018/CitationAndResponsiblePartyInformation#
cap-parcel	http://lpis.ec.europa.eu/registry/applicationschema/cap-iacs-parcel#
lcc-cr	https://www.omg.org/spec/LCC/Countries/CountryRepresentation/
skos	http://www.w3.org/2004/02/skos/core#
foaf	http://xmlns.com/foaf/0.1/

GloSIS: The Global Soil Information System Web Ontology

Abstract

Keywords

1. Introduction and Motivation

1.1. The Importance of Soils and Related Risks

1.2. Global Soil Partnership (GSP) and its Goals

1.4. Document Structure

2.1. SOTER

2.2. ISO 28258

2.3. Australian and New Zealand Soil Mark-up Language (ANZSoilML)

2.4. The Soil Theme in INSPIRE

3. Ontology Specification and Implementation

3.1. Methodology

3.3.1. Reusing and Reengineering Non-Ontological Resources

3.3.3. Introduction of Procedure Code-Lists

3.4.3. Documentation

3.5. Maintenance

4. Applications of the Ontology

4.1. LUCAS 2015 Topsoil Dataset

4.2. Soil Respiration Database (SRDB)

4.3. The WoSIS RDF Service

4.4. Data Discovery and Access

4.4.1. SPARQL Queries

4.4.2. Semantic REST API

5.1. Ontological Extensions

5.2. Operational Improvements

5.3. Human Factors and Education

Glossary

Footnotes

Acknowledgements

Funding

Declaration of Conflicting Interests

Notes

References