Chapitre 2 La gestion électronique de documentsdocinsa.insa-lyon.fr/these/2003/alvarez_escobedo/Chapitre_2.pdf · Chapitre 2 / État de l'art : la gestion électronique de documents

Chapitre 2 / État de l'art : la gestion électronique de documents

ALVAREZ Abraham 45 Thèse en Informatique / 2003 Institut national des sciences appliquées de Lyon

Chapitre 2

La gestion électronique de documents

« L'imagination est plus importante que le savoir »

Albert Einstein

Résumé du chapitre : La première partie de ce chapitre introduit les concepts de

gestion et production de documents ainsi qu'une description des phases du cycle de

vie du document. Nous décrivons ensuite deux clases de systèmes de gestion de

documents : les systèmes Hyperbases & Hypertextes. Une attention toute particulière

est accordée à leurs principales fonctionnalités techniques



Table des matières

1 INTRODUCTION _______________________________________________ 47

1.1 GESTION DES DOCUMENTS______________________________________________48

1.2 PRODUCTION DES DOCUMENTS __________________________________________49

2 BASES DE DOCUMENTS (HYPERBASES) ______________________________50

2.1 DEFINITION DU SYSTEME HYPERBASE _____________________________________50

2.2 ARCHITECTURE D’UN SYSTEME HYPERBASE ________________________________51

2.3 LE SERVICE DE LIEN (LINK SERVICE) ______________________________________54

3 SYSTEMES HYPERBASE - HYPERBASE MANAGER SYSTEM (HBMS) _____57

3.1 SYSTEME DEXTER (HYPERTEXT REFERENCE MODEL) ________________________57

3.1.1 Description générale du modèle _____________________________________57

3.1.2 Les couches du modèle _____________________________________________58

3.2 MICROCOSM ________________________________________________________60

3.2.1 Description Générale ______________________________________________60

3.2.2 Architecture Générale _____________________________________________62

3.3 HYPERWAVE (HYPER-G) ______________________________________________63

3.4 GHIS –SYSTEME D’INFORMATION HYPERMEDIA GEOGRAPHIQUE _______________64

3.4.1 Modélisation des liens _____________________________________________65

3.4.2 Types de liens ____________________________________________________65

3.5 HYPERDISCO ________________________________________________________67

4 CONCLUSION _______________________________________________ 67



1 Introduction Le cycle de vie du document relève de plusieurs processus parmi lesquels il existe

deux processus distincts comportant chacun des objectifs spécifiques. Il s'agit de la

production (axe horizontal) et de la gestion des documents (axe vertical). Cette der-

nière est le centre de notre réflexion au cours de notre travail de recherche. La figure

2-1, illustre l'interrelation entre ces deux axes.

Chercher

Création de document à partir

du modèle

Prod

uctio

n de

s doc

umen

ts

Accéder

Consulter


de zéro.

Besoin de communiquer

Créercontenu

Valider

Acquérir

Editer, transmettre

Gestion des docum

ents

Enregistrer

Archiver

Production des documents

Gest

ion

des

docu

men

ts

Chercher


du modèle

Prod

uctio

n de

s doc

umen

ts

Accéder

Consulter


de zéro.

Besoin de communiquer

Créercontenu

Valider

Acquérir

Editer, transmettre

Gestion des docum

ents

Enregistrer

Archiver

Production des documents

Gest

ion

des

docu

men

ts

Figure 2-1 Interrelation des processus de production et de gestion des documents

Dans l’axe horizontal, le document est considéré comme un objet à cons-

truire parce qu’il est, pour l’utilisateur, un moyen de réaliser une activité quelconque

dans un processus de travail. Dés lors, on s’intéresse donc aux différentes fonctions

nécessaires afin qu’un document soit produit, validé, distribué et utilisé à l’intérieur

d’un processus de travail particulier. Les besoins d’affaires se traduisent souvent par



l’obligation de créer un document. Dans cette perspective, le document est un produit

à construire.

Les étapes de la production et de l’assemblage de ces différents éléments en

une chaîne de traitement particulière ouvrent la porte vers des produits informatiques

de gestion de processus, d’événement, de travail en collaboration, de distribution, de

circulation et d’approbation de documents.

1.1 Gestion des documents Les activités de gestion documentaire présentées à la figure 2-1 peuvent se

résumer de la façon suivante :

Chercher : Rechercher et repérer un document selon certains critères

fournis en partie par l'indexation issue des métadonnées créées ou encore

directement explicitées dans le contenu des documents.

Accéder : De façon générale, cette activité concerne la capacité physique

à manipuler un document. Il s'agit fondamentalement de définir et de gé-

rer les droits d'accès aux documents. Dans un contexte électronique, le

transfert de documents actifs et semi actifs, le versement de documents

vers les archives peuvent être vus comme des changements d'emplace-

ment pour l'accès à ces documents.

Consulter : Activité cognitive relative à la lecture du document, à la

prise en compte de son contenu signifiant.

Acquérir : Acquisition d'un document provenant d'un fournisseur quel-

conque grâce à un emprunt, un abonnement, ou un téléchargement d'un

document publié sur le Web.

Distribuer : Activité relative à la diffusion, à la transmission, à la circu-

lation et au prêt des documents. Elles consistent à désigner les docu-

