À la fin des années 1990, nous avions de nombreux problèmes conceptuels liés aux ensembles de données, brutes ou finalisées. C’était le cas en sciences de l’environnement ou nous avions des collectes sur le terrain, en laboratoire, des interactions avec d’autres disciplines expérimentales ou théoriques, jusqu’aux sciences sociales. Donc des cultures scientifiques et des données différentes à combiner dans des projets collaboratifs.

Egalement des problématiques de concurrence entre collecte de données et modélisation de données : les informaticiens attendant des données pour réaliser une base de données et les thématiciens attendant une base de données pour réaliser la collecte. Puis du temps pour le choix et la définition des données et métadonnées à intégrer dans le projet. En effet, le périmètre des données finalisées (exposables et valorisables dans des rapports, SGBDRs …) est focalisé sur la question scientifique alors que les données brutes peuvent être issues d’une collecte plus large. Finalement, le temps que tous ces développements se finalisent, les thématiciens ou les expérimentateurs passaient souvent à autre chose.

Ce contexte posait les questions, bien avant les notions d’innovation frugale, de l’intérêt à moyen terme de ces efforts (générer des bases de données pour tout et pour rien) et de la conservation des données à long terme.

Publications initiales : buidez.net (2012), rapports techniques sur arXiv (2012) – Version refondue et mise à jour en 2024-2025.

1. Des questionnements

Ces enjeux nous ont amenés à nous intéresser aux données brutes, en amont de ces problématiques, pour voir si nous étions résolutif à ce niveau. Mais au delà de ce choix, les questionnements étaient multiples :

• Comment agréger des données au sein de projets collaboratifs impliquant des acteurs de disciplines scientifiques différentes ?
• Comment assurer la lecture à long terme des données brutes (qu’elles soient destinées ou non à être intégrées dans une base) sans perte d’information ?
• Comment assurer une concurrence entre collecte et modélisation ? Notre objectif n’était pas de développer des techniques agiles de bases de données, mais bien de travailler directement sur les données brutes.
• Les données brutes constituent un ensemble élargi, allant au-delà des seules données utiles à une question scientifique précise. Là où un jeu de données en SGBDR est conçu et structuré pour répondre à un problème donné, les données brutes peuvent contenir de nombreuses informations apparemment non pertinentes, dont il est impossible de savoir si elles seront utiles ultérieurement. Donc comment produire un jeu de données en réponse à une stimulation scientifique donnée ?
• Cette représentation (sous forme de table ou de collection) devait être immédiatement exploitable pour générer ou alimenter des bases relationnelles.
• Nous voulions également favoriser l’intelligence collective inhérente aux projets collaboratifs, lesquels impliquent le partage de données entre divers champs scientifiques et institutions. Donc comment annoter les données, d’une manière lisible et compréhensible par l’ensemble des acteurs, de manière à automatiser des processus de transformation et de fusion.

2. Des constats

Dans le cadre de projets scientifiques collaboratifs, nous avons mené une première phase d’investigations (notamment au sein du programme PEVS du CNRS et du projet GIS-ECOBAG) dans le contexte des Ressources Écologiques à Long Terme (LTERs). Entre 1999 et 2002, nous avons progressivement défini le format et le type de métadonnées dont nous avions besoin. Une approche classique à une époque qui vivait des développements liés aux métadonnées (par exemple le Dublin Core). Et les résultats de cette réflexion se sont avérés surprenants sur plusieurs points :

• L’importance d’un minimum de métadonnées et d’une approche générique. Les échantillonnages de données qui étaient en notre possession nous incitaient à ne pas passer du temps à définir des jeux de métadonnées spécifiques par rapport à une problématique.
• XML ne nous amenait rien de plus, sachant que la plupart de nos données étaient tabulaires, sous la forme d’ilots de données (data islands). Typiquement une table, de l’ordre de quelques milliers de lignes et de quelques dizaines de colonnes, avec des ‘trous’ (colonnes vides ou données dispersées).
• Inutilité des SGBDRs pour bien gérer ces ilots de données. La plupart du temps, les tables étaient auto consistantes, il n’était pas nécessaire de développer un schéma, des tables multiples et des relations.
• Privilégier des fichiers plats (flat files) en mode ASCII ou Unicode. Une approche qui était naturelle (ex: banques de séquences et de structures dans les années 80-90s) en biologie/bioinformatique.

Cette orientation était en totale contradiction avec les idées dominantes à l’époque et pouvait causer une sorte de scepticisme pour d’autres acteurs orientés données, par exemple des services d’observation. Par contre, l’accueil était très favorable coté SHS, la démarche était instantanément comprise. Aujourd’hui, vis à vis d’autres problématiques ‘données’, sortir du modèle relationnel pur n’est plus exceptionnel, comme en a témoigné le mouvement NoSQL, les bases de données orientées objets …

