Chapitre 6 : Interface de navigation et d’interrogation 6 ...docinsa.insa-lyon.fr/these/2003/ouziri/12_iidomed_p3.pdfimage (ou du moins une image ambiguë) de l’espace d’information

Intégration et interrogation de données distribuées / Introduction

Mourad Ouziri / Thèse en informatique / 2003 / Institut national des sciences appliquées de Lyon 168

Chapitre 6 : Interface de navigation et d’interrogation

6.1 Introduction L’accès à l’information via l’outil informatique n’est plus réservé à l’informaticien. Plusieurs catégories d’utilisateurs utilisent l’ordinateur comme outil de recherche et de visualisation de l’information. Au départ, les concepteurs informaticiens ont cherché à adapter l’utilisateur à l’outil informatique. Ils ont notamment essayé de lui transmettre l’expertise informatique en lui apprenant à se servir de l’outil informatique d’une façon autonome. Le relatif échec de cette approche a conduit les informaticiens à adapter l’outil informatique à l’utilisateur.

Les interfaces d’interrogation et d’exploration de données ont fait l’objet de longues années de recherche dans ce sens. L’objectif est d’offrir à l’utilisateur un outil visuel suffisamment personnalisé qui lui permet d’effectuer sa tâche de recherche d’informations avec le moindre effort. Ces travaux ont abouti à des in-terfaces très élaborées de plus en plus interactives et personnalisées. Comparées aux interfaces d’interrogation de bases de données, telles que SQL ou même QBE, les interfaces d’aujourd’hui sont très interactives, plus intelligentes et met-tent l’utilisateur au centre de l’interrogation à travers la modélisation du profil de l’utilisateur.

La plupart des interfaces actuellement conçues sont basées sur la naviga-tion dans un grand espace (appelé aussi hyperespace) d’informations. Au fil de sa navigation, l’utilisateur se construit un image mentale conforme à celle qui lui est présentée. Toutefois, l’utilisateur est confronté, dans ce type d’interfaces, à une surcharge d'informations et une multitude de possibilités de navigation qui le mènent à un état d’égarement connu sous le terme de perte dans un hyperespace (ce syndrome est connu sous le nom anglo-saxon : lost in hyperspace). La consé-quence directe de cet état de fait est que l’utilisateur se construit une fausse image (ou du moins une image ambiguë) de l’espace d’information ainsi créé ce qui affecte considérablement la qualité et l'efficacité de la recherche d'informa-tions.

Nous proposons dans ce chapitre de concevoir une interface intelligente qui permet à l’utilisateur de réaliser sa navigation le plus intuitivement possible et sans efforts intellectuels considérables tout en lui garantissant la cohérence sémantique de l’information présentée. Nous ne nous sommes pas intéressés aux techniques de visualisation de l’information (en graphes, cartes, réalité virtuelle, etc.), nous avons utilisé une technique toute simple pour la visualisation de

Intégration et interrogation de données distribuées / Introduction


l’information, à savoir les cartes de concepts. Nous nous sommes intéressés aux aspects dynamiques des interfaces comme l’adaptation, l’interactivité et la navi-gation sémantique. Notre interface génère à l’utilisateur un document qui synthé-tise sa session de recherche d’informations. Ce document est appelé document virtuel personnalisé.

6.2 Les deux modes d’utilisation de l’interface

En partant de la vue matérialisée construite en intégrant plusieurs sources de données, nous développons notre interface selon deux approches d’exploration de données : l’approche centrée sujet et l’approche centrée population. La logique d’exploration des données diffère selon l’objet de la recherche d’informations.

Figure 6.1 Étapes préliminaires de conception d’interfaces

DS1 DS2 DS3

topic map3

topic map 1

topic map 2

Intégration Sémantique

topic map fédérée

Interface centrée

population

Interface

centrée sujet

Interprétation

Intégration et interrogation de données distribuées / Interface centrée sujet


6.3 Interface centrée sujet La recherche visuelle d’informations est une technique très sollicitée pour la conception d’interfaces. L’approche la plus utilisée dans ce type d’interfaces est constituée des phases suivantes [Doan 99] [Shne 96] :

• Phase 1 - Vue d’ensemble (Overview) : présenter tout d’abord pour l’utilisateur une synthèse du contenu de l’espace d’informations. Cette re-présentation donne à l’utilisateur uniquement les caractéristiques princi-pales des données de la collection.

• Phase 2 - Zoom : l’utilisateur va effectuer une première recherche en sé-lectionnant des items généraux qu’il juge pertinents pour la suite de sa re-cherche.

• Phase 3 - Filtrage : le système filtre ainsi les items non sélectionnés par l’utilisateur.

• Phase 4 - Détailler sur demande : l’espace d’informations étant réduit, l’utilisateur a la possibilité de visualiser un item ou un groupe d’items avec plus de détails.

• Phase 5 - Mise en relation : l’utilisateur peut effectuer sa recherche d’informations par sélection d’items reliés à ceux précédemment sélec-tionnés. Par exemple, à partir d’un item Directeur de recherche, l’utilisateur peut vouloir visualiser les items étudiants liés par la relation encadrés par.

• Phase 6 - Historique des actions : étant donné que, généralement l’utilisateur ne parvient pas à retrouver l’information directement et qu’il emprunte souvent des faux chemins, le système doit garder en mémoire les actions effectuées par l’utilisateur pour pouvoir remonter en arrière dans sa recherche.

• Phase 7 - Extraction : le système doit pouvoir extraire les informations sé-lectionnées lors de la recherche et la stocker dans un format exploitable par des applications externes telles la que messagerie électronique (pour échanger l’information par mail) et les outils de calculs statistiques.

L’interface que nous proposons a été conçue suivant cette approche que

nous avons adaptée à nos besoins. En effet, nous avons constaté que dans de nombreux domaines d’application, la recherche d’informations respecte la logi-que suivante : l’utilisateur recherche des informations autour d’un sujet connu au préalable.

Rappelons que notre but est de concevoir un système d’accès à l’information distribuée qui prenne en charge tous les niveaux d’abstraction des données (donnée/valeur, structure, sémantique). En effet, la majorité des systè-mes d’accès à l’information ne vérifient pas la sémantique des données et laissent par conséquent la charge d’interpréter les données à l’utilisateur. Ceci constitue



une charge intellectuelle très lourde voire impossible compte tenu du volume de données que l’utilisateur est amené à explorer.

Nous avons montré dans les sections précédentes comment nous avons pris en considération la sémantique des données dans le processus d’intégration. Nous poursuivons notre conception dans la même perspective et nous concevons une interface d’interrogation basée sur une approche par navigation sémantique dans l’espace de données intégrées. En résultat, nous obtenons un système com-plet qui prend totalement en compte la sémantique à tous les stades de traitement de l’information (représentation, fusion, interrogation et présentation). De plus, l’interface produit un document virtuel personnalisé qui contient l’information requise par l’utilisateur. Ce document est conçu selon la structure logique et sé-mantique des données. L’architecture de l’interface se présente comme suit :

Figure 6.2 Architecture de l’interface de navigation et de génération de docu-ments virtuels centrés sujet

Dans ce qui suit, nous essayons de présenter notre interface tout en nous

référant aux concepts d’interfaces visuelles présentés ci-dessus et définis dans [Shne 96].

Données (Topic Map)

Document personnalisé

navigation

XSLT Web

DocumentXSL



6.3.1 Navigation sémantique centrée sujet L’espace d’informations que nous interrogeons est représenté et organisé en une topic map. Cette organisation contribue fortement au développement de notre in-terface notamment à la navigation sémantique. En effet, les données sont repré-sentées par des topics. Un topic est une entité sémantique issue d’une fusion sé-mantique des données multisources. Les topics qui représentent les données sont organisées autour d’un topic représentant un concept. En d’autres termes, chaque topic donnée est attaché à un topic concept. Une donnée peut être soit un individu tel que Dupont ou Arnaud soit une association telle que examen37 ou ensei-gner24.

Pour permettre à l’utilisateur d’interroger les données facilement et le plus naturellement et intuitivement possible, nous avons opté pour l’approche d’interrogation par navigation dans une interface visuelle de type carte de concepts. En effet, cette façon de présenter l’information est exactement similaire à la façon dont l’être humain organise ses connaissances mentales, c’est-à-dire un ensemble d’unités conceptuelles interconnectées par des liens sémantiques. Une unité conceptuelle correspond à un topic et un lien sémantique à une association. Notons que la topic map globale est générée suivant un processus d’intégration sémantique des données. L’interface ne présente pas à la fois toute la carte de concepts. A chaque instant, elle ne présente que les informations pertinentes par rapport aux conditions sur les attributs exprimées par l’utilisateur pendant la na-vigation.

Schéma de données exactement instancié Cette carte de concepts n’inclut pas explicitement les topics données. Elle est constituée uniquement de topics concepts qui représentent le schéma des don-nées. Les données sont implicitement confondues dans le schéma. Le schéma est composé de topics concepts qui sont liés par des topics associations (liens séman-tiques). Par contre, ces topics (concepts et associations) sont régis par les topics données. Plus précisément, un topic du schéma n’existe que s’il a au moins un topic donnée. Nous appelons ce schéma topic map exactement instanciée. De plus, chaque topic de la topic map exactement cardinalisée est libellé par un en-tier représentant sa cardinalité, c’est-à-dire le nombre de ses instances.



Figure 6.3 Schéma exactement cardinalisé centré sur le concept MEDECIN

Schéma de données dynamique Le schéma est entièrement dynamique du moment qu’il n’a pas une structure unique et figée. En effet, si à un instant donné, il n’y a aucune instance associée à un concept C du schéma, il est considéré comme non pertinent et est supprimé par conséquent de ce schéma. De même, s’il n’y a aucune instance d’une associa-tion A entre les concepts C1 et C2, le lien matérialisant cette association est sup-primé du schéma ; le concept C2 est également supprimé du schéma en considé-rant que la topic map était centrée sur le concept C1. Le schéma n’a donc pas les mêmes concepts à chaque instant et les liens d’associations évoluent également dans le temps. Cette notion de topic map dynamique et exactement instancié est centrale dans la conception de cette interface. Dans ce qui suit, la carte de concepts est un schéma dynamique exactement instancié.

Navigation sémantique L’interface est donc une représentation visuelle d’une carte de concepts dans la-quelle le schéma et les instances sont confondus. Les liens d’associations de cette représentation sont exactement cardinalisés. Les instances de chaque concept et les cardinalités exactes de ses liens sont calculées au fur et à mesure pendant la navigation de l’utilisateur dans cette carte en fonction des contraintes spécifiées sur leurs attributs. Ces cardinalités exactes donnent à l’utilisateur une informa-tion a priori sur les liens entre les concepts (c’est-à-dire sur le nombre d’occurrences répondant à sa requête) ce qui lui permet de mieux diriger sa navi-gation sans pour autant être contraint à formuler une requête.

Au début d’une session d’interrogation, la carte de concepts est centrée sur le sujet de l’interrogation. En effet, à chaque ouverture d’une session par l’utilisateur, ce dernier doit spécifier un sujet sur lequel sera centrée toute la ses-sion. Cette visualisation correspond à la phase d’overview (phase 1 - vue d’ensemble) de l’approche. A partir de ce sujet, une partie de la carte de concepts est visualisée. Cette partie, que nous appelons partie valide de la carte de