ments à distribuer, à établir la stratégie de distribution, la liste des desti-

nataires, à préparer la transmission, à transmettre les documents et enfin

à gérer les accusés de réception.



Archiver : Activité relative à la sélection des documents à conserver se-

lon de critères de conservation, à leur préparation pour le rangement

physique et au rangement comme tel.

1.2 Production des documents Dans l'axe horizontal, on s'intéresse aux différentes fonctions nécessaires pour qu'un

document soit élaboré, validé, distribué et utilisé à l'intérieur d'un processus de tra-

vail quelconque. Sont considérés ici les différents composants qui doivent être cons-

truits et assemblés en un tout cohérent, c'est-à-dire la structure, le contenu, la forme,

ainsi que le support physique du document.

La conception du contenu du document regroupe des activités pour lesquel-

les le document est considéré uniquement comme un contenu informatif à concevoir

et à interpréter. Essentiellement, ces activités traitent de problématiques de contenu

(souvent textuel) où l'usager requiert une assistance dans l'utilisation et l'interpréta-

tion de ce contenu afin d'en produire un autre. Ce regroupement d'activités comprend

la conception, l'utilisation, la recherche de contenu, l'analyse, l'assemblage de don-

nées, etc.

Rappelons que la figure 2-1 indique trois entrées possibles de données lors

de la création d'un document : l'utilisation d'un modèle de contenu (par exemple un

formulaire), la consultation de sources d'informations existantes et la validation inte-

ractive du modèle de contenu ou de l'aspect linguistique. Une fois créé, le document

