Blog article

How OGC Contributes to FAIR Geospatial Data

Standards are a key element of the FAIR Principles of Findability, Accessibility, Interoperability, and Reusability. As such, the Open Geospatial Consortium (OGC) has been supporting the FAIR Principles for geospatial information since its formation 30 years ago. This blog post offers an overview of select OGC Standards and components that support FAIRness in geospatial data.

By: Joan Masó Pau

Standards are a key element of the FAIR Principles of Findability, Accessibility, Interoperability, and Reusability. As such, the Open Geospatial Consortium (OGC) has been supporting the FAIR Principles for geospatial information since its formation 30 years ago.

Following the more recent codification of the FAIR principles, the growing recognition of their potential to improve data production, storage, exchange, and processing is seeing them being used to support and enhance recent technological developments such as artificial intelligence, crowdsourcing, data spaces, digital twins, cloud computing, and beyond. This blog post, therefore, offers an overview of select OGC standards and components that support FAIRness in geospatial data.

Within the whole OGC Standards suite, we can broadly distinguish two types of Standards: data format and transfer standards that facilitate data exchange between systems; and semantic interoperability standards that support a common understanding of the meaning of data. For example, OGC Standards that define interoperable geometrical information formats, such as 3D Tiles, GML, GeoPackage, GeoTiff, or KML, support FAIRness by facilitating data Access and Reuse.

Communication Standards

Starting with OGC Web Map Service (WMS) 1.0 in 2000, the suite of OGC Web Services Standards grew to become OGC’s most popular and successful suite of Standards. Services that implement OGC Web Services Standards give access to different kinds of data through the web. Most OGC Web Services provide instructions on how to post a message or build a query URL that gives access to the data behind the service. The URL contains an action to perform and parameters to modify the action and specify the form of the result.

While perfectly functional, the OGC Web Services Standards do not completely follow modern practices on the Web. In particular they do not focus on resources but on operations. To correct that issue, the OGC is evolving the OGC Web Services into the OGC APIs – open web APIs that define resources and use HTTP methods to retrieve them. OGC APIs have diverse functionalities, as explained below.

Communication Standards for Finding Data

The Catalog Service for the Web (CSW) is an OGC Web Service that provides the capacity to query a collection of metadata and find the data or the services that the user requires. Deploying a CSW (e.g. a GeoNetwork instance) is a way to comply with the FAIR sub-principle F4. (Meta)data are registered or indexed in a searchable resource. CSW is compatible with Dublin Core and ISO 19115 metadata documents. An interesting characteristic of the GeoNetwork is its capability to store attachments to the metadata. This provides a way to store the actual data as an attachment and link it to the distribution section of an ISO 19115. This ensures not only Findability of the metadata but also Findability of the data. In the Open Earth Monitor (OEMC) project, CSW can be effectively used to store metadata about the in-situ data and some of the results of the pilots, making them Findable on the web. The original Remote Sensing data is offered through a SpatioTemporal Asset Catalog (STAC).

The OGC API – Records Standard is an alternative to CSW that uses the aforementioned resource-oriented architecture. It gives a URL to each and every metadata/data record stored in the catalog, making it compliant with the FAIR sub-principle F1. (Meta)data are assigned a globally unique and persistent identifier.” The OGC API – Records Standard is still in its draft phase and the authors are making efforts to exploit STAC good practices and make the two compatible. 

For flexibility, in the CSW and OGC API – Records Standards, a metadata record is not obligatory, though it is desirable in many cases. This is useful for improved findability, but also for preservation purposes when the dataset may no longer be available. This ensures compatibility with the FAIR sub-principle A2. Metadata are accessible, even when the data are no longer available.

Communication Standards for Accessing Data

The OGC Web Feature Service (WFS) and the Web Coverage Service (WCS) give access to feature or coverage data independently of the data’s data model or schema. Implementations of these services are based on Open Standards that can be implemented for free. This complies with the FAIR sub-principle A1.1 The protocol is open, free, and universally implementable. It is possible to get the whole resource or a subset of it based on spatial or thematic queries. However, these services are based on a service-oriented architecture and do not necessarily provide a URI for each resource. 

The newer OGC API – Features and OGC API – Coverages Standards, though, provide similar functionality with a resource-oriented architecture. They provide a URI for each resource they expose. This makes the OGC API Standards, as well as the SensorThings API, compliant to the FAIR sub-principle A1. (Meta)data are retrievable by their identifier using a standardized communications protocol. OGC Web Services and OGC APIs both use the HTTP protocol over the Internet and can make use of the current standards and practices for authentication and authorization, such as OpenID Connect

However, the resource-oriented architecture of the OGC API Standards means they are better positioned to adopt best practices for authentication and authorization. In this paradigm, authorization on geospatial resources can be fine-tuned for each resource URI in the same way as any other resource on the Web. As such, OGC API – Features, OGC API – Coverages, and The Sensor Things API comply with the FAIR sub-principle “A1.2 The protocol allows for an authentication and authorization procedure, where necessary.”

Semantic Interoperability Standards

The OGC RAINBOW

