OGC API - Records SWG

Chair(s):

Vretanos, Panagiotis (Peter) A. (CubeWerx)
Yutzler, Jeff (Image Matters LLC)
Kralidis, Tom (Environment and Climate Change Canada)

Group Description:

Purpose of the Standards Working Group

The purpose of this Standards Working Group is to:

  • Design, discuss and document a new version of Catalogue Service standard (the HTTP Protocol Binding) as a Web API.

  • Develop new parts for the OGC API - Records multipart standard.

  • Develop corrigenda for previous versions of the OGC Catalogue standard(s).

Business Value Proposition

In order to be able to better exploit geospatial resources (e.g., feature collections, coverages, etc.) and other related resources (code lists, definitions, etc.), end-users must be able to discover, filter and fetch those resources. The proposed Web API will define the methods and apparatus to support:

  • Discovery of geospatial resources by standardizing the way collections of descriptive information about the resources (metadata) are exposed;

  • Discovery and sharing of related resources that may be referenced from geospatial resources or their metadata by standardizing the way all kinds of records are exposed and managed.

For providers of geospatial resources who need to catalogue their holdings, a catalogue provides a uniform means for indexing those resources as metadata records. The Records service API provides a uniform interface for these catalogues. The same uniform interface may be used for managing and sharing the related resources.

For developers building infrastructures to host, harvest and/or manage collections of geospatial resources, this proposed standard will define:

  • A light-weight, but extensible, common core record schema for describing resources of all kinds including geospatial resources.

  • A light-weight, but extensible, core API for searching collections of these descriptive records.

Finally, users of geospatial resources are often in a position of having to construct specialized processing flows for each different collection of geospatial resources that they consume. The Records API will be defined to reduce such complexity and encourage the use of common tooling.

Scope of Work

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.

  • Name:
    The proposed name of the new standard is "OGC API - Records - Part 1: Core."

  • Scope:
    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.

  • Architecture:
    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.

  • Encodings:
    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.

  • Linked data:
    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.

  • Reuse:
    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.

  • Modularization:
    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.

  • Security:
    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:

  • Working implementations for all capabilities defined in the proposed API must be available and tested and;

  • Implementation feedback must be considered.

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.

Statement of relationship of planned work to the current OGC standards baseline

This standard is intended to be a major revision to the Catalogue Services standards published by OGC. This revision will take advantage of Web API patterns identified in the OGC API standards efforts (e.g., OGC API - Features, AKA WFS 3.0) to better align with current and emerging IT practices. "OGC API - Records" does overlap in scope with the existing OGC Catalogue Services standards. In addition, the SWG will coordinate with the EO Product Metadata and OpenSearch SWG on potential alignment of efforts.

What is Out of Scope?

Standards are important for interoperability. At the same time, it is important that standards only state requirements that are important for a significantly large group of users. Proposals for new parts of OGC API - Records or change requests to existing parts must identify the user group that will benefit from the proposal and include the commitment for three independent implementations for each proposed conformance class; otherwise the proposal will be considered out-of-scope.

OGC API - Records will be a modular, multi-part standard. Developing profiles of OGC API - Records should not be necessary and is, therefore, out-of-scope for the SWG. If a community has a need to develop a profile, the profile should be specified and governed by that community.

Specific Existing Work Used as Starting Point

The starting point for the work will be the "OGC® Catalogue Services 3.0 Specification - HTTP Protocol Binding", OGC 12-176r7. The work will also be informed by the following documents and by recommendations found in:

  • OGC/W3C Spatial Data Working Group on the Web Best Practices (https://www.w3.org/TR/sdw-bp/);

  • OGC Geospatial API White Paper (OGC 16-019r4);

  • OGC API - Features - Part 1: Core candidate standard, OGC 17-069r2;

  • OGC® OpenSearch Geo and Time Extensions, OGC 10-032r8;

  • SpatioTemporal Asset Catalog API Specification (https://github.com/radiantearth/stac-spec).

Each of these documents recommends an emphasis on resource oriented APIs in future OGC standards development including use of tools such as OpenAPI.

In addition, the following metadata standards will be reviewed:

 

Description of deliverables

The following deliverables will result from the work of this SWG:

  • A final version of the "OGC API - Records - Part 1: Core" document for submission to the TC; and

  • At least three prototype implementations of the core based on the standard — although more would be preferred.

  • Zero or more additional parts as time and desire permits.

Part 1 will cover read-only access to records and simple query capabilities.

Capabilities for richer queries or to create, update or delete records will be specified in additional parts.