Présentation

Projet de spécification d’une API de catalogage qui s’inscrit dans la lignée des APIs de l’OGC.
Le core est largement fondé sur API Feature et définit ce qu’est un enregistrement de métadonnées (Record) et quels mécanismes permettent de chercher/classer les résultats (mots clefs, titres, description…). Le modèle est analogue à ce qui est disponible dans un catalogue de type CSW.

Une extension OpenSearch est définie, comme dans la version 3.0 du standard CSW.
Enfin les résultats peuvent être renvoyés suivant trois formats : JSON, ATOM et HTML (chacun dispose de son extension).

Ce qui est intéressant est la possibilité de décrire l’accès aux services et données avec plus de détails (par exemple, un template d’URL pointant vers la bonne couche WMS/API Maps, ou collection de données API feature…), au lieu du seul lien vers un document de capacité (GetCapabilities). Cela devrait permettre une meilleure intégration de l’API Records avec l’ensemble des autres APIs.

L’intégration de l’OGC API Records parmi les autres API se fait selon deux mécanismes : Les ressources collections deviennent requêtables (il est possible de les filtrer) et la collection peut également être un catalogue de métadonnées.

Notes de version

La partie 1 de base est adoptée: OGC API – Records – Part 1: Core

Travaux en cours

La partie OGC API – Records – Part 2: Facets qui permet d’agréger des enregistrements dans des “buckets” et fournir des statistiques au sujet du nombre d’enregistrements dans chaque “bucket”;  et la partie [DRAFT] OGC API – Records – Part 3: Create, Replace, Update, Delete, Harvest inspirée de la partie 4 de l’API Features, sont en cours de rédaction active. La notion de “harvest” permettrait plutôt que de laisser le client déterminer quels enregistrements créer pour rendre une ressource détectable, de transférer cette responsabilité au serveur. Des recherches pour incorporer les cas d’utilisation du Protocole d’Initiative des Archives Ouvertes pour la Moissonnage de Métadonnées (OAI-PMH) sont en cours.

A l’avenir est prévue une partie 4 sur les catalogues “fédérés” à savoir un ensemble de catalogues agrégés et listés.

Des questions se posent sur la nécessité d’une partie supplémentaire sur les extensions STAC.