2. Une base documentaire

Un exemple dans le domaine des sciences de l’environnement. Le processus commence à partir d’un ensemble de documents (livres, articles, rapports, documents divers) portant sur un lieu particulier (Malause), connu comme une zone de sédimentation dans une rivière (la Garonne, France). Il était question de générer une base documentaire, via un SGBDR, mais il aurait fallu prendre le temps du développement et de la modélisation de données. Est ce que cela valait ce type d’effort ?

Il s’agit de littérature grise, peu de documents étant indexés dans les systèmes bibliographiques. Après un processus de numérisation pour archivage, les données textuelles étaient extraites des fichiers PDF, filtrées, puis enregistrées dans des documents OpenOffice (en utilisant un modèle commun). Cette nouvelle collection de documents était ensuite utilisée comme source primaire par divers composants logiciels : conversion en XML (DocBook XML), en HTML, et analyse via un parseur XML dédié.

L’index CSVM

Les champs pertinents trouvés dans les documents (année, titre, résumé, etc.) étaient donc extraits et sauvegardés dans un fichier CSVM. La figure suivante montre un parseur CSVM en Perl affichant quelques colonnes du CSVM dans un widget sous forme de grille (wxGrid  de wxWidgets). La colonne DONNEES contient des liens vers les documents HTML correspondants (URL|Nom de l’URL), ANNEE correspond à l’année, TITLE au titre et RESUME au résumé. Nous notons qu’il y a une colonne FLORAISON qui est vide dans cet affichage, ce n’est pas une erreur, la table est compatible avec un processus de fusion avec d’autres ilots de données qui incluent une information de ce type.

Le fichier CSVM, en tant qu’index, intègre les informations extraites des documents. Au niveau du CSVM, il s’agit de données, au niveau des fichiers indexés (fichiers XML convertis en fichiers HTML) il s’agit de métadonnées.

Ces tâches étaient effectuées automatiquement, les conversions entre fichiers (texte brut, HTML, XML, XML-DocBook, HTML) ou les filtres pouvaient être configurées et pilotées par des fichiers CSVM. Par exemple, la figure suivante montre un fichier CSVM utilisé pour piloter des modifications dans l’index CSVM lui-même (chaque ligne correspond à un filtre appliqué à l’index).

La première colonne est utilisée pour stocker le type de filtre au moyen d’un mot-clé. Par exemple le mot-clé ‘STR‘ sert à spécifier un remplacement de chaîne : la valeur stockée dans la deuxième colonne est remplacée par la valeur de la troisième colonne. Il existe des filtres plus complexes que STR, qui nécessitent l’utilisation complète des dix colonnes, consulter l’article [ https://buildblog.buildez.fr/cxs-filtre-texter/ ] sur ce blog, pour avoir une idée de ce type de composant réactualisé.

Du CSVM à la table dynamique

L’index CSVM a ensuite été transformé en table Javascript et intégré à un framework JavaScript afin de fournir une vue de la collection destinée aux utilisateurs finaux. Avec l’image suivante, nous reconnaissons une table dynamique générée par GXMLDISPLAY (voir l’article [ https://buildblog.buildez.fr/javascript-gxmldisplay-et-tables-dynamiques/ ] sur ce blog). L’affichage est réalisé en mode liste, avec des boutons provoquant un tri étendu en fonction de la colonne.

L’image suivante montre une table dynamique générée par GXMLDISPLAY Les boutons situés en haut du tableau dynamique permettent de trier les données de l’index CSVM selon une colonne donnée, dans ce cas il s’agit de la colonne ANNEE.

Le bouton FLORAISON est encore présent, mais un paramétrage de GXMLDISPLAY permet de le faire disparaitre de la table dynamique (tout en gardant les informations dans la table JavaScript). Lorsque la chaîne de publication fonctionnait, il suffisait de rédiger le fichier CSVM et d’exécuter les scripts de transformation.