concepts, est composée des concepts directement liés au concept sujet ainsi que les associations qui les lient. Supposons qu’on ait à visualiser une carte de concepts S à partir du concept sujet cs. Nous avons :

S = C ∪ A où C = {c1, …, cs, …, cn} et A = {a1, a2, …, am} sont, respecti-vement, l’ensemble des concepts et l’ensemble des associations du schéma dy-namique S. L’algorithme de construction de la partie valide de la carte de concepts globale est le suivant :

Tableau 6.1 Algorithme de construction de la partie valide par rapport à un concept sujet

Une fois que la partie valide de la carte de concepts est calculée, elle est

visualisée par l’interface sous forme de boîtes visuelles connectées par des droi-tes. L’utilisateur peut interroger cette carte soit par spécification de conditions sur les attributs du concept sujet soit par navigation du concept sujet vers un au-tre concept de la partie valide visualisée.

La navigation sémantique consiste à explorer la carte d’un topic vers un autre selon l’hypothèse suivante : tous les topics successivement visités lors de la navigation sont liés à deux niveaux, au niveau sémantique et au niveau instances. 1. Au niveau sémantique : Étant donné que la topic map globale est générée suite à une fusion sémantique de données, les concepts sont liés par des relations sémantiques. Donc, quand l’utilisateur navigue d’un topic t1 vers un autre topic t2, cette navigation a le sens suivant : le topic t2 du topic t1. Par exemple, soit les deux topics Patient et Méde-cin liés par la relation sémantique Examiné. Si l’utilisateur navigue de Patient vers Examiné et ensuite de Examiné vers Médecin, ces deux actions de naviga-tion doivent être interprétées, respectivement, par l’utilisateur comme suit :

- Les examens des patients, et - Les médecins qui ont examiné les patients.

2. Au niveau instances :

Inputs : S = C ∪ A : Schéma dynamique, Cs : un concept sujet Output : P : la partie valide P ⊆ S / P = Cp ∪ Ap = ∅ // Partie valide par rapport à cs Cp = Cp ∪ {cs} Pour chaque c ∈ C faire si ∃ a ∈ A telle que a(cs,c) alors // c est associé avec cs par a Cp = Cp ∪ {c} // ajout sans doublons Ap = Ap ∪ {a} finsi finpour



Chaque topic (représentant un concept ou une association) de la carte de concepts est décrit par une partie intensionnelle et une partie extensionnelle. La partie in-tensionnelle d’un topic ti est constituée de l’ensemble de ses attributs et des asso-ciations auxquelles il participe. Sa partie extensionnelle Ext_ti est composée d’in-dividus ; Ext_ti = {ii1, ii2, …, iin}.

A l’ouverture d’une session, la carte de concepts se trouve dans un état initial E_0. Cet état change chaque fois que l’utilisateur réalise une opération de navigation ou d’interrogation. Un état de la carte de concepts est constitué de :

• Les topics de la carte, • La partie extensionnelle de chaque topic, • Le concept valide

En d’autres termes, E_0 = <T_0, Ext_T_0, Cv_0>

A l’état initial, le concept valide est le concept sujet à partir duquel la navigation commence. Quand l’utilisateur navigue d’un topic t1vers un topic t2, la partie ex-tensionnelle de t2 est recalculée de telle sorte que tous ses individus soient liés à au moins un individu de t1 :

Ext_t2_1 = {i2j / i2i ∈ Ext_t2_0, ∃ i1k ∈ Ext_t1_0 et R(i2j , i1k)} La formule précédente est valable uniquement pour calculer les instances d’un topic directement lié au sujet de la session. Supposons que l’utilisateur ait navi-gué du concept sujet vers le topic t1, ensuite du topic t1 vers le topic t2, jusqu’au topic tn. La chaîne de navigation est donnée par la liste suivante :

Nav = <cs, t1, t2, …, tn> Les instances du topic tj (j≥2) dépendent non seulement des instances du topic tj-1 mais aussi des instances des topics tj-2, tj-3, …, t1, cs, donc :

Ext_tj_β = {iji / iji ∈ Ext_tj_β-1, ∃ ij-1 ∈ Ext_tj-1_β-1, ∃ ij-2 ∈ Ext_tj-2_β-1,…., ∃ ics ∈ Ext_cs_β-1 et R(ics, i1, …, ij-2 , ij-1)}

Comme nous l’avons expliqué, la navigation sémantique est une inter-

prétation d’une chaîne de navigation constituée de topics. La navigation des to-pics Patient, Médecin, Examen, Service (dans cet ordre) est interprétée comme suit : les services dans lesquels ont été réalisés les examens des patients prescrits par les médecins. Cette approche de navigation est plus intéressante quand l’interrogation est centrée sur un individu. Par exemple, prenons comme sujet l’individu Dupont du topic Patient. La navigation sémantique centrée sur le sujet Dupont consiste donc à explorer son dossier médical. La chaîne de navigation Patient, Médecin, Examen, Service s’interprète à chaque étape comme suit : {Patient, Médecin} : les médecins du patient Dupont. {Médecin, Examen} : les examens réalisés par les médecins lors des soins de Du-pont. Notons que les médecins de Dupont ont produit plusieurs examens lors de leurs rencontres avec d’autres patients. Ces examens, bien qu’ils soient reliés aux médecins, ne font pas partie du résultat de la navigation.



{Examen, Service} : les services dans lesquels les examens de Dupont sont réali-sés par les médecins.

Les instances de chaque topic sont calculées au fur et à mesure de la na-vigation en suivant la sémantique définie : Initialement : Ext_Patient = {Dupont} {Patient, Médecin} : Ext_Médecin = {Peter, Jack}. Peter et Jack ont examiné cha-cun le patient Dupont. {Médecin, Examen} : Ext_Examen = {e1,e2,e3}. Peter a soigné Dupont deux fois, les examens e1 et e2 sont les examens de Dupont prescrits par Peter et e3 est l’examen de Dupont prescrits par Jack. {Examen, Service} : Ext_Service = {s1,s2}. Peter a prescrit deux examens à Du-pont, e1 et e2, au sein du service s1 et Jack a prescrit e3 à Dupont au sein du ser-vice s2.

A chaque étape de la navigation, le schéma visualisé pour l’utilisateur représente à la fois la description conceptuelle des données et les données elles-mêmes. Ceci est visible dans la figure 6.3 à travers les cardinalités des concepts affichés sur le schéma. Ces cardinalités donnent à l’utilisateur une idée globale sur la distribution des données et lui permettent d’orienter sa navigation sans être contraint à formuler des requêtes. A travers la cardinalité 5 sur le lien associant Patient et Médecin, l’utilisateur saura que le patient Dupont, sujet de la session, est examiné par 5 médecins. A partir de là, il peut décider s’il continue la naviga-tion en suivant le lien vers Médecin ou en empruntant un autre chemin. Si le nombre de médecins est très petit, l’utilisateur peut donc aller directement visua-liser des informations sur ces médecins, sinon il pourra affiner sa requête sur une maladie donnée et ensuite aller vers Médecin pour visualiser les informations sur les médecins qui ont traité cette maladie.

6.3.2 Interface multi-facettes : adaptation, confidentialité et sécurité des données

Nous avons présenté dans la section précédente une approche de navigation sé-mantique centrée sujet. Cette navigation permet à l’utilisateur d’interroger et d’explorer des données multisources d’une façon très intuitive et naturelle. Ce-pendant, cette interface ne peut être utilisée par tous les utilisateurs du système d’une façon efficace. En effet, le contenu de la carte de concepts présentée à l’utilisateur n’est pas adaptée à tous les utilisateurs pour diverses raisons. Nous citons, entre autres, les deux suivantes :

1 L’interface ne tient pas compte du niveau de connaissances de certains utilisateurs.



2 L’interface présente des informations non pertinentes qui deviennent en-combrantes pour la recherche de l’utilisateur.

Nous présentons dans cette section l’adaptation de l’interface aux diffé-rentes classes d’utilisateurs. L’utilisation du système n’est pas restreinte à un uti-lisateur donné mais plutôt à plusieurs utilisateurs. L’interface du système est ob-tenue suite à la phase d’intégration des données. A ce stade, elle est constituée d’une carte de concepts qui présente les données telles qu’elles ont été intégrées sans tenir compte des spécificités des utilisateurs.

Les utilisateurs ont des objectifs spécifiques, des habitudes différentes, des préférences personnelles et des connaissances qui varient d’un utilisateur à l’autre. Pour adapter l’interface selon ces critères, les utilisateurs sont classés suivant des catégories appelées profils d’utilisateurs. Médecin, spécialiste, can-cérologue, pédiatres, secrétaire administrative, secrétaire médicale, etc. sont des exemples de profils qui peuvent être construits pour le domaine médical. L’interface est donc adaptée à chaque profil et non à chaque utilisateur.

De plus, par le processus d’adaptation, nous proposons une interface qui garantit la sécurité et la confidentialité des données. Les utilisateurs ont effecti-vement des attentes et des préférences mais ont aussi des droits d’accès diffé-rents. Dans le domaine médical, par exemple, les secrétaires administratives ne doivent pas avoir accès aux informations de soins ; les médecins généralistes peuvent avoir accès à tous les examens exceptés ceux qui sont édités par des spé-cialistes. Ceci constitue l’aspect de la confidentialité des données. Nous abordons un aspect de la sécurité des données, par la notion de contrôle d’accès aux don-nées protégées. Par exemple, l’utilisateur peut consulter le dossier médical d’un patient donné mais n’a pas le droit de le modifier ni de l’exporter dans un format externe pour l’impression ou pour toute autre opération.

Les préférences et les droits d’accès attribués aux utilisateurs sont pris en considération dans la conception de l’interface par la notion de facette. La no-tion de facette est donc utilisée pour modéliser l’ensemble des informations qui permet de personnaliser l’interface par rapport aux profils des utilisateurs. Cha-que facette de l’interface correspond à un seul profil d’utilisateurs. La figure sui-vante schématise la notion d’interface multi-facettes.



Figure 6.4 L’aspect multi-facettes de l’interface L’interface multi-facettes est constituée de la topic map globale, appelée

topic map générique, et d’un ensemble de facettes. Comme le montre la figure 6.4, la topic map générique est personnalisée par l’utilisation des facettes. En fait, une facette caractérise un profil d’utilisateurs et transforme la topic map gé-nérique en une topic map personnalisée aux utilisateurs du profil concerné. Ce schéma représente bien le fonctionnement des interfaces génériques présentées dans [Lafo 97]. L’utilisateur expert définit les paramètres de chaque facette en fonction du profil des utilisateurs. L’interface adapte automatiquement la topic map générique à ce profil.

Spécification des facettes Nous avons vu, d’après l’architecture des interfaces génériques, que la facette est définie par l’utilisateur expert. La topic map générique n’est visible que pour cet utilisateur. Ce dernier connaît parfaitement la notion de facettes, de profils d’utilisateurs et leurs paramètres, notamment les droits d’accès et les préférences des utilisateurs.

