Le concept de hi´erarchie est omnipr´esent dans un environnement de programmation traditionnel. Les fichiers, les modules, les documentations, etc., sont organis´es en hi´erar- chies. Il serait plus exact de parler de structures navigationnelles car ce qui importe ce n’est pas tant le rang d’un objet dans la hi´erarchie que le chemin qui y m`ene. De plus, la plupart de ces organisations hi´erarchiques souffrent des exceptions.
Les syst`emes de gestion de fichiers, de programmation modulaire, les documents hy- pertextes et l’exploration d’Internet fournissent des exemples de ces organisations naviga- tionnelles, et des exceptions que souffrent celles qui semblent hi´erarchiques. En effet, un syst`eme de gestion de fichiers hi´erarchique peut aussi offrir des liens qui permettent d’aller d’un point `a un autre quelles que soient leurs positions relatives dans la hi´erarchie. Dans ce cas la structure de base est un graphe orient´e quelconque mais `a dominante hi´erarchique. Les syst`emes de modularit´e permettent d’importer plusieurs fois un mˆeme module dans des contextes diff´erents, mais la plupart n’autorisent pas d’importation circulaire :
M
0im- porteM
1 qui importeM
2, etc., qui importeM
0. Ici, la structure de base est un graphe orient´e le plus souvent sans cycles. Un document est souvent organis´e en une hi´erarchie de sections, mais contient aussi un grand nombre de liens sous forme de r´ef´erences crois´ees, d’index et de tables des mati`eres. Cela est d´ej`a vrai pour les documents((papier))et la no- tion d’hypertexte ne fait qu’animer ces liens. L`a, la structure de base est un graphe orient´e quelconque avec une composante hi´erarchique. Avec leWWW(World Wide Web, le Web), le graphe devient arbitraire, et presque plus hi´erarchique. Dans tous les cas, le graphe est orient´e et est le support d’une navigation. On part d’un sommet racine (r´epertoire person- nel, module principal, page titre, home page) et on ne peut atteindre un autre point qu’en suivant un chemin qui y m`ene.Une grande partie de l’art du programmeur est donc de trouver son chemin dans ces graphes. Tr`es souvent, sa m´emoire ou ses connaissances ne suffisent pas et des robots le remplacent pour faire des parcours syst´ematiques. Toutes les structures navigationnelles dont nous avons parl´e ont ´et´e dot´ees de tels robots : la commande find pour le syst`eme de gestion de fichiers, des logiciels de gestion de version ou d’´etude d’impact pour le logi- ciel, des indexeurs et navigateurs pour l’hypertexte et le Web. Malheureusement, ces robots sont eux-mˆeme difficilement contrˆolables, ils manquent de discernement ou au contraire ils filtrent trop, et le plus souvent, ils d´elivrent des r´esultats o`u la structure originelle est oubli´ee.
Il est important de pr´eserver la structure originelle du graphe, car mˆeme si elle est trop contraignante quand elle est consid´er´ee comme un espace de navigation, elle peut v´ehicu- ler de l’information, mˆeme si ce n’est que l’intention de l’auteur. Par exemple, si le serveur d’une universit´e est organis´e en cursus, et qu’un ´etudiant cherche o`u est enseign´ee la pro-
grammation logique, il vaudrait mieux que la r´eponse respecte l’organisation originelle car elle est vraiment op´erationnelle pour contacter un responsable et s’inscrire. Si on cherche les modules logiciels concern´es par telle op´eration de maintenance, il vaut mieux que le r´e- sultat apparaissent sous la forme d’un fragment de la hi´erarchie originelle. Enfin, sur le Web un indexeur r´epond souvent `a une requˆete par une liste de pages la satisfaisant, mais oublie compl`etement les relations qu’elles entretiennent. En particulier, il est assez ridicule, et fi- nalement nuisible, de lister toutes les pages d’un serveur qui satisfont la requˆete ; un r´esum´e des pages du serveur qui permettent d’atteindre les pages list´ees suffiraient largement.
En fait, la situation de ce domaine refl`ete celle des bases de donn´ees d’avant 1970, date `a laquelle Codd propose le mod`ele relationnel [Codd 70]. Un mod`ele navigationnel domine alors, mais n’est pas satisfaisant. Cependant, nous ne pensons pas que le mod`ele des bases de donn´ees relationnelles soit la r´eponse au probl`eme. En effet, le r´esultat d’une requˆete re- lationnelle ´etant une relation, il lui manque la repr´esentation de la structure originelle. Dans ce cadre, ce qui s’approcherait le plus de notre objectif serait une forme de r´eponse consti- tu´ee d’une base de donn´ees relationnelle o`u on trouverait les r´eponses au sens relationnel et la repr´esentation de leur structure.
Nous avons entam´e une r´eflexion sur des structures que nous appelons relationnelles et qui sont aux structures navigationnelles ce que la programmation logique et les bases de donn´ees relationnelles sont `a la programmation imp´erative et aux bases de donn´ees navi- gationnelles. L’id´ee principale est de calculer des relations et de consid´erer leurs extr´ema comme des indices de structurations. Un tel calcul pourrait guider l’organisation de fichiers, de modules, ou de documentation. Il pourrait aussi ˆetre utilis´e a posteriori pour faire appa- raˆıtre de la structure l`a o`u elle n’est plus visible (navigation sur le Web). Dans son utilisation a posteriori, ce calcul peut ˆetre vu comme une forme de data-mining symbolique.