2. Métadonnées et mots-clés

Les mots-clés #TITLE, #HEADER et #TYPE doivent obligatoirement être présents dans un fichier CSVM. Ils garantissent la généricité du format. Le mot-clé #META a été introduit, de manière à ajouter des informations supplémentaires au bloc de métadonnées. Ce mot-clé est optionnel : l’API de lecture de fichiers CSVM ne requiert que les trois premiers mots-clés, mais traitera également #META lorsqu’il est présent.

Le mot-clé #TITLE

Ce mot-clé permet de stocker une information générale relative au tableau, généralement sous la forme d’un titre. Il occupe une seule ligne et une seule cellule. Toutefois, la chaîne de caractères utilisée peut revêtir n’importe quelle signification, selon le choix de l’utilisateur. Dans le cas où l’on souhaiterait ajouter d’autres métadonnées de colonnes que celles spécifiées par #HEADER et #TYPE, il est préférable de recourir à #META plutôt qu’à #TITLE.

Le mot-clé #HEADER

Comme son nom l’indique, ce mot-clé définit les intitulés des colonnes, à l’instar de certaines variantes de fichiers CSV qui contiennent également ces informations. Les mots-clés #HEADER n’ont pas besoin d’être encadrés de guillemets simples ou doubles.

Le mot-clé #TYPE

Ce mot-clé permet de spécifier les types de données associés à chaque colonne, la spécification CSVM s’articule sur 4 points qui impactent sur le contenu du champ #TYPE :

Le parseur CSVM lit le fichier mais n’interprète pas les données, soit en se basant sur le format (explicite), soit en tenant compte des champs #TYPE pour faire des transformations de type.

Le parseur CSVM renvoie une structure de données qui inclue la table CSVM (par exemple une matrice) et tous les éléments (cellules) de cette table sont de type string.

Nous pouvons donc étiqueter les champs #TYPE avec n’importe quel type de données. En d’autres termes, les métadonnées incluses dans les champs #TYPE ne correspondent pas forcément à des types de données (float, int, string …) au sens du langage informatique utilisé par le parseur.  La lecture d’un fichier CSVM ne doit pas être contrainte par les types de données.

En conséquence, nous pouvons inventer de nouveaux types avec un contenu plus signifiant que syntaxique.

Pour illustrer ces axes par un exemple, prenons le cas d’un extrait de fichier CSV décrivant des données environnementales :

Nous constatons que les colonnes Diamètre et Densité pourraient contenir des valeurs numériques, tandis que la colonne Nature pourrait contenir des chaînes de caractères. Nous pouvons étiqueter les deux premières colonnes comme étant des données numériques et la troisième comme correspondant à des données textuelles. Par exemple le CSVM résultant pourrait être (nous utilisons cette fois le caractère | comme séparateur) :

Nous pouvons utiliser une nomenclature simplifiée, imaginons que dans un projet commun différents intervenants utilisent des noms de type différents pour les mêmes données, par exemple FLOAT, REAL, REELS … Il n’est pas nécessaire de se mettre d’accord pour la collecte de données, le travail de typage se fera un niveau applicatif, nous utilisons des étiquettes simplifiées, par exemple la nomenclature suivante :

• NUMERIC : données numériques (entiers ou flottants) ;
• TEXT : chaînes de caractères de longueur illimitée ;
• DATE : dates, selon les formats DD/MM/YYYY ou MM/DD/YYYY ;
• BOOLEAN : données binaires (valeurs 0/1, ou éventuellement représentées par « y/n » ou d’autres chaînes équivalentes). Concernant les colonnes BOOLEAN, les valeurs doivent être codées en 0 (faux) et 1 (vrai). Toutefois, un codage textuel peut aussi être accepté, tout est possible.

La couche applicative peut réaliser le typage en fonction des champs #TYPE ou en fonction des entêtes #HEADER (titre des colonnes) qu’elle relie à des connaissance ou des règles. Si nous voulons être plus explicites, nous pouvons utiliser des types de base tels que INTEGER, FLOAT, REAL, TEXT ou STRING …

Dans l’approche CSVM, c’est à l’application utilisatrice et non au parseur de faire la transformation des données vers des types cibles.

Le mot-clé #WIDTH

Ce mot-clé est employé lors des conversions de fichiers CSVM vers d’autres formats, notamment pour des affichages tabulaires sur des pages web (par exemple via des listes ou tableaux Javascript). La ligne #WIDTH peut être ignorée ou remplie de valeurs arbitraires (0, 10, 50, etc.). Ces valeurs correspondent à une unité conventionnelle, initialement assimilée à la largeur en pixels d’une colonne, mais qui constitue en réalité une approximation de la longueur maximale des chaînes de caractères contenues dans une colonne donnée. Lorsqu’aucune proportion correcte n’est fournie, le parseur peut être amené à recalculer ces valeurs. Néanmoins, la présence de cette ligne (même avec #WIDTH|0|0|0) est obligatoire dans tout fichier CSVM.

Le mot-clé #META 

Le mot-clé #META permet d’introduire des informations complémentaires. Son usage est fréquent pour stocker des références externes relatives aux données du tableau, telles que des adresses URL ou des références bibliographiques, une date d’enregistrement ou de modification, le nom d’un fichier source ou de données expérimentales en amont de l’ilot CSVM … La syntaxe peut inclure des séparateurs secondaires (par exemple des | ou ;  …) s’ils ne sont pas utilisés comme séparateurs principaux dans le fichier.

L’objectif est d’associer des items différents dans une même ligne #META (par exemple: fichier source | date de transformation | auteur).  Nous pouvons même utiliser des symboles tels que  <> pour embarquer de l’XML, ou faire la même chose avec du Json. A condition de rester sur la même ligne, ce type de champ doit rester un champ orienté métadonnées et limité.

Utilisation pour inactiver des colonnes
Mais nous pouvons aussi utiliser ce champ pour contrôler la manière dont on peut afficher une table ou bloquer des colonnes, par exemple prenons le cas d’une mini collection de composés chimiques (des inhibiteurs d’enzymes) au format CSVM, les tabulations apparaissent en rouge :

Nous remarquons que le ligne #META ne contient que des valeurs ‘yes‘ ou ‘no‘ en fonction de colonnes qui sont activées ou inactivées, un espace est utilisé en tant que séparateur secondaire entre ces valeurs. Si cette table est utilisée dans un workflow, nous avons l’information pour masquer certaines colonnes (il s’agit d’une ‘vue’ de la collection de données). L’exemple suivant montre le résultat dans le cas d’une table dynamique (HTML et composants Javascript) avec affichage des colonnes dépendant de la valeur du champ #META : 

Nous constatons dans cette sortie que le colonne pour laquelle #HEADER=SECTOR n’est pas affichée dans la table dynamique, elle correspond à la valeur ‘no‘ de #META. En fait, cette colonne SECTOR contient des valeurs qui permettent de filtrer les lignes. Par exemple une molécule de la table peut faire partie du projet ‘glcerase‘, si nous n’affichons qu’une partie de la table correspondant à ce projet (un filtre Javascript implémentant une requête), il est inutile d’afficher la colonne correspondant aux données utilisées par le filtre.