H2PTM (1989) Richard

Quelques idées pour une modélisation

Des systèmes hypertextes

---

 
 

Titre Quelques idées pour une modélisation : Des systèmes hypertextes Auteurs Gilles Richard(i), Antoine Rizk(ii) Affiliations (i) LIFO, université d'Orléans, B.P.6759, 45067 Orléans Cedex 2 (Centre) (ii) INRIA Rocquencourt, B.P.105 - Rocquencourt, 78153 Le Chesnay Cedex (Île-de-France, France) Dans actes du colloque H2PTM 1989 Paris publié dans H²PTM89 : Communication interactive, Paris, France, 1990

Résumé

Nous présentons ici quelques idées pour formaliser les concepts de base des systèmes hypertextes. Bien que la grande diversité des systèmes existants ne permette pas de donner une définition précise et complète de ce qu'est un système hypertexte, certaines notions de base (les ancres, les différents types de liens, etc...) sont suffisamment bien dégagées d'un point de vue intuitif pour pouvoir faire l'objet d'une définition formelle. Notre approche, inspirée des travaux de Garg([GAR88]) et de ceux de Abiteboul et Hull [AH87] sur les bases de données, est ensembliste et relationnelle: elle devrait permettre d'intégrer sans difficultés majeures les concepts hypertextes nouveaux qui se dégageraient dans l'avenir comme étant les plus pertinents. Sans prétendre à l'université, notre travail constitue un pas vers une formalisation nécessaire des systèmes hypertextes, à l'image de ce qui s'est construit peu à peu pour les bases de données et qui participe de leur maturité.

Introduction

L’intérêt pour les systèmes hypermédia a été grandissant ces dernières années. En conséquence, les prototypes de recherche aussi bien que les produits industriels supportant de tels systèmes, ont proliférés, allant de l’extension simple d'éditeurs structurés ou non comme GRIF [QUI86, QUI 89 ] ou CENTAUR [BOR87], à l'interface de gestion d'outils comme NextStep de la station NEXT, en passant par la gestion des bases de données, les serveurs basés sur les transactions comme la machine abstraite HAM [CAM87], ou bien encore la gestion de la durée de vie des documents d'un système de génie logiciel comme DIF [GAR88] ou [SAN89].

Au delà des particularités propres à chaque logiciel, ces systèmes tendent à se différencier assez largement quant à la philosophie qui a présidé à leur conception : paradigme orienté-objet [CHL89], édition structurée [VER89], etc... Cependant, un système hypertexte doit nécessairement implanter un certain nombre de concepts de base pour mériter ce nom.

Il n'est pas dans notre intention de décider ici quelles doivent être ces notions fondamentales : on peut d'ailleurs se reporter pour de tels travaux à Conklin [CON87], Dexter [HAL88], Halasz [HAL89]. Notre but est plus modeste : il s'agît simplement, partant de l'observation des systèmes les plus répandus et des diverses tentatives de formalisation dans ce domaine [GAR88, CHL89], de donner une description mathématique simple de quelques concepts de bases et de montrer qu'il est possible de poursuivre dans la même voie pour introduire de nouvelles notions.

Pour l'instant, aucun modèle formel universellement reconnu n'a été fourni pour modéliser les systèmes hypertextes. Cependant, comme dans d'autres domaines de l'informatique, la nécessité d'un tel modèle se fait sentir, ne serait-ce que pour assurer la consistence des applications actuelles ainsi que des applications à venir (sauf à admettre qu'il suffit qu'une application "tourne" pour avoir prouvé l'absence d'inconsistence!). On peut d'ailleurs se reporter à la littérature abondante à ce sujet pour les bases de données afin de mesurer l'importance d'une telle modélisation.

Notre but dans cet article est donc de fournir une base formelle pour les applications hypertextes. Plutôt que de faire la n+lième tentative, nous préférons partir des travaux de Garg ([GAR88]), qui nous semblent suffisamment pertinents et généraux pour modéliser toutes les facettes de notre objet. Ce document nécessite cependant d'être précisé et approfondi pour générer des résultats pratiques. Le point de vue adopté est un point de vue ensembliste et relationnel [AH87], [PS 87], fortement inspiré de ce qui se fait pour les bases de données, mais modifié en fonction des concepts inhérents aux systèmes hypertextes. En d'autres termes, nous introduisons les concepts de liens ou ancres, de média élément et de document hypertexte.

Notre papier est organisé de la manière suivante : dans la section 1, nous présentons de façon informelle le modèle choisi afin de faciliter la lecture de la section 2 qui introduit le formalisme. La section 3 est dédiée à la présentation rapide de quelques concepts usuels qui peuvent être intégrés facilement au modèle de base. Dans la section 4, nous exposons en quoi notre modèle est en adéquation avec des systèmes réels (Hypercard, Notecards, GRIF, ...). La section 5 est une comparaison avec d'autres travaux existants dans ce domaine et la section 6 évoque les futurs travaux. Enfin, nous concluons dans la section 7.

