Nouveaux guides pour Etalab et data.gouv.fr 📚

[Antonin_Garrone]

Bonjour à toutes et tous,

Nous avons travaillé à la refonte des guides et de la documentation de data.gouv.fr.

Cette nouvelle version a vocation à accompagner au mieux les démarches d’ouverture et de réutilisation de données.

Vous y trouverez ainsi des aides, des conseils et des bonnes pratiques pour :

• Répondre aux obligations légales d’ouverture de données publiques ;
• Améliorer la qualité de vos données ;
• Bien utiliser data.gouv.fr ;
• etc.

Ces nouveaux guides reprennent à la fois les guides d’Etalab et la documentation de data.gouv.fr en les enrichissant.

Voici le lien vers la premiere version (qui deviendra guides.data.gouv.fr)

Nous attendons vos retours avec impatience via un petit questionnaire.

Si vous avez d’autres ressources qui vous semblent pertinentes à référencer n’hésitez pas à nous le faire savoir

Merci !

[thomyphi (Thomy Philippe)]

Bonjour Antonin,

J’ai regardé attentivement le chapitre « lier des données à un référentiel » et je partage totalement ce qui y est présenté.

Par contre, je suis resté sur ma faim car je n’ai pas trouvé d’explication du mécanisme qui permet de décrire les référentiels et de lier les données aux référentiels.

C’est aussi une autre de mes « marottes » (cf après celle postée en réponse à la proposition d’aide à la publication) pour laquelle je « pousse » une solution :

• La solution consiste à ajouter une notion de « type » au nom d’un champ d’un fichier CSV ou bien dans une représentation JSON,
• le « type » correspond soit à une donnée standard (ex. date, position…), soit à une donnée d’un référentiel (les référentiels pouvant être imbriqués),
• par exemple pour un type standard:
  • {"mise à jour::date" : ["2021-02-01", "2022-02-03"]} est un Json qui porte le nom « mise à jour » et qui décrit une liste de deux valeurs de type date,
  • {"fin de vacances:date" : "2023-09-02"} est un Json qui décrit l’objet qui porte le nom « fin de vacance », de type « date » et de valeur « 2023-09-02 »
  • pour un champ d’un CSV, on aurait la même dénomination que dans le premier exemple : "mise à jour::date"
• pour les données des référentiels, on pourrait par exemple avoir dans le référentiel « fr » un type « siren », ce qui donnerait pour une liste d’entreprises : {"entreprises::fr.siren" : [ 1234, 5678]} ou bien un nom de champ dans un fichier CSV : "entreprises::fr.siren"

La mise en oeuvre prend alors deux formes :

• la construction du référentiel des « types » (sous une forme arborescente permettant une décentralisation),
• l’utilisation (optionnelle) des « types » dans les échanges de données

Ceci pourrait généraliser d’une part la notion de « variable-pivot » et d’autre part la notion de « format détecté » qu’on retrouve dans « explore.data.gouv ».

Nota :

• Cette notion de type intégré au nom est généralisé dans le format NTV (cf lien github qui inclut également une première liste de « types » standards)
• Une intégration au niveau de Pandas est envisagée (cf issue + PDEP (pandas enhancement proposal) (à suivre)
• Une conférence a été proposée pour « Opensource Experience » (à suivre)