Ce rapport technique a pour objectif de fournir une mise en correspondance « officielle » entre ISO 19115-1 et GeoDCAT. De nombreuses mises en correspondances entre l’ISO et le vocabulaire DCAT existent localement mais elles différent entre elles et ne fournissent en général pas une mise en correspondance exhaustive.
Les travaux démarrent. Le premier élément à préciser est de déterminer exactement quel est le périmètre de la cible de départ et celle d’arrivée.
DCAT est un vocabulaire W3C largement utilisé pour décrire les ensembles de données et les services d’accès aux données. Certaines propriétés temporelles et géographiques de base font déjà parti du vocabulaire DCAT v2 et/ou sont prévues pour la v3, mais ces propriétés ne répondent pas à l’ensemble des exigences identifiées dans le Discussion Paper élaboré par l’OGC.
L’UE fait référence à GeoDCAT-AP en tant que « bonne pratique » et note qu' »un projet de document de bonnes pratiques de l’OGC (Open Geospatial Consortium) est en cours d’élaboration. » Des discussions sont en cours pour faire de GeoDCAT-AP une norme communautaire de l’OGC.
Les travaux visent à séparer un profil géospatial général de DCAT, appelé « GeoDCAT », de GeoDCAT-AP ; le profil d’application (AP) spécifique à l’Europe ne fera pas partie du travail de normalisation de l’OGC.
GeoDCAT fournira un vocabulaire et un encodage normalisés pour les descriptions d’ensembles de données spatiales et les descriptions de services (enregistrements de métadonnées) respectant les recommandations décrites dans les Spatial Data on the Web Best Practices. GeoDCAT pourrait à l’avenir être utilisé comme encodage dans les API tels que les API Records de l’OGC et STAC.
Le groupe GeoDCAT SWG travaille sur la standardisation de GeoDCAT. L’objectif de ce groupe de travail est de publier un standard GeoDCAT, un profil spatio-temporel de la recommandation DCAT du W3C. Il fait suite au Discussion Papers OGC 18-001 publié sur le sujet.
Cette norme permet de spécifier comment établir, maintenir et publier un registre de mesures qualité conformément à l’ISO 19135-1. Cette norme comprend également la définition des moyens d’accès machine (API) à ce registre.
Les travaux comprennent aussi l’initialisation du registre avec un jeu de mesures prédéfinies. Elle devrait permettre de mettre en place un registre de mesures qualité à l’ISO, accessible par une machine et dont la maintenance sera facilitée.
Concernant le financement et la gouvernance du registre, l’OGC a été élu organisme d’enregistrement du registre (hébergement, publication et maintien du registre). Passée au stade de Community draft à l’OGC et ouverte aux commentaires techniques, l’enjeu est aujourd’hui d’avoir des retours sur le déploiement technique.
Les travaux du groupe ont débuté en 2021. Le projet a été relancé en mai 2023, suite au retard d’ISO 19135 (lié à l’impact potentiel de la révision de l’ISO 19135 sur le registre géodésique).
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 quel 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.
La partie 1 de base est sur le point d’être adoptée. Un brouillon est accessible ici : OGC API Records Part 1 Draft
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.
Viendront ensuite : la partie 2 sur les “facettes” (agrège des enregistrements dans des “buckets” et fournit des statistiques au sujet du nombre d’enregistrements dans chaque “bucket”), la partie 3 pour Create, Replace, Update, Delete (inspirée de la partie 4 de l’API Features), et la partie 4 sur les catalogues “fédérés” (ensemble de catalogues agrégés et listés).
Ce standard définit un modèle conceptuel de données sur les retours utilisateurs dans le domaine géospatial (GUF).
Les retours utilisateurs sur les données géospatiales sont des métadonnées qui sont principalement produites par les consommateurs de produits de données géospatiales au fur et à mesure qu’ils utilisent ces produits et acquièrent de l’expérience avec ceux-ci.
Cette norme complète les conventions de métadonnées existantes selon lesquelles les documents enregistrant les caractéristiques des ensembles de données et les flux de production sont générés par le créateur, l’éditeur ou le conservateur d’un produit de données. Dans le cadre des métadonnées, le modèle de données GUF réutilise certains éléments de la norme ISO 19115-1:2014, mais pas la structure générale. Cette utilisation sélective des éléments de métadonnées ISO donne la priorité à l’interopérabilité future avec les modèles de métadonnées ISO en développement. Cette norme est conçue pour être utilisée en combinaison avec une norme d’encodage.
Initialement, un codage XML suivant les règles d’encodage ISO 19139 est spécifié dans une norme d’implémentation OGC séparée (OGC 15-098). A l’avenir, d’autres encodages pourront être définis, y compris des exemples tels que l’utilisation de JSON-LD basé sur des parties de schema.org.
Ce standard est un profil de :
https://nextgeoss.eu/2019/03/31/user-feedback/
Les travaux sur Geospatial User feedback ont repris à l’OGC. Le standard est en mise à jour et le projet a été proposé à l’OGC pour relecture finale, le groupe est en attente de retours.
Le GUF existe aujourd’hui avec un MCD et un encodage XML. Le groupe suit les évolutions des standards 19115-1 (MCD métadonnées) et 19115-4 (encodage JSON) pour faire évoluer son MCD et son encodage. Ce dernier est notamment en discussion, avec en modèle soit l’OGC API Records, soit l’encodage JSON à venir de l’ISO 19115-4.
Les travaux d’une API Feedback sont en cours. Elle s’appuie sur API Features et Records ainsi que l’ISO 19115-4. Elle est disponible sur GitHub et sera présenté en juin 2025. Une implémentation test est déjà disponible.