The current versions of the catalogue standards (i.e. CAT 2.0, CAT 3.0) — developed in the early 2000s — use a Remote-Procedure-Call-over-HTTP architectural style using XML for any payloads. This was considered state-of-the art at the time but this legacy is now badly outdated and does not conform to current web development practices.
The definition of an "OGC API - Records" standard is intended to break free of this legacy and will specify a modernized service that aligns with the current architecture of the Web and the Spatial Data on the Web Best Practices (https://www.w3.org/TR/sdw-bp/). The key changes are as follows.
The proposed name of the new standard is "OGC API - Records - Part 1: Core."
Catalogue interfaces have, in the geospatial domain, traditionally been used to access collections of formal metadata such as FGDC, ISO19115 or ISO19119 metadata documents. While the intent of the OGC API - Records SWG is to preserve this functionality going forward, there is also a desire to broaden the scope so that a catalogue can also act as a registry of other types of descriptive metadata about resources such as code lists.
The definition of the "OGC API - Records" will be consistent with HTTP and HTTPS. In previous versions, HTTP has been used mainly as a tunnel for RPC-like request messages.
Previous versions of the OGC catalogue standards were strongly tied to XML (Capabilities documents, XML schemas, Filter Encoding expressions, etc.). The definition of the "OGC API - Records" standard will not define mandatory encodings and will allow clients and servers to negotiate a mutually agreeable output formats using standard HTTP content negotiation rules. Because they are in common use today, the definition of the "OGC API - Records" standard will include conformance classes for JSON, HTML and XML encodings. Other encodings may also be defined as extensions in future parts of the standard.
Basic information model:
Previous versions of the OGC Catalogue Standard used the Dublin Core set of metadata (encoded as XML) as the basic, cross-platform, information model or set of queryables that all implementations needed to support. "OGC API - Records" will review the use of this model and strongly consider using DCAT (https://www.w3.org/TR/vocab-dcat/) or GeoDCAT (https://inspire.ec.europa.eu/good-practice/geodcat-ap), which are extensions to the Dublin Core model, for this purpose.
The use of links or hypermedia controls to guide users accessing the catalogue and to link related resources together will be strongly encouraged in the proposed standard. Wherever possible, provisions will be made to include "links" sections to accomodate the use of such hypermedia or linking elements.
The use of OGC Catalogue-specific resources or components will be minimized and, where available, existing industry-standards that are commonly used by developers will be considered instead. The most important example for this is the use of an OpenAPI definition instead of OGC-specific "Capabilities" documents.
The OGC Catalogue Services 3.0 Specification - HTTP Protocol Binding standard, together with the OGC Filter Encoding 2.0 Encoding Standard, specifies a powerful, but complex service interface. In order to better support implementations that only need a relatively simple service or client, the intent is to modularize the next version of the standard into multiple parts. The first part (the "core") will specify a simple interface to search collections of catalogue records that is sufficient for use cases that do not require support for transactions, complex data structures, rich queries, etc. Additional parts will specify extensions to this part to meet the needs of use cases that require such capabilities.
The OGC Catalogue Services 3.0 Specification - HTTP Protocol Binding standard, like many other OGC web standards, does not specify how services may be secured and some requirements are incompatible with secured services that still conform to the standard. The use of OpenAPI would address this issue, too. Catalogues Services may be secured using security schemes that are commonly used on the Web today (e.g., OAuth2) and that developers are familiar with.
As a result of the planned modernization, "OGC API - Records" implementations will not be backwards compatible with implementations of the OGC Catalogue Services 3.0 Specification - HTTP Protocol Binding. However, a design goal is to define "OGC API - Records" in a way so that the interface can be mapped as a facade on top of existing OGC catalogue implementations - at least for the capabilities that were already in scope for those standards.
"OGC API - Records" is intended to be simpler and more modern, but still be an evolution from the previous versions and their implementations.
The goal is to develop part 1 of "OGC API - Records", the foundation for the new version, as quickly as possible and work on additional parts after that, driven by community interest.
An important aspect is to ensure that implementing the standard will lead to efficient implementations, happy developers of both server and client components, and satisfied users of such components.
This has several aspects:
Before finalizing the first version of "OGC API - Records", the SWG needs to verify that the following objectives are met:
A consequence of this approach is that the period between the availability of what is considered a mature draft and the finalization of the catalogue API standard may take longer than in the past, depending on the availability of evidence about the suitability of the candidate Standard based on implementations.
Developers, including those that are not active in OGC or ISO/TC 211, should be encouraged as early as possible to implement the draft standard and provide feedback. An aspect of this outreach is public access to in work draft documents.
To this end, the SWG intends to use GitHub in the development of this standard as this is the environment may developer are familiar with and user on a daily basis.