Présentation informelle de notre modèle

Dans cette section, nous introduisons de manière informelle les différents constituants de notre modèle. Nous avons ici deux objectifs au moins :

• d'une part, faciliter la lecture de la partie formelle en soutenant l'intuition du lecteur (courageux!)

• d'autre part, justifier l’adéquation qu'il y a entre nos concepts formels et les objets concrets dont ils sont censés décrire le comportement

On se donne 2 ensembles de symboles D et I, non vides et disjoints. Les élément de D seront les types atomiques et les éléments de I seront les objets informatifs atomiques.

Par D, nous entendons, par exemple, les types suivants : livres, documents scientifiques, graphiques, etc...

Par I, nous entendons : les caractères, les mots , les cercles, etc...

Naturellement, selon l'application considérée, de nombreux autres types et objets peuvent être considérés. A chaque type d est associé un sous ensemble de I qui représente toutes les instances possibles du type d.

Le mécanisme d'instanciation permet donc de relier D et I.

Sur D, on définit ensuite les opérations classiques qui sont :

• généralisation
• agrégation
• composition
• spécialisation

Ces opérations permettent de construire, à partir des types atomiques, des types structurés plus sophistiqués modélisant une réalité plus complexe. La construction de ces nouveaux types est liée à celle de leurs instances : aux différentes opérations précédentes, correspondent des mécanismes particuliers d'instanciation différents permettant d'associer à des types structurés des objets informatifs nouveaux.

La clôture de D pour ces différentes opérations (ce sont des opérations permettant de construire de nouveaux types à partir de types atomiques donnés) constitue l'ensemble des types noté ID.

On distingue dans D deux symboles particuliers HD et ME sur les instances desquels on impose un certain nombre de contraintes qui sont :

• i) tout n-uplet d’éléments de I est de type ME (ME dénote le type média-élément)

• ii) tout n-uplet d'éléments de type ME est de type HD (HD dénote le type hypermédia document)

En d'autres termes, ME est le type de toutes les "agrégations" possibles (n-uplets d'éléments de I) et HD est le type de toutes les "agrégations" possibles du type ME. L'ensemble I permet donc de définir dom(ME) et dom(HD). On veut signifier par là qu'un média élément est un assemblage d'objets informatifs atomiques. Typiquement, on dispose d'un texte constitué de paragraphes au sens usuel et d'ancres permettant de changer de document ou bien d’éxécuter un script prédéfini. Un document hypertexte est un assemblage de média éléments : pour simplifier, la représentation physique d'un document est une succession de fenêtres, chaque fenêtre étant la représentation d'un média élément (i.e. un texte ou un dessin ou un document vidéo, etc...).

Naturellement, ces deux types ME et HD constituent des concepts essentiels dans le cadre d'un système hypertexte. Il nous reste à définir les ancres.

Pour ce faire, on se donne un ensemble de 6 relations binaires R_i, 1 ≤ i≤ 6, de profil respectif I x I,

I x ME, I x HD, ME x ME, ME x HD, HD x HD : ces relations définissent des liens entre différents objets et traduisent la notion de lien hypertexte. Il en découle la notion d'ancre (objet actif), classique dans les systèmes hypertextes.

Il est alors relativement aisé d’introduire un mécanisme spécifiant les divers attributs que l'on trouve dans les systèmes hypertextes. Dans la même direction, on peut spécifier la nuance entre les liens insertionnels et les liens référentiels ; les liens référentiels permettent de passer d'un document à un autre en quittant le document courant (avec retour possible) alors que les liens insertionnels, après activation, ajoutent en quelque sorte le contenu informatif du document lié au document courant. De même, nous décrivons les mots clé comme des objets informatifs particuliers possédant des propriétés classiques de propragation : en effet, les mots clé, non seulement apportent de l'information au document qui les contient, mais encore servent de support pour certains mécanismes de filtrage.

Présentation formelle

Les objets informatifs et les types

les types

On se donne deux ensembles infinis disjoints D et I : D « I = Ø.

Déf.1: Les éléments de D sont appelés les types atomiques. Les éléments de I sont appelés les objets informatifs atomiques.

On distingue dans D deux symboles particuliers ME (média élément) et HD (document hypertexte).

Un type sera entièrement défini dès que l'on connaîtra son domaine, par analogie avec la théorie intuitionniste des types où une formule (ou type) est définie par la donnée de ses preuves.

domaine d'un type