To better support the “Interoperable” FAIR principle as it applies semantic interoperability, OGC is implementing the OGC RAINBOW (formerly the OGC Definitions Server) as a Web accessible source of information about concepts and vocabularies that OGC defines or that communities ask the OGC to host on their behalf. It applies FAIR principles to the key concepts that underpin interoperability in systems using OGC specifications.

The OGC Registry for Accessible Identifiers of Names and Basic Ontologies for the Web (RAINBOW) is a linked-data server, published and maintained by OGC, used to manage and publish reference vocabularies, standard definitions with profiles, ontologies, and resources. It is intended to be a node in an interoperable ecosystem of resources published by different communities. It supports a wide spectrum of resources and allows more value to be realized from data. It can be accessed at opengis.net/def.

OGC RAINBOW is implemented using Linked Data principles that provide enhanced findability, making it compliant with the FAIR sub-principles F1. (Meta)data are assigned a globally unique and persistent identifierand F4: (Meta)data are registered or indexed in a searchable resource.”  It is accessed using the HTTP protocols over the Internet, so is also compliant with A1. (Meta)data are retrievable by their identifier using a standardised communication protocol and A1.1 The protocol is open, free, and universally implementable.”

The set of concepts stored in the RAINBOW or in other vocabularies can be used by data and metadata to comply with the FAIR sub-principles I1. (Meta)data use a formal, accessible, shared, and broadly applicable language for knowledge representation and I2. (Meta)data use vocabularies that follow FAIR principles.” 

The OGC SensorThings API

The OGC SensorThings API is an open and free standard that complies to the FAIR sub-principle A1.1 The protocol is open, free, and universally implementable.” It incorporates a data model that includes two properties that allow for linking to URLs for “units of measurement” and “observed properties” (e.g. references to variable definitions) that makes it compliant with the FAIR sub-principle “I2. (Meta)data use vocabularies that follow FAIR principles.” However, other services and APIs, such as OGC API – Features and OGC API – Coverages, do not specify how this could be done in practice, so more work needs to be done in that respect. 

On the other hand, the new OGC APIs use link mechanisms to connect datasets, resources, and resource collections to other resources for different purposes, making them compliant with the FAIR sub-principle I3 (Meta)data include qualified references to other (meta)data.” 

Similarly, the new OGC SensorThings API plus (STAplus) Standard includes an additional element called “Relation” that allows for relating an observation to other internal or external observations. It also adds an element called “License” associated with the datastream or observation group that complies with the FAIR sub-principle “R1.1. (Meta)data are released with a clear and accessible data usage license.” Further, the STA data model can be extended to domain-specific areas by subclassing some of the entities, such as “Thing” and “Observation,” allowing it to meet the FAIR sub-principle “R1.3. (Meta)data meet domain-relevant community standards.” 

STAplus includes many considerations for secure operations and can support authentication and authorization through the implementation of business logic, making it compliant with the FAIR sub-principle “A1.2. The protocol allows for an authentication and authorization procedure where necessary.”

Other Standard Thematic Data Models

OGC also offers Standards that define thematic data models and knowledge representations. For example, WaterML is an information model for the representation of water observations data. In addition, PipelineML defines concepts supporting the interoperable interchange of data pertaining to oil and gas pipeline systems. The PipelineML Core addresses two critical business use-cases that are specific to the pipeline industry: new construction surveys and pipeline rehabilitation. 

Another example is the Land and Infrastructure Conceptual Model (LandInfra) for land and civil engineering infrastructure facilities. Subject areas include facilities, projects, alignment, road, railway, survey, land features, land division, and “wet” infrastructure (storm drainage, wastewater, and water distribution systems). CityGML is intended to represent city objects in 3D city models. The (upcoming) Model for Underground Data Definition and Integration (MUDDI) represents information about underground utilities. IndoorGML offers a data model to represent indoor building features. Finally, GeoSciML is a model of geological features commonly described and portrayed in geological maps, cross sections, geological reports and databases. This standard describes a logical model for the exchange of geological map data, geological time scales, boreholes, and metadata for laboratory analyses. 

The existence of these Standards can help each thematic sector to comply with the FAIR Interoperability sub-principle I1. (Meta)data use a formal, accessible, shared, and broadly applicable language for knowledge representation.” As well as these standards, connecting their vocabularies to information systems or databases would significantly increase their usefulness and encourage the principle of Reusability R1.(Meta)data are richly described with a plurality of accurate and relevant attributes and sub-principle “R1.3 (Meta)data meet domain-relevant community standards.”

FAIR in Everything We Do

OGC’s Mission, to “Make location information Findable, Accessible, Interoperable, and Reusable (FAIR),” places the FAIR Principles at the heart of everything we do. This post has shown how OGC Standards explicitly address the FAIR Principles to contribute to FAIR geospatial data. 

The Standards shown here were chosen due to their popularity and utility, but represent only a small portion of what’s available from OGC. You can see the full suite of OGC Standards at ogc.org/standards

For more detailed information on OGC API Standards, including developer resources, news of upcoming code sprints, or to learn how the family of OGC API Standards work together to provide modular “building blocks for location” that address both simple and the most complex use-cases, visit ogcapi.org.