est édité (en fonction si possible de modèles d'édition) et inséré dans un média quel-

conque avec l'encodage de données approprié pour sa transmission (messagerie) ou

sa distribution.

Les activités liées à la gestion du cycle de vie des documents sont : les acti-

vités de description et d'indexation selon des fiches de références afin de repérer les

documents ; les activités de prêt et d'acquisition de documents pour permettre leur

consultation et constituer un fonds documentaire; les activités de conservation afin

de respecter la valeur administrative, légale, historique ou de référence des docu-

ments et les activités d'entreposage temporaire ou permanent des documents.



2 Bases de documents (Hyperbases) Depuis leur apparition sur la scène Internet entre 1988 et 1990, les premiers liens ex-

ternes ont été implémentés dans les Systèmes Hypermédia [AMY88], [LS94],

[GHMS94], [CCH94], [DGH99]. Aujourd’hui, c’est le cas pour les systèmes docu-

mentaires, nommés Hyperbase, qui sont des systèmes hypertextes ou hypermédia et

qui stockent séparément les données et les liens dans une base de données. L'origine

du nom Hyperbase naît du mariage de l’hypertexte et des bases de données (de

l’anglais, Hypertext Database Retrieval System).

Le double objectif de ces systèmes est d’une part de mettre à disposition des

utilisateurs une collection de documents dans sa totalité grâce à une interface hyper-

textuelle, et d’autre part, d'offrir des mécanismes de consultation de type hypertexte

[Conklin87], [Nielsen90]. Cela doit alors ressembler à un système de recherche do-

cumentaire, associé à une base de données pour garantir un stockage robuste et un

accès flexible aux données. La navigation via ces mécanismes est le concept clé de

ces systèmes.

2.1 Définition du système Hyperbase L’implémentation des liens externes dans des systèmes hypermédia, est abordée de la

même manière que dans les systèmes Hyperbase. D’après Nürnberg [NLSS96], Wiill

[Wiil93], Schütt et Streitz [SS90], un système Hyperbase est défini comme suit :

« Un système est de type hypermédia lorsqu’il est possible de gérer

des données et des liens en utilisant un système de gestion de base de

données ».

Un système Hyperbase est conçu pour stocker et gérer un hyperdocument,

c’est-à-dire un ensemble de documents liés entre eux par différents types

d’associations [Quint92]. Dans [Pinon90], un hyperdocument est considéré comme

un ensemble de documents ou fragments de documents appelés nœuds et reliés entre

eux par des liens.

Une particularité d’un système Hyperbase est que l’information n’est pas

traitée en dehors de l’application ; les données sont récupérées directement depuis le



module de stockage, tandis que leur téléchargement se fait à travers le système. Les

travaux de Kappe [Kappe95], [Kappe95a], Schütt & Streitz [SS90], et [Thistle-

waite95], avec le système Hyper-G, également connu sous le nom HyperWave

[AKM95], [Maurer96] sont conçus dans cette optique.

Cette approche de l’accès aux données est identique à celle des Systèmes de

Gestion des Bases de Données (SGBD). En fait, une grande partie des systèmes Hy-

perbase s’appuient sur des Systèmes de Gestion des Bases de Données Relationnelles

(SGBD-R).

Une architecture Hyperbase basée sur un SGBD-R a été présentée par Zobel

[ZWT++91], Ashman & Chase [ACH93]. Le système Dexter par Grønbæk & Hem

[GHMS94], [AMY88], [DGH99]. Le système Intermedia par Smith & Zdonik

[SZ87], [TNHN91], Hyper-G [AKM95], [Kappe95], [Maurer96] et TROP [CCC et

al. 93] sont des systèmes supportés par des Gestionnaires de Bases de Données

Orientées Objets (SGBD-OO).

Parmi les systèmes les plus réputés citons :

le système GMD-IPSIs CHS et CoVer : Schütt et Streitz [SS90],

SP3 et HB2 : Leggett et Schnase [LS94], Kacmar et Leggett [KL91],

[SLHN++93],

DGS et ABC: Shackelford et al [SSS93], Smith et Smith [SS91],

Hyperform : Wiil et Leggett [WL92],

DHM : Grønbæk et Trigg [GT92] et

DHT : Noll et Scacchi [NS91].

Finalement GHIS : Ashman et Chase [ACH93], est un exemple de système

hybride qui peut s’appuyer sur plusieurs SGBD: Sybase, Oracle et Progress.

2.2 Architecture d’un système Hyperbase Dans un système Hyperbase, les données sont stockées et récupérées à travers une

base de données. Ils sont en cela différents des systèmes hypermédia car ceux-ci ex-

traient leurs données « in situ » dans leur propre base et dans un format natif.

Un avantage majeur de l’approche Hyperbase est que toutes les modifica-

tions, aussi bien des données que des liens restent localisées dans le système Hyper-



base. Ainsi la coopération entre les serveurs d’Hyperbase et les rédacteurs de portion

de contenu peut être assurée.

Sachant que toutes les actions, telles que le stockage, la récupération et

l’édition de données sont effectuées dans un environnement homogène de travail, ce-

lui du système Hyperbase, nous pouvons en déduire que la gestion, l’accès, la fiabili-

té et la persistance des données sont assurées de façon implicite. Ces données pro-

viennent d’une source simple et sont contrôlées selon des règles de gestion strictes.

Le système Hyperbase a la totale responsabilité de la gestion des données.

D'autres, les systèmes Hyperbase supportent diverses sources de données,

avec des formats différents. Parfois, la gestion, la sauvegarde, et la présentation des

données ne sont pas du ressort du système Hyperbase. La figure 2-2, illustre

l’architecture d’un système hypermédia, d’après Leggett. Un tel système comporte

trois grandes couches [LSSF93].

Système hyperbase(Couche hyperbase)

Gestionnaire de stockage(Couche de stockage)

Application(Couche d’application)

Système hyperbase(Couche hyperbase)

Gestionnaire de stockage(Couche de stockage)


Figure 2-2 Architecture des systèmes hypermédia [LSSF93].

La couche Application regroupe un ensemble d’outils tels que les éditeurs de

texte, les éditeurs graphiques, des outils de courrier électronique et des outils

pour la présentation multimédia.

La couche Hyperbase comporte un modèle de données pour supporter des

applications hypermédia. Celle-ci va interagir avec la couche de stockage,



laquelle garantit la persistance des données (nœuds, liens, ancres, contextes

etc.) qui ont été stockées. Ce modèle est très similaire à l'Hypertext Abstract

Machine (HAM) [AMY88], [GHMS94], [DGH99] (C.f. Section 3.1). Dans

Campbell & Goodman [CG88], ce dernier a été utilisé dans le système de

conception assisté par ordinateur Neptune (Delisle & Schwartz [DS86]) et

également dans la conception de Dynamic [Bigelow88] où il fournissait les

couches de base.

Les architectures des systèmes Hyperbase et hypermédia sont caractérisées

par sept critères [Davis95] :

1. L’échelle

La taille de l’Hyperbase est mesurée en octets d’information, nombre de

nœuds, de liens, d’ancres, de version, de contextes et de vues, ainsi que par

le nombre d’utilisateurs simultanés.

2. L’ouverture

C’est le degré d’interopérabilité entre des applications sans leur imposer de

restrictions par rapport au modèle de données.

3. La distribution

Ce critère concerne la possibilité de répartir « des processus hypermédia »

sur de multiples machines.

4. L’hétérogénéité

Ce critère concerne les différents modèles de données capables de supporter

le système Hyperbase.

5. L’extensibilité

C’est la faculté du modèle de données à supporter de nouvelles abstractions

et opérations sur les données.

6. Le Traitement de données

Le système doit supporter des possibilités de calcul et déduction sur les élé-

ments du modèle de données, tels que les nœuds, les liens, les ancres, etc.

7. La plate-forme de développement



Le modèle doit être capable de supporter la coopération entre de multiples

utilisateurs.

Citons les couplages réussis de systèmes de gestion de bases de données

(SGBD) et XML [BBB2000], [Bourret2003], de systèmes de recherche d’information

(SRI) et de (SGBD) orientés objets [VAB96], [VAB96a], des systèmes hypertextes

(SH) et (SGBD) relationnelles [Blair98].

Les systèmes Hyperbase ne sont pas en cela une exception. On évolue dans

des domaines vers des systèmes hybrides. Dans les hyperbases, c'est-à-dire que le

système Hyperbase (le système de base) stocke et manipule localement une partie des

données alors que l’autre partie des données est gérée par une application tiers

« Third Party ».

Dans cette perspective d’évolution, la question soulevée par la communauté

Hyperbase était de savoir :

«Comment doter ces systèmes de capacités à supporter des services

hypertexte vers des applications tiers ?»

Cela implique deux conséquences : premièrement les systèmes Hyperbase

stockent le contenu du noeud, tandis que les applications externes ou tiers attendent

d’avoir l’adresse du fichier stocké pour récupérer les données ; deuxièmement, les

systèmes Hyperbase laissent à l’utilisateur la gestion des ancres et donc de l’intégrité

des liens.

2.3 Le service de lien (link service) Le service de lien, offre une fonctionnalité de type hypertexte aux applications. Le

service de lien offre également aux applications une interface leur permettant de

stocker et récupérer des liens sous forme d’objet.

Le terme « service de lien » est de plus en plus utilisé pour décrire les sys-

tèmes qui stockent séparément les données et les liens dans une base de données.

Une application ou un système Hyperbase qui est basé sur le modèle Dexter peut être

considéré comme un système de service de lien.



Le modèle du système Microcosm [FHH+90], [HHD93], [DHH+92], [Da-

vis95], [CDHH95], [Davis98], [CHH98] a été utilisé pour décrire le concept de

« service de lien ». La figure 2-3, représente ce modèle. L’inconvénient du modèle

Hyperbase à trois couches représenté sur la figure 2-2 est que l’interface entre

l’application et la couche de l’Hyperbase est laissée à la charge de l’application, uti-

lisant généralement un modèle client-serveur pour la communication. Cette architec-

ture exige que chaque application hypertexte implémente le code pour se connecter à

la couche API de l’Hyperbase. D’autre part les applications doivent être des applica-

tions d’hypertexte actives capables de recueillir les requêtes de l’utilisateur, deman-

dant des informations sur des aspects tels que les caractéristiques des liens et

l’affichage et la redirection vers d’autres applications.

Composant actif du type middleware, il reçoit des messages des deux couches

Service des liens(Link Service)

Interaction entre l’utilisateur et le service des liens.

Stockage des liens, nœuds, des ancres, versions, etc.


Composant actif du type middleware, il reçoit des messages des deux couches

Service des liens(Link Service)

Interaction entre l’utilisateur et le service des liens.

Stockage des liens, nœuds, des ancres, versions, etc.


Figure 2-3 Représentation du service de lien du système Microcosm [Davis95]

Le service de lien se comporte comme s’il s’agissait d’une application sim-

ple au-dessus de la couche de stockage. Il a la pleine responsabilité de la gestion des

communications entre les applications que l’utilisateur souhaite utiliser. C’est un

composant actif qui intègre les fonctionnalités permettant à la couche de stockage et

aux applications de communiquer entre elles.

L’idée du «service de lien» a fait l'objet de nombreuses publications en 1989

[Pearl89] et par l’équipe de Microcosm en 1990 par Fountain [FHH+90], Hall



[HHD93], Davis [DHH+92], [Davis95], Carr [CDHH95], [Davis98] et [CHH98].

Cette idée a été concrétisée quelques années plus tard par la communauté hypertexte

et hypermédia [CHD2000]. Une direction majeure de recherche, et probablement un

des obstacles à l’adoption universelle du concept de « service de lien », a été le degré

de cohésion attendu entre les applications et le service de lien.

Le service de lien de Microcosm a adopté une approche moins restrictive,

permettant aux applications de participer à tous les protocoles de « service de lien »

(fully aware viewers), à certains protocoles (semi-aware viewers) ou à aucun proto-

cole (unaware viewers).

Une autre question est de savoir comment la couche de stockage est implé-

mentée. Le service de lien, qu’il s’agisse de celui de Sun ou de Microcosm, s’appuie

sur le système de gestion de fichiers du système d’exploitation utilisé. Un utilisateur

peut déplacer ou modifier directement les fichiers à l’aide d’outils qui ne sont pas

supportés par le «service de lien», pouvant ainsi générer des incohérences. Pour ces

raisons, dans le système Intermedia de Yankelovich [YHMD98], Haan [HKRC+92],

où est implémentée une couche service de lien et afin d’éviter ce problème

d’incohérence, on exige que tous les objets ne soient accessibles que via des applica-

tions d’Intermedia ou par le browser d’Intermedia. De cette façon, le service

d’hypermédia est en mesure de maintenir l’intégrité dans un système hypertexte, de

façon similaire aux systèmes Hyperbases.

De nombreux exemples d’applications ont implanté la couche de service de

lien, que ce soit implicitement ou explicitement. Nous pouvons citer le service d'In-

termedia Yankelovich [YHMD88], Sun Pearl [Pearl89], Microcosm Davis

[DHH+92], [Davis95], [Davis98], [OHS98],[Hall99], Fountain [FHH+90]. IRIS

[HKRC+92], HyperDisco [WL97], HyperTED [Vanzyl93], [Vanzyl94] Knowledge

Weasel [Lawton et Smith93], ABC [SSS93], PROXHY [KL91], Hitchcock avec le

projet «Open Journal Project » [HCHHH97], Multicard [RS92] et SP3 [LS94] et pour

finir; Tompa et al [TBR93] qui décrivent un prototype pour une telle architecture.



3 Systèmes Hyperbase – Hyperbase Manager System (HBMS)

3.1 Système Dexter (Hypertext Reference Model) Un premier effort de standardisation a abouti au modèle Dexter en octobre 1988 (Ha-

lasz & Schwartz 94 [HS94]). Il a depuis servi de base à l’élaboration d’autres modè-

les par la plupart des systèmes hypermédia [LS94]. Entre 1988 et 1990, suite à plu-

sieurs discussions au sein de la communauté hypertexte sur les système existants

FRESS [W8], Intermedia Yankelovich [YHMD88], Hypercard d'Apple [Natchez89],

[Martin90] Knowledge Management System [AMY88], HAM - Hypertext Abstract

Machine [GHSM94], [DGH99], Notecards [Halasz88], etc. Un consensus sur les mo-

délisations et les architectures des systèmes hypermédia a été dégagé dans le docu-

ment [HS90],[HS94], donnant lieu au modèle Dexter.

3.1.1 Description générale du modèle Le modèle de référence Dexter [HS90], [HS94] propose trois couches : une couche

d’exécution, une couche de stockage, et une dernière de contenu informatif. Les deux

premières possèdent une série de fonctions et de propriétés permettant de gérer le ré-

seau hypertexte constitué d’éléments génériques (nœuds et liens). La troisième cou-

che définit essentiellement le contenu et la structure des informations. La figure 2-4,

schématise le modèle en question.

Affichage d’hypertexte, Interaction dynamique entre l’utilisateur et le système.

Stockage des nœuds et des liés dans une base de données.

Couche d’exécution

(environnement de présentation)

Couche de stockage

(stockage du contenu et de la structure interne)

Présentation

Spécification

Ancrage Couche de représentation

Interne(structure de composants)

Affichage d’hypertexte, Interaction dynamique entre l’utilisateur et le système.

Stockage des nœuds et des liés dans une base de données.

Couche d’exécution

(environnement de présentation)

Couche de stockage

(stockage du contenu et de la structure interne)

Présentation

Spécification

Ancrage Couche de représentation

Interne(structure de composants)

Figure 2-4 Les trois couches du modèle Dexter [HBR94]



3.1.2 Les couches du modèle La couche d’exécution nommé aussi couche d'application (run time layer),

offre les fonctionnalités de navigation et de manipulation du réseau hyper-

texte (i.e. l'affichage de l'hypertexte) et de tout ce qui concerne les aspects

de l’interface utilisateur. Elle supporte aussi les interactions dynamiques en-

tre l’utilisateur et le système, ainsi que les outils de navigation [HS94].

L’interaction est réalisée à travers une interface de présentation nommée

« Presentation Specifications ».

La couche de stockage nécessite tous les atouts des SGBD et représente le

noyau du système. Cette partie du système est essentielle dans la mesure où

elle modélise le réseau hypertexte et fournit les fonctionnalités nécessaires à

sa gestion. Elle décrit le réseau des nœuds et des liens contenus dans la base

de données, ceci implique que les données seront stockées et gérées par le

système. Chaque élément est identifié et unique. Le niveau d’abstraction de

la couche permet de traiter des données de manière générique, dont le type

peut être : texte, graphique, animation, etc. L’élément lien constitue une

relation entre deux composants.

La couche de représentation interne représente et gère le contenu des nœuds

hypertextes. Les données possèdent leur propre organisation. Le modèle

Dexter ne définit pas de modèle de structure ou de type de document. Il spé-

cifie uniquement un mécanisme d’adressage ou de localisation nommé an-

crage ou « Anchoring » pour permettre l’accès aux contenus et aux structures

des composants. Cette couche est implantée sous forme d’un ensemble

d’éditeurs adaptés à la gestion de différents types d’information (images,

textes, graphiques etc.). Cela ne signifie pas que les données interprétées par

l’outil de cette couche seront également interprétées par des outils externes à

la couche.

L’indépendance entre les couches de stockage et de contenu est un point es-

sentiel dans le modèle Dexter. Un mécanisme d’ancrage permet l’adressage des em-



placements ou objets (boutons, régions) dans le contenu informatif à partir de la cou-

che de stockage.

Le modèle Dexter ne précise pas une structure interne des données, mais

spécifie que les données sont logiquement utilisables comme des composants. Cha-

que type de données possède un outil approprié pour sa présentation et sa manipula-

tion. Un lien est un composant de type spécifique qui peut être manipulé directement

par un outil du type hypermédia.

Les liens sont stockés et traités comme des composants ordinaires, donc, leur

présentation et leur manipulation sont prises en charge par le même outil hypermédia

utilisé pour les données. De ce fait, les liens sont de type externe, parce qu’ils sont

des composants propriétaires, séparés des composants à lier.

La couche de stockage du modèle Dexter peut être considéré comme le

noyau des systèmes Hyperbase.

Le modèle Dexter sert de modèle de référence et de comparaison. Il est utili-

sé comme modèle exemple pour formuler des analyses critiques. De plus, il est com-

plété avec des outils permettant d’augmenter ses capacités afin de pallier ses faibles-

ses : la rigidité du concept de granularité des données, l’insuffisance de support pour

des composants composites [LS94], ses possibilité d’évolution limitées [LS94], la

limitation des comportements pendant la navigation [LS94], le manque de support

pour gérer la relation temporelle entre les données complexes (par exemple synchro-

nisation entre l’audio et la vidéo) [HBR94]. Leggett et Schnase [LS94] concluent

qu’il existe un point au-delà duquel il n’est apparemment plus avantageux d’aller

plus loin en améliorant le modèle Dexter, tandis que [HBR94] recommande ce mo-

dèle parce qu’il permet la composition des structures hiérarchiques, la spécification

des liens entre composants et l’utilisation des ancres, et qu’il permet également à

l’information sur des données dépendantes d’être enregistrée séparément de l’hy-

perstructure.



3.2 Microcosm Microcosm ([OHS98], Davis [DHH+92], Fountain [FHH+90]) est un des premiers

systèmes avec des services de liens hypermédia. Il a été développé par l’équipe de

recherche Multimédia de l’Université de Southampton, (Royaume-Uni). Le modèle

de Microcosm est supporté par le groupe de travail OHS (Open Hypermedia System),

[OHS98] L’objectif premier a été de concevoir un système sur mesure et évolutif,

capable de supporter différents types de recherche. Il a été développé à partir des

langages C et « Actor ». Un aspect important de la conception de Microcosm 1.0 est

que les fonctionnalités ont été développées de façon modulaire. D’autres versions

sont apparues progressivement, la version 2.0 en 1992, la version 3.0 en 1994 et en

1995 la version 3.2. Les domaines d’application considérés sont variés, de la docu-

mentation technique à la gestion de projet, en passant par l’édition électronique, les

systèmes d’information géographiques et les systèmes d’information coopératifs. La

compagnie Multicosm, a été chargée de commercialiser le système dans divers sec-

teurs d’activité.

3.2.1 Description Générale Microcosm permet aux utilisateurs d’organiser et de naviguer dans de volumineux

entrepôts de données hétérogènes [FHH+90]. Une caractéristique importante de Mi-

crocosm, du point de vue de la gestion des liens, est qu’il stocke des informations sur

les liens et les ancres du lien, de façon distincte des données. Cette approche présente

un certain nombre des avantages :

1. Les applications externes ou « tiers » sont faciles à intégrer dans des sys-

tèmes hypertexte, à moindre coût.

Ajouter des identificateurs pour les ancres de nœud, comme dans la plupart

des systèmes, pourrait les altérer du point de vue données et application.

Conserver les ancres en dehors des données, permet à l’application d’agir à

la fois en tant que visionneur et éditeur de données. Les systèmes qui main-

tiennent les données dans un format qui leur est propre, doivent également



fournir des outils pour accéder et manipuler ces données. Néanmoins, cette

approche est une solution assez semblable à la première.

2. Il devient facile de créer des liens génériques.

Si une ancre du lien est imbriquée dans les données du nœud, la seule façon

de le suivre sera de le rechercher à l’endroit où l’ancre source a été imbri-

quée. Une ancre source doit être donc insérée pour chaque lien, ce qui impli-

que un coût additionnel considérable. Cependant, si toute l’information du

lien est stockée de façon séparée par rapport aux données, il est alors possi-

ble d’implémenter une fonction service de lien suivie de n’importe quel ob-

jet source choisi par l’utilisateur. Un lien générique est défini comme un lien

qui provient d’un objet particulier à n’importe quel endroit et dans n’importe

quel document et qui est relié a un autre objet particulier, du type cible, dans

un autre document.

3. Des liens en lecture seule.

Dans un environnement de travail coopératif, un utilisateur peut permettre

aux autres utilisateurs la visualisation de ses données, mais en ne leur lais-

sant pas la possibilité de les éditer. Si les ancres du lien sont stockées dans

les données, il ne sera pas possible aux autres utilisateurs de créer des liens

vers les données de l’utilisateur. Stocker les ancres du lien de façon séparées

des données permet à un utilisateur de naviguer dans des données stockées

sur des CDROMs, des vidéodisques, des DVDs, ou d’autres médias en lec-

ture seule.

4. Des outils pour le traitement des liens.

Dans un système où les liens sont complètement imbriqués dans le document

source, comme c’est le cas des fichiers HTML du World Wide Web. On peut

se demander :

« Quels sont les liens qui pointent vers mon document en cours de

modification ? »

Il est donc, nécessaire de créer une interaction avec la totalité de

l’Hyperbase. On doit chercher pour chaque document, les ancres qui répondent à



cette condition. Maintenir les liens dans une base à part, une « Linkbase », va nous

permettre de réaliser des opérations de traitement sur les liens et disposer d’une Hy-

perbase persistante, et par conséquent d’un système évolutif. En permettant à des ap-

plications tiers d’accéder aux données de l’Hyperbase, Microcosm se décharge de la

récupération des données qui composent le nœud : la couche de stockage de Micro-

cosm est le système de fichiers même.

Cependant, Microcosm, maintient divers attributs du document (méta-

données), et ceux-ci sont entretenus par le système de fichiers. La description longue

d’un fichier, le nom de l’auteur, sont des exemples d’attributs qui sont maintenus par

le système de gestion de documents (Database Manager System - DBMS).

3.2.2 Architecture Générale L’accès aux fichiers se fait via un explorateur de document fourni par Mi-

crocosm. Il affiche les noms des fichiers dans un format long, et les organise en fonc-

tion de leurs types logiques de façon hiérarchique.

Une vue générale du modèle Microcosm est présentée sur la figure 2-5.

Visualisateur pour le texte

Visualisateur pour la vidéo

Visualisateur pour les Bitmaps

Gestionnaire des filtres

MicrocosmSystème de Contrôle des Documents ( DCS )

Filtre # 1Ex. linker

Filtre # 2Ex. base de lien

Filtre # 3Ex. liens calculés

Filtre # 4Ex. liens disponibles

Système Gestionnaire des Documents

Couche de stockage ( hyperbase )

Couche service des liens

(link service)

Couche d’application

Base des liensHistoriqueHistorique d’index pour

Les liens calculésDocuments

Visualisateur pour le texte

Visualisateur pour la vidéo

Visualisateur pour les Bitmaps

Gestionnaire des filtres

MicrocosmSystème de Contrôle des Documents ( DCS )

Filtre # 1Ex. linker

Filtre # 2Ex. base de lien

Filtre # 3Ex. liens calculés

Filtre # 4Ex. liens disponibles

Système Gestionnaire des Documents

Couche de stockage ( hyperbase )

Couche service des liens

(link service)

Couche d’application

Base des liensHistoriqueHistorique d’index pour

Les liens calculésDocuments

Figure 2-5 Modèle général Microcosm [Davis95].



3.3 HyperWave (Hyper-G) Hyperwave est un vrai exemple de système Hyperbase intégré. Il était précédemment

connu sous le nom d’Hyper-G [AKM95], [Maurer96]. Les données et les liens sont

sauvegardés dans un système de gestion de bases de données orientées objets

(SGBD-OO). Les liens sont conservés dans une base de liens séparée et non dans le

document. Les liens sont considérés comme faisant partie des métadonnées du docu-

ment : l’auteur, les mots clés, les droits d’accès etc. Toutes ces métadonnées sont

stockées et gérées par le SGBD [Kappe95].

Ici, les métadonnées sont des données concernant des données, et sont utili-

sées pour décrire le format, le modèle, l’origine ou d’autres aspects des données.

Un certain nombre de serveurs sont maintenus de façon indépendante et peu-

vent coopérer pour mettre des données à disposition d'un nombre illimité

d’utilisateurs, de telle sorte qu’HyperWave est considéré comme un vrai système

d’information basé sur une architecture «client-serveur». Il donc est très proche des

systèmes WWW. Ces serveurs coopèrent entre eux pour proposer un certain degré de

gestion d’intégrité des liens [Hyperwave].

La maintenance de l’intégrité référentielle implique l’utilisation d’un proto-

cole de propagation des mises à jour, des créations et modifications de liens sur les

autres serveurs. Chaque action, initiée localement ou reçue par le bais du protocole,

est ajoutée à une liste de mises à jour. C’est cette liste qui est propagée périodique-

ment. On peut donc avoir quand même, sur des périodes toutefois assez courtes, des

problèmes d’intégrité référentielle car les mises à jours ne sont pas à effet immédiat.

Hyper-G est multi-protocole, il est compatible avec des protocoles HTTP, GOPHER,

FTP, et les protocoles natifs de Hyper-G. La figure 2-6 schématise l’architecture glo-

bale d’Hyper-G.



Serveurdocument

Serveur liens

Serveur texteGopherGopher

FTPFTP

HyperHyper--GG

Client Serveur Hyper- G

HTTPHTTP

Serveurdocument

Serveur liens

Serveur texteGopherGopher

FTPFTP

HyperHyper--GG

Client Serveur Hyper- G

HTTPHTTP

Figure 2-6 Architecture globale d’Hyper-G [AKM95].

3.4 GHIS –Système d’information Hypermédia Géographique GHIS est un système d’information hypermédia géographique avec des fonctionnali-

tés pour la gestion des liens [ACH93]. GHIS a été développé dans le cadre du projet

« Defense Science and Technology, Organisation’s Geographic Hypermedia Infor-

mation System ».

Il a été conçu comme un moyen de réaliser l’intégration d’une base de don-

nées multimédia extensible, qui inclut une gamme d’outils permettant de supporter

de multiples fonctionnalités comme le stockage, la récupération, la présentation et la

maintenance des données géographiques multimédia. Les caractéristiques des liens

sont stockées dans une table de base de données relationnelle.

GHIS peut être considéré comme un Browser de bases de données, compor-

tant du texte, des données spatiales et hiérarchiques. Les objets binaires, images, vi-

déos ou une feuille de calcul utilisant une application externe pour le traitement.

Toutes les données sont stockées dans un Système de Gestion de Base de Données

Relationnelles (SGBD-R). Les objets en dehors du SGBD, sont listés dans un catalo-

gue, chacun avec un identificateur unique et une référence à sa localisation dans le

système de fichiers.

Les suppressions sont effectuées manuellement. Elles font d’ailleurs partie

de la spécification interne. En revanche, les ajouts au catalogue sont automatisés



parce qu’ils se produisent plus fréquemment. Les entrées du catalogue incluent des

métadonnées.

3.4.1 Modélisation des liens Les implémentations actuelles des Systèmes de Gestion Hypermédia (HMS) sont ba-

sées sur des modèles de liens qui imposent certaines contraintes sur leurs spécifica-

tions. Le module de gestion des liens dans GHIS est basé sur un modèle fonctionnel.

Celui-ci réunit tous les aspects pertinents du comportement de la navigation par

liens, dans le cadre de la spécification des liens. Le modèle peut être appliqué à

n’importe quel type de spécification des liens. Il supporte la génération automatique

des liens et l’exportation des spécifications des liens entre Systèmes de Gestion Hy-

permédia.

Le modèle fonctionnel définit les spécifications du lien comme une paire de

fonctions (s,r) où la source du prédicat s sélectionne l’ensemble des éléments de

type source et la fonction de résolution r calcule l’ensemble des points de type cible

sélectionnés précédemment par les points de connexion du type source.

Le modèle fonctionnel des liens est très évolutif et d’une grande flexibilité,

car il n’impose aucune restriction dans le domaine ou contexte de navigation. Ceci

donne de la flexibilité et permet l’intégration de nouveaux documents. Le domaine

source devient un objet configurable par l’utilisateur, il n’est plus restreint aux clas-

ses ou aux types prédéfinis.

Le modèle fonctionnel est capable de supporter n’importe quel type de liens,

qu’il soit proposé ou utilisé par un autre Système Hypermédia. En particulier, il sup-

porte le lien un-à-un (déclaré).

3.4.2 Types de liens A l’origine du système GHIS, trois types de liens ont été abordés. Le nombre de ty-

pes de liens était précédemment limité par la nécessité de coder manuellement les

spécifications du lien dans le code de l’application. L’ajout de nouveaux types de

liens est cependant possible à tout moment.



Les trois types de liens originaux du système GHIS sont :

Recherche par mots clés : ce lien est activé lors de la sélection d’un objet

de la base de données, par exemple une ligne de la table. Sur un panneau

s’affiche le champ avec les valeurs par défaut et le nom de l’objet en cours

de sélection. L’utilisateur peut alors remplir ce champ de type texte. Une

fois la requête lancée, le texte est recherché dans une table indexée par des

mots clés, ensuite une liste avec des entrées est récupérée et ordonnée par

nom dans le catalogue. L’utilisateur doit ensuite choisir quel lien il veut ré-

cupérer dans le catalogue. La représentation du modèle fonctionnel est la

suivante :

- s est un attribut basé seulement sur le type du point de connexion. Le point

de connexion doit être de type texte.

- r fait appel à une requête afin d’extraire ou récupérer toutes les entrées de

la table indexée par des mots clés qui répondent à un critère de corres-

pondance. Les entrées retournées incluent le nom du catalogue et sont or-

données par celui-ci.

Relation au domaine : quand un objet de la base de données est affiché,

chaque nom de colonne est recherché dans une table qui correspond à un

domaine défini. Nous supposons alors l'existence d'une ou plusieurs autres

tables avec des colonnes de même nom. Deux options sont disponibles :

a) rechercher dans les tables des domaines définis, lesquelles ont une