On suppose que pour tout type d Œ D, distinct de ME et HD, il existe une partie non vide de I, dom(d) telle que :

• i) si d ≠ d'alors dom(d) « dom(d') = Ø

• ii) » dom (d) = I

dŒD

Il découle immédiatement des deux propriétés précédentes que, pour toute partie P de I, il existe au plus un type atomique d tel P = dom(d) (il peut éventuellement ne pas en exister).

Déf.2 : dom(d) est l'ensemble des objets informatifs de type d : on l'appelle domaine de d. La propriété i) signifie qu'un objet informatif atomique donné n'a qu'un seul type atomique. La propriété ii) signifie qu'il n'y a pas d'objets atomiques sans type : ceci correspond à la propriété pour un hypertexte d'être "fortement défini" des travaux de Garg [GAR88]. La définition des domaines de ME et HD relève d'un autre mécanisme :

Déf.3 : Le domaine de ME est l'ensemble des n-uplets d'éléments de I et le domaine de HD est l'ensemble des n-uplets d'éléments de type ME.

On a donc : dom(ME) = » Iⁿ et dom(HD) = » dom(ME)ⁿ

n ΠIN n ΠIN

Les objets de type ME et ceux de type HD ne sont donc pas des objets informatifs atomiques bien que leurs types le soient. Les éléments de type ME seront appelés média éléments et ceux de type HD seront appelés documents hypertextes.

Pour un objet i et un type d donnés, on notera i Œ d pour signifier que i Œ dom(d) et on lira i est de type d ou i est une instance du type d.

Mécanismes d'abstraction sur les types

Agrégation

Déf.4 : Etant donnés n types d_i , i Œ[1, n], le type agrégé des d_i, noté a = (d₁,..., d_n) est l'unique type dont le domaine est le produit cartésien des dom(d_i) :