Avant la spécification des facettes, l’utilisateur expert doit avoir une connaissance complète du contenu de la topic map globale, notamment des to-pics, des associations entre topics et de leurs attributs. A partir de là, une facette est spécifiée en prenant en compte plusieurs éléments : Les concepts qui vont constituer l’interface personnalisée. En effet,

l’interface générique contient tous les concepts du système d’information. Or,

topic map globale

(générique)

TM 1 TM 2 TM 3

MédecinSecrétaire Spécialiste

topic maps facettées

Profils d’utilisateurs

Facette1 Facette2 Facette3



l’interface est adaptée par rapport aux connaissances des utilisateurs ainsi qu’à leurs droits d’accès. Par exemple, pour les utilisateurs du personnel ad-ministratif d’un hôpital, leur niveau d’accès aux données est limité. D’autre part, pour garantir la confidentialité des données, il est possible de cacher complètement des concepts. Par exemple, pour les médecins externes et les médecins stagiaires de l’hôpital, on peut cacher certaines données très confi-dentielles. Les concepts qui constituent l’interface sont l’un des éléments les plus importants pour l’adaptation de l’interface.

Les individus associés aux concepts de l’interface. Très souvent, les utilisa-teurs s’intéressent uniquement à une classe donnée d’individus. Par exemple, les médecins spécialistes ne s’intéressent pas aux traitements des maladies autres que celles relevant de leur spécialité ou encore les pédiatres ne consul-tent que les patients âgés de moins de 16 ans. Pour ces deux catégories, les concepts Patient et Traitement sont visibles mais leurs extensions sont res-treintes à celles qui sont pertinentes par rapport à un profil donné. La confi-dentialité est aussi un facteur qui définit les individus pertinents de chaque concept. Par exemple, les examens de certains patients ne doivent pas être consultés par des médecins non permanents de l’hôpital.

Les droits d’accès aux objets de la topic map globale. Les opérations que peuvent effectuer les utilisateurs sur les données diffèrent d’un utilisateur à l’autre. Par exemple, l’opération d’export des données d’un patient dans un dossier papier est restreinte uniquement au médecin du patient. Un ensemble de droits/opérations est à définir en fonction des besoins des utilisateurs du domaine d’application et à intégrer dans la facette.

Le vocabulaire utilisé dans la topic map facettée. La topic map générique est construite à partir de la fusion des données extraites des sources de données. Ces sources ont été conçues et définies par des spécialistes. Ces spécialistes sont confrontés à des contraintes de conception et d’implémentation. C’est pour cela que, généralement, les données sont indépendantes des utilisateurs potentiels. Donc, nous devons adapter ces données aux différentes catégories d’utilisateurs. Les termes choisis pour constituer la topic map facettée est un élément très important pour l’adaptation. En effet, les utilisateurs n’ont pas tous le même niveau de connaissances et utilisent des vocabulaires différents. Ce point consiste à présenter une topic map dans laquelle tous les termes uti-lisés sont familiers à l’utilisateur. Par exemple, le topic Patient peut être pré-senté aux utilisateurs qui ne font pas partie du personnel médical sous le nom de Malade. C’est en fait le nom visible de l’objet qui sera visible à l’utilisateur. Les éléments de la topic map qui auront un nom visible sont les topics (qui représentent des concepts ou des associations) et les attributs des topics.



Figure 6.5 Spécification de facettes de personnalisation de l’interface générique

Modèle des facettes Nous avons vu que l’adaptation est mise en œuvre grâce à la notion de facette. Nous avons défini clairement ce qu’est une facette et comment elle est spécifiée pour l’adaptation de l’interface générique aux profils utilisateurs. Les systèmes d’information disposent d’un certain nombre d’outils pour concrétiser la notion de facette. Par exemple, pour identifier les utilisateurs, on pourra utiliser le nom utilisateur et son mot de passe. Les facettes peuvent être modélisées par des ta-bles du modèle relationnel.

Nous formalisons la notion d’adaptation de l’interface générique en uti-lisant des outils plus performants et intelligents. Parmi les objectifs que nous nous sommes fixés est celui de concevoir un système d’information intelligent. Nous utilisons le terme de système intelligent pour désigner un ensemble de fonctionnalités qui rendent le système capable de réaliser certaines tâches sans qu’un opérateur humain n’intervienne pour spécifier explicitement toute la pro-cédure. L’autonomie du système est donc davantage augmentée.

Dans les principes de conception d’interfaces traditionnelles, les utilisa-teurs sont identifiés dans le système par deux attributs : le nom de l’utilisateur et son mot de passe. Tout utilisateur de l’interface est déclaré explicitement appar-tenant à un profil donné. Les spécificités de chaque profil sont déclarées explici-tement par l’administrateur de l’interface. L’interface que nous proposons facilite grandement les tâches de l’administrateur en proposant des procédures plus intel-ligentes pour la gestion de l’adaptation et des utilisateurs de l’interface. Par exemple, les utilisateurs et leurs profils sont représentés dans le système non pas par des identificateurs mais par des descripteurs qualitatifs. Dans les systèmes traditionnels, les utilisateurs sont affectés aux profils explicitement. Dans notre

Sécurité

Interface adaptée

Facette

ConfidentialitéInterface générique

Adaptation



interface, les utilisateurs sont affectés aux profils qui leur correspondent selon leurs descriptions en utilisant des raisonnements automatiques et intelligents. D’autre part, les profils utilisateurs peuvent avoir des relations telles que l’inclusion. Ces relations, implicites, sont automatiquement détectées et tous les utilisateurs du sous-profil sont affectés au profil qui le contient. De même, les droits d’accès du sous-profil sont naturellement donnés au profil qui le contient.

Dans les interfaces traditionnelles, toutes les opérations de gestion des utilisateurs et des droits d’accès se font soit manuellement soit par des procédu-res dans lesquelles le concepteur doit expliciter toutes les tâches d’administration. Ayant un grand nombre d’utilisateurs et de profils à gérer, plu-sieurs incohérences peuvent apparaître. Nous gérons ceci grâce au formalisme des logiques de descriptions qui offre des raisonnements automatiques et assez intelligents. Le modèle des facettes est un quadruplet défini comme suit :

Facet = (object, visible-name, subject, access-rights) Où, object représente un topic, une sous-partie d’un topic ou un attribut sur lequel porte la facette, visible-name représente le nom visualisé pour l’objet object dans la topic map personnalisée, subject représente le profil utilisateur pour lequel est définie la facette. Access-rights représente les droits d’accès donnés aux utilisateurs du profil sub-ject sur l’objet object. Les éléments des facettes peuvent être représentés indépendamment les uns des autres. Chaque élément sera représenté en utilisant un formalisme adéquat. Ceci concerne essentiellement les éléments object et subject des facettes.

1. Représentation des objets d’une facette : l’élément object Object représente un topic concept/association, un sous-ensemble d’un topic ou un attribut d’un topic. Il est composé d’une partie intentionnelle et d’une partie extensionnelle. La partie intentionnelle d’un objet object constitue sa description conceptuelle. La partie extensionnelle est constituée des instances de l’objet ob-ject. Pour cet objet, le modèle relationnel semble le plus adéquat car il est per-formant pour le stockage et l’interrogation des données représentées par les par-ties extensionnelles des objets.

Finalement, les objets d’une facette ne sont rien d’autre que des vues créées sur les objets de la topic map générique. Cette notion est très connue dans le monde des bases de données relationnelles sous le nom de vue (vir-tuelle/matérialisée). Les objets d’une facette correspondent à une vue qui est



créée par une requête. La requête elle-même représente la partie intensionnelle de l’objet et son résultat représente la partie extensionnelle de l’objet. Le nom visi-ble de l’objet est directement représenté dans la vue. Par exemple, soit à créer une facette sur l’objet Patient qui est restreint uniquement aux patients de la ré-gion parisienne. On appelle cet objet Patient-Parisiens. La partie intentionnelle de cet objet est représenté par la vue :

Create view Patient-Parisien as select * from Patient where ville = “Paris”

De même, les attributs pour lesquels la facette est définie sont représentés dans la vue. Par exemple, la vue définie uniquement sur les attributs prénom et date de naissance des patients parisiens dont les noms visibles de ces attributs sont pré-nom_parisien et date-nais-parisien est donnée par la requête :

Create view Patient-Parisien (prénom_parisien, date-naiss-parisien) as select prénom, ddn from Patient where ville = “Paris”

2. Représentation et gestion des utilisateurs et des profils utilisateurs : l’élément subject

Les profils utilisateurs et les droits d’accès d’une interface sont généralement gé-rés à l’aide de procédures statiques, c’est-à-dire que l’administrateur doit spéci-fier explicitement tous les profils, les droits d’accès pour chaque profil et doit af-fecter chaque utilisateur aux profils correspondants. Cette approche complexifie la gestion des utilisateurs et de leurs profils d’autant plus que le nombre de pro-fils et d’utilisateurs du système augmente. Généralement, ceci amène le système à un état d’inconsistance. Supposons que le profil Médecin ait été défini par les droits d1 et d2. Quand un nouveau profil est introduit dans le système, l’administrateur doit donner explicitement toutes ses spécificités. Soit à ajouter le profil Spécialiste. Si ce profil est défini uniquement par les droits d3 et d4, nous considérons que le système est dans un état d’incohérence sémantique car les spécialistes sont aussi des médecins. Donc, le système doit attribuer automati-quement les droits d1 et d2 au profil Spécialiste.

Nous proposons une approche de gestion plus intelligente et automatique des utilisateurs, des profils, des affectations des droits d’accès aux profils et des affectations des utilisateurs aux profils adéquats. Les performances que nous avons obtenues sont liées d’une part au formalisme utilisé pour représenter les données de l’interface et d’autre part à la manière dont sont représentés les utili-sateurs et les profils dans le système.

Les utilisateurs et les profils utilisateurs de l’interface sont représentés par des attributs qualificatifs et non par des attributs d’identité. Considérons le domaine médical et soit à représenter les utilisateurs d’un hôpital définis dans la TBox suivante:



Tableau 6.2 Représentation de type qualificatif des profils utilisateurs

Les profils sont décrits par des attributs qualificatifs sémantiquement compréhensibles. Par exemple, le spécialiste est un médecin qui a au moins une spécialité. Les profils ne sont pas complètement indépendants et peuvent avoir généralement des relations. Nous nous intéressons à la relation de subsomption entre les profils. Ces profils sont automatiquement classés selon leurs descrip-tions sous forme d’une hiérarchie, comme le montre la figure suivante :

Figure 6.6 Hiérarchie des profils générée automatiquement Cette hiérarchie est générée dynamiquement en utilisant le raisonnement

de subsomption de la logique de descriptions. Si un nouveau profil venait à être introduit dans le système il sera classé automatiquement, en fonction de sa des-cription, dans la hiérarchie au niveau le plus adéquat.

Employé ≡ ∀nom.String ⊓ ∀ddn.Date ⊓ ∀adresse.String ⊓ ∀catégo-

rie.String ⊓ ∀spécialité.String ⊓ ∀fonction.String

Médecin ≡ Employé ⊓ catégorie = ”médical”

Secrétaire ≡ Employé ⊓ ≥1 catégorie = ”administratif”

Infirmier ≡ Employé ⊓ catégorie=”infirmier”

