Ajouter explications sur les séparateurs et Table Schema

[johanricher]

(J'ai hésité sur le lieu pour avoir cette discussion, au final ici me paraît le plus adapté. En effet, les guides Etalab ont vocation à mon avis à faire référence en la matière et s'appliquer de façon canonique aux différents projets et produits *.data.gouv.fr)

Les séparateurs dans les fichiers tabulaires sont un sujet de désaccords récurrent. Pourtant, pour les producteurs de données, les séparateurs ne devraient avoir aucune espèce d'importance. Par exemple, l'utilisation des schémas Table Schema permet justement de supprimer certaines de ces préoccupations qui sont autant de frictions à l'ouverture des données.

La conversation qui a lieu depuis le 28 avril sur la page de la Base nationale consolidée des lieux de covoiturage illustre bien les différents problèmes.

Premièrement, il y a à la base l'éternel débat du point-virgule contre la virgule et la croyance qu'il y aurait un "standard CSV" à respecter. Il serait possible sur ce point de compléter le guide d'Etalab afin de casser les idées reçues sur le CSV. Les utilisateurs pourraient ainsi s'y référer.

Deuxièmement, le plus important pour moi serait d'expliquer que les séparateurs n'ont la plupart du temps pas d'importance. En particulier, documenter le fait que la spécification Table Schema n’a aucune notion de séparateur puisqu'on travaille sur des données tabulaires et pas que des CSV. En clair, un fichier sera valide s'il respecte le schéma, quel que soit le séparateur utilisé et même quel que soit son format tant qu'il est supporté (.csv, .xlsx, .xls, .ods...).

La documentation du SCDL, avec ses "recommandations pour le formatage des fichiers" rédigées par OpenDataFrance, entretient également cette confusion. Nous allons tâcher d'y remédier : https://git.opendatafrance.net/scdl/documentation/-/issues/12, mais je pense que ça sera plus facile de convaincre OpenDataFrance si Etalab montre la voie.

Enfin, il faudrait enlever toutes les mentions de séparateurs dans la documentation des schémas, en l'occurence celle du schéma des lieux de covoiturage. Pour clarifier encore davantage, il faudrait préciser que les producteurs peuvent choisir le séparateur (et le format tabulaire) qu'ils préférent.

Qu'en pensez-vous ? @geoffreyaldebert @abulte @fchabouis

[abulte]

Merci de soulever ce point ! Métaphoriquement, je pense qu'on est sur une boite de Pandore remplie de 🍿.

Néanmoins le sujet mérite d'être adressé. Je voudrais notamment écrire un guide ou enrichir notre page de doc.data.gouv.fr (cf existant https://doc.data.gouv.fr/a-propos/que-publier-et-comment-le-publier/#données-tabulaires) sur "comment produire un CSV" à destination du "grand public" et cette question y a toute sa place.

Je vais commencer par essayer de lister les "problèmes":

1. format : CSV vs le reste
2. séparateur de champs CSV
3. délimiteur de champs CSV
4. séparateur de décimales

Mon avis à chaud :

1. Promouvoir autre chose que le CSV me parait "dangereux" dans le sens où le mix entre forme et fond dans les outils de types tableur sont un vrai nid à confusion (pour rester poli). D'ailleurs je n'ai pas en tête les performances de validata sur ce sujet, mais côté csvapi je sais que c'est une vraie gageure. Point godwin : quid du .shp?
2. J'accepte très libéralement virgule et point virgule, j'ai plus de mal avec les séparateurs exotiques qui posent des problèmes à beaucoup d'outils dans la chaine de production et de diffusion.
3. double quote recommandé, pas de quote accepté. Idéalement https://docs.python.org/fr/3/library/csv.html#csv.QUOTE_NONNUMERIC — ce qui permet normalement de faire passer un numéro de SIREN comme texte dans un parser par exemple.
4. Sur celui-là je suis moins à l'aise et je n'ai pas d'avis tranché, il faut que je fasse plus de tests.

Il s'agit de simplifier la vie autant des producteurs que des utilisateurs des données qui n’ont plus à se préoccuper de ces questions pour eux futiles, et c’est bien ça l’objectif !

Je ne suis pas sûr qu'être parfaitement libéral dans notre documentation facilite la vie des producteurs et réutilisateurs. Etre très libéral dans les outils que nous écrivons, en revanche, oui. Mais malheureusement ou heureusement nous ne maitrisons pas l'ensemble de la chaîne de production et je pense que nous gagnerions à faire la promotion de bonnes pratiques qui seraient une balance entre contraintes et libertés.

[thbar]

Je commente car ça a un impact chez nous sur Transport (et dans ma vie en générale haha!).

1. CSV versus le reste: je trouve ça "dangereux" aussi car c'est une boite de pandore, pour différentes raisons:

