2. Transformation des données

Un jeu de traduction défini dans un dictionnaire peut être utilisé pour modifier les valeurs de #HEADER d’un fichier ou objet CSVM, mais qu’en est-il des données du fichier cible ? Nous allons voir que nous pouvons aller assez loin si nous savons comment interagir avec une application.

Nous sommes d’accord que le périmètre de CSVM-1 couvre uniquement la syntaxe d’un fichier CSVM, et non les valeurs de données, d’ailleurs le parseur renvoie le bloc de données en tant que chaines de caractères. Les informations du champ  #TYPE (TEXT, NUMERIC…) ne sont pas utilisées par le parseur.

Mais elles pourraient être utilisées par une application, pour faire des conversions de types, en plus des transformations de noms/identifiants. Le fait qu’il est possible de définir les valeurs pour les mots-clés #TYPE et #WIDTH nous permets d’aller plus loin qu’un typage des données. Par exemple, nous pourrions inventer #TYPE=6*FLOAT pour dire que les données de cette colonne CSVM doivent être transformées en réels et multipliées par 6.0 (ou 6). C’est ce que nous appelons un standard. Sans autre information dans le champ #TYPE (par exemple sa valeur est positionnées sur NUMERIC) celui ci est assimilable à une multiplication par 1 ou 1.0 (entier ou réel). Donc il y a une certaine équivalence entre type et standard.

Mais nous pouvons aller plus loin et faire mieux, si nous voulions le faire. Prenons l’exemple d’une collaboration entre deux équipes, certaines colonnes d’un fichier CSVM préparé par l’équipe 1  qui utilise son propre dialecte ( TEAM1) doivent être renommées avant le transfert des données à l’équipe 2 (TEAM2). Mais chaque équipe utilise des unités différentes (ex. concentration massique au lieu d’unités molaires) pour chaque dialecte.

Celle ci, ayant lu le dictionnaire et le fichier CSVM, pourrait le faire si elle connaissait une règle permettant de transformer des Mol/l (moles par litres) en g/l (grammes par litres).  Nous pouvons la guider en inventant de nouveaux dialectes, dédiés à l’exécution des règles par l’application. Par exemple, il est possible d’ajouter des colonnes (TEAM1_UNITS, TEAM2_UNITS) codant pour les unités locales utilisées par chaque équipe.

Nous avons donc ajouté un nouveau standard, à destination de l’application. Dans le dictionnaire, les colonnes définies par les valeurs de #TEAM1_UNITS et #TEAM2_UNITS ne seront pas utilisées par les fonctions de conversion. En effet, les identifiants #TEAM1_UNITS et #TEAM2_UNITS ne sont pas définis dans les champs de données #HEADER des fichiers de données. Du coup on peut guider de manière externe l’application en incluant des dialectes de règles ce qui peut se résumer par ce schéma :

Nous avons donc une possibilité pour découpler la collecte entre thématiciens, informaticiens et curateurs, chacun pouvant alimenter un dictionnaire CSVM, le nombre de colonnes et de cellules vides n’a aucune importance, nous cherchons à conserver de l’information, pas à l’optimiser.

Un dictionnaire CSVM peut donc aussi être utilise pour sauver des connaissances minimales ou critiques sur un espace de données CSVM, en incluant des champs et dialectes supplémentaires.

Echappatoires sur les mots clés

Les dictionnaires sont des fichiers CSVM et peuvent être annotés comme un CSVM standard. Les lignes de remarques marquées par # dans le bloc de données ou de métadonnées sont utilisées. Ce qui est bien utile pour comprendre les transformations possible ou les sources à l’origine de dialectes. La seule règle est qu’un mot-clé CSVM (#TITLE, #HEADER, #TYPE, #WIDTH, #META) ne peut pas être utilisé, mais rien n’empêche d’utiliser des variantes telles que ‘# TITLE‘, ‘#_HEADER‘, ‘##HEADER‘ … en jouant, en quelque sorte, sur les mots. Le niveau d’annotation peut être élevé, car ces lignes ne sont pas prises en compte, par défaut, par le parseur CSVM.