3. Une réponse

La plupart de nos données correspondant à des tables ou des ilots de données, nous avons proposé un format de données simple, utilisable de manière générique, et restant aussi proche que possible du CSV.

La solution retenue a consisté à ajouter des métadonnées au tableau de données. Celles-ci devaient être génériques et limitées autant que possible : nous avons donc écarté les descripteurs propres à un domaine scientifique particulier, pour ne retenir que ceux relatifs aux données elles-mêmes, avec un minimum de modélisation. De plus, les métadonnées devaient rester succinctes : si leur rédaction exigeait un effort considérable de la part des utilisateurs, nous risquions d’échouer.

L’ensemble (données + métadonnées) devait enfin être compatible avec les outils habituellement employés par les scientifiques, ingénieurs ou techniciens (tableurs, éditeurs de texte). Pour cette raison, le bloc de métadonnées a été placé en fin de fichier, après le bloc de données, permettant ainsi une édition aisée dans un tableur ou un éditeur classique, tout en conservant la simplicité d’un format inspiré du CSV.

Pour illustrer cette idée, prenons un exemple de correspondance entre une table des données, puis un fichier CSVM, puis un objet Python encapsulant les données. Tout d’abord la table :

Nous avons 80 lignes et 8 colonnes nommées en rouge, la dernière colonne représente des molécules exprimées dans un format chimique (notation SMILES). Le fichier CSVM qui peut en être dérivé reprends le contenu de la table, au format CSV délimité par des tabulations (flèches rouges dans l’image suivante) et ajoute un bloc de métadonnées à la fin du fichier (lignes #TITLE, #HEADER, #TYPE, #WIDTH et #META) :

Dans cet exemple, la table n’a pas de titre, le champ #TITLE est vide, d’ailleurs ce champ peut servir à autre chose qu’un titre, son contenu est totalement libre, par exemple : nom de fichier, date, auteur, informations diverses …

#HEADER	Identifiants de colonne.
#TYPE	Type de données correspondant à la colonne, au sens CSVM. Cette notion sera développée à la suite.
#WIDTH	Indicateur de la ‘largeur’ de la colonne (qui ne sert que pour de l’affichage, des formulaires, ou une insertion dans un SGBDR ou ce type d’information est nécessaire)

Le fichier sera lu avec un parseur pour alimenter un objet csvm_ptr qui est défini via une classe Python ou l’on retrouve des éléments du fichier CSVM :

Nous remarquons que les types de données définies dans le fichier CSVM sont ‘exotiques’. Par exemple ‘TEXT‘ qui n’a aucune signification en Python, contrairement à string. La colonne vrac qui indique une quantité aurait pu avoir un type ‘NUMERIC‘ au lieu de float. En fait CSVM ne définit pas de type au sens informatique, le type CSVM est plutôt une information à destination de l’application qui va exploiter l’objet CSVM et qui en comprendra la sémantique. Donc toute identifiant est utilisable. Nous aurions pu typer la colonne molfile avec 'FILE‘ et la colonne smi avec ‘SMILES‘.

Une fois que l’objet est chargé, nous pouvons l’afficher (10 premières lignes pour alléger) via une méthode csvm_ptr_dump intégrée :

Ce qui ne se voit pas ici, c’est que le contenu des listes self.HEADER, self.TYPE et de la matrice self.DATA ne correspond qu’à des chaines de caractères. Le parseur n’interprète pas les types, ce travail est à la charge de l’application, ce n’est pas une insuffisance, c’est l’application d’une démarche qui nous libère de types au sens informatique. Le champ #META est optionnel, nous pouvons y placer n’importe quelle chaine de caractères évitant des sauts de ligne et le délimiteur utilisé dans le fichier (ici des tabulations), à notre convenance.

Le bloc métadonnées définit donc un jeu minimal d’informations, centrées sur les colonnes et la table, et sans norme prédéfinie quand au contenu, ce qui garantit la généricité du format.

4. Pousser le concept

Nous avons ajouté des possibilités intégrées de transformations de tables (dictionnaires CSVM), d’annotation, d’extensions … Ce qui définit en fait une démarche globale pour appréhender des ilots de données. Nous avons constaté qu’une architecture CSV (triviale) était capable de faire beaucoup de choses. Voire d’être plus intéressante que XML ou JSON dans certains cas. Le point clé c’est vraiment le parseur CSVM qui n’interprète pas les données, au niveau des types ou de la sémantique. Ce qui ouvre paradoxalement des possibilités inédites.

A partir du milieu des années 2000, le concept a été étendu à d’autres disciplines scientifiques (chimie, bio-informatique, sciences des protéines et enzymes). Le paradigme CSVM a parfaitement résisté, démontrant la validité du format en termes de généricité. Nous avons mis au point des preuves de concept (Perl) et opérationnelles (Python) au niveau du parseur, de passerelles vers d’autres matérialisations : XML, CSV, tables Javascript dynamiques, tables incluant des objets binaires ou métier (par exemple les molécules précédentes). Ce travail en termes de middleware, wrappers, pipes logiciels … nous a permis de constater que CSVM pouvait aussi être considéré comme un format pivot.

5. Data museum

Cet aspect ouvre d’autres perspectives, par exemple nous pouvons sauver une table CSVM en tant que données de référence (master) dans un processus. Et transformer une partie (une vue) de ces données vers un autre format ou l’intégrer dans un SGBDR (correspondant à la question scientifique). De fait nous répondons à une problématique ‘données’ sur le long terme, car nous sommes surs qu’un fichier texte plat, bien annoté, correspondant à la collecte, résistera mieux dans le temps qu’une base de données focalisée. Cette approche permettra également de conserver des données, non utilisées au moment de la vue, mais qui pourraient être utiles plus tard, fournissant la possibilité d’un t0 (temps zéro) de référence (1). Sur le moyen terme, c’est aussi la base de donnée qui peut disparaitre, celle ci n’étant plus développée.

Finalement, ce qui est critique c’est finalement plus les données brutes que les données finalisées. Celles ci dépendent de dispositifs (par exemple un SGBDR) qui s’affaiblissent dans le temps, alors qu’un fichier texte ne dépendra de rien. Paradoxalement, plus la durée est importante, plus les donnés dans la base peuvent être considérées comme perdues.

Pour nos ilots de données, l’idée d’un data museum cadre parfaitement avec la paradigme CSVM et la notion de collection de données. En effet, prenons l’exemple des tiroirs d’une collection qui pourrait contenir des fossiles. Physiquement, les tiroirs et les pièces sont très peu décrits, les métadonnées concernent une étiquette de tiroir, un numéro sur un fossile … Comme un fichier CSVM : avec un jeu de métadonnées volontairement réduit mais auto-documenté car elles font partie du fichier dès sa conception (et permettent également de l’indexer). Alors qu’une annotation externe (par exemple dans un contexte de GED) nécessitera un effort  d’écriture. Il ne reste qu’à définir et implémenter l’entrepôt de données adéquat (ce qui sortait de notre champ d’action).

6. Parseur et dictionnaires CSVM

Nous avons donc volontairement évité de définir des types de données précis (par exemple ‘TEXT‘ ou ‘NUMERIC‘) afin de signaler aux utilisateurs et aux concepteurs de logiciels que le format CSVM (en particulier la ligne #TYPE) ne doit pas être contraint par une interprétation normative des types.

En pratique, le parseur CSVM n’interprète pas directement les données en fonction des types déclarés : toutes les valeurs (en particulier #HEADER et #DATA) correspondent à des chaînes de caractères (scalaires, listes ou matrices) en mémoire. Le parseur est donc découplé du contenu, ce qui permet d’utiliser n’importe quel type de données dans un fichier CSVM. L’interprétation relève exclusivement de la couche applicative, qui s’appuie sur les métadonnées ou des règles prédéfinies.

Cette souplesse pose néanmoins un problème : que se passe-t-il si plusieurs acteurs (chargés de la collecte ou l’exploitant) utilisent des identifiants, des types, des normes (par exemple des unités de mesure) différents pour désigner la même donnée ? Pour répondre à cette difficulté, le format prévoit l’usage de fichiers complémentaires appelés dictionnaires CSVM.

Un dictionnaire CSVM est un fichier (lui même au format CSVM) qui documente les en-têtes utilisés dans d’autres fichiers, en précisant leurs unités, leurs types et leurs correspondances, à la manière d’un thésaurus. Par exemple, si certains acteurs utilisent ‘CONCENTRATION‘ et d’autres ‘MOL_CONC‘ ou ‘MASSIC_CONC‘, un dictionnaire permettra d’harmoniser ces variations et de ‘normaliser’ les données. Nous avons donc la possibilité de transformer le contenu d’une table CSVM, ou de fusionner plusieurs tables sans perte de cohérence. Le même parseur peut lire à la fois des fichiers CSVM contenant les données et des dictionnaires descripteurs de métadonnées. Cette approche ouvre la voie à des conversions systématiques de noms, d’unités ou de types entre fichiers. Le concept de dictionnaires CSVM constitue donc une première extension du format, lisible sans modification du parseur.

Ce qui permet d’implémenter des processus collaboratifs et de mettre en place une vraie concurrence entre collecte et modélisation. Si nous disposons d’un dictionnaire bien écrit, qui se complète au fur et à mesure de la collecte, il y aura toujours la possibilité d’une agrégation de données et de l’export vers une ‘vraie’ base de données.

7. Est ce que CSVM est FAIR ?

Le concept FAIR (Findable, Accessible, Interoperable, Reusable) exprime des idées autour de données que l’on pourrait trouver, qui soient accessibles, interopérables et réutilisables. Par définition CSVM est FAIR, même au niveau ‘trouvable’ car on peut à partir d’une masse d’ilots CSVM générer des index, il suffit de parser et de s’approprier certains éléments de métadonnées ou d’annotations.

Nous avons même poussé la démarche plus loin, à une époque il était facile d’accéder à des documents de type traitement de texte en générant un flot de données au format DocBook (ex: à partir d’OpenOffice). Le flot XML pouvait être même optimisé avec une écriture ‘réfléchie’ des titres, sous-titres et autres éléments (ex: titres de tables) du document. Nous pouvions alors produire un CSVM à partir du XML/docbook, et ces tables représentatives de documents (et non d’ilots de données) pouvaient être indexées.

CSVM est FAIR, presque 20 ans avant la publication de l’initiative Data FAIRport, mais je ne le revendique pas, car FAIR ne réponds pas, il me semble, aux questions à l’origine de CSVM. En particulier i) la gestion de la concurrence entre collecte et modélisation et ii) la conservation des données brutes et à leur annotation. Il me semble aussi que les acteurs FAIR ne sont pas sortis du paradigme base de données, certainement parce qu’ils sont sur des processus ‘données’ différents, extrêmement importants et qui l’imposent.

8. Est ce que CSVM est frugal ?

Soyons honnêtes, dans beaucoup de bases de données, les utilisateurs ne font pas des requêtes complexes. La plupart du temps, il s’agit d’une recherche sur un ou quelques critères, associée à un tri. Souvent c’est un besoin de consultation, seuls quelques utilisateurs avec droits étant autorisés à y accéder en écriture. Ce qui réponds aussi à des besoins de curation, si une base présente trop d’erreurs quelle est sa valeur ? Nos expériences en chimie, montrent que le taux d’erreur peut être de 10% sur la saisie manuelle de formules moléculaires. Donc, s’il s’agit de consulter des données dans ce contexte, un SGBDR peut être inutile. Une table dynamique (HTML/Javascript), focalisée sur la question, avec des possibilités de filtrage et de requêtes est souvent suffisante et très souvent plus facile à implémenter, en particulier s’il faut afficher des objets métier. Donc CSVM est frugal et écologique, il n’impose pas de serveurs de type SGBDR, tout en étant compatible avec l’import de données vers ceux ci.

Dans beaucoup de disciplines, pour des raisons d’agilité et d’adaptabilité, il vaut mieux savoir très bien gérer des ilots de données, dont l’existence est transitoire, que des bases de données sur un moyen terme. Il faut également savoir gérer des collections ou des index, et générer des vues adaptées à la question scientifique sous-jacente.

9. Conclusion

Les années big data ont ouvert d’autres perspectives, mais si nous sommons ces ilots de données qui existent un peu partout sur les postes utilisateurs ou les serveurs, la masse de cette longue traine des données (long trail of data) est phénoménale. CSVM s’inscrit également dans ce contexte car le format est favorable à des outils d’indexation de fichiers CSVM. Et ces index peuvent également être enregistrés en CSVM. Donc un seul parseur, générique mais permettant plusieurs finalités possibles, pour une économie de temps de programmation.

Rapports techniques (2012)

Technical Report: CSVM format for scientific tabular data [ https://doi.org/10.48550/arXiv.1207.5711 ].
Indexé dans Quantitative Methods (q-bio.QM); Software Engineering (cs.SE).
Version HAL [ https://hal.science/hal-00720153v2 ].

Technical report: CSVM dictionaries [ https://doi.org/10.48550/arXiv.1208.1934 ].
Indexé dans Computational Engineering, Finance, and Science (cs.CE); Quantitative Methods (q-bio.QM).
Version HAL [ https://hal.science/hal-00722937v1 ].

Technical Report: CSVM Ecosystem [ https://doi.org/10.48550/arXiv.1209.2946 ].
Indexé dans les catégories Computational Engineering, Finance, and Science (cs.CE); Data Structures and Algorithms (cs.DS); Quantitative Methods (q-bio.QM).
Version HAL [ https://hal.science/hal-00730995v1 ].