• Si il y a trop de liberté, on peut techniquement exprimer du tabulaire sous de très nombreuses façons, y compris sur des formats assez peu faciles (voir difficiles) à consommer pour des réutilisateurs moyennement techniques (protobuf, parquet, avro etc etc). Quelqu'un pourrait donc dire "on respecte le schéma", mais produire du parquet, et ça n'arrangerait personne.
• Mettre une recommandation forte sur du CSV permet de simplifier le fonctionnement de l'écosystème et de standardiser. En tant que constructeur de pipelines de données ou ETL, se retrouver face à un CSV est bien plus simple que du XLSX ou du XLS (pour l'avoir fait un paquet de fois, dans différentes technos). Moins d'erreurs d'interprétation, de données corrompues (ça arrive).

2, 3, 4: historiquement tout cela (de mémoire) me semble venir quasi uniquement du comportement par défaut des tableurs en "culture française". Je ne sais pas si ça vient de Quattro Pro, de Excel ou de Lotus 123, mais bon l'idée est là. Il y a bien le RFC 4180 mais ce n'est qu'informatif (https://chriswarrick.com/blog/2017/04/07/csv-is-not-a-standard/).

À titre personnel, je trouve qu'on peut avoir un rôle relativement éducatif et un effet de levier en incitant le plus de monde, tant que possible, à standardiser sur UTF-8, séparateur ,, séparateur décimal ., car une fois que c'est fait, tout est homogène (la première étape des pipelines de données tabulaires que je mets en place est souvent une pré-conversion pour avoir quelque chose d'homogène derrière).

[abulte]

J'oubliais l'encodage ! UTF-8 of course ;-)

[fchabouis]

J'ajouterais aussi le retour chariot à la liste des variations possibles :P

Ce qui est fait avec https://contribuer.transport.data.gouv.fr/, c'est que théoriquement, un contributeur peut produire son csv comme il le veut (séparateurs, guillemets, retours chariots), que sa contribution est parsée avec la librairie papaparse, puis remise en csv avec la même librairie, mais en utilisant toujours les mêmes conventions. Ce qui nous permet d'avoir une cohérence dans le temps de notre base nationale, mais sans être trop tatillon sur ce que soumet le contributeur.

Il y a un point assez clair sur ce qu'on ne doit pas faire (et que l'on fait actuellement 🤦 ), c'est dire dans la doc du schéma qu'on veut des ; et publier une base nationale avec des ,.

[johanricher]

On voit bien avec le guide Etalab et la doc SCDL (entre autres) qu'en terme de recommandations (CSV, séparateur ,, séparateur décimal ., UTF-8, etc.) tout est déjà là donc ce n'est pas de là que viennent les problèmes. A mon avis, les frictions viennent plutôt des spécifications inutiles ou des incohérences qu'elles provoquent comme on peut le voir dans l'exemple que j'ai cité.

Ma position était en effet d'enlever au maximum les règles qui n'ont pas lieu d'être dans le cadre - bien spécifique - de l'ouverture sur datagouv des données conformes à des schémas Table Schema. Processus qui, à long terme, tendrait à se généraliser et qui permet de se concentrer dès à présent sur l'essentiel du travail : le contenu et faire en sorte qu'il soit conforme au schéma.

Dans ce cadre, les règles de formatage font, au mieux, perdre du temps pour rien car les logiciels majoritairement utilisés par les producteurs (Excel, Calc... bientôt publier.etalab.studio !) s'en chargent et, au pire, bloquent des utilisateurs qui ne sauront pas comment les respecter.

De toute façon les fichiers CSV vont continuer à être publiés suivant différentes caractéristiques (séparateur, dialecte, encodage...). C'est inévitable et ça serait contre-productif de punir les producteurs de données qui ne respectent pas des règles plus contraignantes. Par conséquent, celles-ci n'ont pas lieu d'être et il faut que l'outillage s'adapte. En fait on est déjà dans cette situation, mais ça irait mieux en le disant. 🙂

[akakeronos]

Le problème d'interprétation de ces recommandations est souvent dû aux difficultés rencontrées par les réutilisatrices ou réutilisateurs français de fichiers csv qui ouvrent ces fichiers avec Excel. En effet il me semble que par défaut excel ne gère pas bien l'ouverture des fichiers csv utilisant comme séparateur la virgule ni dans certains cas, l'encodage en utf-8.

Pour leur simplifier la vie, certains producteurs ou prescripteurs ont préconisé d'utiliser le ; comme séparateur de champs afin de rendre plus accessible les fichiers csv

En retour cela peut gêner certains outils comme CKAN qui par défaut utilisent le séparateur , pour la librairie de prévisualisation recline.js ou d'autres extensions utilisées pour cette fonctionnalité.

Préconiser la virgule comme séparateur de champs ne me semble pas ajouter de confusion pour les productrices ou producteurs de données à condition bien sûr que tout le monde préconise la même chose ;)

Je n'avais pas compris que tableSchema s'appliquait à la production de données en .xsl, .xslx ou .ods. Je pensais que c'était exclusivement réservé à la production de données en .csv.

Ça m'a toujours semblé bizarre de publier des fichiers opendata en utilisant les formats propriétaires de Microsoft et j'ai pu constater que cela posait parfois des problèmes dans les chaînes de traitement de données.

Côté OpendataFrance on a longuement hésité sur le séparateur à recommander et finalement on opterai plutôt pour une recommandation en faveur de l'utilisation de la virgule. Si c'est contre-productif on peut l'enlever.