dom(a) = { (i₁,..., i_n) / n>0 et " j Œ[1, n] , i_j Œ dom(d_j)}

Les di sont les composantes de l'agrégat a. Un objet de type agrégé est ordonné canoniquement par l'ordre de ses composantes.

Si l'on se donne un type générique W dont le domaine serait I et que l'on se reporte à la définition du domaine du type ME, on voit que ME serait le type de toutes les aggregations finies du type W. De la même manière, HD est le type de toutes les agrégations finies possibles du type ME.

Généralisation

Déf.5. : Etant donnés n types di, i Œ[1, n], le type généralisé des d_i, noté g = {d₁,..., d_n) est l'unique type dont le domaine est la réunion des domaines de ses constituants :

dom(g) = » dom(di) i Œ[1, n]

Déf.6 : Etant donnés 2 types g et d, on dit que g est une généralisation de d ssi dom(d) Ã dom(g). Notons que :

- un type atomique ne peut être une généralisation d'un type donné d'après la propriété d'intersection vide des domaines des types atomiques

- un type donné peut naturellement avoir plusieurs généralisations

- un élément informatif i Œ I peut avoir plusieurs types (mais un seul type atomique) au sens indiqué plus haut : si i est de type d et que g généralise d, alors i est aussi de type g. Ceci ne fait que formaliser une notion intuitivement évidente et naturelle.

Propriété 1 : La relation GEN définit sur les types par :

g GEN d ssi g est une généralisation de d

est une relation d'ordre partiel sur les types. Elle satisfait donc l'axiome 4.4 de [GAR88] (preuve triviale liée aux propriétés de la relation d'inclusion sur les ensembles).

L'ensemble des types ID muni de la relation GEN est donc un poset : ceci est le pendant avec notre formalisme du lemme 2 de [GAR88].

Propriété 2 : Le type généralisé des d_i (i Œ [1, n]) est la borne supérieure de l'ensemble {d_i /i Œ [1, n]} dans le poset ID.

Comme dans [GAR88], il est aisé maintenant de définir le niveau de généralité d'un objet comme la hauteur de son type dans le poset ID.

Note : contrairement à [GAR88], la relation de généralisation n’est définie que sur les types (et non sur les objets informatifs). Le mécanisme de généralisation ne permet pas, dans notre formalisme, de passer des objets aux types : l'axiome 4.5 de [GAR88] ne peut donc être satisfait.

Composition

Déf.7 : Etant donnés n types di, i Œ [1, n], le type composite des d_i, noté c = <d₁,..., d_n> est l'unique type dont le domaine est l'ensemble des parties à n éléments {i₁,..., i_n) tels que i_j Œ dom(d_j) :

dom(c) = { (i₁,i_n} / n>0 et " jŒ[l, n] , i_j Œ dom(d_j)}

La différence entre le type composite et le type agrégé est qu'il n'y a pas de notion d'ordre canonique pour les éléments de type composite. Les opérations de généralisation, d'agrégation et de composition peuvent se répéter récursivement pour définir de nouveaux types.

Note : Il est possible de considérer explicitement les types comme des termes ou des arbres construits sur les constantes constituées par les types atomiques en utilisant les différentes opérations indiquées précédemment et en donnant explicitement des symboles de fonction particuliers pour chaque construction. Ce point de vue a été adopté pour les bases de données (cf [AH87]) : pour l'instant, il ne nous semble pas nécessaire de l'adopter ici.

Remarque : Par abus de langage, nous dirons qu'un objet informatif appartient à un objet composé ou agrégé s'il est une composante de cet objet. De la même manière, on dira qu'un objet informatif appartient à un média élément s'il est une composante de ce média élément, qu'il appartient à un document hypertexte s'il appartient à un média élément appartenant à ce document

Spécialisation

On définit en quelque sorte ici l'opération inverse de la généralisation.

Déf.8 : Etant donnés 2 types d et s, on dit que s est une spécialisation de d ssi d est une généralisation de s.

Notons que :

• un type atomique ne peut pas être spécialisé

• étant donnés n types d_i, i Œ [1, n], leur plus grande spécialisation est le type d de domaine « dom(d_i), s'il existe.

Maintenant que l'on a défini les opérations de base sur les types, il nous reste à expliciter la notion de lien, essentiel dans le contexte hypertexte, et qui fait la différence avec l'univers des bases de données. La notion de lien est relative aux objets informatifs et non aux types : en d'autres termes, nous souhaitons maintenant imposer des contraintes sur les objets, qui modéliseront l'univers réel. Ceci est l'objet de la section suivante.

Les relations sur les objets informatifs

Les trois ensembles d'objets qui nous concernent maintenant sont I, dom(ME) et dom(HD). En effet ME et HD sont les types d'intérêt dans le cadre hypertexte. A partir de ces trois ensembles, on se donne un ensemble de 6 relations binaires Ri (1≤ i ≤ 6) de profil respectif I x I, I x dom(ME), I x dom(HD), dom(ME) x dom(ME), dom(ME) x dom(HD), dom(HD) x dom(HD) qui établissent des liens entre les différentes entités définies précédemment. Ces relations modélisent les liens existants entre les différentes entités d'un système hypertexte : aussi certaines contraintes seront elles imposées. On convient de noter H l'ensemble I » dom(ME) » dom(HD). Les contraintes que nous imposons sont les suivantes :

a) toutes les relations sont symétriques, ce qui signifie que, si l'on peut accéder à un élément d(estination) à partir d'un élément s(ource), alors il est possible de revenir à s à partir de d :

"i Π[1,6] s R_i d fi d R_i s

b) tout élément est accessible à partir de tout autre: en effet, supposer le contraire impliquerait l'existence d'une entité que l'on ne pourrait atteindre et donc cette entité serait considérée comme ne faisant pas partie du système. De manière plus précise:

Déf.9.: x, y Œ H : y est accessible à partir de x ssi il satisfait l'une des deux propriétés suivantes :

• i) 'i Œ [1,6] tel que x R_i y (y est directement accessible à partir de x)

• ii) 'i Œ [1, 6] et z Œ H tel que x R_i z et y est accessible à partir de z

Notons Ac, la relation "être accessible à partir de". Elle est trivialement transitive et l'ensemble H doit être connexe pour cette relation.

c) enfin, on impose qu'à l'intérieur d’un même média élément (respectivement document) tout objet informatif (respectivement média élément) soit directement accessible, ce qui se traduit formellement par :

" me = (...,o,...,o',...) Œ ME, o R₁ o' et (o' R₁ o)

" hd = (...,me,...,me',...) Œ HD, me RR₄ me' et (me' R₄ me)

Note : En fait, dans la plupart des systèmes, on peut toujours revenir au point d'où l'on est parti mais pas nécessairement par le même chemin : c’est pourquoi la condition a) semble trop forte et elle doit être remplacée par la condition a') suivante :

a') la relation Ac est symétrique.i.e. : "s, d Œ H, s Ac d fi d Ac s

On arrive maintenant à la définition d'un hypertexte :

Déf.lO : L'ensemble H muni des relations Ri, i Œ [1,6], est un hypertexte si et seulement si il satisfait les 3 propriétés a'), b), et c) précédentes. Revenons aux objets informatifs i.e. les éléments de I.

Déf.11 : un objet informatif o est appelé ancre ssi il satisfait l'une des trois propriétés suivantes :

i) ' o' Œ I,o et o' n'appartenant pas au même média élément tel que: o R₁ o'

ii) ' me Œ ME tel que : o R₂ me

iii) ' hd Œ HD tel que : o R₃ hd

