DataFair permet d’enrichir et de partager facilement ses données pour pouvoir ensuite les utiliser dans des applications. Le partage des données peut se faire en mode privé (private data) ou public (open data). Pour l’instant, les données partageables sont des données de type tabulaire, mais le service devrait bientôt supporter d’autres formats, comme les données géographiques. DataFair permet de mettre facilement des données à disposition, mais les métadonnées sont minimes et ce n’est donc pas un service de catalogage. Il peut donc être un excellent complément à un service comme udata utilisé sur le site data.gouv.fr.
Bonjour,
Je me disais que j’allais bientôt présenter le projet ici, mais ce n’est plus nécessaire ! Pour le nom du projet, on est parti du sujet ici sur le lien entre Open Data et FAIR, et on est parti sur un jeu de mots basé sur “la foire aux données”.
L’idée est est de pouvoir API-fier des données fichier (tabulaires pour l’instant) facilement pour pouvoir les rendre interopérables avec d’autres APIs et des applications. L’interopérabilité se fait avec l’utilisation d’un vocabulaire sémantique commun.
Quand on charge un jeu de données, on peut typer les colonnes avec ce vocabulaire : une colonne peut être une code siret, un code insee, un code parcelle ou une paire lat/lon par exemple. On peut ensuite configurer des applications qui vont utiliser certains types de données. On a par exemple une application Infos Parcelles : https://koumoul.com/s/data-fair/app/infos-parcelles qui peut être configurée avec 3 éléments :
- un dataset qui a une colonne de type code parcelle et une colonne de type lat/lon (obligatoire)
- des fond de carte du cadastre (obligatoire)
- une api qui prend en entrée une adresse et rend une paire de coordonnées (optionnel pour la barre de recherche)
Le service peut être testé sur notre site (n’hésitez pas à me contacter car la documentation est encore à améliorer) ou déployé soi-même. Le service étant encore très jeune, nous sommes très preneurs des différents retours qu’on pourrait avoir et je répondrai avec plaisir ici aux différentes questions.
2 « J'aime »
Ca ressemble fichtrement à Datahub ! 
(on en parlait ici)
Dans quel format sont stockés les fichiers ? Datapackage ?
Les fichiers sont stockés tels quels comme ça l’utilisateur peut retélécharger son fichier d’origine. Les données des fichiers sont indexées dans ElasticSearch.
Je ne connais pas trop Datahub, mais il a l’air axé fichier (on télécharge des csv ou des bouts de csv), je ne vois pas d’API Rest pour accéder aux données des datasets.
Nous avons récemment ajouté un nouveau type de ressources : les catalogues. Cela permet de faire des exports des descriptions et schémas des jeux de données pour faciliter la publication. Nous avons implémenté un connecteur qui est pour uData (utilisé pour data.gouv.fr). Une organisation peut ainsi publier des jeux de données sous forme d’API, donc interopérables et réutilisables, sans forcément avoir de portail Opendata.
Le connecteur permet aussi d’exporter les applications configurées sous forme de réutilisations. Les connecteurs sont des plugins, on peut donc en développer un maison pour se connecter à un catalogue en particulier. Nous en avons développé un qui permet d’exporter un dataset vers un service d’un de nos partenaires qui va l’analyser pour savoir si les données peuvent être sensibles ou pas, ce qui permet par exemple de faire une première vérification avant de rendre le dataset public sur un autre catalogue comme data.gouv.fr.
Nous pensons en plus de l’export rajouter l’import : on pourrait imaginer se connecter à un catalogue, récupérer tous les jeux de données d’une organisation qui ont des formats structurés, les APIfier puis remettre a jour la description du catalogue avec ces nouvelles ressources.
1 « J'aime »
Quelques nouvelles quand à l’avancement du projet et de ce qui a été réalisé depuis mon dernier post :
- Support de plusieurs formats en entrée en plus du CSV et du geoJSON. Nous nous sommes focalisés sur les formats les plus communs, la liste complète est consultable ici. Si vous voyez des manques, nous sommes preneur de vos retours.
- Simplification du système de permissions, surtout au niveau interface (on peut encore faire beaucoup de choses via l’API).
- Refonte de la documentation qui est aussi accessible sur n’importe quelle instance de Data Fair
- Amélioration du support des erreurs avec notamment un journal détaillé pour les enrichissements
- Possibilité de charger un fichier ZIP contenant plusieurs fichiers PDF : si les fichiers PDF sont issus d’une conversion (et pas scannés), il est alors possible de rechercher en mode full text dans l’ensemble des fichiers. Cette fonctionnalité répond à 2 cas d’usage que nous avons identifiés : rechercher rapidement dans un ensemble de délibérations (en lien avec le format SCDL) ou dans un ensemble de factures. Pour illustrer cette fonctionnalité, nous ferons bientôt une petite application de recherche documentaire qui sera publiée en open source.
- Possibilité de moissonner des catalogues avec un support expérimental de uData (et donc de data.gouv.fr)
- Amélioration du système d’agrégations: on peut faire des agrégations imbriquées et extraire les mots les plus signifactifs d’un dataset, ce qui permet de faire entre autres des histogrammes empilés ou des nuages de mots.
- Authentification possible par clé d’API
- Création de miniatures pour les applications configurées
- Jeux de données virtuels : ce sont des jeux crées à partir d’autres jeux de données, par agrégation ou filtrage
- Plein d’autres choses mais j’ai déjà fait un gros pavé et je pense avoir mis l’essentiel …
Au niveau de la feuille de route :
- Nous commençons à travailler sur les jeux incrémentaux : ce sont des jeux qui seront persistés en base de données (jusqu’à présent on ne gérait que des fichiers). Cette fonctionnalité devrait faciliter le branchement avec d’autres applicatifs et permettre de supporter la diffusion d’informations en temps réel. La fonctionnalité devrait être disponible début 2019.
- Support de contraintes au niveau des schémas des jeux de données. Cette fonctionnalité sera mise en avant avec la réalisation d’une application autour du SCDL qui nécéssitera des jeux de données avec un schéma particulier.
- Nous attaqureons ensuite la traduction en anglais
- Il y a sans doutes une ou 2 idées que j’ai oublié, mais nous nous focaliserons surtout sur des améliorations de fonctionnalités existantes, le périmètre fonctionnel de la solution s’approchant de ce que l’on souhaite.
2 « J'aime »
Merci pour cette mise à jour ! C’est extrêmement intéressant et on voit que le projet devient très ambitieux dans ses fonctionnalités… Bravo !
1 « J'aime »
Question : la gestion du GTFS est-elle dans votre roadmap à long terme ?
1 « J'aime »
On l’avait évoqué, mais le cas n’est pas évident à traiter dans la mesure ou le GTFS correspond à plusieurs fichiers en relation entre eux et regroupés dans une archive. Data Fair se base sur des technologies NoSQL qui ne sont pas très adaptées à ce genre de cas. Il faudrait presque pouvoir générer plusieurs jeux de données à partir d’un fichier GTFS : le plan du réseau, les horaires des lignes, …
Pour l’instant, notre approche par rapport à ce format est que si on doit le gérer, on le fera dans un autre service a coté adapté à ces spécificités.
2 « J'aime »
Bonjour,
Cela fait quelques temps que nous n’avons pas donné de nouvelles concernant ce projet, et y a pas mal de choses à dire 
. Par rapport à ce que j’avais évoqué dans la feuille de route, il n’y a pas les contraintes sur les schémas des jeux de données, ni la traduction en anglais (qu’on espère attaquer cette année). Pour le reste :
Les jeux incrémentaux sont en place depuis quelques temps : ce sont des données stockées en base contrairement aux autres jeux de données provenant de fichiers, et on peut modifier ces jeux de données ligne par ligne (création, édition, suppression). Nous avons pour l’instant identifié 2 cas d’usage : publier des données temps réel ou issues de l’IoT, et récupérer des données à partir d’applications type formulaire. Dans le 2e cas, l’idée est de créer un jeu de données, configurer une visualisation type formulaire que l’on peut intégrer dans un site ou un portail de données, et récupérer les données soumises par les internautes.
Les données cartographiques (geoJSON, KML, SHP, …) sont supportées, et publiées sous forme de tuiles vectorielles. Ces données sont servies par l’API, et il est possible de télécharger un fichier mbtiles. Il est possible lors du chargement des données de changer la projection, pour par exemple passer du Lambert 93 à du WGS 84.
Il est maintenant possible de rajouter des pièces jointes aux jeux de données, à deux niveaux. Au niveau du jeu de données, pour par exemple fournir des fichiers de métadonnées complémentaires (notices pdf par exemple), et au niveau lignes : dans ce cas on charge un zip contenant des fichiers et il faut une colonne dans le jeu de données qui contient le chemin du fichier auquel la ligne correspond. On peut rajouter des images (des miniatures seront automatiquement générées), des fichiers pdf qui seront indexés (des recherches matchant le contenu de ces fichiers permet de filtrer les lignes du dataset) ou d’autre format qui ne recoivent dans ce cas pas de traitement particulier.
Il y a pas mal d’autre petites améliorations, mais la plupart des autres grosses fonctionnalités proviennent d’autres services que nous publions en open source (AGPL v3) : Data Fair Processings et Data Fair Portals.
Data Fair Processings permet de programmer des traitements périodiques. Cela peut être la mise à jour régulière d’un jeu de données à partir d’un fichier mis à disposition sur un espace d’échange (par exemple un fichier CSV publié sur un serveur HTTP ou FTP), ou la mise à jour en continu d’un jeu de données incrémental : il y a par exemple un plugin GTFS-RT qui permet de récupérer les positions temps réel de véchiules. Ce service est extensible : on peut soit contribuer en rajoutant des plugin traitant de formats standard, ou développer ses propres plugins en interne pour gérer des formats spécifiques ou privés et activer ses plugin lors de l’installation du service.
Data Fair Portals permet de créer des portails de données ouverts ou privés. Nous sommes en train de rajouter plusieurs fonctionnalités, notamment la gestions de pages de contenus, ce qui va permettre d’en faire un CMS orienté partage de données. Je reviendrai donner plus de précisions sur ce sujet bientôt. Un aperçu est disponible : le portail de l’ADEME, mais il n’utilise pas encore la dernière version.
Il nous reste aussi la partie sur les connecteurs de catalogue à revoir. Il est prévu de les gérer sous la forme d’un contrat d’API à implémenter, ce qui permettra de rajouter de nouveaux connecteurs à une installation au fil de l’eau et assez facilement. Il sera aussi bientot possible de faire de l’enrichissement d’un jeu de données à partir d’un autre jeu de données.
Avec tout cela, il est possible de monter un portail de données 100 % open source et gratuitement, mais sans cartographie, enrichissement de données, et avec un nombre de visualisations réduit. Les recettes pour concevoir ces fonctionnalités et que Data Fair puisse les comprendre sont cependant documentées, et nous mettons ces fonctionnalités à disposition sous forme d’abonnement.
Nous avons fait une bonne passe pour mettre à jour la documentation, mais il reste encore du boulot. La documentation est mise à jour régulièrement à cette adresse : https://koumoul-dev.github.io/data-fair/master/ . Vous y trouverez :
- Une présentation fonctionnelle
- Une présentation de l’architecture technique
- Une documentation d’installation
- Une documentation pour étendre les fonctionnalités de Data Fair (création de visualisations, APIs d’enrichiessements, …)
Pour chaque section, il est possible de générer un fichier PDF pour une lecture plus verticale avec l’icone imprimante sur chaque sommaire puis une impression dans un fichier PDF.
3 « J'aime »