colonne du même nom,

b) chercher dans ces tables toutes les colonnes qui ont des valeurs iden-

tiques dans la colonne correspondante.

Admettons que nous avons un objet de la base de données avec une colonne C de V.

Sa représentation fonctionnelle sera :

- s est un attribut source qui vérifie que C existe dans la table correspondant au

domaine défini.

- r est une résolution qui fait appel à une requête pour récupérer toutes les don-

nées dans toutes les tables qui ont une colonne C contenant la valeur v.



Lien crée par l’utilisateur : correspond au lien classique. Il est créée

comme nous l’avons décrit ci-dessus. Ce type de lien est largement accepté

et existe dans la plupart des Systèmes de Gestion Hypermédia (HMS - Hy-

permedia Management System).

3.5 HyperDisco Le système HyperDisco a été connu comme un OHS-HBMS ( Open Hypermedia Sys-

tem - Hyperbase Management System ), car il est basé sur un système de gestion Hy-

perbase [WL97]. En réalité, c'est un système hybride Hyperbase et OHS. Le système

original est intégralement Hyperbase (comme son nom l’indiquait !) [Wiil93].

Ce système prend en charge le stockage des liens et des objets autour des

liens. Il permet la création des liens dans des formats arbitraires soit dans la base ou

en dehors de la base. Les données stockées sont des objets binaires de grande taille

du type BLOB (Binary Large OBject). Ils sont considérés comme une entrée de la

base de même que les liens. Évidemment, ceci fonctionne seulement au niveau des

objets de la base. Tous les objets sont donc des BLOB et sont stockés comme des en-

trées de la base de données.

4 Conclusion Dans ce chapitre nous avons étudié les différents modèles et architectures des systè-

mes hyperbases (Dexter, Microcosm, HyperWave, HyperDisco …). Le modèle du

système hyperbase définit l'architecture selon laquelle les données contenues sont

stockées et par conséquent, gérées. Les fonctionnalités fournies par les Systèmes Hy-

perbase vont s'appuyer sur cette architecture. Un des objectifs majeurs du système est

d'assurer la cohérence des hyperdocuments et ses hyperliens. Assurer la cohérence

nécessite entre autre de garantir la validité des liens référentiels qui existent et ce,

tout au long de son cycle de vie. Ceci implique donc, que le système soit averti de

tous les changements intervenant lors de l'édition du contenu de l'hyperbase, notam-

ment lors de la création et la suppression d'un lien référentiel.