Le concept de hiérarchie est omniprésent dans un environnement de programmation traditionnel. Les fichiers, les modules, les documentations, etc., sont organisés en hiérarchies. 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érarchie que le chemin qui y mène. De plus, la plupart de ces organisations hiérarchiques souffrent des exceptions.
Les systèmes de gestion de fichiers,
de programmation modulaire,
les documents hypertextes
et l'exploration d'Internet fournissent des exemples de ces organisations
navigationnelles,
et des exceptions que souffrent celles qui semblent hiérarchiques.
En effet,
un système de gestion de fichiers hiérarchique peut aussi offrir des
liens qui permettent d'aller d'un point à un autre quelles que soient
leurs positions relatives dans la hiérarchie.
Dans ce cas la structure de base est un graphe orienté quelconque
mais à dominante hiérarchique.
Les systèmes de modularité permettent d'importer plusieurs fois un même
module dans des contextes différents,
mais la plupart n'autorisent pas d'importation circulaire :
importe 
qui importe 
, etc., qui importe .
Ici,
la structure de base est un graphe orienté le plus souvent sans cycles.
Un document est souvent organisé en une hiérarchie de sections,
mais contient aussi un grand nombre de liens sous forme de références croisées,
d'index et de tables des matières.
Cela est déjà vrai pour les documents «papier»
et la notion d'hypertexte ne fait qu'animer ces liens.
Là,
la structure de base est un graphe orienté quelconque avec une composante
hiérarchique.
Avec le 
(World Wide Web, le Web),
le graphe devient arbitraire,
et presque plus hiérarchique.
Dans tous les cas,
le graphe est orienté et est le support d'une navigation.
On part d'un sommet racine (répertoire personnel, module principal, page titre,
home page)
et on ne peut atteindre un autre point qu'en suivant un chemin qui y mène.
Une grande partie de l'art du programmeur est donc de trouver son chemin dans ces graphes. Très souvent, sa mémoire ou ses connaissances ne suffisent pas et des robots le remplacent pour faire des parcours systématiques. Toutes les structures navigationnelles dont nous avons parlé ont été dotées de tels robots : la commande find pour le système de gestion de fichiers, des logiciels de gestion de version ou d'étude d'impact pour le logiciel, des indexeurs et navigateurs pour l'hypertexte et le Web. Malheureusement, ces robots sont eux-même difficilement contrôlables, ils manquent de discernement ou au contraire ils filtrent trop, et le plus souvent, ils délivrent des résultats où la structure originelle est oubliée.
Il est important de préserver la structure originelle du graphe, car même si elle est trop contraignante quand elle est considérée comme un espace de navigation, elle peut véhiculer de l'information, même si ce n'est que l'intention de l'auteur. Par exemple, si le serveur d'une université est organisé en cursus, et qu'un étudiant cherche où est enseignée la programmation logique, il vaudrait mieux que la réponse respecte l'organisation originelle car elle est vraiment opérationnelle pour contacter un responsable et s'inscrire. Si on cherche les modules logiciels concernés par telle opération de maintenance, il vaut mieux que le résultat apparaissent sous la forme d'un fragment de la hiérarchie originelle. Enfin, sur le Web un indexeur répond souvent à une requête par une liste de pages la satisfaisant, mais oublie complètement les relations qu'elles entretiennent. En particulier, il est assez ridicule, et finalement nuisible, de lister toutes les pages d'un serveur qui satisfont la requête ; un résumé des pages du serveur qui permettent d'atteindre les pages listées suffiraient largement.
En fait, la situation de ce domaine reflète celle des bases de données d'avant 1970, date à laquelle Codd propose le modèle relationnel [Codd 70]. Un modèle navigationnel domine alors, mais n'est pas satisfaisant. Cependant, nous ne pensons pas que le modèle des bases de données relationnelles soit la réponse au problème. En effet, le résultat d'une requête relationnelle étant une relation, il lui manque la représentation de la structure originelle. Dans ce cadre, ce qui s'approcherait le plus de notre objectif serait une forme de réponse constituée d'une base de données relationnelle où on trouverait les réponses au sens relationnel et la représentation de leur structure.
Nous avons entamé une réflexion sur des structures que nous appelons relationnelles et qui sont aux structures navigationnelles ce que la programmation logique et les bases de données relationnelles sont à la programmation impérative et aux bases de données navigationnelles. L'idée principale est de calculer des relations et de considérer leurs extréma comme des indices de structurations. Un tel calcul pourrait guider l'organisation de fichiers, de modules, ou de documentation. Il pourrait aussi être utilisé a posteriori pour faire apparaître de la structure là où elle n'est plus visible (navigation sur le Web). Dans son utilisation a posteriori, ce calcul peut être vu comme une forme de data-mining symbolique.