Spécialiste ≡ Médecin ⊓ ≥1 spécialité

Généraliste ≡ Médecin ⊓ = 0 spécialité

Pédiatre ≡ Spécialiste ⊓ spécialité= ”pédiatre”

Cancérologue ≡ Spécialiste ⊓ spécialité= ”cancérologue”

Secrétaire-méd ≡ Secrétaire ⊓ fonction = ”secrétaire médical”

Secrétaire-admin ≡ Secrétaire ⊓ fonction = ”secrétaire administratif”

Employé

MédecinInfirmier

GénéralisteSpécialiste

Cancérologue

Secrétaire

Pédiatre

Médical Administratif



Cette hiérarchie joue un rôle très important pour l’attribution cohérente de privilèges (droits d’accès) aux profils. En effet, si on attribue le privilège d1 au profil Médecin, logiquement ce privilège devrait être attribué également aux profils Spécialiste, Généraliste, Cancérologue et Pédiatre puisqu’un spécialiste est avant tout un médecin, Spécialiste ⊑ Médecin. D’une manière générale, la formule suivante devrait être vérifiée pour tous les profils :

∀ P1, P2 ∈ {profils de l’interface}, P1 ⊑ P2 ⇒ Privilèges (P2) ⊆ Privilèges (P1)

Cette formule permet d’attribuer les privilèges aux profils d’une façon cohérente et automatique. L’utilisateur ne sera pas obligé de définir tous les privilèges pour les profils et ne s’occupera pas de la cohérence de cette tâche. Cette tâche com-plexe est garantie par le système sans l’intervention de l’administrateur.

Une fois les profils et leurs privilèges définis, le système identifie les utilisateurs et les affecte à leur profil adéquat d’une façon automatique. En effet, les utilisateurs sont également décrits par des attributs qualificatifs. A l’inverse des profils, les utilisateurs sont déclarés dans la ABox. Par exemple, soit la ABox suivante :

Les utilisateurs Durant et Arnaud sont déclarés comme étant des employés de l’hôpital. En utilisant le raisonnement msc (Most Specific Concept), le système classe les utilisateurs dans les profils les plus adéquats. En effet, nous avons vu que les profils sont représentés par des descriptions dans une TBox et les utilisa-teurs sont représentés par des individus dans la ABox. Le msc consiste à affecter à chaque utilisateur le profil le plus spécifique ce qui lui confèrera le maximum de privilèges. C’est ce que nous appelons la découverte de privilèges pour les uti-lisateurs. Les utilisateurs e1 et e2, bien qu’ils soient déclarés instances de Em-ployé, sont classés respectivement sous les profils Spécialiste et Généraliste.

Les descriptions qualificatives des utilisateurs sont utilisées uniquement pour décrire et classer les utilisateurs dans leur profil le plus adéquat. A l’ouverture d’une session, l’utilisateur s’identifie grâce à un nom d’utilisateur et un mot de passe. A partir de cette identification, le système récupère les asser-tions qui décrivent l’utilisateur de la ABox et lance le processus de découverte de privilèges et du profil le plus adéquat.

Employé(e1) Employé(e2) nom(e1, ”Durant”) nom(e2, ”Arnaud”) Catégorie(e1, ”médical”) Catégorie(e2, ”médical”) spécialité(e1, ”radiologie”)



Adaptation de la présentation et de la navigation La facette ainsi conçue concerne uniquement l’adaptation du contenu de la topic map générique par rapport aux profils des utilisateurs. L’adaptation de la présen-tation consiste à adapter la présentation de la topic map personnalisée par la fa-cette par rapport aux préférences de l’utilisateur.

L’adaptation de la présentation concerne les aspects graphiques et vi-suels de la topic map présentée. Par exemple, les topics sont visualisés sous dif-férentes formes et couleurs en fonction de leurs pertinences par rapport à l’utilisateur. La position des topics dans la topic map est aussi un facteur qui permet de personnaliser la présentation.

L’adaptation de la navigation consiste à présenter une topic map dans laquelle les liens entre les topics sont également triés et présentés sous des for-mes et couleurs exprimant leur pertinence. En effet, la pertinence d’un lien est évaluée en fonction de celle des topics référencés par ce lien. Nous n’avons pas travaillé intensivement sur ces deux points. Le lecteur pourra se référer à l’état de l’art pour les travaux concernant l’adaptation des hypermédias.

La procédure d’adaptation du contenu, de la présentation et de la naviga-tion de l’interface générique par rapport à l’utilisateur est donnée par la figure suivante :

Figure 6.7 Classification automatique de l’utilisateur et adaptation de l’interface générique

Interface

Personnalisée

Identification

Affectation de l’utilisateur

(LD)

Adaptation(facettage)

Intégration de données

Interfacegénérique



6.3.3 Interface adaptative Le développement d’une interface adaptée permet de présenter à chaque utilisa-teur une interface adaptée à ses préférences, à son niveau de connaissances et lui donne les privilèges en fonction de son profil. Toutefois, l’utilisateur a des be-soins spécifiques et ponctuels qui ne sont pas représentés dans le profil soit parce que ses besoins sont ponctuels et changent d’une session à l’autre soit parce que l’utilisateur exprime ses besoins en terme d’information en fonction des données instantanées présentées par l’interface.

D’une autre part, l’adaptation de l’interface est réalisée par les informa-tions sur les préférences, les besoins, les objectifs, le niveau de connaissance des utilisateurs du profil. Pour une session d’interrogation donnée, le volume de don-nées présenté par l’interface adaptée pour ce profil reste toujours vaste par rap-port au besoin à un instant donné de l’utilisateur. En effet, les données de l’interface adaptée au profil sont calculées pour tous les utilisateurs du profil et pour toute utilisation future.

C’est pour cette raison que nous avons développé l’autre aspect des in-terfaces, à savoir les interfaces adaptatives. L’interface adaptée présente à l’utilisateur des données présentées en fonction de ses besoins et de ses préféren-ces. Ces données sont personnalisées cette fois-ci en utilisant les requêtes de l’u-tilisateur qui expriment ses besoins en temps réel. La structure complète du topic map n’est donc pas connue avant la navigation et change et s’adapte à chaque requête de l’utilisateur. Pour pouvoir réaliser cette aspect de l’interface nous avons introduit la notion de schéma dynamique exactement instancié.

Notion de schéma exactement instancié Un schéma dynamique exactement instancié est une topic map qui représente la partie conceptuelle des données, c’est donc tout d’abord un schéma traditionnel. Les topics de ce schéma représentent soit des concepts soit des associations conceptuelles entre les concepts. Dans sa définition traditionnelle, la notion de schéma est indépendante de l’état actuel des données. Un schéma exactement ins-tancié est régi par les données. L’appartenance d’un quelconque topic au schéma est conditionnée par l’existence d’individus pour ce topic. Un schéma exactement instancié peut être représenté par l’équation suivante :

Schéma exactement instancié = Schéma conceptuel PROJETÉ SUR

Instances Soit le schéma de la figure suivante :



Figure 6.8 Exemple d’un schéma exactement instancié représenté en Topic Maps Tous les topics d’un schéma exactement instancié ont au moins une instance. Par exemple, le schéma comporte le topic Patient qui a 10 individus qui sont tous examinés par deux médecins en 70 examens. Ces 10 patients ont 8 maladies. Comme la cardinalité exacte du topic association Possède est supérieure au nombre de patients et maladies, l’association Possède enregistre plusieurs mala-dies pour plusieurs patients. Ce schéma a été obtenu après projection du schéma de la figure 6.9 sur les instances. En effet, il n’y a aucun patient qui ne soit at-teint par un cancer, c’est-à-dire que les topics Atteint et Cancer n’ont aucune ins-tance et ne seront donc pas considérés dans le schéma exactement instancié.

Figure 6.9 Schéma exactement instancié = schéma + instances

Patient

Examen Médecin

MaladiePossède

70 2

8

10

25

Patient

Examen Médecin

MaladiePossède

Cancer Atteint

Patient(p1) … Médecin(m1) … Maladie(m1) …

Examen(e1) Med-exam(e1,m1) Pat-exam(e1,p1) … Possède(ps1) …



Navigation sémantique et schéma dynamique exactement instancié L’interface permet à l’utilisateur d’explorer les données grâce à la navigation sémantique centrée sujet dans une topic map. Conjointement à la navigation, l’utilisateur peut spécifier des requêtes simples pour restreindre l’espace d’informations à explorer par navigation. Rappelons que l’interface ne montre pas la totalité de la topic map mais elle la visualise au fur et à mesure que l’utilisateur effectue la navigation. A tout moment, la partie de la topic map vi-sualisée constitue le topic actif et les topics qui lui sont directement liés. Un peu comme la navigation sur le Web, l’utilisateur peut spécifier une requête, qui porte uniquement sur le topic actif. Cette requête fixe les instances du topic actif. La topic map visualisée par l’interface est un schéma exactement instancié. Par conséquent, la structure de cette topic map change en fonction du résultat de la requête. Donc la structure de la topic map n’est pas fixe. Elle dépend, en effet, des requêtes spécifiées par l’utilisateur. C’est ce que nous appelons un schéma dynamique.

Supposons que nous ayons à consulter le dossier médical d’un patient nommé Dupont. Le concept sujet de cette session d’interrogation est donc Pa-tient. L’interface est centrée, au départ, sur le sujet Patient en visualisant ce topic ainsi que tous les topics directement liés au topic Patient. Supposons que les to-pics Examen, Opération chirurgicale et Voyage en Chine sont liés à Patient dans la topic map générique. Le fait que l’utilisateur spécifie la requête Nom = ”Du-pont” sur le topic actif Patient, la topic map, qui est un schéma exactement ins-tancié, se reconstruit et sera centrée uniquement sur le patient Dupond. Si par exemple, Dupond n’a subi aucune opération chirurgicale, le topic Opération chi-rurgicale ne fera plus partie de la topic map et les cardinalité exactes seront recal-culées pour les topics Examen et Voyage en Chine pour donner le nombre exact d’examens de Dupont et le nombre exact de voyages en Chine. En supposant que le nombre d’examens de Dupont est très élevé, il pourra naviguer vers ce topic et spécifier une requête du type date de l’examen > 2002 pour restreindre la recher-che. De même la structure de la topic map est recalculée et le processus de navi-gation/interrogation continue suivant cette logique.

Figure 6.10 Navigation dans un schéma exactement instancié



Navigation dans un graphe dynamique : une algèbre adaptée L’utilisateur navigue dans un graphe dont la structure n’est pas statique. En effet, la topic map est un schéma exactement instancié, c’est donc un graphe de concepts et d’instances. Lorsque l’utilisateur navigue, la topic map ne peut être visualisée intégralement puisque sa structure n’est pas connue a priori, elle dé-pend des instances liées aux concepts du graphe.

Pour parcourir le graphe dynamique, nous avons développé une algèbre qui prend en considération ses spécificités. Cette algèbre est composée d’opérandes et d’opérateurs adaptés pour manipuler aussi bien les nœuds (concepts) que les instances associées aux nœuds. 1. Opérandes prédéfinis de l’algèbre :

This : représente le nœud (concept) courant. Previous : représente le dernier concept visité avant le concept This. Next : est une liste des concepts accessibles par des liens directs depuis le concept This. Currents : représente les instances liées au concept courant This.

