Open Data

Open Data

Ouvrir les données et après ?


Comment cataloguer des données publiques ?

Le Guide pratique que nous avons publié il y a quelques semaines s'enrichit petit à petit de nouveau contenus. Avant sa deuxième édition nous vous en soumettons ici certains, sous forme d'articles. Aujourd'hui il s'agit d'un article plutôt technique sur la manière de cataloguer des données (voir partie 2.3.2 du guide). C'est un sujet qui se structure progressivement avec la naissance progressive de bonnes pratiques voire de standards. Commentaire évidemment bienvenus (il faut s'identifier pour commenter).

 

Quelles données pour décrire des jeux de données ?

Du point de vue réglementaire, l’article 36 du décret n° 2005-1755 du 30 décembre 2005 stipule que les répertoires des informations publiques doivent préciser, « pour chacun des documents recensés, son titre exact, son objet, la date de sa création, les conditions de sa réutilisation et, le cas échéant, la date et l'objet de ses mises à jour ». Ces 6 métadonnées, certes essentielles, sont cependant loin d'être satisfaisantes pour produire un catalogue efficace. Nous proposons de lister ici quelques métadonnées qui complèterons utilement ces 6 initiales.

 

Pour décrire efficacement un jeux de données, certaines métadonnées s'imposent d'eux-même (nous rappelons les métadonnées réglementaires en les faisant suivre d'une astérisque) :

  • le titre du jeux de données*

  • son objet ou description sous la forme d'un texte, car un titre ne parle pas toujours de lui-même*

  • l'auteur

  • l'éditeur

  • la date de création et la date de dernière mise à jour*

  • les conditions de sa réutilisation*

  • le cas échéant, la date et l'objet de ses mises à jour*

 

A ces critères, on peut en ajouter quelques autres à forte valeur ajoutée, qui sont d'ailleurs utilisés par la quasi totalité des catalogues de données :

  • le sujet ou la catégorie, permettant ultérieurement d'effectuer des recherches plus efficaces

  • la fréquence d'actualisation des données

  • la liste des métadonnées du jeux de données ou le format de métadonnées du jeux de données

  • le format physique du jeux de données, permettant au réutilisateur potentiel d'appréhender sa capacité à le réutiliser

  • le lieu de diffusion : une URL ou bien le moyen d'accéder à ces données

  • les droits d'usage, surtout utiles lorsque les données sont en ligne

 

Certains autres critères, s'ils ne sont pas indispensables, facilitent la compréhension et l'usage des jeux de données :

  • la couverture spatiale ou temporelle des données

  • la langue ; souvent la langue du jeu de données est implicite mais elle peut être utile pour des organisations internationales ou pour la constitution de catalogues internationaux

  • des mots-clés, permettant de mieux catégoriser les données

  • un échantillon, complétant utilement la description du jeu de données (rarement assez complète) en permettant par exemple de lever des ambiguïtés

 

Il est possible d'ajouter encore des métadonnées le risque étant cependant d'y perdre beaucoup de temps et de submerger le réutilisateur de données inutiles. Un premier catalogue complet avec peu de métadonnées sera toujours plus utile qu'un catalogue très détaillé mais incomplet.

 

Mais un catalogue peut aller au delà d'une collection de métadonnées et se faire interactif en permettant à ceux qui le consultent :

  • soit d'indiquer leur souhait de voir tel ou tel jeux de données disponible

  • soit, pour chaque jeu de données, de permettre une évaluation de leur intérêt ou bien encore de collecter le nombre de consultation de chaque descriptif pour juger de leur popularité

  • soit plus concrètement de passer commande d'un jeu de données

 

Enfin, il est très utile de permettre au catalogue d'être lui-même téléchargeable sous forme de jeu de données, notamment lorsque les données sont nombreuses à l'exemple du catalogue des 438 jeux de données du Grand Londres. (Signalons que depuis hier, Montpellier rejoint Londres et New-York en proposant un tel jeu de données.) Il sera encore plus efficace si le format technique du catalogue est répandu : un simple fichier CSV peut suffire. Le fait d'être téléchargeable sous forme de jeu de données, rend possible d'autres usages : par exemple d'intégrer le catalogue à un moteur de recherche spécialisé comme open data search qui recense ainsi plus de 10 000 jeux de données... A condition toutefois que le format de métadonnées réponde à un standard connu.

 

Standards de métadonnées

A l'heure où nous écrivons ces lignes (avril 2011), il n'existe pas de norme spécifique consensuelle ou aboutie de catalogage des données publiques. Certaines normes, néanmoins, peuvent convenir voire sont candidates à cet usage. Le format OPML (Outline Processor Markup Language), couramment utilisé pour décrire des collections de flux RSS, peut servir à cataloguer des jeux de données publiées il est par exemple utilisé par le District de Columbia. Ce dernier n'est cependant pas particulièrement adapté au catalogage de jeux de données.

Le format Dublin Core est ancien et éprouvé pour cataloguer des « ressources ». Sa généricité et sa richesse en font un bon candidat : il possède les notions de titre, description, sujet, créateur, éditeur, source, format, type, droits, etc., toutes très utiles à décrire chaque jeu de données d'un catalogue. Le Dublin Core est extrêmement répandu et, cerise sur le gâteau, il est un des formats pivot du web sémantique et du web des données liées (linked data web). C'est aussi le format de base du protocole d'agrégation de données OAI-PM, qui gagne en popularité dans le monde des bibliothèques.

Le format Data Catalog Vocabulary, quant à lui encore en cours d'élaboration, est un travail très complet avec 9 classes et 32 propriétés associées. Il est actuellement en train d'émerger chez plusieurs acteurs de poids comme l'OKFN ou le portail national suédois -- il est également à l'étude chez Data-publica. Ce format est spécifiquement dédié à la description de catalogues de jeux de données. Il possède donc des métadonnées spécifiques aux catalogues de données comme la notion de jeux de données (Dataset), la granularité du jeux de donnée, la qualité des données, la taille, le mode de distribution de chaque jeu de données (téléchargement, flux ou API), etc. Ce format a le bon goût de réutiliser largement les métadonnées du Dublin core, permettant ainsi une transition facile avec ce dernier.

Enfin, dans l'annexe 2 de son « Guide méthodologique d'aide à la mise en place d'un répertoire des informations publiques au sein d'un ministère », l'APIE propose ce qui pourrait être un véritable standard de métadonnées de catalogage nous l'appellerons les recommandations APIE. Tout d'abord le statut de ce « standard » n'est pas très clair puisqu'on ne sait pas vraiment s'il s'agit de recommandations ou d'une tentative de standardisation. On ne peut véritablement parler de standard en l'absence de version, de titre et d'ambition claire de ce travail. Pour autant, il décrit de manière très complète 26 métadonnées ainsi que leur statut (obligatoire, recommandé ou facultatif). Le statut de chaque métadonnées permet de faciliter la création d'un catalogue en priorisant celles-ci, en permettant par exemple d'envisager une livraison en plusieurs temps du catalogue, etc. Destiné initialement aux ministères, ce Guide peut aussi être utile pour des acteurs publics de toutes sortes. Les métadonnées proposées par l'APIE sont toutes issues du standard Dublin Core, ce qui facilitera son usage.

 

Par parenthèse pour l'ingénieur, ces 4 formats de métadonnées ne préjugent pas forcément du format technique des données. En règle générale cependant, OPLM se trouve sous la forme de fichier XML à plat et les trois autres ont avantage à être sous la forme de fichiers RDF à plat ou directement accessible via l'API SPARQL, format de requettage standard du web sémantique. Pour des questions d'usage, il est cependant tout à fait possible de produire des fichiers CSV qui intègrent ces formats de métadonnées -- conservant ainsi une compatibilité sémantique avec d'autres catalogues et en laissant de côté l'interopérabilité technique permise par RDF.

 

On le voit ce domaine commence à se structurer avec des initiatives riches portées par de gros acteurs. Il serait sans doute utile que les initiatives de Data Catalog Vovabulary et de l'APIE puisse dialoguer pour arriver, sinon à un standard commun, tout au moins à faciliter l'interopérabilité entre ces normes. Dans tous les cas de figure, on recommandera l'usage du Dublin Core qui améliore le potentiel d'interopérabilité du catalogue avec d'autres outils et services.

Charles Nepote

Charles Nepote

Directeur du programme

Commentaires

  • Sylvain Hellegouarch le 21 avril 2011

    @Laurent: DC et RDF en eux-mêmes n'apportent pas grand chose si l'on ne définie pas l'ontologie associée. Il ne s'agit que de formats. Par conséquent, il faudrait déjà, mis à part pour des champs classique comme auteur, définir de quoi on parle et comment le sérialiser via DC, Atom ou autre.


Vous devez vous identifier pour ajouter un commentaire.
Veuillez vous identifier, ou créer un compte.

Conception & réalisation : Facyla ~ Items International

Plateforme construite avec le framework opensource Elgg 1.8