En d'autres termes, une ancre est un objet particulier qui permet d’établir un lien avec un objet d'un autre média, ou bien avec un média d'un autre document, ou bien avec un autre document. Une ancre peut naturellement être reliée à plusieurs objets (on clique une fois, deux fois, etc...)

Déf.12 : tout objet qui n'est pas une ancre est appelé un paragraphe (généralisé).

On peut donc parler d'objets actifs (les ancres) et d'objets inactifs (les paragraphes).

Note : un texte usuel est un média élément sans objets actifs, et est donc constitué uniquement de paragraphes ! Intuitivement, un paragraphe ne permet pas “d'échapper” au texte courant : c'est seulement le moyen dont on dispose pour passer au suivant (notion d'ordre). Au contraire, une ancre permet de "quitter" le texte courant.

Quelques éléments supplémentaires

Dans cette section, nous montrons qu'il est possible (et même nécessaire!) d'enrichir les concepts de base présentés au dessus afin de modéliser d'autres aspects des hypertextes qui sont implantés dans de nombreuses applications particulières.

a) les attributs

On se donne un ensemble A, ensemble de symboles dénotant les attributs et un ensemble V dénotant les valeurs possibles de ces attributs :

" a Œ A, ' val(a) à V, dénotant l'ensemble des valeurs possibles de a.

Ces attributs sont reliés à D par la fonction att :

D Æ P(A)

d Æ att(d)

att(d) est l'ensemble des attributs du type d : toute instance de d héritera des attributs de d.

Si i est une instance de d (i Œ d), alors a(i) Œ val(a) dénote la valeur de l'attribut a de d pour l'instance i.

Nous ne décrivons pas ici de mécanisme général de propagation des attributs pour les types structurés car ces mécanismes peuvent varier selon l'attribut considéré (ex.: nombre de lignes, date de création, fonte utilisée, etc...).

D'autre part, on peut, si on le souhaite envisager des attributs plus sophistiqués et donc structurés : ce n'est pas notre but ici mais on peut néanmoins se reporter aux travaux de [PS87] pour l'étude d'attributs structurés : ces travaux sont relatifs aux bases de données mais peuvent probablement s’adapter sans difficultés majeures au contexte hypertexte.

b) les différents liens

Nous proposons ici une méthode pour modéliser deux types de liens entre documents usuellement implantés dans les systèmes hypertextes : nous les appellerons liens insertionnels et liens référentiels . Nous simplifions le problème en ne considérant dans un premier temps que des liens entre un objet informatif inséré dans un document hypertexte et un autre document hypertexte. Pour ce faire, l'idée est de décomposer les relations Ri (1 ≤ i ≤ 6) données plus haut. En effet, ces relations sont définies par leurs graphes respectifs G_i . Convenons de noter pri(G_i ), la première projection de G_i (i.e. on ne considère que les premières composantes des couples en relation).

" i Œ [1,6], pr₁ (G_i ) = Ins_i  » Ref_i

" i Œ [1, 6], Ins_i « Ref_i = Ø

La sémantique des deux ensembles Insi et Refi peut alors se définir à l'aide d'une relation de transition activate notée —> vérifiant :

hd —> hd1 si o est un élément de hd en relation avec hd1 et o Œ Ref_i

hd —> hd » hd1 si o est un élément de hd en relation avec hd1 et o Œ Ins_i

Naturellement, une décomposition plus fine permettrait de définir d'autres types de liens si cela s'avérait nécessaire, comme par exemple les liens organisationnels de KMS [ACK87].

c)les mots clé

Dans le cas des mots clé, on peut envisager de les définir comme des objets informatifs atomiques particuliers de l'ensemble I : I devient alors la réunion disjointe de trois ensembles, les paragraphes P, les ancres A et les mots clé KW.

On définit ensuite une fonction kw de I à valeur dans P(KW), ensemble des parties de KW : kw(i) désigne l'ensemble des mots clé associés à l'objet i.

On peut dans ce cas très simple définir un mécanisme de propagation de la manière suivante, conformément aux principes usuels de propagation des mots clé :

si i est une instance de type d :

i) si d est le type généralisé des di, d = {d₁,...,dc_n} alors i = {i₁,...,i_n}

kw(i) = » kw(i_j)

j Œ[l, n]

ii) si d est le type agrégé des di, d = (d₁,...,d_n) alors i = (i₁,...,i_n)

kw(g) = « kw(a_i)

i Œ[l, n]

Notons que les mots clé sont attachés aux objets et non aux types.

Adéquation avec les systèmes existants

Dans cette section, nous souhaitons essentiellement montrer sur quelques exemples en quoi notre modèle est bien adapté aux systèmes déjà développés. Hypercard

