pour le diagnostic à base d’hypertexte
Charles-Claude Paupe — Pierre Morizet-Mahoudeaux
Université de Technologie de Compiègne UMR-CNRS 6599, Heudiasyc
B.P. 20529, 60206, Compiègne Cedex paupe@hds.utc.fr, pmorizet@hds.utc.fr
RÉSUMÉ. La réalisation d’un système hypertexte d’aide au diagnostic de systèmes demande d’une part une instrumentation adaptée pour une navigation dans les documents guidée par la tâche et d’autre part une représentation des connaissances mises en jeu permettant des parcours guidés par le contexte. Nous présentons dans cet article un système qui possède ces deux propriétés. La première, qui a fait l’objet de travaux précédents, a été réalisée en reconsidérant la notion de documents hypertextes et en leur donnant une structure propre, indépendante de leur structure de présentation sur un support visuel. La seconde, qui fait l’objet central de cette étude, a été réalisée en implémentant un formalisme de description d’ontologies dans un langage hypertexte et en l’équipant d’outils d’indexation adaptés aux parcours contextuels. Cette approche est validée par son application à l’aide au diagnostic des vibrations sur machines tournantes.
ABSTRACT. The development of a hypertext based diagnostic system requires, on the one hand, adapted tools for a task oriented navigation across the documents, and on the other hand, context sensitive browsing capability of the knowledge base. This paper presents a system, which possesses both properties. The first one, which has been presented previously, has been realised by revisiting the definition of hypertext documents and consequently giving document structure definitions independent of their projection on visual supports. The second one, which is the main contribution of this work, has been realised by implementing an ontology formalism into a hypertext language. Thus, we could equip the knowledge base with indexing tools, for context sensitive browsing. An application of the approach for the diagnosis of vibration on rotating machines is also presented.
MOTS-CLÉS : diagnostic, systèmes hypertextes, indexation, ontologie, documents structurés.
KEY WORDS : diagnosis, hypertext systems, indexing, ontology, structured documents.
1. Introduction
La réalisation d’une tâche de diagnostic fait appel à la manipulation d’informations et de connaissances. De nombreux travaux de recherche et réalisations industrielles dans ce domaine ont donc naturellement porté sur l’ensemble des principes et méthodes de traitement d’informations par ordinateur.
Les approches concernées relèvent, par exemple, de l’analyse de données, de la reconnaissance des formes et de la classification [DUB 90], ou de l’utilisation des techniques d’intelligence artificielle (IA) pour le diagnostic [ABU 94]. Parmi ces techniques, on peut distinguer celles qui utilisent une approche expérimentale visant à représenter la connaissance heuristique humaine relative à la maintenance et à la réparation d’un procédé ou d’un processus, celles qui utilisent des modèles quantitatifs ou qualitatifs du comportement normal et attendu d’un processus afin de détecter et d’expliquer la différence entre le comportement observé et le comportement prévu par le modèle, ou encore celles qui font référence à la possibilité de représenter, de gérer et de mettre à jour notre connaissance de cas étudiés précédemment lors de l’échec d’un processus. Les procédures automatiques d’acquisition de connaissances utilisent soit des techniques de classification pour construire la théorie d’un domaine, soit des modèles conceptuels de la théorie d’un domaine pour établir des analogies. L’intégration de plusieurs de ces techniques de diagnostic propose des solutions quand aucune stratégie ne convient seule [MUS 95 ; MOR 96]. L’évolution de ces techniques parallèlement à celle des techniques de manipulation d’information a permis de s’intéresser à des cas de plus en plus complexes faisant appel à l’intégration de plusieurs techniques de diagnostic ainsi que de plusieurs sources d’information ou de connaissances descriptives des systèmes étudiés.
Dans le cas de l’utilisation de plusieurs sources de connaissances, typique des diagnostics complexes ou intégrés, nous avons montré que l’approche à base de systèmes hypertextes offrait des solutions intéressantes [MOR 98a]. Elle permet en particulier de s’affranchir de la détermination a priori des relations qui existent entre ces techniques. Nous avons montré que cela était possible à condition de pouvoir développer des outils de navigation hypertexte orientés tâche. Cette approche repose sur la notion de navigation contextuelle. Son objectif est de rendre compte du fait que le chemin suivi par le lecteur de l’hypertexte n’est pas seulement défini par les relations entre les nœuds, mais aussi par le contexte dans lequel les liens et les autres possibilités de navigation apparaissent. Ceci nous a conduit à définir la notion de document numérique, qui contient ses propres structures potentielles de navigation. Ces structures potentielles deviennent perceptibles par projection, et correspondent à une opération d’interprétation et d’instanciation [BRU 98]. Nous avons également montré que, en séparant le contenu des nœuds de la structure du document hypertexte, il devient possible d’implémenter des outils, que nous appelons instruments de lecture et qui permettent la création dynamique de documents durant la lecture [MOR 98b].
La création et l’implémentation des outils d’instrumentation de la lecture reposent sur la description de la connaissance que l’on a des systèmes étudiés et des tâches que l’on veut effectuer. Pour réaliser cette description, nous nous sommes appuyés sur une approche de construction d’une ontologie d’objets techniques, et plus précisément des machines tournantes. La construction de cette ontologie repose sur un langage formel, Def-* [KAS 97]. Pour la réalisation pratique du système, nous avons utilisé une implémentation en SGML du formalisme Def-*.
Il reste cependant à permettre à l’utilisateur de naviguer à l’aide d’un système hypertexte correctement instrumenté dans cette ontologie pour résoudre les tâches de diagnostic souhaitées. Le principe consiste à utiliser la connaissance décrite dans l’ontologie pour guider le parcours de navigation.
L’aide à l’utilisateur peut se réaliser selon deux approches : soit on connaît un modèle de l’utilisateur et le système de navigation adapte les parcours possibles à ce modèle [DEC 99, HIR 98], soit on peut décrire le domaine documentaire et on utilise cette description pour en extraire les sous-ensembles pertinents [BOY 91, CHA 98]. Nous nous plaçons dans cette seconde perspective. Dans ce dernier cas, la plupart des approches utilisent des calculs statistiques sur les nombres de liens sortant des ou pointant vers les documents, ainsi que des notions de proximité pour extraire la partie pertinente. Cette approche se justifie quand la taille et le nombre des documents sont très élevés et que les contenus sont très divers. Nous sommes dans le cas plus favorable où le domaine décrit un monde spécifique (en l’occurrence, celui des machines tournantes) et dans lequel les tâches à accomplir correspondent à une pratique professionnelle. Le principe est alors d’utiliser les liens statiques de la taxonomie pour construire dynamiquement, en fonction de la tâche à réaliser, des parcours de l’ontologie adaptés à la requête. Nous avons utilisé les propriétés structurantes de SGML pour construire des index qui serviront au parcours de la base de connaissance. On distinguera en particulier les index statiques, images des liens induits par la taxonomie, des index dynamiques, construits au fur et à mesure de la progression de la requête de l’utilisateur, en parcourant la structure de la base de connaissance.
Le plan de cet article est donc le suivant. Dans la section 2, nous donnons un bref rappel sur les principes généraux de construction de notre ontologie et une courte présentation du formalisme Def-*, nécessaire à la compréhension de la suite de l’article. La section 3 présente plus en détail la structure de l’ontologie développée dans le domaine des machines tournante et son implémentation en SGML. Dans la section 4, nous décrivons la construction des index, à partir de la structure SGML pour parcourir l’ontologie. La section 5 est une illustration de notre approche par un exemple complet d’application. Nous présentons, enfin, dans la dernière section les conclusions et les perspectives de ce travail.
2. Un formalisme de description d’ontologie
La réalisation d’un système de diagnostic à base d’hypertexte nécessite une description complète et sa représentation associée de notre connaissance du domaine. Cette connaissance n’est pas descriptive, mais plutôt synthétique et structurelle. Nous avons besoin de savoir comment chaque concept de diagnostic est articulé par rapport aux autres concepts. Pour représenter l’organisation de cette connaissance nous nous reposons sur une approche de description par une ontologie.
Une ontologie définit la connaissance d’un domaine donné en reproduisant sa propre structure de concept. Elle possède deux dimensions [CHA 99] :
– la connaissance factuelle du domaine, qui fournit la connaissance des réalités du domaine d’intérêt (objets, relations, événements, états, etc.),
– la connaissance de résolution de problème, qui fournit la connaissance des façons d’atteindre différents buts. Une partie de cette connaissance peut être une forme de méthode de résolution de problèmes spécifiant d’une façon indépendante du domaine comment atteindre un certain but.
Valente [VAL 99] considère que dans le cas de KBPS (Knowledge-Based Problem Solving), les ontologies ne sont pas seulement utilisées pour décrire le domaine, mais aussi pour supporter des applications. Dans ce cas, les ontologies ne développent pas la connaissance tout entière concernant le domaine, mais seulement ce qui est nécessaire pour une bonne compréhension d’une application spécifique.
Le développement de notre ontologie de résolution de problème correspond à ce type d’approche.
Pour décrire un domaine à travers une ontologie, il existe plusieurs langages de représentation. Genesereth et Fikes ont décrit KIF (Knowledge Interchange Format), une technologie qui facilite l’expression de la connaissance factuelle du domaine [GEN 92]. Neches a décrit une proposition d’échange de connaissance [NEC 91], alors que Gruber a proposé un langage appelé Ontolingua pour l’aide à la construction d’ontologies portables [GRU 93]. Le projet CommonKADS a suivi une approche similaire de modélisation de la connaissance du domaine [SCH 94]. Ces langages décrivent principalement la connaissance d’un domaine. Ils permettent de partager la connaissance, mais nous voulons pouvoir en plus décrire et utiliser des méthodes de résolution de problèmes.
Notre approche est donc basée sur le langage formel Def-* qui a été proposé par Kassel [KAS 99]. Ce langage appartient aux types de langages développés pour formaliser et/ou rendre opérationnels des modèles conceptuels selon des méthodes similaires à CommonKADS. Le but de Def-* est de formaliser des modèles opérationnels. Def-* est basé sur des « hypothèses épistémologiques », qui définissent les types de connaissance que le langage est capable de représenter, formant ainsi une « ontologie de représentation ». Une des caractéristiques principales de Def-* est qu’il permet également de formaliser des tâches réflexives.
On peut assimiler ces tâches à des activités de résolution de problèmes tout à fait
semblables à des tâches de diagnostic. Nous avons donc développé une ontologie des machines tournantes à partir du formalisme de Def-*.
Nous définissons trois sortes de concepts :
– les concepts génériques qui désignent les objets génériques, – les concepts relations qui désignent les relations entre les concepts,
– les concepts individuels ou instances de concept qui désignent des objets particuliers.
2.1. Def-concept
Dans le langage Def-*, un concept générique est à la fois une suite d’objets et une entité. Une définition introduite par Def-concept comprend à la fois la représentation de l’intention du concept et la représentation de ses propriétés (cf.
figure 1).
La définition conceptuelle situe le concept dans la taxinomie en utilisant les propriétés qui le rendent différent de tous les autres concepts. Dans l’exemple de la figure 1, elle correspond à la ligne :
Def-concept #rotor, Est-un #pièce-mécanique qui définit le rotor comme une spécialisation de pièce mécanique.
Figure 1. Exemple de syntaxe de Def-concept Def-concept #rotor
Est-un #pièce-mécanique Propriété
tt E est-composé-de arbre
Définitions
· Un rotor est une pièce mécanique qui est composée d’un arbre.
(Définition conceptuelle)
· Un rotor est une partie d’une machine tournante qui est en rotation par rapport au stator qui est fixe. (Définition « encyclopédique »)
Figurent ensuite la ou les propriétés du concept exprimées au moyen de relations avec les autres concepts. Ces relations, dont la définition est donnée dans le paragraphe ci-dessous, utilisent les quantificateurs universels " et $, notés respectivement « tt » et « E » dans le formalisme Def-*.
On donne enfin une définition du concept en langage naturel, pour une compréhension plus naturelle par l’utilisateur lorsqu’il parcourt l’ontologie dans le formalisme Def-*. La définition en langage naturel comporte deux parties :
– une définition conceptuelle exprimant les propriétés définies par Def-* au cours de la définition de concept ;
– une définition « encyclopédique » de type entrée de dictionnaire avec une référence bibliographique si il y a lieu.
Cette dernière définition peut être complétée par un exemple et une illustration multimédia du concept (image, film, son, etc.). Les concepts étant définis comme une spécialisation d’autres concepts, il en résulte une taxinomie en forme d’arborescence telle que présentée figure 2.
Figure 2. Taxinomie en forme d’arborescence
2.2. Def-relation
Ces relations sont particulièrement importantes pour la définition des propriétés de chaque concept. Les relations sont définies par la primitive Def-relation de la même façon que la primitive Def-concept. De plus, cette construction permet de définir à la fois le concept relationnel et tous les couples qui sont concernés par le concept. La figure 3 présente un concept de relation simple « est-composé-de ».
rotor arbre aube écrou objet artificiel
pièce mécanique
Figure 3. Exemple de syntaxe de Def-relation
Dans cet exemple, la relation est-composé-de permet de mettre en relation un couple de concepts en spécifiant qu’un concept est composé d’un autre concept.
Cette relation est une relation d’objets, c’est-à-dire une relation définie entre deux objets (le couple de concepts).
2.3. Instance de concept
On définit enfin des instances de concept, correspondant à des objets spécifiques, instances d’un concept générique, dont ils possèdent toutes les propriétés. La figure 4 représente un exemple de syntaxe de Def-conceptind qui permet de définir des individus. L’instance de concept #Paul est définie relativement au concept générique #être-humain, exprimant ainsi que « Paul est un être humain ». On obtient ainsi un lien d’appartenance entre le concept #Paul qui est un objet et le concept #être-humain en tant qu’ensemble. Par cette appartenance, le concept #Paul hérite des propriétés du concept générique #être-humain.
Figure 4. Exemple de syntaxe de Def-conceptind
3. Implémentation structurante de l’ontologie
Def-* est un formalisme intéressant et puissant, mais ce n’est pas encore un langage de programmation. Nous avons réalisé une implémentation de Def-* en SGML (Standard Generalized Markup Language). L’implémentation de Def-* en SGML, nous a permis de structurer notre ontologie en utilisant les propriétés de structures documentaires liées au langage SGML. Cette implémentation permettra
Def-relation #est-composé-de Est-un [#relation-object]
Def-conceptind #Paul
Est-un [#être-humain]
de définir et d’utiliser des index pour parcourir la base, mais ce dernier point sera discuté au paragraphe suivant. L’intérêt de cette implémentation est donc qu’elle autorise l’instrumentation de nos documents, en particulier la navigation à travers la base de connaissance, que nous pourrons exploiter pour réaliser des tâches de diagnostic.
3.1. Implémentation en SGML de Def-*
L’implémentation de Def-* en SGML nous a permis, premièrement de réaliser une représentation de la base de connaissance dans un langage formel opérationnel sur machine, et deuxièmement, de disposer d’emblée d’outils de navigation hypertexte dans cette base.
Du point de vue pratique, nous écrivons un fichier par concept présent dans l’ontologie. En revanche, nos fichiers ne sont pas organisés dans une arborescence de répertoires, qui reproduirait la structure de la taxinomie. Contrairement à cette organisation généralement rencontrée pour représenter les ontologies, nous avons préféré mettre tous les fichiers dans un répertoire unique. L’intérêt de cette organisation des fichiers est qu’elle n’engendre aucune contrainte pour la maintenance de la gestion des fichiers. Nous avons conservé la représentation de la taxinomie grâce aux structures SGML qui définissent chaque fichier et leurs liens hypertextes.
Figure 5. La syntaxe de Def-concept
Def-concept #nom de concept (ex. : #rotor)
Est-un #pere de concept (ex. : #pièce mécanique) Propriété (optionnel)
Quantificateur relation variable (ex. : tt E est-composé-de arbre)
Définitions
· Définition conceptuelle
· Définition « encyclopédique » Référence (optionnel) Exemple (optionnel) Illustration (optionnel)
Le passage de Def-* à SGML s’effectue grâce à la création d’une DTD (Définition de Type de Document) pour chaque primitive de Def-*. La figure 5 montre la syntaxe de la primitive Def-concept.
A partir de la syntaxe de la primitive def-concept, on obtient sa DTD, dont la structure d’arbre est présentée figure 6. On a défini ainsi pour chaque primitive de Def-* une DTD associée. L’ontologie elle-même est représentée par une DTD, qui inclut les DTD des différentes primitives.
Figure 6. Structure d’arbre d’un concept
Deux solutions étaient possibles pour représenter les propriétés de concept : soit on utilisait une balise de type relation possédant comme attribut une relation spécifique choisie dans une liste de relations prédéfinie, soit on laissait à l’utilisateur le choix de définir lui-même chaque relation. Dans le premier cas, nous devons définir la liste des relations possibles au niveau de la DTD. Nous figeons ainsi le nombre d’attributs et leurs contenus. Si nous sommes ensuite amenés à modifier l’ontologie en y ajoutant de nouvelles relations, il est nécessaire d’ajouter ces nouvelles relations à la liste d’attributs qui figure dans DTD. La modification de cette DTD pourrait alors faire apparaître des problèmes de maintenance de la cohérence du système.
Dans le second cas, c’est à l’utilisateur d’affecter les relations qui entrent dans la définition d’un concept. Cette solution demande à l’utilisateur de bien connaître l’ontologie et notamment les relations déjà définies. En effet, si l’utilisateur affecte un nom de relation qui n’existe pas, cela peut entraîner un dysfonctionnement du système. En revanche, la liberté qu’offre cette solution permet d’avoir une ontologie dynamique. Elle peut être modifiée à tout moment sans pour autant engendrer de grands bouleversements dans le système. On peut y ajouter de nouveaux types de
relations sans que cela modifie les liens existants. La seule contrainte est de définir une relation avant de la faire apparaître dans un concept, ce qui ne semble pas poser de problème pratique. Cet aspect dynamique de l’ontologie est un point important.
En effet, l’ontologie peut être modifiée par l’utilisateur, mais également enrichie par l’expérience issue des diagnostics réalisés par le système.
3.2. Structure de la taxinomie
La syntaxe utilisée pour la définition des concepts fait clairement apparaître les liens entre les concepts. Premièrement, un concept est défini comme spécialisation de son concept père. Il en résulte une organisation hiérarchique entre les concepts, qui n’est autre que la taxinomie. D’autre part, l’énoncé de ses propriétés fait apparaître des liens transversaux entre les concepts. Les liens de la taxinomie et les liens transversaux sont tous orientés (figure 7).
On pourrait imaginer construire des liens inverses tels que « a pour fils » ou « a pour relation inverse », mais cela entraînerait des problèmes de maintenance lors des mises à jour de la base de connaissance. En effet, la construction de la taxinomie suppose que l’on va toujours dans le même sens : du général vers le spécialisé. La création de liens du type « a pour fils » nécessite de reconsidérer l’ensemble de ces liens dès qu’un nouveau concept est inséré. Il en est de même pour les liens de type relation. Ces liens, qui sont pourtant nécessaires pour le parcours de l’ontologie lors de la résolution d’une tâche diagnostique, seront construits dynamiquement au moment de la résolution de tâche. Cette construction s’accompagne de la construction des index correspondants et sera décrite dans la section 4.
Figure 7. Taxinomie issue des définitions de concept
#pièce-mécanique
#est-composé-de
#est-composé-de
#lie
#est-un
#est-un
#est-un #est-un
#artefact
#liaison-mécanique
#rotor #arbre #aube #ecrou #bille
L’implémentation de Def-relation est similaire à celle de Def-concept, leur structure étant identique au niveau de leur déclaration dans Def-*. Par contre, l’implémentation de Def-conceptind demande une attention plus particulière.
3.3. Ontologie d’instance
La notion d’instance de concept existant dans Def-* est perdue en SGML. Pour résoudre ce problème, on crée un objet pour chaque instance d’un même concept générique. Cette base d’objets étant structurée de la même façon que l’ontologie, nous l’appellerons ontologie d’instance. Pour illustrer cette notion d’ontologie d’instance, nous allons étudier le cas des instances d’utilisateurs figure 8.
Les balises <TYPE> et </TYPE> permettent d’identifier le type de l’utilisateur, et représentent également un lien vers le concept expert de l’ontologie. De même, les balises <MACHINE> et
</MACHINE> identifient la machine sur laquelle a été effectué le diagnostic, et représentent un lien vers l’instance ventilateur#4 de l’ontologie d’instance de machine.
Figure 8. Exemple d’instance d’utilisateur
Le concept générique utilisateur est défini et figure dans l’ontologie principale, les instances d’utilisateurs appartiennent à une ontologie d’instance. La structure du document SGML définissant chaque utilisateur est bien particulière et dépend directement de la définition du concept générique d’utilisateur. En effet, nous savons qu’un utilisateur est défini par son nom, son prénom, la catégorie d’utilisateur (expert, technicien, étudiant, etc.) à laquelle il appartient, mais également par des renseignements sur les différents diagnostics qu’il a effectués sur des machines tournantes. Ces renseignements intègrent les dates des diagnostics ainsi que la référence de la machine sur laquelle il a effectué cette tâche.
L’ontologie d’instance d’utilisateurs est liée à l’ontologie principale par l’appartenance des utilisateurs à un type d’utilisateur. Elle peut être également en
<! DOCTYPE USER SYSTEM “ user.dtd ”>
<USER>
<NOM>PAUPE</NOM>
<PRENOM>Charles-Claude</PRENOM>
<TYPE>expert</TYPE>
<DIAG> lien vers l’ontologie
<DATE>Thu May 11 08:50:46 2000</DATE> de concept
<MACHINE>ventilateur#4</MACHINE>
</DIAG> lien vers l’ontologie
</USER> d’instance de machine
liaison avec d’autres ontologies d’instance, comme par exemple l’ontologie d’instance des machines tournantes. En effet, dans chaque fichier représentant un utilisateur figurent des renseignements concernant les diagnostics effectués par l’utilisateur. Ces renseignements sont la date et la machine sur laquelle le diagnostic a été effectué. Le nom de la machine, c’est-à-dire son identifiant, est présent dans ce que nous appellerons le dossier de l’utilisateur (sa définition). Il existe ainsi un lien entre cet utilisateur et cette machine. Ce lien relie donc deux ontologies d’instance entre elles, comme illustré à la figure 8.
L’aspect dynamique dont nous avons déjà parlé pour l’ontologie principale est d’autant plus présent pour les ontologies d’instance, qu’elles servent d’archives pour les diagnostics qui ont été réalisés. Les ontologies d’instance sont en fait modifiées à chaque utilisation, à chaque nouveau diagnostic.
4. Indexation pour le parcours de la base
La réalisation d’une tâche de diagnostic nécessite de parcourir l’ontologie. On peut identifier deux types de parcours. Un premier type de parcours, à l’initiative de l’utilisateur, correspond au besoin de se renseigner sur la connaissance du domaine.
Nous lui avons associé un module lexical, qui donne accès aux différents concepts de l’ontologie. Le second type de parcours, qui est en général réalisé directement par le système, correspond à la tâche de diagnostic proprement dite. Il s’agit, à partir d’un protocole de diagnostic représenté dans le système d’aide au diagnostic, d’aller chercher les éléments pertinents pour résoudre la tâche en cours. Le système doit donc pouvoir accéder aux différents objets concernés de l’ontologie d’instance, ainsi qu’à leurs propriétés génériques qui figurent dans l’ontologie générique. Il y a également un type de parcours spécifique à la consultation d’archives que nous détaillerons dans le dernier paragraphe de cette section.
La gestion de ces parcours repose sur l’utilisation de tableaux d’index. Bien que ni l’ontologie ni les dossiers de suivi de chaque machine ne puissent être considérés comme des documents numériques au sens habituel du terme, la construction et l’utilisation d’index reposent sur une approche comparable. Dans les deux cas, les index sont construits par analyse des valeurs spécifiques rencontrées dans les documents pour une balise ou un ensemble de balises SGML. Cette approche est souvent adoptée dans l’indexation de documents numériques [BAE 99].
4.1. Lexique
La réalisation de ces parcours repose sur l’existence de liens hypertextes, qui doivent être construits automatiquement par le système. La construction de ces liens est réalisée à partir de tableaux d’index.
Les liens que nous avons définis précédemment au niveau des différentes ontologies permettent de les parcourir dans le sens des arcs du graphe orienté tel que
présenté à la figure 7. Pour l’instant, ce parcours est unidirectionnel. On peut ainsi connaître le père d’un concept, mais on ne peut pas connaître son ou ses fils. Il en va de même pour les liens relationnels qui sont également orientés. Nous venons de voir qu’il était nécessaire de donner à l’utilisateur le moyen d’une consultation lexicale de l’ontologie. En effet, la réalisation d’un diagnostic tel que celui concerné par notre application, les vibrations sur les machines tournantes, nécessite une parfaite connaissance du domaine.
Comme nous l’avons vu précédemment, le langage naturel est trop ambigu et peut conduire à des erreurs d’interprétation. C’est pourquoi l’utilisateur doit pouvoir dialoguer avec le système en employant les mêmes termes. L’objet du lexique est donc de proposer à l’utilisateur d’accéder à chaque concept de l’ontologie. Cet accès est possible à partir d’une liste des concepts présents dans l’ontologie, qui peut être présentée sur un support quelconque dans le cas général, et qui, dans notre cas, l’est sous forme d’un menu déroulant sur l’écran d’un ordinateur.
Dans une seconde phase, lorsqu’un concept a été sélectionné, il faut permettre à l’utilisateur d’accéder à tous ceux avec lesquels il est en relation. Il faudra donc pouvoir parcourir l’ontologie dans d’autres directions que celles établies par la taxinomie.
Les parcours de l’ontologie vont donc être réalisés à l’aide d’index de deux types. Les premiers seront simplement construits à l’aide des DTD SGML qui ont été décrites ci-dessus. Ce seront des index dits statiques, dans la mesure où ils sont une autre représentation des relations qui existent dans l’ontologie. Les seconds seront déduits de la structure de l’ontologie pour permettre des parcours dans des directions inverses de celles proposées par la taxinomie. Ce sera, par exemple, la recherche de tous les fils d’un concept père, ou encore de tous les objets qui en composent un autre.
Ces index seront dits dynamiques, dans la mesure où ils doivent être recalculés pour chaque nouvelle consultation, leur existence n’ayant pas de lien direct avec la construction de la taxonomie pour les raisons de maintenance que nous avons évoquées précédemment.
4.1.1. Index statiques
On définit le graphe G(V,E) représentant l’ontologie par l’ensemble V de ses concepts et E de ses relations. Si p et q sont des concepts de V, leur relation est représentée par l’arc orienté (p,q) Î E.
Pour un concept p donné on peut définir la balise <nomconcept> comme un index vers ce concept. On peut alors facilement construire le tableau inverse permettant de parcourir le graphe orienté à l’aide de la relation donnée dans le tableau 1.
Nom_concept Nom_concept-père
Rotor #fichier(pièce mécanique)
rupture de roulement #fichier(cause de balourd)
Tableau 1. Tableau des index permettant de trouver le père d’un concept
La construction de ce tableau peut être formalisée de la façon suivante :
"p Î V, p a_pour_père q ssi (p, q) Î G
La construction de ce tableau est donc réalisée à l’aide de l’algorithme : Pour tout concept p de V
Extraire la chaîne de caractères cc1 comprise entre <pereconcept> et </pereconcept>
Pour tout fichier des concept #F Ouvrir #F
Extraire la chaîne de caractères cc2 comprise entre <nonconcept> et </nonconcept>
SI cc1 = cc2
Insérer #F dans le tableau FinSI
Fin pour tout Fin pour tout
4.1.2. Index dynamiques
La construction dynamique des liens est réalisée en interprétant le contenu des définitions de concept. On retrouve cette idée de création dynamique de liens à partir de l’ontologie dans les travaux d’Auffret [AUF 99].
Si on veut, par exemple, accéder à la connaissance de ce qu’est une cause de balourd et avoir accès à toutes les causes de balourd connues dans l’ontologie, il faut aller chercher ces causes parmi les fils du concept cause de balourd.
On peut également accéder aux informations relatives au concept machine tournante et connaître ainsi la classification des machines tournantes, chaque type de machine tournante étant un concept fils du concept machine tournante.
Nom_concept Nom_concept fils
pièce mécanique #fichier(rotor), #fichier(arbre),
#fichier(aube), …
cause de balourd #fichier(rupture de roulement) ;
#fichier(exès de matière), …
machine tournante #fichier(groupe-I), #fichier(groupe-II), … Tableau 2. Tableau des index permettant de trouver les fils d’un concept. On remarquera qu’ici, il peut y avoir plusieurs concepts fils pour un concept donné.
Pour construire le tableau inverse donnant pour un concept p la liste de ses fils (tableau 2), il suffit de parcourir l’ontologie et de construire l’ensemble des concepts q tels que :
"p Î V, p a_pour_fils q ssi (q, p) Î G ce qui peut encore s’écrire :
{q Î V ½ (q, p) Î G}
L’algorithme de construction du tableau est le suivant : Pour tout concept p de V
Extraire la chaîne de caractères cc1 comprise entre
<nomconcept> et </nomconcept>
Pour tout fichier des concept #F Ouvrir #F
Extraire la chaîne de caractères cc2 comprise entre <pereconcept> et </pereconcept>
SI cc1 = cc2
Insérer #F dans le tableau FinSI
Fin pour tout Fin pour tout
4.2. Module diagnostic
Nous allons présenter les principes de fonctionnement de ce module dans le cas particulier de notre application, ce qui n’enlève rien à la généralité de l’approche, mais permet une présentation plus claire. L’aide au diagnostic vibratoire des machines tournantes s’appuie sur la norme NFE90-300 [AFN 78] qui définit le
protocole et la mise en œuvre de l’appréciation vibratoire globale à partir de signaux vibratoires mesurés et enregistrés sur une machine tournante.
Nous avons défini plusieurs niveaux d’utilisateurs (expert, novice, en formation, etc.) et l’aide fournie par le système sera donc adaptée à chaque niveau. La première requête est donc l’identification de l’utilisateur. S’il est connu du système, il est présent dans l’ontologie d’instance des utilisateurs. Dans le cas contraire, la création d’un nouvel utilisateur correspond à l’ajout d’une nouvelle instance d’utilisateur, c’est-à-dire d’un nouvel objet dans l’ontologie d’instance d’utilisateurs. Ceci montre bien que les ontologies d’instance ne sont pas figées, et peuvent être modifiées à tout moment par un utilisateur ou, comme nous le verrons, par le système.
Nous présentons à la figure 8 le document SGML représentant une instance d’utilisateur. On remarquera dans ce document la valeur expert comprise entre les balises <TYPE> et </TYPE>, qui permettra de construire un lien hypertexte vers le concept générique expert qui figure dans l’ontologie de concepts (un expert étant une spécialisation d’utilisateur). De même, on remarquera la valeur Ventilateur#4 comprise entre les balises <MACHINE> et </MACHINE>, qui permettra de construire un lien hypertexte vers le concept Ventilateur#4 qui figure dans l’ontologie d’instance de machines. Cette instance d’utilisateur sera donc modifiée à l’issue de cette consultation, en particulier par l’ajout des balises et valeurs associées qui sont comprises entre les balises <DIAG> et </DIAG> (par exemple la date).
Après avoir identifié un utilisateur, il faut identifier la machine concernée par la session courante. Si cette machine existe, elle est trouvée par le système dans l’ontologie d’instance des machines tournantes, sinon elle est créée. Le document SGML défini par la DTD correspondante d’une machine tournante est présenté figure 9. De même que dans le cas des utilisateurs, on remarquera l’existence de liens vers l’ontologie de concept et les autres ontologies d’instance.
L’utilisateur renseigne alors le système sur l’identifiant de la machine, sa situation géographique, son groupe d’appartenance suivant la norme et la situation des points de mesure définis par la norme. Pour une machine donnée, les points de mesure sont généralement les mêmes d’un diagnostic à un autre, ce qui sera exploité pour réaliser des comparaisons ou suivre l’évolution de différents diagnostic. C’est pourquoi la situation et l’orientation des points de mesure sont demandées lors de la création de la machine, en tant qu’instances dans l’ontologie. Ces points de mesure font partie de la carte d’identité de la machine au même titre que son identifiant.
L’étape suivante du diagnostic consiste à donner au système des signaux à analyser. Pour chaque point de mesure, l’utilisateur fournit au système un signal correspondant à la mesure vibratoire en ce point. Pour connaître la liste de points de mesure de la machine et leurs caractéristiques, le système parcourt l’ontologie d’instance de machine à la recherche de la machine concernée puis identifie les points de mesure et leurs caractéristiques grâce aux balises ad hoc. A partir de ces signaux, le système détermine ce que l’on appelle la vitesse efficace de vibration (Veff). Cette valeur doit être comparée à des seuils d’admissibilité définis par la
norme et qui dépendent du groupe d’appartenance de la machine. Elles figurent donc dans l’ontologie de concepts, parmi les caractéristiques des objets concepts machines tournantes de chaque type. Le système doit donc d’une part rechercher le groupe d’appartenance de la machine en parcourant l’ontologie d’instance de machine. Il doit d’autre part connaître les seuils d’admissibilité pour ce groupe en parcourant l’ontologie de concepts. Il interprète alors les propriétés du groupe et en déduit ainsi la valeur des seuils d’admissibilité.
Figure 9. Document SGML représentant une instance de machine
Connaissant les seuils d’admissibilité le système donne à l’utilisateur l’admissibilité du niveau de vibration correspondant à la valeur de Veff. Il fournit également une vue du signal et une image de sa transformée de Fourier (FFT) s’il y a lieu, le calcul de la FFT ayant lieu uniquement si le signal est temporel. Les calculs d’admissibilité et de FFT sont réalisés pour chaque point de mesure. Par la suite, le système archive les résultats dans l’instance de la machine, et la trace d’un diagnostic effectué dans celle de l’utilisateur. Toutes les fonctions de mise à jour des instances sont automatiques et gérées par le système qui se charge de maintenir les documents conformes aux DTD des instances d’objets concernés. Ces informations pourront être exploitées par la suite par le module de consultation d’archives qui est présenté dans le paragraphe suivant.
<!DOCTYPE MACHINE SYSTEM “machine.dtd”>
<MACHINE>
<ID>ventilateur#4</ID>
<SITE>Compiègne</SITE>
<GROUPE>groupe-I</GROUPE>
<POINT>
<SITUATION>palier</SITUATION>
<DIRECTION>x</DIRECTION>
</POINT>
<DIAG>
<DATE>Thu May 11 08:50:46 2000</DATE>
<USER>PAUPE_Charles-Claude</USER>
<MESURE>
<FICHIER>../MESURE/…/palier_x_08_50.txt</FICHIER>
<SIGNAUX>../MESURE/…/palier_x_08_50.gif</SIGNAUX>
<VEFF>0.010</VEFF>
</MESURE>
</DIAG>
</MACHINE>
Il apparaît donc clairement que le système doit parcourir les ontologies disponibles dans de nombreuses directions et selon des liens qui n’existent pas directement dans la taxinomie. Ces parcours s’appuient sur une construction d’index identique à celle présentée dans le paragraphe précédent. En plus des index qui ont été construits dans l’ontologie de concepts, on construira des index dynamiques entre les ontologies d’instance et l’ontologie de concepts selon les mêmes principes.
On donne ci-dessous l’exemple de l’algorithme permettant d’extraire les seuils d’admissibilité d’une machine donnée.
Pour l’instance i de l’ontologie d’instance OI Extraire la chaîne de caractères cc1 comprise entre
<GROUPE> et </GROUPE>
Pour tout fichier des concept #F Ouvrir #F
Extraire la chaîne de caractères cc2 comprise entre <nonconcept> et </nomconcept>
SI cc1 = cc2
Extraire les propriétés comprise entre
<PROPRIETE> et </PROPRIETE>
FinSI Fin pour tout Fin
Les seuils d’admissibilité figurent en réalité parmi les propriétés qui ont été extraites, et sont eux-mêmes extraits à l’aide de l’identificateur (balise SGML) de la relation concernée. Cette partie a été omise de la présentation de l’algorithme ci- dessus pour en maintenir la clarté.
Les valeurs extraites, qui servent d’index vers les différents éléments nécessaires au diagnostic (les seuils, les courbes, les niveaux d’admissibilité, etc.) sont réunies dans un document synthétique, qui est stocké dans l’espace de travail. Ces index sont représentés dans cet espace comme des liens hypertextes. L’espace de travail est donc un document SGML synthétique. Dans la pratique, cet espace de travail est accessible à l’utilisateur grâce à une interface hypertexte, dont la réalisation est présentée dans la section suivante. Cette interface est en fait une instanciation HTML du document espace de travail synthétique au format SGML.
4.3. Consultation d’archives
Un autre aspect de l’utilisation du système est la consultation d’archives. Il est par exemple intéressant de connaître, pour une machine donnée, la liste des interventions de diagnostic qui lui sont associées. Dans ce cas, comme dans le précédent, nous allons construire dynamiquement un document SGML dans un espace de travail, qui permettra de naviguer parmi les différentes connaissances
auxquelles l’utilisateur souhaiterait avoir accès. Si l’on considère, par exemple, le cas du suivi des diagnostics d’une machine donnée, il est assez simple de construire un document SGML qui fera apparaître dans l’espace de travail la liste des dates d’intervention et des intervenants sur cette machine. Il suffit pour cela de consulter l’instance de cette machine. L’utilisateur peut utiliser ces deux items, comme liens hypertextes vers les connaissances qu’ils contiennent. Cela signifie, par exemple, que le nom d’un utilisateur est un lien vers l’instance utilisateur concernée et de là vers les autres éléments de l’ontologie. Si l’on veut que l’activation de ces liens soit efficace, il faut que les objets vers lesquels ils pointent soit déjà référencés dans un tableau d’index. Ceux-ci sont réalisés selon les mêmes principes que ceux qui ont été utilisés au paragraphe 4.1 et nous donnons ci-dessous un exemple d’algorithme d’extraction des index vers les utilisateurs d’une machine donnée.
Pour l’instance i de l’ontologie d’instance machine OIM Pour chaque balise <DIAG>
Extraire la chaîne de caractères cc1 comprise Entre <USER> et </USER>
Pour tout fichier #F de l’ontologie d’instance d’utilisateurs OIU
Ouvrir #F
Extraire la chaîne de caractères cc2 Comprise entre <NOM> et </NOM>
SI cc1 = cc2
ajouter cc2 à la liste des utilisateurs de i
FinSI Fin pour tout Fin pour tout
Nous allons présenter dans la section suivante l’implémentation de cette approche dans un environnement de navigation Netscape, écrit en HTML.
5. Exemple de réalisation
D’un point de vue pratique, nous avons créé une interface utilisateur à l’aide d’une page HTML. Cette page HTML représente l’espace de travail (figure 10).
Cet espace de travail permet d’afficher les pages SGML synthétisées, en affichant une projection HTML du document SGML. Seul l’espace est écrit en HTML, tout le reste de l’implémentation restant dans son formalisme d’origine.
L’appel et la manipulation des différents documents SGML sont faits à l’aide de scripts perl.
Figure 10. Espace de travail
Figure 11. Exemple d’utilisation du lexique
L’espace de travail est divisé en trois parties, correspondant aux trois outils du système d’aide au diagnostic pour les machines tournantes : le lexique, l’aide au diagnostic et la consultation d’archives. Nous allons voir un exemple de manipulation de chacun de ces outils.
5.1. Lexique
Comme nous l’avons vu dans la section précédente, le lexique permet d’accéder à un concept de l’ontologie, ainsi qu’à tous ses fils, comme présenté figure 11. Nous remarquons également la présence de liens hypertextes vers les concepts en relation avec le concept choisi, mais également des liens vers les concepts de relations présents dans la définition de celui-ci.
Le lexique permet à l’utilisateur de comprendre le langage du système, et ainsi de dialoguer avec lui lors de l’utilisation du module d’aide au diagnostic.
5.2. Aide au diagnostic
Figure 12. Informations sur les points de mesures de la machine
L’outil d’aide au diagnostic fournit des résultats en termes d’appréciation globale de machine tournante d’après la norme NFE 90-300. L’utilisateur s’identifie ainsi que la machine qu’il étudie à l’aide des menus déroulants (figure 10). Le système recherche alors les informations concernant cette machine. Après avoir
synthétisé un document SGML informant l’utilisateur sur les points de mesures de la machine, il en offre une vue HTML (figure 12).
L’utilisateur fournit alors au système les fichiers de mesures de chaque point, pour obtenir un résultat en terme de vitesse efficace de vibration (Veff). Le système ayant déterminé la valeur de Veff, il va rechercher les seuils d’admissibilité correspondant au groupe de la machine. Ainsi il peut fournir à l’utilisateur la valeur de Veff et le résultat d’admissibilité (figure 13).
Figure 13. Résultats d’admissibilité
Les informations concernant les résultats obtenus et les fichiers de signaux sont ajoutés dans le document d’instance de la machine. Le système ajoute à l’instance de l’utilisateur une trace de ce diagnostic. Toutes ces informations relatives au diagnostic vont être exploitées lors de la consultation d’archives.
5.3. Consultation d’archives
Comme on peut le voir figure 10, l’utilisateur doit choisir de consulter les archives d’un utilisateur particulier ou d’une machine. Nous allons donc présenter chacun de ces deux cas.
5.3.1. Choix d’un utilisateur
Si l’utilisateur choisit de consulter les archives d’un utilisateur particulier, le système lui propose alors une vue HTML d’un document de synthèse (SGML) présentant l’utilisateur en question avec les informations sur les diagnostics qu’il a réalisés (figure 14).
Figure 14. Document de synthèse sur les diagnostics d’un utilisateur.
L’utilisateur peut ainsi choisir un diagnostic particulier et accéder alors aux résultats issus de ce diagnostic. Le système réalise donc une synthèse de document afin de fournir à l’utilisateur ces résultats, et lui en propose une projection HTML (figure 15).
Figure 15. Consultation d’archives d’un diagnostic
5.3.2. Choix d’une machine
Par ailleurs, si l’utilisateur choisit de consulter les archives d’une machine particulière, le système lui propose comme pour l’utilisateur une vue du document synthétisé représentant la machine et ses diagnostics (figure 16).
Figure 16. Document de synthèse sur les diagnostics d’une machine
6. Conclusions et perspectives
Un système hypertexte d’aide au diagnostic doit offrir des possibilités de navigation guidées par la tâche. Ce type de navigation n’est possible que dans la mesure où elle est contextuelle, c’est-à-dire que les parcours sont construits à partir des données du problème courant au moment de la consultation. La construction de tels parcours repose sur une représentation des connaissances mises en jeu et des outils de parcours de la base de connaissance adaptés.
La navigation contextuelle a été réalisée en dotant notre système hypertexte d’instruments de lecture, qui utilisent des structures de projection de documents indépendantes des documents eux-mêmes. Ce résultat a été acquis dans des travaux précédents. Dans le cas présent, il fallait trouver une approche générique de construction de ces structures de projection. Elle repose sur la synthèse de documents hypertextes réalisée à partir de tableaux inverses construits sur des index.
Ces index sont des pointeurs vers les éléments constitutifs des objets de la base de connaissance diagnostique.
La construction de la base de connaissance correspondant à un domaine donné de diagnostic de systèmes s’est appuyée sur un formalisme de représentation d’ontologie. Ce formalisme garantit une fondation correcte de l’ontologie. Il a été
implémenté en SGML, ce qui a permis de représenter correctement la structure inhérente à l’ontologie. Au-delà de cette représentation, SGML est également un support parfaitement adapté aux parcours de cette structure. Certains de ces parcours sont directement suggérés par la taxinomie, d’autre doivent être construits au cours de la consultation des documents.
Pour faciliter la réalisation de ces parcours, nous avons pu construire des index à partir des balises définissant les structures des documents concernés. Ces index ont permis de construire des tableaux inverses, construits dynamiquement lors d’une consultation. Les éléments pointés dans ces tableaux sont regroupés dans une page hypertexte de synthèse qui représente les différentes phases de la tâche de diagnostic.
Notre approche a été validée par la présentation d’une application qui montre les différentes phases d’une démarche diagnostique : la consultation de la base de connaissance, l’élaboration d’un diagnostic, la consultation d’archives.
Dans une étape ultérieure, nous envisageons d’étendre les possibilités de notre système en ajoutant dans l’ontologie la représentation de procédures de diagnostic, autorisant ainsi la mise en œuvre de procédures concurrentes ou de fusion. Nous comptons également y adjoindre des possibilités de parcours d’archives plus riches, exploitant en particulier des liens hypertextes pour permettre aux utilisateurs de les exploiter en fonction de besoins spécifiques (courbes de tendances, résultats statistiques, fouille de données).
7. Bibliographie
[ABU 94] ABU-HAKINA S., « Artificial Intelligence Techniques in Diagnosis: a review of Approaches, Applications, and Issues », Technical Report, NRC 37142, National Research Council, Canada, 1994.
[AFN 78] AFNOR, NFE 90-300 : Vibrations mécaniques des machines tournantes ayant une fréquence de rotation comprise entre 10 s-1 et 200 s-1, mai 1978.
[AUF 99] AUFFRET G., CARRIVE J., CHEVET O., DECHILLY T., RONFARD R., BACHIMONT B.,
« Audiovisual-based hypermedia authoring : using structured representations for efficient access to AV documents », Hypertext, Darmstadt, Allemagne, 1999.
[BAE 99] BAEZA-YATES R., RIBEIRO-NETO B., Modern Information Retrieval, Addison Wesley, 1999.
[BOY 91] BOY G., « Indexing Hypertext Documents in Context », Hypertext Proceedings, 1991.
[BRU 98] BRUNIE V., MORIZET-MAHOUDEAUX P., AND BACHIMONT, B, « Separating Textual Content from Structures for Reading Hypertext Structured Medical Records », in Proceedings of the Ninth ACM Conference on Hypertext and Hypermedia, Pittsburgh, PA, 1998.
[CHA 98] CHAKRABARTI S., DOM B., INDYK P., « Enhanced hypertext categorization using hyperlinks », SIGMOD, Seattle, WA, USA, 1998.
[CHA 99] CHANDERSEKARAN B., JOSEPHSON J. R., BENJAMINS R., « What Are Ontologies, and Why Do We Need Them? », IEEE Intelligent Systems & their applications, vol. 14, n° 1, 1999, p. 20-26.
[DEC 99] DE CAROLIS B., « Generating Mixed-Initiative Hypertexts : a Reactive Approach », IUI, Redondo Beach, CA, USA, 1999
[DUB 90] DUBUISSON B., Traité des nouvelles technologies, série Diagnostic et Maintenance, Diagnostic et reconnaissance des formes, Hermès, Paris, 1990.
[GEN 92] GENESERETH M., FIKES R., Knowledge interchange Format, version 0.3, Knowledge System Lab., Stanford, 1992.
[GRU 93] GRUBER T., « A Translation Approach to Portable Ontology Specifications. », Knowledge Acquisition, vol. 5, 1993, p. 199-220.
[HIR 98] HIRASHIMA T., MATSUDA N., NOMOTO T., TOYODA J., « Context-Sensitve Filtering for Browsing in Hypertext », IUI, San Francisco, CA, USA, 1998.
[KAS 97] KASSEL G., TRAORE M., « Modelling with a Strongly Intensional Language Brings Numerous Advantages », in Proceedings of the Seventh Workshop on Knowledge Engineering, Milton Keynes, UK, 1997
[KAS 99] KASSEL G., Def-* : manuel de référence, LARIA, janvier 1999.
[MOR 96] MORIZET-MAHOUDEAUX P., « On-Board and Real-Time Expert Control », IEEE expert, Intelligent Systems and their Applications, vol. 11, n° 4, 1996, p. 71-81.
[MOR 98a] MORIZET-MAHOUDEAUX P., TERRAY P., BRUNIE V., KASSEL G., « Toward Hypertext System Based Diagnosis », Ninth International Workshop on Principles of Diagnosis, Cape Cod, MA, USA, 23-27 May, 1998.
[MOR 98b] MORIZET-MAHOUDEAUX P., TERRAY P., BRUNIE V., KASSEL G, « A Framework for Building Hypertext-Based Diagnostic Systems », IEEE International Conference on Systems, Man, and Cybernetics, San Diego, CA, USA, 11-14 October 1998
[MUS 95] MUSLINER D.J., HENDLER J.A., AGRAWALA A.K., SIMON H., « The Challenges of Real-Time AI », Computer, vol. 28, n° 1, 1995, p. 58-66.
[NEC 91] NECHES R. et al., « Enabling Technology for Knowledge Sharing », AI Magazine, vol. 12, n° 3, 1991, p. 36-56.
[SCH 94] SCHREIBER G. et al., « CommonKADS: A comprehensive Methodology for KBS Development », IEEE Expert, vol. 9, n° 6, 1994, p. 28-37.
[VAL 99] VALENTE A., RUSS T., MAC GREGOR R., SWARTOUT W., « Building and (Re)Using an Ontology of Air Campaign Planning », IEEE Intelligent Systems & their applications, vol. 14, n° 1, 1999, p. 27-36.
