Les dictionnaires CSVM permettent de mettre en œuvre un système de transformation s’appliquant à des tables CSVM. Ces manipulations peuvent inclure des conversions dans les métadonnées (par exemple changer le nom des colonnes) ou des conversions dans les données (par exemple filtrer et supprimer des colonnes). Elles s’appuient sur des dictionnaires qui incluent des informations applicables aux métadonnées de fichiers CSVM. Ces dictionnaires sont également des fichiers CSVM (ou des objets de type csvm_ptr) et sont lisibles par le même parseur que les fichiers CSVM classique. Cet article propose des spécifications et une méthodologie, avec un exemple concret en chimie.

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

1. Implémentation de dictionnaires CSVM

Le dictionnaire CSVM doit : 1) utiliser la même base qu’un fichier CSVM; 2) être lu sous la forme d’un objet csvm_ptr; et 3) intégrer toutes les informations nécessaires pour transformer un fichier CSVM en un autre. Nous allons voir comment définir un ensemble de traduction, le coder dans un dictionnaire CSVM et comment cet ensemble de traduction peut être utilisé pour transformer ou normaliser les données d’un fichier CSVM.

Un vocabulaire spécifique

Comme nous allons tordre CSVM un peu dans tous les sens, il nous faut disposer d’un cadre syntaxique simple :

• Notion – Si nous avons différents identifiants, titres de colonnes … correspondant à une même donnée, nous appelons ce terme une notion. Par exemple une distance, dans un contexte particulier qui ne nécessite pas une interprétation, est une notion.
• Identifiant – Il peut exister différents noms ou identifiants possibles associables à cette notion. Par exemple, cette distance pourrait être nommée (titre de colonne)  ‘DISTANCE‘, ‘Dist‘, ‘D‘, ‘distancia‘ … avec des combinaisons de majuscules et minuscules ou de langue (FR ou autre pays).
• Dialecte – Si nous avons des identifiants, pour plusieurs notions, qui forment un ensemble cohérent, il s’agit d’un dialecte. En d’autres termes, un jeu de translation (translation set). Par exemple le dialecte-1 définit les notions distance et masse en tant qu’identifiants ‘DISTANCE‘ et ‘POIDS‘.
• Type – Chaque notion correspond à un type de données unique, quel que soient le nombre de dialectes. Au sens CSVM et défini dans un champ #TYPE, par exemple #NUMERIC (ou #FLOAT, ou autre chose,  il n’y a pas de type numérique défini en CSVM). Nous pouvons étendre cette approche en définissant aussi (toujours au sens CSVM) une valeur #WIDTH associée à la notion.
• Dictionnaire – Il s’agit d’une table CSVM qui regroupe plusieurs notions (lignes) pour différents dialectes (colonnes).  C’est un ensemble cohérent et évolutif. En effet, un notion peut être connue ou non selon le dialecte, dans ce cas la valeur dans la table du dictionnaire correspondra à une cellule vide (ou équivalent comme ‘-‘). Par exemple, nous n’avons pas encore défini d’identifiant correspondant à la notion de masse dans le dialecte-4.

Résumons ces points avec deux notions (distance et masse) déclinées en 4 dialectes :

dialecte-1	dialecte-2	dialecte-3	dialecte-4	#TYPE	#WIDTH
DISTANCE	Dist	D	distancia	#NUMERIC	#10
POIDS	Masse	MW	–	#NUMERIC	#10

Chaque dialecte peut être défini par une chaine de caractères quelconque, par exemple ‘team-ES‘ au lieu de ‘dialecte-4‘, il ne faut surtout pas normaliser cet aspect.

L’intérêt de cette approche est de permettre une collecte de données collaborative, chacun disposant de son propre identifiant pour la même notion. En conséquence, chacun peut échanger ses tables de données (CSV ou CSVM, ou feuilles issues de tableurs, DataFrames …) avec les noms de colonnes qu’il veut. Nous ne sommes même pas obligés de définir un standard comme on le ferait pour une approche XML ou Json, nous pouvons même changer d’identifiant en chemin … Il s’agit d’un découplage complet entre collecte et modélisation de données, même s’il y a concurrence entre les deux processus.

Tant qu’il existe un dictionnaire (correctement alimenté) des informaticiens seront capables de tout traduire en un dialecte commun et les thématiciens pourront continuer à alimenter une collection de données sans contraintes de dialecte.

Structure de données et jeux de traduction

Le fichier CSVM ci-dessous correspond à une table d’inventaire chimique, limitée à six lignes et cinq colonnes pour simplifier l’exemple. Cette table code pour : un numéro de rang (numero), une structure chimique (fichier), une masse moléculaire exacte (masse_exacte), un nom commun de molécule (nom), et une quantité (c’est-à-dire g ou mg) disponible de produit chimique en laboratoire (vrac) :

Les #HEADER, #TYPE et #WIDTH que l’on trouve pour chaque colonne de cette table, définissent un premier dialecte  SYS1. Si l’on souhaite transférer les données vers un autre système avec des conventions de nommage différentes (par exemple, pour préparer l’importation dans un SGBDR), nous définirons un autre dialecte, par exemple SYS2. Pour accomplir cette tâche, nous pouvons encoder un dictionnaire CSVM :

La seule différence avec un fichier CSVM ‘standard’ réside dans le fait que certains mots-clés précédés du caractère # apparaissent dans les deux dernières colonnes des blocs de données et de métadonnées. Ces deux colonnes (ordonnées 4 et 5 de gauche à droite) sont utilisées pour stocker les types de données des ensembles de traduction, tandis que les colonnes de données (ordonnées 1, 2 et 3) contiennent les données de l’ensemble de traduction. Le dictionnaire CSVM stocke les noms de colonnes utilisés dans SYS1 (colonne orange) et attendus dans SYS2 (colonne rose) ou dans un autre dialecte (ex: SYS1_UK, colonne verte). Il contient également les champs #TYPE et #WIDTH correspondant à chaque notion.

Ainsi, toutes les informations nécessaires à la conversion d’un fichier CSVM utilisant SYS1 vers un autre dialecte sont présentes, puisque les valeurs #HEADER, #TYPE et #WIDTH de SYS1 et SYS2 figurent dans ce dictionnaire. Comme il est possible qu’une colonne (#HEADER) s’appelle TYPE ou WIDTH … de manière à éviter toute confusion, les métadonnées type et width sont marquées dans le bloc de données (colonnes bleues) par le caractère #.

Un dictionnaire CSVM peut donc aussi être défini comme un moyen de stocker les métadonnées de n fichiers CSVM dans le bloc de données d’un autre fichier CSVM.

Le dictionnaire précédent définit donc trois dialectes, utilisables pour une traduction :

• Jeu SYS1 : [numero, nom, fichier_mol, masse_exacte, vrac].
• Jeu SYS2 : [ID, identificateur, MOLSTRUCTURE, , vrac].
• Jeu SYS1_UK : traduction anglaise de SYS1 [number, name, molfile, mol.weight, quantity].