2. Opérateurs de l’algèbre : En plus des opérateurs traditionnels tels que la projection et la sélection, nous avons défini des opérateurs spécifiques au parcours du graphe dynamique. Nous ne détaillons pas leur mise en œuvre puisqu’elle dépend du modèle de données choisi. L’opérateur Next : L’opérateur Next est défini de deux façons distinctes :

NextC(instances, Csuivant) et NextC(instances) Cet opérateur consiste à sélectionner les instances du concept (premier proto-type) ou des concepts (deuxième prototype) lié(s) aux instances du concept C. L’opérateur de navigation Previous : Avec les mêmes objectifs que l’opérateur Next, cet opérateur effectue l’opération inverse. Il consiste à calculer les instances, d’un concept précédemment visité, par rapport à celles d’un concept donné. L’opérateur Access : Cet opérateur est une généralisation des deux opérateurs précédents. Il est utile pour développer des langages d’interrogation plus évo-lués pour interroger le graphe dynamique. Son prototype est donné comme suit :

AccessConceptSource (Instances,Chemin). qui consiste à retrouver tous les concepts “atteignables” à partir des instances du concept ConceptSource en suivant le chemin spécifié. Il est à noter que la navigation en suivant le chemin spécifié dépend des instances du concept de départ et non pas que de la structure du graphe de concepts. Soit à évaluer la requête suivante : - Quels sont les traitements donnés au patient Dupond pendant les deux der-niers mois ?



Elle est exprimée en SQL comme suit : SELECT Traitement.All INTO Trait_Dupond_2mois FROM patient.*.médecin.*.traitement WHERE patient.nom = ”Dupond” and traitement.date.ToMonth() > now.ToMonth() - 2

En utilisant les opérateurs de notre algèbre, son plan d’exécution peut être donné comme suit :

Tableau 6.3 Exemple de requête utilisant les opérateurs algébriques

6.3.4 Document Virtuel Personnalisable (DVP) Les documents virtuels personnalisables (DVP) constituent une évolution des systèmes hypermédias qui devenaient très lourds et difficiles à utiliser pour gérer la quantité importante d’informations sur le Web. Plusieurs définitions ont été données pour les documents virtuels (voir la thèse [Iksa 02] pour plus de détails). Nous retenons la suivante : un document virtuel est un hypertexte dont les nœuds virtuels sont des documents générés à la demande à partir de contenus existants [Nana 95]. Un document virtuel est donc un document, peu importe sa structure, dont les instances sont générées lors de la consultation. Pour réaliser cette instan-ciation, des mécanismes adaptés sont associés au graphe d’informations.

Un document virtuel personnalisable (DVP) est un document virtuel in-teractif interrogé par l’utilisateur pour créer un document réel personnalisé et adapté à ses besoins. Il est souvent considéré comme un ensemble de fragments associés à des mécanismes de filtrage, d’organisation et d’assemblage selon des modèles donnés. La spécification et la composition constituent deux étapes prin-cipales et essentielles d’un DVP. La spécification est un ensemble d’information, spécifiées par l’utilisateur, qui permet au système de composer, à l’étape de composition, des documents personnalisés. Ces deux étapes permettent à

SelectPatient (Patient.nom= ”Dupond”)

Accesspatient (currents, Taritement, patient.*.médecin.*.traitement)

Selecttraitement (traitement.date.ToMonth() > now.ToMonth() - 2)

Project (traitement.All)

This = patient Currents =le patient Dupond

This = traitement Currents = trait. de Dupond

This = traitement Currents =Trait. cardios de Dupond



l’utilisateur de sélectionner les fragments de données qui représentent le contenu du document réel et de spécifier la façon dont ces fragments seront organisés et assemblés dans le document réel.

L’interface constituée d’une topic map visualisée sous forme d’une carte conceptuelle est un DVP. En effet, cette interface est un document adaptatif utili-sé interactivement par l’utilisateur en mode navigation/interrogation pour générer un document personnalisé. En fonction des données sélectionnées et de leur or-ganisation, l’interface génère une multitude de documents personnalisés pour l’utilisateur. La génération de ces documents est montrée dans le schéma sui-vant :

Figure 6.11 Concept de DVP pour la génération de documents personnalisés L’interface est un DVP, elle permet à l’utilisateur de créer un document

réel à la fin d’une session d’exploration de la carte de concepts. Ce document constitue une vue personnalisée de l’utilisateur concernant les données requises. La spécification du document personnalisé est réalisée d’une façon interactive se-lon les deux étapes suivantes : 1. Phase de Filtrage :

Pendant la navigation, l’utilisateur spécifie des requêtes et consulte des to-pics. Nous considérons donc deux types de sélection de contenu pour consti-tuer un document personnalisé : les concepts et les instances. Les concepts sélectionnés sont ceux visités lors de la navigation et marqués par l’utilisateur comme étant pertinents. Les instances sélectionnées sont obtenues lors de l’évaluation des requêtes spécifiées par l’utilisateur.

2. Phase d’organisation et d’assemblage : Les concepts et les instances sélectionnés lors de la phase de filtrage sont or-ganisés puis assemblés dans un document XML. Les instances sélectionnées

Spécification/ composition

BDR

Document personnalisé

XSLNBP

BDO XML

DVP



sont représentées dans le document XML sous des balises qui correspondent à leurs concepts d’appartenance. L’organisation de ces balises est définie par trois facteurs : la structure conceptuelle de la topic map qui administre l’organisation sémantiquement cohérente du document personnalisé, le profil de l’utilisateur et l’ordre de consultation des topics lors de la navigation. Les relations entre les concepts sont généralement exprimées en XML par la rela-tion sous-balise-de qui organise un document XML en une hiérarchie de bali-ses.

Les concepts les plus visibles dans le document sont ceux du niveau le plus haut de la hiérarchie. Les balises les plus profondes sont les moins visi-bles. Les concepts les plus visibles sont choisis en fonction des préférences de l’utilisateurs (profil de l’utilisateur) et de l’ordre de navigation des concepts. En effet, souvent l’utilisateur commence la navigation par les concepts les plus pertinents et continue la navigation pour rechercher d’éventuelles informations pertinentes relatives à ces concepts. Le concept le plus pertinent est le concept sujet. C’est donc le concept du premier niveau dans la hiérarchie du document personnalisé.

Le document XML généré est destiné à être échangé sur le Web ou à être utilisé par d’autres applications. Ce document est transformé en un do-cument lisible et compréhensible par l’utilisateur en utilisant par exemple les feuilles de style XSL. La feuille XSL traduit les préférences visuelles de l’utilisateur en définissant la nature du document (Word, HTML, texte, etc.), les couleurs et les tailles des polices, etc.

Le document personnalisé est un élément très important dans les interfa-ces. En effet, le document est le moyen de communication le plus favorisé par l’humain. D’autre part, lors de la navigation, les données sélectionnées par l’utilisateur sont éparpillées sur plusieurs endroits. C’est à la charge de l’utilisateur de mettre en relation ces données en fur et à mesure qu’il navigue. Cette charge mentale est délicate à réaliser notamment s’il s’agit d’une quantité importante de données à lier. Ceci diminue l’efficacité de la recherche. En créant un document personnalisé selon ses préférences, l’utilisateur n’aura plus qu’à consulter le résultat de sa navigation dans un document sémantiquement cohérent présenté selon ses préférences.

L’interface de type DVP permet donc à l’utilisateur de créer son propre document, c’est-à-dire que l’utilisateur est l’auteur du document personnalisé. Les caractéristiques de ce document sont les suivantes :

• Document centré sujet : tout son contenu est relatif à un concept ou à un individu donné.

• Document non persistant : il n’est pas destiné à être stocké pour long-temps puisqu’il est créé sur demande de l’utilisateur pour des besoins ins-tantanés.



• Document sans propriétaire : les données contenues dans ce document sont extraites à partir de plusieurs sources de données. Le document n’est donc pas la propriété de l’utilisateur même s’il en est l’auteur.

• Document virtuel : le document n’existe pas en tant que tel dans le sys-tème, il est assemblé et créé à la demande de l’utilisateur à partir de don-nées hétérogènes.

La notion de DVP est très utile dans beaucoup de domaines d’applications. Dans le domaine médical, le document personnalisé représente un dossier médical d’un patient créé pour les besoins instantanés à la demande du praticien. Nous avons donc apporté une solution théorique au problème du dos-sier médical réparti. Jusqu’à l’heure actuelle, la notion de dossier médical physi-que unique réunissant l’ensemble des informations nécessaires au suivi médical du patient est largement un mythe car les informations sont produites dans diffé-rents établissements de santé sur des supports variés. Le DVP représente une contribution pour la résolution de ce problème. De même, dans le domaine judi-caire, les enquêteurs peuvent reconstituer le casier judiciaire d’un malfaiteur et obtenir toutes les informations le concernant représentées dans un seul document.

Le document personnalisé regroupe les données pertinentes concernant un sujet. C’est donc un support très efficace pour l’aide à la décision.

6.3.5 Contribution : interface intelligente La conception d’interfaces intelligentes constitue l’un des points les plus impor-tants dans le développement des systèmes d’information de ces dernières généra-tions. En effet, l’objectif principal est de concevoir des interfaces intelligentes, conviviales et suffisamment adaptées à l’utilisateur pour qu’il puisse explorer les données d’une façon intelligente et efficace dans le but d’obtenir l’information réellement pertinente.

Dans cette perspective, nous avons consacré une grande partie de notre travail à la conception d’interfaces intelligentes. Nous avons pour cela proposé une interface adaptée et adaptative avec une nouvelle approche de navigation, à savoir la navigation sémantique centrée sujet. Le concept clé de cette interface est la notion de schéma dynamique exactement instancié sur lequel nous avons basé notre conception. Pour l’adaptation de l’interface, nous avons utilisé les lo-giques de descriptions pour gérer intelligemment et sans incohérences sémanti-ques, les utilisateurs, les profils utilisateurs, l’affectation des utilisateurs à leur profil adéquat ainsi que l’attribution des droits d’accès aux profils. Nous avons représenté l’adaptation en utilisant la notion de facettes.

L’interface fonctionne en mode navigation et interrogation. L’approche de navigation que nous avons développé pour l’interface est assez originale : la navigation sémantique centrée sujet. L’interface présente les données sous forme



d’une carte de concepts. L’utilisateur explore cette carte par navigation sémanti-que, l’utilisateur commence la navigation à partir du concept sujet (sur lequel est centrée toute la session) et tous les concepts visités son sémantiquement liés par des relations sémantiques. De plus, cette interface est interactive et permet à l’utilisateur à tout instant lors de la navigation de spécifier des requêtes pour res-treindre l’espace de recherche.

Notre approche présente plusieurs avantages par rapport à la navigation Web. Les liens entre les pages Web sont syntaxiques et statiques. Malgré les as-pects dynamiques qui sont ajoutés aux pages Web via les scripts de programma-tion, ces liens sont statiques et sont définis au moment de la conception des pa-ges. La notion de sujet sur lequel sera centrée la navigation est très importante dans plusieurs domaines d’application. La navigation Web n’est pas adaptée à ce type d’applications. Pour explorer le dossier d’un étudiant, très souvent les pages explorées contiennent des données concernant d’autres étudiants.