Hypercard est un système développé par Apple. Il est le premier produit commercial de grande diffusion à mettre en œuvre les concepts hypertextes. Il est constitué par un ensemble de cartes de taille fixe, regroupées en piles. Chaque carte est un document multimédia qui peut être relié à d'autres cartes dans la même pile ou bien dans d'autres piles. Un langage de script, Hypertalk, permet de gérer ces liens.

De notre point de vue, une carte n'est autre qu'un document hypertexte : les média éléments qui le constituent étant les champs ("fields") usuels des cartes, les images et les boutons. Les boutons jouent un rôle particulier en ce sens que leur contenu est réduit à une ancre et que ce sont les seuls média éléments à contenir des ancres. Cependant, il y a des relations de boutons à cartes, de champs à cartes, et enfin de cartes à cartes : en d'autres termes, il n’y a que les relations R₃, R₅ et R₆ qui sont réalisées.

Conformément à ce que nous avons défini plus haut, on peut toujours accéder à une carte (pas de carte isolée) et on peut aussi revenir à un objet source à partir de la destination, mais pas nécessairement en suivant le même chemin : ce qui confirme le fait que la relation Ac est symétrique mais pas les relations R_i.

Les notions de pile et de fond ("background") nécessitent de définir le concept de groupe, dont elles dérivent et que nous n'avons pas abordé pour le moment

Notecards [HAL87]

C'est un système conçu et développé à Xerox Parc. Plus homogène que Hypercard, il tire probalement une partie de sa puissance de sa simplicité conceptuelle. Il n'est constitué que de cartes et de liens entre ces cartes (disparition de la notion de pile et de "background"). Comme précédemment, une carte est un document hypertexte constitué de média éléments. Les relations sont réalisées par des boutons comme Hypercard. La seule relation qui existe alors est celle de boutons à cartes C'est à dire R₃.

Les éditeurs structurés (Grif [QUI86, FUR88], Mentor [DON80], Cornell Synthesizer [TEI81])

Dans un tel système, les documents textuels sont structurés de manière logique, généralement arborescente. Les différents types de média éléments (graphiques, vidéo, etc...) sont des feuilles de ces arbres et sont donc considérés comme atomiques. Cette structuration logique n'est pas d'essence hypertextuelle étant donné que les nœuds de ces arbres n'ont pas de contenu informatif : de notre point de vue, ceci est complètement transparent.

Dans ce cadre, les types sont spécifiés par des grammaires qui régissent la division en sections et le formatage des documents.

Comparaison avec d'autres travaux

Comme nous l'avons indiqué en introduction , notre travail est fortement inspiré de celui de Garg. Il en constitue cependant un approfondissement. regardons de plus près les rapports entre ces travaux. Garg donne deux ensembles d'objets qui correspondent ici à ID et I. Cependant, il n'y a aucun constructeur de nouveaux objets dans le modèle de Garg: tous les objets sont supposés préexister à priori et sont tous atomiques. De plus, ils sont tous au même niveau sémantique: le mécanisme d'instanciation est décrit de manière relationnelle sans autre précision. L'ensemble P₂ des prédicats binaires n'est autre que l'ensemble de nos relations R_i qui établissent les liens entre les différents objets. Ce que Garg appelle un hypertexte fortement défini correspond pour nous au fait que I est la réunion des domaines des types atomiques.

Les deux mécanismes d'agrégation et de généralisation ne sont pas décrits et Garg expose simplement un certain nombre d'axiomes qui les régissent. D'autres part, le mécanisme d'instanciation est un cas particulier de spécialisation, ce qui n'est pas le cas ici: en spécialisant, on ne peut pas passer de ID à I, on reste das ID, ce qui nous semble plus cohérent compte tenu de la différence de nature qu'il y'a entre les types objets informatifs.

le contenu d'informatif est vu comme un attribut de l'objet parmi d'autres: cela tient au fait que tous les objets sont atomiques et donc les propriétés que l'on attribue aux objets ne peuvent en aucun cas se déduire de leur structure. pour nous, l'atome d'information est le paragraphe ou l'ancre( on pourrait en ajouter d'autres si nécessaire): en les combinant en séquence, on obtient par exemple les objets de type média élément. De notre point de vue, le travail de Garg reste à un niveau tel de généralité qu'il est fort probable que sa spécification ne soit pas assez restrictive et que des objets autres que les systèmes hypertexte soient ainsi modélisés. le travail de Garg est fortement inspiré des travaux de Abiteboul et Hull [AH87]sur les bases de données. [AH87] définissent u modèle formel complet pour les bases de données, issu du modèle relationnel, et enrichi par une description élégante des mécanismes de propagation des mises à jour. Nous avons naturellement utilisé les idées sous jacentes et les avons adaptées au contexte. Essentiellement, la notion de type et de domaine d'un type, où un objet est toujours donné( ou construit) avec son type. Notons que ces concepts existent de toute façon déjà en logique intuitionniste et qu'ils ont fait l'objet de recherches approfondies. Compte tenu de l'importance des travaux à ce sujet, on peut se demander quelle serait leur pertinence dans le domaine hypertexte car il y'aurait un grand intérêt à les utiliser.

