Animateurs :
Jean-Philippe Clément, Jérémie Valentin, Pascal Romain
Pourquoi un catalogue de jeux de données
La présence au sein d’un projet Open Data d’un jeu de données “Catalogue des jeux de données”, qui recense tous les jeux de données du projet, permet aux réutilisateurs de prendre la mesure en un fichier de l’étendue des jeux de données libérés.
Si chacun des projets Open Data utilise le même formalisme (colonnes et types d’informations) pour créer son catalogue des jeux des données , il sera d’autant plus facile de créer un méta-catalogue à l’échelle de tous les projets Open Data. Celui-ci permettra :
- de faciliter l’identification des jeux intéressants pour les réutilisateurs
- de faciliter le repérage des jeux de données identiques ou proches dans chacun des projets pour créer des réutilisations utilisables avec plusieurs jeux de données d’origine différente
- de repérer au sein des projets Open Data les jeux de données qui mériteraient également d’être normalisés pour faciliter leur agrégation
- de faciliter le croisement de ces données par la mise en relation des métadonnées
Une normalisation ouverte aux commentaires
Les projets Open Data du Conseil général de la Gironde et de la Région Aquitaine, de la Ville de Montpellier, de la Métropole Nantaise et de la Ville de Paris ont effectué un travail de synthèse et de projection à partir de leur propre catalogue de jeux de données. Ils proposent aujourd’hui aux commentaires de la communauté une synthèse de leur travaux qui pourrait devenir la norme de construction d’un catalogue de jeux de données comprenant :
- Un nommage identique des champs utilisés
- Un ordonnancement identique des champs
- Des valeurs de champs attendues identiques
Vous trouverez le fruit de ce travail à cette adresse : Document de normalisation des datasets
Tous ces éléments sont proposés aux commentaires, en utilisant le système de commentaires ci-dessous.
La proposition de schéma expliquée
Le schéma de données est présenté ici en lignes pour plus de commodité, mais un catalogue csv de projet open data sera bien entendu présenté en colonnes. Chaque ligne correspondant à un jeu de données du projet.
Le schéma de données comprend deux parties, une qui concerne la description d’un jeu de données, l’autre qui concerne les ressources (fichiers, webservices…) attachées à ce jeu de données. Il ne peut y avoir qu’une seule fois les champs de description d’un jeu de données (lignes 2 à 25). Par contre, les champs ressources (lignes 26 à 33) peuvent être dupliqués autant de fois que le jeu de données a de formats différents (xls, ods, csv, webservice…).
Dans les deux parties, il existe des champs optionnels. Il ne sera pas forcément utile ou nécessaire de les renseigner pour chaque jeu de données, mais ils devront être présents (même vide) pour ne pas décaler l’ordonnancement des champs (notamment dans un fichier plat csv).
Le schéma propose d’atteindre un objectif ultime de publication du catalogue sous forme sémantique. C’est-à-dire que le catalogue ainsi publié permettrait d’utiliser les données selon le format DCAT (Data Catalog Vocabulary) du W3C permettant une interopérabilité et la création future de liens sémantiques entre les données de chaque catalogue et donc d’un méta-catalogue. C’est pour cette raison que chaque nature de champs est accompagnée de sa déclinaison DCAT. La troisième colonne accompagne l’utilisateur en précisant le type de valeur attendue dans ce champ.
Le schéma de données DCAT est une proposition de standard pour l’interopérabilité des catalogues de données. Il est basé sur le schéma de données RDF. Ce format a été élaboré à l’université DERI de Galway et est aujourd’hui maintenu par le W3C.
Les liens officiels de documentation sont les suivants :
● http://www.w3.org/2011/gld/wiki/Data_Catalog_Vocabulary
● http://dvcs.w3.org/hg/gld/raw-file/default/dcat/index.html
● http://www.w3.org/TR/dcat/ (future URL permanente)
Une liste de cas d’utilisation est actuellement en cours d’élaboration au sein du W3C
http://dvcs.w3.org/hg/gld/raw-file/default/dcat-ucr/index.html
L’intérêt d’utiliser ce standard est sa capacité à intégrer d’autres schémas de données notamment pour tout ce qui concerne la description des thèmes, catégories, mots-clés, etc…
En effet, il est tout à fait possible d’intégrer des thésaurus existants sous la forme de fichiers RDF-SKOS et de ce fait d’augmenter les possibilités de rapprochement de jeux de données provenant de portails différents automatiquement.
Un exemple de fichier DCAT est disponible sur le catalogue de jeux de données http://publicdata.eu : http://publicdata.eu/rdf/package/abandoned-vehicles
Comment utiliser ce schéma dans un projet Open Data
Le formalisme précis et exigeant (notamment dans son objectif sémantique) de ce catalogue peut également être envisagé comme une cible. C’est-à-dire que les projets Open Data peuvent atteindre ce formalisme en plusieurs étapes.
Dans un premier temps, il est envisageable qu’un projet Open Data ne constitue son catalogue qu’à partir des données de description des jeux de données sans renseigner la partie ressource. Dans ce cas, il pourra publier son catalogue sous forme tabulaire (csv) et pourra s’entraîner à le publier sous forme XML – RDF.
Dans un second temps, il pourra produire son catalogue complet et sémantique sous forme XML – RDF en respectant les noeuds de ce type de fichier.
En l’occurrence, les noeuds du schéma proposé sont le noeud dataset qui ouvre sur les champs description et ressources et le ou les noeuds ressources en fonction du nombre de formats publiés pour ce jeu de données.
Le modèle de données identifie un noeud racine constitué par le catalogue (Catalog) . On y décrit les caractéristiques de celui-ci grâce aux métadonnées disponibles.
Le noeud racine Catalog contient optionnellement des noeuds fils CatalogRecord qui peuvent servir à indiquer l’historique de publication des jeux de données dans le catalogue.
Le noeud racine contient ensuite un ou plusieurs noeuds fils Dataset qui contiennent chacun les métadonnées descriptives d’un jeu de données.
Enfin, chaque jeu de données peut être disponible dans un ou plusieurs formats de données ou via un ou plusieurs mécanismes d’interrogation. En conséquence, un ou plusieurs noeuds Distribution peuvent permettre de décrire leurs caractéristiques.
Voilà un schéma du format DCAT
Des réflexions sont en cours pour la mise en place d’un protocole d’interrogation et de récupération des métadonnées exprimées dans le schéma Dcat : http://wiki.okfn.org/OpenDataCatalogues/2#Proposed_Harvest_Mechanism
Actuellement, le moyen le moyen le plus simple de générer des fichiers en RDF-DCAT est de :
1. mettre en forme un tableur numérique contenant les champs détaillés dans le fichier résultant des travaux du groupe de travail
2. télécharger google-refine : https://code.google.com/p/google-refine/
3. installer google-refine
4. télécharger et installer l’extension rdf : http://lab.linkeddata.deri.ie/2010/grefine-rdf-extension/
5. lire la doc 
http://lab.linkeddata.deri.ie/2010/grefine-rdf-extension/rdfExportDocs
6. éventuellement lire cette présentation http://www.slideshare.net/fadimaali/employing-google-refine-to-publish-linked-data
7. exporter le fichier en RDF
8. publier sur votre portail opendata
Sinon, l’application CKAN dispose d’un module permettant l’export des métadonnées du catalogue en RDF
Etat d’avancement :
Compte rendu de la conférence téléphonique ayant eu lieu vendredi 22 mars 2013 autour de l’atelier #3
L’objet de cette conférence téléphonique était de s’accorder avec la mission Etalab sur ce sujet.
Trois points étaient au sommaire :
- La future ontologie Etalab (disponibilité ?)
- Thésaurus des thèmes de l’ontologie Etalab (utilisation d’un thésaurus existant ?)
- Référencement des données sur le portail data.gouv (offre de service destinée aux collectivités ?)
Les participants :
- Paris (JF Clément)
- CG33 (Pascal Romain)
- Montpellier (Jérémie Valentin)
- Etalab (Charles Ruelle)
Vous trouverez à cette adresse le document de travail de cette séance (http://titanpad.com/MDLOjj0KRz).
En quelques lignes, un état des lieux des méthodes de « génération » des métadonnées rdf (dcat compatible) a été fait. A ce sujet il serait intéressant pour l’atelier #3 et Etalab d’avoir une vision complète des méthodes (ou positionnement sur le sujet) des autres collectivités.
Etalab a annoncé la publication prochaine de son ontologie et de sa description, cette dernière utilise en partie le thésaurus eurovoc (http://eurovoc.europa.eu/) pour décrire le thème de chaque donnée.
Il a été évoqué la nécessité de créer une description complète et une « boite à outils » pour accompagner les collectivités qui souhaitent agir sur la normalisation et la mutualisation des données open data entre les divers acteurs français.
Etalab a exposé sa méthode de référencement automatique utilisée en interne pour déposer des données sur data.gouv.fr. La documentation technique va être transmise afin de pouvoir tester cette méthode l’objectif étant de référencer les données locales sur le portail national sans passer par une double saisie.
Enfin, a été proposé d’organiser une réunion sur la question du catalogue collectif entre Etalab et opendatafrance, certainement fin juin à Marseille lors de la semaine open data.
DCAT est aussi issu du groupe de travail sur le Linked Data pour les Gouvernements du W3C en lien avec le programme ISA de la Commission Européenne, c’est donc intéressant de s’y raccrocher, au lieu de réinventer sa ènième roue
Bonne initiative.
Concernant l’identifiant unique du jeu (dct:identifier), il l’était pour moi au sein d’un même site, mais votre réflexion va plus loin en proposant une codification qui souhaiterait aboutir à une unicité dans l’open data « français » (chose qui pourrait être intéressante).
Il y a-t-il déjà une codification des collectivités quelque part ?
Au passage une petite erreur dans l’exemple fourni « CG33_DGAC_DET_ENSZH » le code de la collectivité serait plutôt sur 4 ou 5 caractères et non sur 3 comme mentionné.
Un bel effort d’interoperabilité …
Pourquoi ne pas faire l’effort de publier directement un service RDF /Sparql ?
Dans le domaine géographique, dans le cadre de la directive INSPIRE, nous avons beaucoup travaillé sur les métadonnées. Un guide de recommandation a été conçu dans un groupe de travail national et publié ici : http://georezo.net/wiki/main/donnees/inspire/aide_a_la_saisie_des_metadonnees_inspire. Nous pensons que ces travaux peuvent être aussi utiles aux domaines non géographiques.
Par exemple, , qui est en effet indispensable pour séparer « des jeux de données identiques ou proches », peut prendre deux formes. La plus simple est une structure FR–>n°interne à l’organisme>.
Des remarques sur deux champs :
* Objet des mises à jour : est-ce ici 1. l’historique de toutes les mises à jour ou bien 2. l’objet de la présente mise à jour. Dans le cas 1. il faut donner un exemple où il y a plusieurs mises à jour. Dans le cas 2. il faut peut-être renommer le champ « Objet de la présente mise à jour » pour être plus clair.
* Qualité : je n’aime pas du tout cette notion : au mieux elle laisse entendre qu’elle est subjective, au pire elle l’est vraiment… Je lui préférerais les notions, plus factuelles, de « complétude » (ex : 50% du territoire couvert) ou de « taux d’erreur » (ex : taux d’erreur d’environ 10%). Avec le terme « qualité », on risque d’avoir des mentions du genre « Bonne » qui ne veulent strictement rien dire puisque la qualité dépend des usages : ce qui va être « bon » pour un usage va être insuffisant pour un autre et vice-versa. Je vois que c’est un champ DCAT, mais il est possible de faire remonter ce problème au groupe de travail DCAT.
>>La qualité c’est aussi les 5 étoiles de Tim Bernes-Lee ou les 72 bonnes pratiques du référentiel opendata ou des notions comme référence, à améliorer, exhaustif, à enrichir. SI tu as une précision sur la granularité de l’information ce n’est pas gênant de dire que l’information n’est pas bonne pour un usage trop précis. De toute les manières il faudra bien s’attaquer à cette notion de qualité
Il a également été évoqué la question du regroupement des jeux de données par grandes thématiques et les listes d’autorités INSPIRE et EUROVOC ont été évoquées.
L’avantage de celles d’EUROVOC c’est elles ont déjà réalisée leur élévation dans le web de données (aparté pour les initiés à l’ascenseur de données datalift)
21 termes d’indexation de niveau concept thématique sont donc disponibles à l’url http://eurovoc.europa.eu/drupal/?q=fr/navigation&cl=fr
Vous pouvez également retrouver les termes d’indexation que vous utilisez actuellement en utilisant le moteur de recherche.
>>Certainement pas car par définition les termes d’EUROVOC sont généralistes et que personne n’aura jamais l’idée de tagger un jeu de données tourisme sous la catégorie « question sociale »
Cependant, l’avantage d’EUROVOC c’est de coller aux métiers des collectivités publiques.
Une fois que l’alignement des jeux de données par catégories a été fait rien n’empêche de le présenter différemment aux utilisateurs finaux
Bonjour,
Merci pour ce travail fondamental pour les réutilisateurs finaux.
Si possible, j’aimerais pouvoir contribuer à cet atelier et également tester l’intégration de notre catalogue dans le métacatalogue ODF. A qui dois-je m’adresser ?
Je ne crois pas avoir vu dans la méthode proposée un système qui permette de mettre à jour automatiquement le fichier catalogue normalisé ; or notre catalogue évolue régulièrement (comme tout le monde je suppose).
Coté Grand Lyon, nous aimerions également tester la possibilité de générer le catalogue au format RDF depuis notre webservice normalisé CSW.
exemple url CSW :
http://catalogue.data.grandlyon.com/geosource/srv/fr/csw?SERVICE=CSW&request=GetRecords&service=CSW&version=2.0.2&resultType=results&OUTPUTSCHEMA=http://www.opengis.net/cat/csw/2.0.2&ELEMENTSETNAME=full&CONSTRAINTLANGUAGE=CQL_TEXT&typeNames=csw:Record&maxRecords=200
Dans le domaine géographique, pour ceux qui utilisent l’outil de catalogage GeoNetwork, il supporte le format DCAT :
http://trac.osgeo.org/geonetwork/wiki/proposals/DCATandRDFServices
Je ne sais pas si je m’adresse ici au bon endroit mais comme vous semblez y consacrer une bonne partie de votre temps aux opendata et que l’on m’a dirigé vers le site opendata du gouvernement je suis assez étonné de la compléxité des formats des données à extraire, certaines données ne sont d’ailleurs pas possible à extraire ou alors je ne sais pas comment faire…