Malgré la conception de système hypermédias adaptatifs, la recherche sur le Web manque d’interactivité. En effet, l’hypermédia est adapté au profil de l’utilisateur et ensuite il est présenté à l’utilisateur pour être exploré. L’utilisateur spécifie une requête sous forme de mots-clés et commence la navigation à partir des liens retournés en résultat de cette requête. Pendant la navigation, l’utilisateur ne pourra pas spécifier des requêtes, donc les besoins instantanés ne sont pas pris en considération. Dans notre interface, à tout instant pendant la na-vigation, l’utilisateur peut spécifier des requêtes qui conditionneront la suite de la navigation. L’adaptation dans les systèmes hypermédias est totalement basée sur le profil de l’utilisateur. Ceci constitue un inconvénient car dans plusieurs domaines d’application les pratiques des utilisateurs sont différentes et il est donc difficile de représenter un groupe d’utilisateurs dans un seul profil. Par conséquent, il est nécessaire de représenter les utilisateurs individuellement. Cette solution peut générer un nombre excessif de profils. Notre interface contourne ce problème par la navigation interactive qui permet à l’utilisateur de spécifier ses besoins individuels lors d’une session d’interrogation/navigation.

Notre interface est un DVP, elle permet à l’utilisateur de regrouper au-tomatiquement toutes les données, jugées pertinentes, dans un seul document sé-mantiquement cohérent et personnalisé. Dans les systèmes de navigation sur Web, ce travail mental est à la charge de l’utilisateur.

Système de reconstruction du dossier médical distribué / Interface centrée population


6.4 Interface centrée population Dans beaucoup de domaines d’application, l’information est utilisée selon deux approches : l’approche micro-utilisation et l’approche macro-utilisation de l’information. L’approche micro-utilisation consiste à regrouper des informations relatives à un individu donné. Pour cette approche, nous avons développé l’interface centrée sujet que nous avons présenté dans les sections précédentes. Dans l’approche macro-utilisation, l’information manipulée par le système concerne une population d’individus regroupés suivant des caractéristiques com-munes. Ces groupements d’individus sont utilisés pour réaliser des calculs statis-tiques pour la prise de décision et l’extraction d’informations concernant le com-portement et les habitudes des individus de chaque population.

Dans le domaine médical, les études épidémiologiques sont utilisées pour définir des tendances d’évolution des maladies (en se basant notamment sur leur fréquence ou leur incidence), des nouveaux comportements en matière de thérapeutiques médicamenteuses ou encore pour créer des études de satisfaction. L’épidémiologie représente l’étude de la distribution et des déterminants des ma-ladies dans les populations humaines. L’épidémiologie se base essentiellement, dans ce but, sur la distribution de ces maladies dans les groupes de population et sur l’influence de cette distribution sur les maladies.

Dans le contexte des systèmes d’information centralisés, nous avons présenté dans la section 4.5 une approche de conception d’enquêtes médicales. Cette approche est basée sur une interface générique pour la conception de for-mulaires d’enquêtes, la saisie des données des enquêtes et le stockage dans une base de données relationnelle. Dans cette section, nous présentons une interface intelligente, dite centrée population, qui permet de réaliser des opérations d’aide à l’analyse de données multisources.

Contrairement à l’interface centrée sujet, l’interface centrée population n’est pas utilisée pour la navigation dans un espace d’informations. C’est une in-terface interactive qui permet à l’utilisateur de visualiser l’analyse des données dans une hiérarchie de concepts qui exprime des relations sémantiques et des dis-tributions de données. Pour commencer l’analyse, l’interface présente à l’utilisateur les données sous forme d’une carte de concepts. A partir d’une carte de concepts initiale, l’utilisateur explore les concepts et spécifie des attributs d’analyse et le système calcule et renvoie les résultats en temps réel. En fonction des résultats retournés, l’utilisateur modifie ses attributs d’études (d’analyse) et spécifie d’autres valeurs pour d’autres attributs d’analyse. En fonction des attri-buts d’analyse, le système regroupe les individus dans une hiérarchie de concepts et inscrit des valeurs destinées à être interprétées par l’utilisateur (ou par des lo-giciels de calculs statistiques et de prise de décision). L’architecture de cette in-terface est donnée dans la figure suivante :



Figure 6.12 Interface d’aide à l’analyse de données multisources Initialement, la carte de concepts présentée par l’interface était compo-

sée des deux concepts Patient et Médecin. L’utilisateur spécifie deux attributs d’analyse concernant l’attribut Nationalité du concept Patient. Le système intro-duit automatiquement deux sous-concepts (Français et Anglais) et calcule en temps réel les distributions verticales et horizontales des données. La distribution verticale est un pourcentage d’individus associé aux sous-concepts d’un concept sur lequel portent les attributs d’analyse. Par exemple, le calcul vertical relatif à l’attribut d’analyse Nationalité du concept Patient consiste à calculer la distribu-tion des individus de Patient sur les deux sous-concepts introduits, à savoir les concepts Français et Anglais. La distribution horizontale est relative aux associa-tions entre les concepts. Cette distribution est conjointe à la distribution verticale et est automatiquement calculée en fonction du résultat de la distribution verti-cale. Dans l’exemple de la figure 6.12, nous constatons que 90% des patients français consultent des médecins spécialistes contre 50% pour les anglais. En af-finant plus l’analyse, l’utilisateur spécifie un autre attribut sur le concept Fran-çais. Comme nous le voyons sur la figure précédente, l’utilisateur introduit une contrainte sur l’âge des patients français. Le système calcule les deux distribu-tions verticale puis horizontale et visualise le résultat sur la carte de concepts.

Données organiséesen Topic Maps

Paramètres d’analyse Base de

Connaissances (LD)

Patient

Français Anglais

15% 80%

Spécialiste Généraliste 10%

50%50%

90%

Médecin

25%75%

90%

80%Moins de 65

Relation de Subsumption

Relation d’association

Plus de 65



6.4.1 Mise en œuvre de l’interface Comme le montre la figure 6.12, l’interface est basée sur une base de connais-sances. Nous utilisons les logiques de descriptions pour mettre en œuvre cette base de connaissances. Les logiques de descriptions nous permettent de réaliser des raisonnements automatiques sur les descriptions des concepts. Les données ont été antérieurement intégrées et organisées dans une topic map. La base de connaissances sur laquelle est fondée l’interface est construite à partir de cette topic map selon deux approches : l’approche ascendante et l’approche descen-dante.

Dans l’approche ascendante, les concepts de la carte de concepts initiale visualisée par l’interface sont pris tels quels de la topic map globale. Par contre dans l’approche descendante, les concepts de la carte de concepts initiale sont dé-terminés par l’utilisateur expert et sont définis ensuite en fonction des concepts de la topic map globale. Figure 6.13 Les deux approches de génération de l’interface d’aide à l’analyse

de données multisources Dans les deux approches, la base de connaissances est composée d’une

ABox et une TBox. Les descriptions des concepts sont définies dans la TBox et les instances dans la ABox. Suivant l’exemple présenté dans la figure 6.12, la TBox est définie initialement par les deux axiomes suivants :

BD1 XML BD2

Intégration

topic map globale

Approche descendante

Approche ascendante

Introduit des concepts

Définition de concepts

Export de concepts



Dans l’approche ascendante, cette TBox est visualisée telle quelle sous forme d’une carte de concepts. Chaque individu de la ABox est associé à l’un de ces deux concepts. L’utilisateur interagit avec l’interface en introduisant des attributs d’analyse. Suivant l’exemple, l’utilisateur spécifie deux valeurs pour l’attributs d’analyse Nationalité du concept Patient. L’interface demande à l’utilisateur de donner de noms aux deux sous-concepts de Patient créés, soit Français et An-glais. Le système introduit les deux nouveaux concepts dans la TBox comme suit :

Grâce au raisonnement msc (Most Specific Concept) qui consiste à affecter un individu au concept le plus spécifique, des instances sont automatiquement affec-tées aux deux nouveaux concepts. Cette redistribution des données est visualisée sur la carte de concepts par des pourcentages. De même, les deux concepts Spé-cialiste et Généraliste sont définis selon l’attribut d’analyse spécifié par l’utilisateur et introduits par le système dans la base de connaissances, TBox, comme suit :

Dès que les deux concepts Spécialiste et Généraliste, définis par l’utilisateur, sont introduits dans la TBox, le système redistribue en utilisant le msc les indivi-dus de la ABox associés au concept Médecin selon leurs descriptions. Considé-rons la ABox suivante :

patient ≐ ∀ nss.number ⊓ ∀ nom.String ⊓ ∀ nationalité.String ⊓ ∀ adresse.String ⊓… médecin ≐ ∀ id.number ⊓ ∀ nom.String ⊓ ∀ spécialité.String ⊓… examen ≐ ∀ pat.patient ⊓ ∀ méd.Médecin ⊓ ∀ date.Date ⊓…

patient ≐ ∀ nss.number ⊓ ∀ nom.String ⊓ ∀ nationalité.String ⊓ ∀ adresse.String ⊓ ∀ examinéPar.Médecin ⊓… français ≐ patient ⊓ nationalité = Fr

anglais ≐ patient ⊓ nationalité = UK médecin ≐ ∀ id.number ⊓ ∀ nom.String ⊓ ∀ spécialité.String ⊓…

médecin ≐ ∀ id.number ⊓ ∀ nom.String ⊓ ∀ spécialité.String ⊓… spécialiste ≐ médecin ⊓ ≥1 spécialité

généraliste ≐ médecin ⊓ =0 spécialité



Dans cette TBox, tous les individus sont définis comme instances du concept Médecin. En fonction des descriptions des nouveaux concepts (Spécialiste et Gé-néraliste) introduits par l’utilisateur pour l’analyse de données, ces individus se-ront automatiquement redistribués en fonction de leurs attributs. Par exemple, l’individus m1 a la spécialité pédiatrie et l’individu m4 a deux spécialités, rhu-matologie et médecine du sport. Ces deux individus sont donc affectés automati-quement au concept Spécialiste. Les deux autres concepts n’ont aucune spécialité et sont par conséquent affectés au concept Généraliste.

L’interface n’est pas utilisée uniquement pour décomposer des concepts. Elle permet également la fusion de concepts en un autre concept afin de consti-tuer une nouvelle sous-population. En supposant que l’interface de la figure 6.12 n’ait que les deux concepts Français et Anglais, l’utilisateur peut s’intéresser aux patients âgés de plus de 65 ans, quelle que soit leur nationalité. Cette fusion est réalisable en logique de descriptions grâce à l’opérateur union. Ce nouveau concept défini est représenté dans la TBox par la description suivante :

Patient>65 ≐ français ⊔ anglais Une fois les individus affectés à leurs concepts les plus adéquats (les

plus spécifiques), les pourcentages de distribution de données sont calculés en fonction de cette redistribution. On obtient des connaissances d’ordre sémanti-que. Par exemple, les connaissances suivantes sont données par l’exemple de la figure 6.12 :

• 75% des patients français ont plus de 65 ans. • La majorité des français de plus de 65 ans consultent des spécialistes. • Pour les patients anglais, on ne peut conclure. L’utilisateur devra donc af-