Les travaux de Hofman[CHL89] constituent plus une formalisation d'un système existant ( l'architecture ODA) qu'une tentative de modélisation générale. L'approche adoptée est orientée objet et les auteurs introduisent une structuration en couches, couches reliées entre elles par un mécanisme de décomposition. Des attributs sont introduits ainsi que des méthodes pour chaque couche (méthode que l'on peut voir comme des classes d'algorithmes utilisables dans certains contextes). les mécanismes de propagation d'attributs sont décrits par des axiomes, de même que la propagation des méthodes. Cependant, ces travaux restent à un haut niveau de généralité, immédiatement illustrés par la présentation de leur système ODA. Nous avons aussi consulté les travaux de Parent et Spaccapietra [PS87 sur les bases de données. Ces travaux constituent une description très précise des attributs ainsi que des mécanismes pour les gérer. Nous pensons qu'il est fort probable que ces travaux conservent une grande pertinence dans le contexte hypertexte même si les attributs ne sont pas associés aux mêmes types d'entités. Une étude plus fine de leurs travaux ne pourrait que clarifier les idées quand aux mécanismes utilisé dans les systèmes hypertextes.

Travaux futurs

Le travail que nous venons de présenter s'inscrit plus dans un contexte de prospective que de formalisation complète de l'univers hypertexte, et ceci pour deux raisons au moins:

• La première raison est que les concepts fondamentaux hypertextes ne sont pas encore suffisamment bien dégagés pour faire l'objet d'un consensus dans la communauté informatique,

• la seconde raison est qu'il existe une grande variété de systèmes intéressants et que l'on ne saurait pour le moment décider de la plus grande pertinence d'un système par rapport à un autre: ce qui entraîne naturellement une inflation de concepts divers sur la pertinence desquels il est trop tôt pour se prononcer.

Pour les raisons qui viennent d'être évoquées, nous n'avons pas encore pris en compte dans notre modèle certains aspects des systèmes hypertextes qui nécessiteront un approfondissement de notre travail dans deux directions complémentaires:

• d'une part, il sera indispensable de préciser certains concepts déjà présentés: attributs, types de liens, etc...,ceci afin de tenir compte des notions concrètes implantées en générale,

• d'autre part, certains concepts nouveaux devront être formellement définis, parmi lesquels on peut citer:

i) les groupes, qui constituent une notion assez mal définie pour l'instant de par la grande variété des implantations. Par exemple, Notecards considère les nœuds composites comme étant des cartes ne contenant que des ancres c'est à dire comme des cartes spécialisées. Au contraire, la notion de pile dans Hypercard ne sous-entend pas 'existence d'un document physique spécialisé: c'est plutôt une relation d'ordre sur un ensemble de documents.

ii) Les notions d'écolution temporelle des hypertextes et notamment la formalisation des données vidéo, animation, son, etc...qui peuvent être intégrées dans un tel document,

