J’ouvre ce sujet pour faire suite à une discussion démarrée ce matin sur twitter à propos de la pérennisation d’opendatArchives :
Petit rappel
opendatArchives a démarré en août 2019, d’abord pour vérifier la faisabilité de l’idée, c’est à dire conserver une archive des données publiées en opendata, une archive de plus historisée.
J’ai écrit quelques script (en bash) qui parcourent les portails opendata régulièrement (data.gouv plusieurs fois par jour, sinon plutôt en quotidien ou en ponctuel pour certains).
Tout cela repose donc sur une initiative personnelle, sur mes ressources personnelles (mes petits doigts pour coder les scripts, mes € pour financer l’infra, mon temps pour gérer tout ça).
Pour pérenniser, une association me semble être une structure assez neutre et conforme à l’objet du projet initial.
Pour info, j’ai pas mal d’expérience associative, ma première remonte à 1981 (un club informatique).
Je suis plutôt radical sur le rôle d’une asso, qui pour moi ne doit pas empiéter sur le monde de l’entreprise (typiquement pas de prestation).
Une asso n’est pas un but en soit, mais un moyen qui n’existe que pour son objet, pas pour elle-même (dérive trop constatée malheureusement). Dans bien des cas, son objectif ultime devrait être de disparaitre car le but est atteint (j’aimerai voir la fermeture des restos du cœur devenus inutiles).
La définition de l’objet est donc essentielle !
Qu’en pensez-vous ?
Seriez-vous partant pour m’aider à monter l’asso, à la faire vivre ?
Il y a aussi l’option de ne pas créer de nouvelle structure et de rattacher l’initiative à une asso existante.
Si jamais cela t’intéresse, Code for France par exemple pourrait jouer ce rôle et je suis certain que le CA validerait l’idée, mais il en existe plein d’autres.
Je relance le sujet ! @cquest je lisais ton poste sur le setup du projet https://www.opendatarchives.fr/le-projet/
et je me demandais s’il existait une manière canonique de gérer l’open data versionnée/archivée ?
Je suis complètement novice dans ce domaine mais la question s’est posée récemment pour moi lorsque j’essayais de comparer toutes les versions d’un fichier de SpF.
Je pensais alors naïvement que la plateforme data.gouv gérait un historique des versions… De fait j’ai réussi à retrouver quelques versions antérieures, mais pas suffisamment… J’imagine que c’est dû au moissonage dont tu parles…
Finalement, j’ai fais un script pour récupérer toutes les versions disponibles du fichier à partir d’un repo git…
C’était un peu laborieux pour du one shot et je me demande si c’est adapté aux data mais ça m’a paru très logique de me servir de git…
(je repense à ça car je suis tombé là-dessus hier : https://qri.io/)
Rien ne semble bien canonique en la matière et vue la diversité des modes de diffusion des données, ça n’a rien d’évident de faire quelque chose de générique.
Pour data.gouv.fr, il y a les fichiers hébergés directement sur la plateforme et ceux où il n’y a qu’un lien vers leur emplacement externe à la plateforme.
Pour les premiers, le fonctionne interne de data.gouv fait qu’un fichier hébergé reste accessible par son URL qui est stable. Par contre, cette URL n’est plus exposée par le site web ou l’API si la ressource est délistée et on ne peut pas la retrouver facilement vu qu’elle contient la date/heure de dépôt du fichier.
Ensuite, chaque producteur de donnée à sa façon de publier un jeu de donnée évolutif…
par une nouvelle version, qui contient toujours plus de données en conservant ou pas dedans ce qui est obsolète (le fichier FANTOIR de la DGFiP est un bon exemple)
par de multiples fichiers qui représentent à chaque fois les nouvelles données
par un mix des deux (l’INSEE publiait SIRENE avec un stock mensuel et des mises à jour quotidiennes)
etc…
Pour les portails an SaaS chez opendatasoft, c’est totalement différent, les métadonnées indiquent si il y a eu un changement dans le contenu, dans ce cas, je récupère tout en csv + geojson pour ce qui est géographique, et je compare avec ce que j’avais déjà car parfois la métadonnée indique un changement, alors que le contenu est identique.
Chaque version d’un jeu de donnée est donc stockée comme un fichier autonome. Ce n’est pas optimal en espace de stockage, mais c’est simple à gérer et les contenus ne changent pas si souvent que ça.
On pourrait réduire l’espace en faisant des diff, façon git, mais la volumétrie actuelle ne l’exige pas.
Merci de ton retour. Effectivement, ça n’a pas l’air simple de généraliser une méthodologie.
En tout cas, toujours motivé si je peux aider sur cet énorme projet !
Totalement d’accord sur le besoin de créer une asso pour que tout ne repose pas sur les seules épaules de @cquest. De mon côté je pourrai léguer davantage d’€ que de temps. À moins qu’on étende le projet à la qualification sémantique des datasets et la création d’un moteur de recherche digne de ce nom