finer son analyse en choisissant un nouveau critère. Si par exemple, l’âge n’est pas un critère discriminant pour les patients anglais, l’utilisateur ne pourra pas en tirer d’analyse concluante ; dans ce cas cet attribut sera supprimé et d’autres seront introduits. Cette interface d’aide à l’analyse de données est interactive et la base de connaissances est dynamique car elle permet d’ajouter, de supprimer des concepts et redistribuer les indivi-dus au fur et à mesure.

médecin(m1) médecin(m2) id(m1,id1) id(m2,id2) nom(m1, "dupont") nom(m2, "durand") spécialité(m1, "pédiatrie")

médecin(m3) médecin(m4) id(m3,id3) id(m4,id4) nom(m3, "dupont") nom(m4, "Peter") spécialité(m4, "rhumatologie")

é i lité( 4 " éd i d

Système de reconstruction du dossier médical distribué / Indexation sémantique des données


6.5 Indexation sémantique de données Pour augmenter l’efficacité de la navigation et par conséquent les performances de notre interface, nous avons conçu un index sémantique des données. Le temps de réponse de l’interface aux actions de navigation de l’utilisateur constitue l’un des éléments importants qui contribuent à l’efficacité de la recherche. En effet, si ce temps de réponse est grand, des restrictions s’imposent à l’utilisateur qui di-minuent l’efficacité de sa recherche d’information. De plus les cardinalités affi-chées sont calculées dynamiquement et peuvent donc demander du temps.

La solution est de mettre en œuvre un index des données qui soit adapté à l’interface pour accélérer le temps de réponse à la navigation/interrogation de l’utilisateur et aux calculs dynamiques des cardinalités des topics.

A l’origine, les données ont été fusionnées en respectant leur sémantique et stockées dans une vue matérialisée organisée sous forme d’une topic map. L’interrogation de ces données, qu’elle soit centrée sujet ou centrée population, suit une certaine sémantique. Un index efficace doit tenir compte à la fois de l’organisation sémantique des données et de la nature des requêtes. Nous avons pour cela conçu un index sémantique pour notre interface.

6.5.1 Conception de l’index En base de données, un index est une table ordonnée de paires valeur-adresse. La valeur correspond à une clé sur laquelle porte la recherche et suivant laquelle l’index est trié. L’adresse est un pointeur vers le cluster de données qui corres-pondent à la valeur. L’espace de données est donc organisé, au plus bas niveau, en données regroupées suivant leur clé en clusters. Dans les systèmes de gestion de documents, la valeur est un terme d’indexation pris d’un thésaurus et l’adresse est un pointeur vers les documents (ou les fragments de documents) pour lesquels le terme d’indexation est pertinent. Pour augmenter l’efficacité de la recherche, les index sont représentés par des structures plus évoluées telles que les index multi-niveaux, les arbres ou les B-arbres.

Les index les plus évolués sont les index sémantiques. Dans ce type d’index, les données ne sont pas indexées selon des valeurs de clés extraites des données elles-mêmes mais on utilise des concepts sémantiques extraits du niveau conceptuel des données. L’index sémantique est donc un arbre de concept-adresse.

Dans notre cas, les données peuvent être indexées à deux niveaux coopé-ratifs : au niveau des données par l’index traditionnel et au niveau sémantique par l’index sémantique. L’espace de données est tout d’abord indexé au niveau sémantique et partitionné en plusieurs partitions sémantiques. Chaque partition



sémantique (on pourra définir des critères pour ne pas indexer toutes les parti-tions sémantiques) est ensuite indexée par un index traditionnel.

Architecture de l’index L’index sémantique est conçu suivant quatre paramètres qui augmentent l’efficacité de l’index et prennent en compte la sémantique des données et des re-quêtes : à savoir, le profil de l’utilisateur, les règles d’association, les contraintes d’intégrité et le volume de données. Dans un profil utilisateur on trouve toutes les informations concernant ses habitudes, les concepts les plus fréquemment in-terrogés et son objectif. On peut utiliser ces informations pour définir d’une fa-çon assez précise le plan de navigation et les requêtes les plus fréquentes. Les rè-gles d’associations sont des formules définissant des relations sémantiques entre les données. Les contraintes d’intégrité expriment également des relations séman-tiques entre les données. L’index est essentiellement défini par trois facteurs : sa structure, les topics (concepts ou association) à indexer et ses termes d’indexation. L’architecture de notre index sémantique est la suivante :



Figure 6.14 Architecture de l’index sémantique Comme le suggère la figure 6.14, nous réalisons une indexation à deux

niveaux : l’indexation intra-concept et l’indexation inter-concepts. Premièrement, après avoir sélectionné les concepts à indexer, ces concepts sont indexés séparé-ment et indépendamment les uns des autres. Le résultat de cette première étape

Espace des données(Topic Map)

Sélection des concepts à in-

dexer

Arbre intra-concept

Base de connaissances en LD

Classification des concepts

Sélection des rôles à indexer

Base de connaissances en LD

Ajuster les do-maines des rôles

Index sémantique

Indexation des concepts

Indexation des rôles - Profil utilisateur

- Règles d’association

- Contraintes d’intégrité



est un ensemble (une forêt) d’arbres dont chacun indexe un concept. Deuxième-ment, l’indexation des rôles1 permet de relier (par des liens sémantiques) ces in-dex intra-concept entre eux en optimisant les associations.

Structure de l’index L’index possède ainsi la structure d’un hyper-arbre dans le sens où les nœuds re-présentent les arbres d’indexation intra-concept et les arcs représentent les rela-tions entre ces arbres. Nous utilisons respectivement les termes hyper-nœud et hyper-arc pour désigner un nœud (index intra-concept) et un arc (relation entre deux hyper-nœuds), respectivement.

La structure globale de l’index suit exactement celle de la topic map sauf que les nœuds de la topic map sont des concepts alors que ceux de l’index sont des index (arbres) de ces concepts et les liens entre les concepts de la topic map sont des associations simples alors que ceux de l’index sont des index de ces associations. Pour mieux comprendre la structure de l’index et comment il est créé, nous appliquons la procédure présentée dans la figure 6.14 sur la topic map (composée de deux (topics) concepts liés par une seule (topic) association) sui-vante :

Figure 6.15 Exemple simple d’une topic map à indexer

Supposons qu’on ait les règles d’associations suivantes : Règle 1 : « Tous les patients anglais sont examinés par des médecins spécialis-tes » Règle 2 : « A part ceux qui habitent Paris, tous les patients français sont exami-nés par des généralistes » Ces deux règles permettent de définir les concepts de l’index sémantique ainsi que les critères de partitionnement de ces concepts. Les deux concepts Patient et

1 Nous avons utilisé le terme rôle importé des LD pour désigner une association.

Patient Médecinexamen



Médecin seront indexés selon les critères « Français ou Anglais », « habite Pa-ris » pour le concept Patient et « Spécialiste ou Généraliste » pour le concept Médecin. Ces deux concepts sont donc indexés séparément et deux arbres d’indexation intra-concept sont conçus suivant le schéma montré dans la figure suivante :

Figure 6.16 Un hyper-index composé de deux hyper-nœuds et un hyper-arc

Chacun des deux index intra-concept constitue un hyper-nœud de l’index sémantique. Ces deux hyper-nœuds sont reliés grâce à l’indexation inter-concepts. La procédure d’indexation inter-concepts consiste à relier les sous-concepts des index intra-concept les uns aux autres conformément aux règles d’association (données ci-dessus), aux contraintes d’intégrité sur les données et au profil de l’utilisateur. Le sous-concept Anglais de l’intra-index sémantique du concept Patient est associé au sous-concept Spécialiste de l’intra-index sémanti-que du concept Médecin. Le sous-concept Français est associé au concept Méde-cin par contre son sous-concept NonParisien est associé au sous-concept Généra-liste selon la deuxième règle donnée précédemment. L’hyper-arc reliant les hyper-nœuds représentés par les index intra-concept des concepts Patient et Mé-decin est constitué de l’ensemble des liens d’association reliant les sous-concepts de l’hyper-nœud Patient à ceux de l’hyper-nœud Médecin.

Modèle de l’index L’index est formalisé en utilisant les logiques de descriptions. L’efficacité des logiques de descriptions pour la conception d’index sémantique a été illustrée à

Médecin

Spécialiste Généraliste

Patient

Français Anglais Autres

Non Parisien

Parisien

Part. 1 Part. 2 Part. 3 Part. 4 Part. 5 Part. 6

Hyper-nœud Hyper-arc

Relation de Subsumption

Rôle Pointeur de

données



travers diverses applications. Les LD ont été utilisées pour indexer les données vidéos [Carr 98]. Les séquences vidéos (vidéos, images, sons, etc.) sont décrites par des descripteurs implémentés en LD pour classifier les objets multimédias [Fan 01] [Gobl 96]. Les index sémantiques basés sur les LD sont utilisés égale-ment en recherche d’informations [Todi 99]. Dans ces approches, une hiérarchie des concepts du domaine d’application est générée par les LD et utilisée pour ré-férencer, à travers ces concepts, les documents les plus pertinents. L’approche la plus connexe à la nôtre est celle présentée dans [Schm 94]. Les concepts sont in-dexés de la même manière en utilisant les relations de subsomption et de disjonc-tion. Notre approche ne se limite pas à indexer uniquement les concepts mais nous indexons à la fois les concepts et les rôles.

Les concepts d’indexation sont représentés par des descriptions dans une TBox. Nous supposons que les associations entre les concepts sont représentées par des rôles. En fait, c’est une représentation simplifiée. Les associations peu-vent être représentées par des descriptions au même titre que les concepts. Soit la TBox suivante :

Comme le montre la figure 6.14, l’index sémantique est créé en deux

étapes : l’indexation intra-concept et ensuite l’indexation inter-concepts.

1. Indexation intra-concept : La TBox ci-dessus représente la topic map (donnée par la figure 6.15) à indexer. Un index intra-concept est une hiérarchie construite automatiquement par la rela-tion de subsomption à partir des descriptions des concepts. L’index intra-concept du concept Patient est une hiérarchie des concepts décrits par la TBox suivante :

patient ≐ ∀ nss.number ⊓ ∀ nom.String ⊓ ∀ nationalité.String ⊓ ∀ adresse.String ⊓ ∀ examinéPar.médecin ⊓… médecin ≐ ∀ id.number ⊓ ∀ nom.String ⊓ ∀ spécialité.String ⊓ ∀ examinéPar-1.patient ⊓ …



Ces concepts sont hiérarchisés selon la relation de subsomption en un arbre d’indexation intra-Patient. Les partitions de données sont également constituées automatiquement par le moteur de raisonnement logique (algorithme msc) en af-fectant chaque individu au concept le plus spécifique. Tous les individus sont ini-tialement déclarés comme instances du concept Patient. Après définition des concepts d’indexation, les individus seront réaffectés pour former les partitions de l’index (voir figure 6.17).

Figure 6.17 Index intra-concept du concept Patient De même la façon, un index intra-concept est automatiquement créé

pour le concept Médecin en appliquant le raisonnement de subsomption pour créer l’arbre de l’index et le raisonnement msc pour partitionner les données. La TBox de cet index est la suivante :

patient ≐ ∀ nss.number ⊓ ∀ nom.String ⊓ ∀ nationalité.String ⊓ ∀ adresse.String ⊓ ∀ examinéPar.médecin ⊓… français ≐ patient ⊓ nationalité = "FR"

anglais ≐ patient ⊓ adresse = "UK"

autres ≐ patient ⊓ ¬ français ⊓ ¬ anglais

parisien ≐ patient ⊓ adresse = "Paris" nonParisien ≐ ¬ parisien

Patient

Anglais Français AutresAnglais Français Autres

Parisien Non ParisienParisien Non Parisien

Partition 2Partition 1 Partition 3 Partition 4Partition 2Partition 1 Partition 3 Partition 4

subsomption

subs

ompti

on

msc

msc

médecin ≐ ∀ id.number ⊓ ∀ nom.String ⊓ ∀ spécialité.String ⊓… spécialiste ≐ médecin ⊓ ≥1 spécialité

généraliste ≐ médecin ⊓ =0 spécialité



2. Indexation inter-concept : En fonction du résultat de l’indexation intra-concept, l’indexation inter-concepts consiste à relier les concepts des index intra-concept entre eux selon une séman-tique donnée extraite à partir des données (règles d’association, contraintes d’intégrité, etc.). L’indexation inter-concepts consiste à indexer les rôles (ou les associations) qui associent les concepts. Les deux concepts Patient et Médecin sont liés par le rôle examinéPar défini par (Domaine : domaine de départ du rôle - Range : domaine d’arrivée du rôle) :

Domaine (examinéPar) = patient (1) Range (examinéPar) = médecin (2)

D’après la règle 1, les patients anglais sont examinés par des spécialistes. Dans la TBox représentant l’index intra-concept de Médecin, le concept anglais est impli-citement défini par le rôle examinéPar défini par les relations (1) et (2). L’indexation inter-concept consiste à ajuster le Domaine et le Range du rôle examinéPar défini pour le concept anglais, soit examinéParUk. Ce nouveau rôle est défini par : Domaine (examinéParUk) = anglais (1) Range (examinéParUk) = spécialiste (2) Le concept anglais est redéfini comme suit :

La relation de subsomption entre les rôles est donnée par le moteur logique : examinéParUk ⊑ examinéPar Ce qui maintient toujours la relation : anglais ⊑ patient De la même manière, le rôle examinéPar est indexé en utilisant la deuxième règle en un autre rôle examinéParNP. Ce rôle est défini pour le concept NonParisien comme suit :

Cette approche d’indexation est également valable pour les associations

quand elles sont définies dans la TBox par des concepts. Supposons que l’association examen soit définie par le concept suivant :

En utilisant la règle 1, cette association est indexée (par le nouveau concept d’indexation examenUk) en spécialisant ses rôles comme suit :

anglais ≐ patient ⊓ adresse = "UK" ⊓ ∀ examinéPa-

nonParisien ≐ ¬ parisien ⊓ ∀ examinéParNP.Généraliste

examen ≐ ∀ pat.patient ⊓ ∀ med.médecin ⊓ ∀ date.Date ⊓…

examenUk ≐ ∀ pat.anglais ⊓ ∀ med.spécialiste ⊓ ∀ date.Date



Les rôles inverses ne sont pas créés automatiquement dans l’index.

Quand on indexe un rôle d’un concept, on ne crée pas forcément son rôle inverse dans le concept cible. Par exemple, nous ne créons pas automatiquement le rôle inverse examinéParUk-1 défini dans le concept spécialiste. Ce rôle inverse est défini comme suit : Domaine (examinéParUk-1) = spécialiste (3) Range (examinéParUk-1) = anglais (4) Ce rôle, quand il est défini pour le concept spécialiste, ajoute à l’index la séman-tique suivante :

« Les spécialistes n’ont examiné que des patients anglais » Ce qui n’est pas vrai.

6.5.2 Utilisation de l’index Pour évaluer les requêtes dans les bases de données ou documents, l’index tradi-tionnel est parcouru en utilisant la valeur (respectivement, le terme) de recherche afin de trouver les clusters (respectivement, les documents) qui contiennent la va-leur ou le terme recherché. Dans cette approche d’index sémantique, les requêtes sont traduites du langage évolué, c’est-à-dire des actions de navigation et des contraintes sur des attributs de concepts, en une requête exprimée en LD par un concept. L’évaluation de cette requête consiste à définir son extension ou les in-dividus qui appartiennent à la requête. Pour cela, la requête est automatiquement classée dans l’hyper-arbre d’indexation grâce au raisonnement glb (Greatest Lo-wer Bound) pour définir les partitions de données qui contiennent l’extension de la requête. Le glb est défini comme suit :

Ci ∈ Glb (C) ssi Ci ⊑ C et ∄Cj / Cj ⊑ C et Ci ⊑ Cj L’index est essentiellement utilisé pour :

• Calculer les instances des concepts et des associations lorsque l’utilisateur navigue et interroge la topic map,

• Calculer ou estimer les cardinalités des concepts et des associations au fur et à mesure que l’utilisateur navigue et interroge la topic map.

Lorsque l’utilisateur navigue, il spécifie, conjointement à la navigation, des requêtes simples sur les concepts. Par exemple, à partir du concept sujet Pa-tient, il spécifie la requête nom = Dupont puis il navigue vers le concept examen où il spécifie la requête date > 20/06/2001 puis vers le concept Médecin où il spécifie la requête spécialiste = oui, etc. A chaque fois que l’utilisateur spécifie une requête, le système classe cette requête dans l’index intra-concept concerné. Puisque la navigation est centrée sujet, si l’utilisateur navigue du concept Patient pour lequel nom=Dupont (admettons que Dupont est anglais), lorsque



l’utilisateur navigue vers le concept Médecin, l’espace de recherche des médecins de Dupont est limité à la partition de l’index associée au concept Spécialiste.

Finalement, les index intra-concept servent à évaluer les requêtes et les index inter-concepts sont utilisés pendant la navigation pour rechercher les ins-tances du concept cible associées à celles du concept de départ.

En fonction de la classification de la requête dans l’index, l’évaluation de la requête et le calcul ou l’estimation des cardinalités se font selon les cas sui-vants : 1. La requête Q est subsumée par un concept d’indexation IC et elle ne subsume

aucun autre concept (figure ci-dessous).

Soit Ext(Q) les instances de la requête et Card(Q) sa cardinalité. Nous avons :

Ext(Q) ⊆ Ext(IC) et Card(Q) ≤ Card(IC) 2. La requête est subsumée par un concept d’indexation IC et elle ne subsume

aucun concept mais elle est disjointe des concepts IC1, IC2,…, ICn subsumés par IC.

Nous avons : U

n

ii )Ext(ICICExtQExt

1)()(

=−⊆

Puisque ∀i,j ICi ⊓ ICj ⊑ ⊥, alors ∑

=−≤

n

iiICCardICCardQCard

1)()()(

sinon, )(()()( 1 in

i ICExtMaxICCardQCard =−≤ 3. La requête est subsumée par un concept d’indexation IC et elle subsume les

concepts IC1, IC2,…, ICn.

Nous avons dans ce cas :

Patient

Français Anglais

Relation de subsumption

Q

Français Anglais

Patient

Q

Relation de subsomption Relation de disjonction

Français Anglais

Patient

Q

Relation de subsomption



)()(1

QExtICExtn

ii ⊆

=U et )()( ICExtQExt ⊆ 4. La requête est subsumée par plusieurs concepts d’indexation IC1, IC2,…, ICn.

Si ∃i, j / ICi ⊓ ICj ⊑ ⊥, alors Ext(Q)=∅ Sinon, I

n

iiICExtcQExt

1)()(

=⊆

( ))()( 1 ini ICCardMinQCard =≤

5. D’autres cas peuvent être générés à partir de la combinaison de ces cas pré-cédents.

La requête est donc considérée comme un concept. Quand l’utilisateur

soumet une requête sur le concept Patient, par exemple, le système classe cette requête dans l’index de ce concept et calcule ensuite les nouvelles instances et la nouvelle cardinalité du concept Patient.

Lorsque l’utilisateur navigue, après avoir spécifié une requête, le sys-tème utilise l’index pour définir le concept d’indexation appartenant à l’index du concept atteint. Par exemple, l’utilisateur spécifie la requête Q : nom=Dupont (qui est un patient anglais) sur le concept Patient. Donc Q ⊑ Anglais. L’utilisateur navigue ensuite vers le concept Médecin. Sachant que le rôle examinéPar a été in-dexé et a comme Range le concept d’indexation Spécialiste, donc les individus du concept Médecin qui ont examiné Dupont sont tous inclus dans le concept Spécialiste.

6.6 Conclusion L’interface utilisateur est une composante très importante dans les systèmes d’information. C’est l’un des éléments qui affecte considérablement l’efficacité de la recherche d’information et par voie de conséquence la prise de décision. Après avoir présenté l’intégration sémantique de données basée sur l’utilisation des Topic Maps, nous avons présenté une interface adaptée et adaptative pour l’exploration et l’analyse de données multisources par navigation et requête.

Selon l’objet de l’utilisation de l’interface, elle fonctionne en deux mo-des : le mode centré sujet et le mode centré population. Dans le mode centré su-jet, l’utilisateur définit un sujet sur lequel sera centrée toute la session de recher-che d’informations. La topic map est présentée sous forme d’une carte de concepts qui représente un schéma exactement instancié (qui est une représenta-

French British

Patient

Q

Relation de subsomption

Système de reconstruction du dossier médical distribué / Conclusion


tion confondue du schéma et des données). La navigation suit une logique conforme à l’objectif de l’utilisateur, à savoir celui de rechercher des informa-tions relatives à un sujet donné. L’interface s’adapte dynamiquement et en temps réel à la navigation et aux requêtes spécifiées par l’utilisateur. A la fin de la ses-sion, le système génère un document qui contient toutes les informations jugées pertinentes pour l’utilisateur. Ce document, appelé document virtuel personnalisé – DVP, est structuré conformément à la sémantique de l’information et à la perti-nence de chacun de ses fragments par rapport au profil de l’utilisateur.

L’interface centrée population est utilisée pour explorer et analyser les données d’une façon interactive. Lorsque l’utilisateur explore la topic map, il peut à tout moment introduire des attributs d’analyse. Le système introduit ces attributs et présente ensuite la nouvelle distribution des données.

Pour augmenter les performances de notre système, nous avons conçu un index sémantique sur les données de l’interface. Cet index prend en considération la sémantique des données et les habitudes de navigation des utilisateurs ce qui augmente son taux d’utilisation et donc l’efficacité de l’interface.

La conception de nos interfaces, centrée sujet et centrée population, a été accomplie grâce à la coopération de techniques des bases de données et celles de l’intelligence artificielle afin de concevoir des modules intelligents et perfor-mants pour notre système. Ces systèmes sont appelés les systèmes d’information intelligents.

Documents

Chapitre 6 : Interface de navigation et d’interrogation 6 ...docinsa.insa-lyon.fr/these/2003/ouziri/12_iidomed_p3.pdfimage (ou du moins une image ambiguë) de l’espace d’information