iii) Les attributs sur les liens (Intermédia [GAR86]qui sont implantés dans certains systèmes et sont utilisés pour générer des plans décrivant des graphes de déplacement dans les divers documents interconnectés,

qui modéliseront des notions existantes dans les systèmes réels. Nous avons déjà commencé à réfléchir sur ces divers problèmes et nous pensons présenter d'ici peu un nouvel état de nos travaux.

Les problèmes de navigation souvent évoqués pour les hypertextes restent encore à formaliser pour être résolus de manière cohérente. Ils sont liés aux notions de liens organisationnels et de groupe, mais aussi, dans le cas des éditeurs structurés [BOR87], à la structure logique (arborescente) des différents documents. Ces problèmes ne pourront donc être traités que lorsque les concepts précédents auront été formalisés.

Les rapports éventuels entre les hypertextes et les hypergraphes devront être clarifiés. A ce sujet, notre opinion est que la notion d'hypergraphe, abondamment citée dans la littérature sur les systèmes hypertextes, ne s'adapte pas de manière naturelle à ce contexte. En effet, on peut considérer un hypertexte comme un graphe tout simplement (cas particulier trivial d'hypergraphe!) , mais il ne nous semble pas nécessaire d'utiliser le formalisme plus puissant de la théorie des hypergraphes [BER83] pour modéliser les concepts sous jacents des hypertextes.

Conclusion

Compte tenu de la grande diversité et de la richesse des systèmes existants sur le marché, le concept même d'hypertexte est difficile à appréhender. Aussi, le travail présenté ne prétend pas à l'universalité. Nous pensons cependant qu'il est aussi près que possible de la réalité actuelle : aucun concept nouveau n'est défini qui ne soit déjà implanté sous une forme ou sous une autre dans un produit hypertexte.

Notre modèle s'inspire fortement des travaux de Garg : il les précise et, de notre point de vue, s'adapte de plus près à la réalité hypertexte. En particulier, nous pensons avoir mis en évidence la particularité des systèmes hypertextes qui tient plus aux relations entre les objets informatifs (instances des types) que sur les relations entre les types d'objets eux-mêmes.

Les notions courantes de liens, ancres, hyperdocuments ont été dégagées et permettront par la suite d'intégrer au modèle d'autres concepts tels que les groupes, les attributs sur les liens ainsi que leur typage. Nous utilisons actuellement ce modèle au sein du projet ESPRIT MULTIWORKS comme une aide pour réaliser un système hypertexte complet.

Bibliographie

[ACK87] ↑ Akscyn R, McCracken D et Yoder E, “KMS : a Distributed Hypermedia System for Managing Knowledge in Organizations”. Hypertext'87 papers, November, pp 1-20.

[AH87] ↑ Abiteboul S et Hull R, “IFO : a Formal Semantics Database Model”. ACM transactions on database systems, December 87, Vol 12 n°4 pp 525-565.

[BER83] ↑ Berge C, “Hypergraphes”. 1983, Ed. Gauthier Villars.

[BOR87] ↑ Borras P, Clément D, Despeyroux Th, Incerpi J, Kahn G et Lang B, “CENTAUR : The System”. RR INRIA n° 777, December 87.

[CAM87] ↑ Campbell B et Goodman J, “HAM : a General-Purpose Hypertext Abstract Machine”. Hypertext'87 papers, November, pp 21-32.

[CHL89] ↑ Cordes R, Hofmann M et Langendorfer H, “Layered object oriented techniques supporting hypermedia and multimedia applications”. WOODMAN'89.

[CON87] ↑ Conklin J, “Hypertext : an introduction and survey”. IEEE Computer September 87 pp 17-41.

[DON80] ↑ Donzeau-Gouge V. & al., “Programming Environments Based on Structured Editors, The Mentor Experience”. RR INRIA n° 26,1980.

[FUR88] ↑ Furuta R, Quint V et André J, “Interactively editing structured documents”. Electronics Publishing, Vol. 1(1), April 1988, pp 19-44.

[GAR86] ↑ Garrett N. L, Smith K. E et Meyrowitz N, “Intermedia : Issues, Strategies, and Tactics in the Design of a Hypermedia Document System”. Proc. Conf. on Computer-Supported Cooperative Work, MCC Software Technology Program, Austin, Texas, 1986.

[GAR88] ↑ Garg P, “Abstraction mechanisms in hypertext”. ACM, Juillet 88 Vol 31 n° 7.

[GS88] ↑ Garg P et Scacchi W, “a hypertext system to manage software life cycle documents”. Proceedings of the 21st Hawai international conference on system sciences Vol 2, Janvier 88 IEEE Computer Society Press.

[HAL87] ↑ Trigg R, “NoteCards in a Nutshell”. Proceedings of the CHI'87 Conference, Toronto, Canada, April, pp 45-52.

[HAL88] ↑ Halasz F, “Reflections on Notecards : Seven Issues for the Next Generation of Hypermedia Systems”. ACM Vol 31, n°7, Juillet 88.

[HAL89] ↑ Conklin J, “The Dexter Reference Model”. SIGCHI89.

[PS87] ↑ Parent C et Spaccapictra S, “un Modèle et une Algèbre pour les Bases de Données de Type Entité-Relation”. TS1, Vol 6, n°5,1987.

[QUI86] ↑ Quint V et Vatton I, “Grif : “An Interactive System for Structured Document Manipulation”. Proc of EP'86 Conference, Univ. of Nottingham, April 14-16,1986.

[QUI89] ↑ Quint V et Vatton I, “Modularity in Structured Documents”. WOODMAN'89, Rennes (France), May 29-31, 1989

[SAN89] ↑ Sandvad E, “Hypertext in an Object-Oriented Programming Environment”. WOODMAN’89, pp 30-41.

[TEI81] ↑ Teitelbaum T et Reps T, “The Cornell Program Synthesizer : a syntax directed programming Environment”. ACM, Vol. 24(9), 1981, pp 563-573.

[VER89] ↑ Vercoustre A.M, “Edition Structurée, Approche Hypertexte, Coopération et Complémentarité”. RR INRIA n° 1052, June 1989.

---