Structurer ses métadonnées open data avec DCAT : rendre ses jeux de données découvrables et interopérables

Publier des jeux de données en open data, c’est bien. Faire en sorte qu’ils soient trouvables, compréhensibles et réutilisables par d’autres organisations, c’est mieux. Le standard DCAT (Data Catalog Vocabulary) est le vocabulaire de référence pour décrire des catalogues de données de manière structurée et interopérable. Cet article explique comment l’appliquer concrètement, notamment dans un contexte CKAN ou de portail territorial.

Pourquoi les métadonnées comptent autant que les données

Un fichier CSV publié sans contexte est pratiquement inutilisable. Qui l’a produit ? À quelle fréquence est-il mis à jour ? Quelle zone géographique couvre-t-il ? Sous quelle licence est-il diffusé ? Sans métadonnées structurées, chaque réutilisateur doit reconstituer ces informations manuellement — quand il y parvient.

À l’échelle d’un territoire ou d’un écosystème de données, le problème se démultiplie. Les portails open data de différentes collectivités publient des jeux de données similaires (transports, urbanisme, qualité de l’air) sans format commun de description. Résultat : les agrégateurs nationaux ou européens peinent à moissonner ces catalogues, et les citoyens ou développeurs ne trouvent pas ce qu’ils cherchent.

DCAT : un vocabulaire RDF pour les catalogues de données

DCAT est une recommandation du W3C qui définit un vocabulaire RDF pour décrire des catalogues de données. Sa structure repose sur trois classes principales :

dcat:Catalog — le catalogue lui-même, qui regroupe un ensemble de jeux de données. C’est l’entité de plus haut niveau, typiquement un portail open data.
dcat:Dataset — un jeu de données, décrit par son titre, sa description, son éditeur, sa couverture temporelle et géographique, ses mots-clés et sa licence.
dcat:Distribution — une représentation physique du jeu de données : un fichier CSV, une API, un flux GeoJSON. Un même Dataset peut avoir plusieurs Distributions dans différents formats.

Cette séparation entre le jeu de données (concept) et ses distributions (fichiers concrets) est fondamentale. Elle permet de décrire qu’un même jeu de données est disponible en CSV, en JSON et via une API, sans dupliquer les métadonnées descriptives.

DCAT-AP : le profil européen

En Europe, le profil d’application DCAT-AP (Application Profile) spécialise DCAT pour les besoins des portails publics européens. Il définit des propriétés obligatoires, recommandées et optionnelles, et s’appuie sur des vocabulaires contrôlés (thèmes EU, types de fichiers, fréquences de mise à jour) pour garantir une cohérence entre les catalogues nationaux.

Concrètement, DCAT-AP impose que chaque Dataset ait au minimum un titre, une description et un éditeur. Il recommande fortement d’ajouter la licence, les mots-clés, la couverture géographique et la fréquence de mise à jour. Ce cadre est utilisé par le portail européen data.europa.eu pour moissonner les catalogues nationaux — dont data.gouv.fr.

La France dispose de son propre profil dérivé, en cohérence avec DCAT-AP, qui ajoute des spécificités liées au cadre réglementaire français (SIREN des organisations, nomenclatures administratives). Les collectivités qui structurent leurs métadonnées selon ce profil facilitent considérablement le moissonnage par data.gouv.fr.

Implémenter DCAT dans CKAN

CKAN, le portail open data le plus répandu dans le secteur public, supporte DCAT via l’extension ckanext-dcat. Cette extension permet d’exposer le catalogue CKAN au format DCAT (RDF/XML, Turtle, JSON-LD) et de moissonner des catalogues DCAT distants.

L’installation et la configuration suivent un schéma classique :

Installer l’extension via pip dans l’environnement CKAN : pip install ckanext-dcat
Ajouter dcat dcat_json_interface structured_data à la liste des plugins dans le fichier de configuration CKAN
Configurer le profil DCAT-AP en définissant ckanext.dcat.rdf.profiles = euro_dcat_ap_2
Mapper les champs CKAN personnalisés vers les propriétés DCAT si nécessaire, via le système de profils de l’extension

Une fois configuré, chaque jeu de données du portail est accessible en RDF à l’URL /dataset/{id}.rdf, et le catalogue complet est exposé à /catalog.rdf. C’est ce endpoint que les moissonneurs nationaux et européens interrogent pour indexer les données.

Les champs essentiels à renseigner

Pour maximiser la découvrabilité et l’interopérabilité de vos jeux de données, certains champs méritent une attention particulière :

Titre et description : clairs, sans jargon interne, avec les mots-clés que les réutilisateurs chercheraient. Éviter les titres comme « Export_BDD_2024 ».
Licence : utiliser un URI standard (Creative Commons, Licence Ouverte Etalab). Un jeu de données sans licence explicite est juridiquement inutilisable.
Couverture géographique : référencer un identifiant géographique normalisé (code INSEE, URI GeoNames) plutôt qu’un texte libre.
Fréquence de mise à jour : utiliser le vocabulaire contrôlé EU (annual, monthly, daily…). Un réutilisateur doit savoir s’il peut s’appuyer sur des données fraîches.
Thème : rattacher le dataset aux thèmes du vocabulaire européen (environnement, transport, santé…) pour le classement dans les portails agrégateurs.
Contact : un point de contact (email, URI) pour que les réutilisateurs puissent signaler des erreurs ou poser des questions.

Valider ses métadonnées

Publier des métadonnées DCAT ne suffit pas — il faut s’assurer qu’elles sont conformes au profil utilisé. Plusieurs outils permettent de valider la conformité :

DCAT-AP SHACL validator (de la Commission européenne) : valide un fichier RDF contre les contraintes SHACL du profil DCAT-AP. Disponible en ligne et en API.
Google Dataset Search : si vos métadonnées sont correctement exposées en JSON-LD (via le plugin structured_data de CKAN), vos jeux de données apparaîtront dans Google Dataset Search — un bon test d’intégration.
Moissonnage test : configurer un moissonnage depuis une instance CKAN de test vers votre portail pour vérifier que les métadonnées sont correctement interprétées.

Au-delà de DCAT : vers un écosystème de métadonnées lié

DCAT s’inscrit dans l’écosystème du web sémantique et du linked data. En utilisant des URI pour identifier les organisations, les lieux et les thèmes, on crée des liens entre catalogues qui permettent des requêtes croisées. Un utilisateur pourrait, en théorie, interroger l’ensemble des catalogues européens pour trouver tous les jeux de données sur la qualité de l’air dans les villes de plus de 100 000 habitants — à condition que chaque portail ait correctement structuré ses métadonnées.

Pour les collectivités et organisations qui gèrent un portail de données ouvertes, investir dans la qualité des métadonnées DCAT est un levier puissant et souvent sous-estimé. C’est ce qui transforme un simple dépôt de fichiers en un catalogue interrogeable, moissonnnable et réellement interopérable — condition préalable à toute ambition de territoire intelligent ou de gouvernance par la donnée.