Un objectif à la base de CSX était d’implémenter un hub de données issu d’une chaine de publication. Il s’agissait de saisir nos informations dans un fichier OpenOffice puis d’exploiter cette source de données primaires. Il s’agissait de limiter les opérations de saisie les données étaient exposées sur un site web pour de la consultation ou si elles étaient utilisées dans d’autres processus. Du point de vue de la chaine de publication, les fichiers SXW (OpenOffice) pouvaient être transformés en fichiers XML Docbook via ooo2sdbk. Ces données XML pouvaient être filtrées (dictionnaires CSVM) et exploités de deux manières: i) un rendu HTML ou ii) une analyse, de manière à produire un index implémenté sous la forme d’une table CSVM (une ligne par fichier). Les colonnes de cette table correspondaient à des types d’informations extraites de chaque fichier XML. L’index CSVM pouvait être transformé en table Javascript dynamique, en reproduisant partiellement ou totalement les colonnes et un pointeur vers le document rendu en HTML (hub de données).

L’objectif de l’article est de montrer quelques exemples, avec l’œil de l’utilisateur final, donc au niveau du rendu (GXMLDISPLAY) de la table Javascript, augmentée ou non par des composants métiers.

Publication initiale : buidez.net (2011) – revu et mis à jour en 2025.

1. Une chaîne de publication

A partir de documents au format SXW nous produisions donc une collection de données et un index sommaire sur cette collection, en d’autres termes une ‘vue’ annotée de la collection, ce qui correspond au paradigme CSVM. La facilité et la qualité de l’indexation dépendait de la structure des documents OpenOffice. Par exemple, si nous faisions l’effort d’inclure un résumé dans chaque document, il apparaissait dans le XML-Dockbook dans la hiérarchie <article>.<articleinfo>.<abstract>.<title> et .<abstract>.<para>. Nous pouvions utiliser aussi les titres de premier niveau (hiérarchie <article>.<section>.<title>) en les fusionnant pour réaliser une sorte d’aperçu des chapitres du document, ce qui est parfois plus informatif qu’un résumé. Nous pouvions également utiliser d’autres blocs XML. Avec un peu d’habitude dans la manière de rédiger, nous pouvions réaliser des contenus hautement indexables.

Pour illustrer cette idée, l’image suivante montre l’extrait d’un document XML-Docbook, il s’agit d’un rapport d’analyse structurale concernant l’entrée 1NOF de la PDB :

Il s’agit du bloc <articleinfo> incluant un résumé (bloc <abstract>) et des métadonnées associées au document, telles que les auteurs, les dates d’édition ou de révision, des versions ou d’autres mots clés, qui sont injectables dans un index CSVM.

Une autre partie du même document, portant sur des blocs <section> et qui montre des titres ou des paragraphes :

Nous constatons, d’après les titres que la finalité est un cahier de laboratoire, avec une analyse préliminaire, et des annexes. En utilisant des mots clés ou des tables, utiles mais pensées ‘indexation’, nous pouvions également proposer plus de données pour être plus précis.

Au final, cet ensemble était représentatif du contenu de la collection, sans la lourdeur d’un système de GED et tout en restant ouvert. En effet, certaines informations (par exemple des tables telles que des listes de molécules ou d’interactions) pouvaient être captées du XML-Docbook et alimenter d’autres processus. Pour y arriver, il suffisait de définir un certain niveau de normalisation dans les documents, par exemple ces tables devaient systématiquement avoir un titre, de manière à faciliter les recherches.

Nous pouvions alors installer ces données sur un serveur web (pour consultation) et mettre à jour les index via une série de scripts automatisés. Disposant d’un index CSVM, il était également possible d’alimenter un SGBDR pour réaliser des recherches, par exemple sur plusieurs collections et critères. Ou de coupler le processus avec un outil d’indexation, par exemple Apache Lucene qui était développé à la même époque.

Nous avions donc défini ce que nous avons appelé des hubs de données, le terme entrepôt de données (data warehouse) ayant une signification informatique plus spécialisée. Ces hubs de données pouvaient être utilisés autant pour des données brutes que pour des données collectées (data museum).