N° d'ordre:
294
THESE
présentée devant
L'UNIVERSITE DE RENNES 1
U.E.R. Informatique (LF.S.Le.) , .• , . , , " cU S:iC'" ç,:;ôC::"U]
.. , , , . , .. , ... , . , • , . , .. ' "'S';',,:,I·:'v'
"'t)' ~-',r"nr"'-1C')'!"iCI -
".' .~; "'; ''ri ''"\\ ,1
Il''}:'_''.J':.,~:I,_,
.J.;I
• •
~
..
1
o. "'0, 0"'"
", ':'''' "" ,-, \\,.I~ '''~'Y .. ,.. [, '-;j ., \\1 ," Od
~; ;;~,~~~',~'~vL~;~~~~;~:;V~~l'l~~[~~OJl
i
..
,.""''''''"...'"'__..._ .......-
.....,-,.__,..__ __00_"_,--
~
pour obtenir
le titre Docteur de l'Université de Rennes 1, mention: Informatique
~~~U~N MODELE OBJECTAL POUR LA SYNTHESE
DE DOSSIERS MEDICAUX
Soutenue le 19 décembre 1989 devant la commission d'examen
Laurent Karr
président
Patrick BOSC
rapporteurs
François RECHENMANN
Christophe ROCHE
Marie Odile CORDIER
examinateurs
Michèle COURANT
Jean François PINEL
Sophie ROBIN

---

Je tiens à remercier Laurent Kott, Professeur à l'Université de Rennes et
Directeur de L'IRISA, qui me fait "honneur de présider cette thèse.
Je remercie Marie-Odile Cordier, Professeur à l'université de Rennes, d'être
mon directeur de thèse. Qu'elle reçoive ici l'expression de toute ma gratitude.
Tous mes remerciements à Patrick Bosc, Chercheur INRIA et Professeur à
l'ENSSAT de Lannion, à François Rechenmann, Diecteur de recherche INRIA au
laboratoire ARTEMIS/IMAG de Grenoble et à Christophe Roche, Professeur à
l'université de Chambéry, pour avoir accepté d'être les rapporteurs de cette
thèse.
Que toute ma reconnaissance aille à Michèle Courant et à Sophie Robin, pour leur
multiples et attentives lectures du manuscrit et leur nombreux conseils qui ont
constitué pour moi de précieux encouragements.
Merci au docteur Jean françois Pinel, médecin des hôpitaux à pontchailloux pour
avoir été à l'origine du projet Gide et d'y avoir participé avec beaucoup
d'enthousiasme et de patience.
Merci à tous mes collègues de l'IRISA pour l'ambiance chaleureuse et coopérante
qu'ils y font régner, ainsi qu'à tous les stagiaires qui ont contribué au
développement du projet Gide.
.,. .!".- ...-

---

1
SOMMAIRE
page
1 • INTRODUCTION
5
1.1 - Genèse de l'application
5
1.2 - Originalité de la problématique
6
1.3 - Travail réalisé
7
1.3.1 - Représentation des connaissances
7
1.3.2 - Analyse du compte-rendu médical
8
1.4 - Organisation de la thèse
9
2· LES MODELES DE REPRESENTATION DES CONNAISSANCES
10
2.1 - Introduction
10
2.2 - Logique
11
,~\\~ t!~ Mt'/P"'C'h
"",t,
(>-0
2.3 - Règles de production
13
'1.""
~/
0
~'
~
<-..
2.4 - Réseaux sémantiques
14
1 C C "u'
'"
••
tI'.:
V
~
CI"
'~~. Ci
2.5 - Représentations objectales
16
~
."
$"
'1$'
?....
<Y
2.5.1 - Introduction
16
.
'~'
'11'
\\ ..
o?
,Qi'
2.5.2 - Concepts de base
" "",y
.~ .'
17
"!.' 1
l''(}~'
2 5 3
L d
.
d
.
t t" .. 1 (\\",'. . t 1
. . - a ynamlque
es represen a IORs.e19Jec a es
20
2.5.3.1 - R.C.O. et attachements procéduraux
20
2.5.3.2 - L.o.o., méthodes et messages
20
2.5.3.3 - Evolution de la distinction entre L.O.O. et R.C.O.
21
2.5.4 - Avantages des représentations objectales
21
2.5.5 - Inconvénients des représentations objectales
22
2.6 - Quelques systèmes intégrant les règles et les objets
23
2.6.1 - Mycin : intégration implicite des règles et des objets
23
2.6.1.1 - Notion de contexte
23
2.6.1.2 - Regroupement des règles dans les contextes
., .25
- ....-
;",-
2.6.1.3 - Contexte et objet
26

---

2
2.6.2 - Kooi
27
2.6.2.1 - Objets
27
2.6.2.2 - Règles
28
2.6.2.3 - Intégration des règles et des objets
29
2.6.3 - Classic
30
2.6.3.1 - Prototypes et arbres des prototypes
30
2.6.3.2 - Règles
31
2.6.4 - Smeci
31
2.6.4.1 - Catégories, prototypes et objets
32
2.6.4.2 - Règles
32
2.6.4.3 - Tâches
33
2.7 - Conclusion
34
3· SPECIFICATION DES CONNAISSANCES DANS LE SYSTEME GIDE
36
3.1 - Formalisme de spécification
36
3.1.1 - Présentation générale
36
3.1.2 - Concepts
38
3.1.2.1 - Structure
39
3.1.2.2 - Dynamique des concepts
42
3.1.2.3 - Famille d'un concept
42
3.1.2.4 - Propagation des informations dans une famille
44
3.1.3 - Opérateurs
46
3.1.4 - L'opérateur ENVIRONNEMENT
49
3.1 .5 - Expression de concepts
50
3.1 .6 - Exemple de spécification de concept
52
3.1.7 - Opérateurs, règles et messages
52
3.1.8 - Opérations
53
3.1.9 - Tâches
55
3.1.9.1 - Structure d'une tâche
55
3.1.9.2 - Présentation d'une tâche
56
3.1.10 - Conclusion
57
....
~
--'" ~ ....-

---

3
3.2 - Présentation de la maquette
59
3.2.1 - Utilisation du système
59
3.2.2 - Architecture du système
61
3.2.2.1 - Présentation générale
61
3.2.2.2 - Le dossier
62
3.2.2.3 - La consultation et l'utilisateur
62
3.2.3 - Réalisation de la synthèse du dossier
64
4 -IMPLEMENTATION DE GIDE A L'AIDE DE SHIRKA
65
4.1- Présentation de Shirka
65
4.1.1 - Structure d'un schéma
66
4.1.2 - Les facettes
67
4.1.3 - L'attachement procédural dans Shirka
68
4.1.4 - Filtrage
69
4.1.5 - Spécialisation
69
4.2 - Principes de traduction d'un concept de Gide
70
4.2.1 - Les classes OPERATEUR et CONTRAINTE
71
4.2.2 - La classe CONCEPT
72
4.2.3 - La classe FILTRE
72
4.3 -Traduction des expressions de concept
74
4.4 - Traduction des opérateurs et des opérations
75
4.4.1 - Traduction d'un opérateur
75
4.4.2 - Traduction de l'opérateur ENVIRONNEMENT
77
4.4.3 - Traduction des opérations
78
4.5 - Traduction de l'attribut STATUT
81
4.6 - Conclusion
82
5 - ANALYSE D'UN COMPTE-RENDU MEDICAL
82
5.1 - Le langage utilisé dans le compte-rendu
...82
5.2 - Analyse d'un texte ne répondant pas à des critères s'yntaxiques précis
85
5.2.1 - Limites des méthodes basées essentiellement sur des
critères syntaxiques
85

---

4
5.2.2 - Les grammaires casuelles
86
5.2.3 - Les grammaires sémantiques
87
5.2.4 - Notion de sous-langage
88
5.2.5 - Les analyseurs à démons
89
5.3 - Compréhension du compte-rendu dans Gide
90
5.3.1 - L'analyse atomique
91
5.3.1 - Dictionnaire des atomes
91
5.1.2 - Les démons
93
5.3.2 - Prédiction des concepts développés dans un compte-rendu
97
5.4 - Instanciation des concepts prédits
100
5.5 - Conclusion
101
6 - CONCLUSION
102
BIBLIOGRAPHIE
104
ANNEXE 1
113
ANNEXE 2
115
- .!'-' ... -

---

5
INTRODUCTION
1.1 - GENESE DE L'APPLICATION
Ce travail a été suscité par des médecins épileptologues de l'hôpital de
Pontchaillou. Ceux-ci rencontrent dans l'organisation et la manipulation du
dossier d'un malade, des problèmes liés à certaines spécificités de l'épilepsie.
En effet, l'épilepsie est une maladie chronique pouvant être suivie sur plus
d'une dizaine d'années. De plus, son diagnostic est beaucoup plus fondé sur des
manifestations cliniques que sur l'identification d'une cause précise. D'autre
part, le déroulement parfois spectaculaire et généralement imprévisible des
crises, crée dans l'entourage du malade une panique préjudiciable à
l'acquisition d'informations sur le malade et sa maladie, induisant un problème
de crédibilité sur les informations rapportées.
Le dossier du malade est en général épais et touffu. Ceci s'explique par la
diversité et l'éparpillement des sources d'informations, ainsi que les
caractéristiques de la maladie évoquées ci-dessus, à savoir, sa chronicité, la
prédominance de la sémiologie dans le diagnostic et la panique qui accompagne
généralement les crises. Ceci rend difficile la définition d'un modèle général de
dossier convenant pour tous les malades. En outre, certaines informations se
retrouvent en plusieurs exemplaires dans le dossier. Cela peut être dû à la
diversité des sources, ou à la répétition de certaines opérations dans le temps.
Les différents exemplaires de ces informations peuvent être périmés,
redondants ou complémentaires.
L'utilisation d'un tel dossier pose au médecin des problèmes portant à la
fois
sur l'évolution individuelle du patient et sur l'ensemble des dossiers du
service. Ceux abordés ici portent essentiellement sur l'évolution individuelle
d'un patient. Ces problèmes sont relatifs aux études rétrospectives et à la prise
en compte des données évolutives contenues dans le dossier. Par exemple, deux
consultations pouvant être séparées d'une durée de plusieurs mois (voire.
.. .!'., ....-
plusieurs années), le médecin peut éprouver des difficultés à faire le point de
la situation. Il se peut également que pour un malade régulièrement suivi, le
médecin ait de la peine à étudier l'effet de la thérapeutique sur la sémiologie
des crises.

---

6
Le but de ce travail est d'offrir au médecin, un système pouvant l'aider à
résoudre les problèmes de manipulation du dossier. Ce système doit aider le
médecin à faire la synthèse d'un dossier en ressortant les informations
significatives au regard du contexte. Par exemple, pour un malade suivi dépuis
plusieurs années et pour lequel on ne remet pas en cause le diagnostic effectué,
il n'est pas nécessaire, lorsqu'on examine son dossier, de revenir sur les
antécédents, sur les crises ou sur le type d'épilepsie; en revanche, les
informations permettant d'apprécier l'effet de la thérapeutique sur la
sémiologie des crises sont intéressantes. De même, si l'épileptologue cherche à
remettre en cause la thérapeutique, certains antécédents et en particulier les
réactions d'intolérances médicamenteuses deviennent importants. Cette
synthèse peut donc être globale ou orientée par un objectif comme l'aide au
diagnostic ou l'aide à la thérapeutique. Le système pourra également aider le
médecin à planifier le suivi du malade, en dehors du cadre d'une consultation,
en établissant par exemple un agenda pour les consultations futures.
1.2 - ORIGINALITE DE LA PROBLEMATIQUE
Le système que nous voulons réaliser diffère de la plupart des systèmes
d'intelligence artificielle appliquée à la médecine. Un grand nombre de ces
systèmes s'attaquent au problème du diagnostic médical. Notre système quant à
lui, doit intégrer plusieurs fonctionnalités telles que le diagnostic, la
thérapeutique et le suivi permanent du patient. Son rôle ne consiste pas à
donner une solution (même approximative) au problème que lui pose le
médecin, mais à fournir les informations contenues dans le dossier ou
déductibles à partir de celui-ci, et qui peuvent contribuer à justifier, ou à
sugérer la solution du problème posé.
D'autre part, le compte-rendu de consultation étant généralement rédigé en
langage naturel, nous avons étudié le problème de l'analyse de ce
compte-rendu, en vu d'en produire une représentation sémantique. Cet aspect
de notre travail se rapproche des problèmes abordés dans [DEGO 84], [ZWEI
85],[FRIED 87], [SAGE 87]. Ces travaux s'attaquent à la compréhension de texte.
". l'O- ....-
médicaux mais, s'interessent plus à leur caractéristiques linguistiques qu'à la
possibilité d'en faire le résumé.

---

7
Le système Patrec [MITT 84] aborde le problème de la représentation du dossier
médical en vue d'en faciliter la saisie et l'accès; c'est celui dont les objectifs se
rapprochent le plus de ceux fixés ici.
1.3 - TRAVAIL REALISE
Pour être complet et autonome, le système que nous proposons doit analyser
les comptes-rendus de consultation et en donner une représentation à parir de
laquelle, sera réalisée la synthèse du dossier. Le travail réalisé comporte deux
parties:
- la définition d'un formalisme de représentation des connaissances du
domaine médical et la description des mécanismes susceptibles d'être mis
en oeuvre à partir de ce formalisme pour réaliser la synthèse du dossier;
- l'analyse d'un compte-rendu de consultation rédigé en langage naturel,
pour en produire une représentation dans le formalisme défini.
1.3.1
- Représentation des connaissances
Le formalisme que nous avons défini pour la représentation du dossier d'un
malade tient compte des impératifs suivants:
- la nécessité de manipuler avec aisance un dossier incomplet. Le formalisme
utilisé doit donc être modulaire, permettre une description autant que possible
autonome des entités du domaine, et une constitution incrémentale du dossier;
- la nécessité de prendre en compte des informations
incomplètes
et
approximatives,
- la nécessité de réaliser des inférences sur les informations représentées. En
effet, il est souhaitable d'éviter les recours inutiles aux sources extérieures
qui sont éparses et peu fiables. Les outils utilisés pour les inférences peuvent
en outre contribuer à donner une représentation exhaustive des entités
figurant en plusieurs exemplaires dans le dossier, en calculant
une
représentation synthétique à partir des différents exemplaires.

---

8
- fa nécessité d'intégrer au système plusieurs fonctionnalités telles que l'aide
au diagnostic, l'aide à la thérapeutique ou la constitution d'un agenda de
consultations.
Le formalisme proposé est un formalisme qui utilise la notion d'objet pour
la description des entités, une combinaison d'appariement structurel et
d'attachements procéduraux pour les inférences.
Le formalisme objet a été choisi pour les avantages qu'il offre dans le cadre
de la structuration des entités décrites et le naturel des descriptions qui en
découlent. En outre, pour faire face au manque de normalisation généralement
observé dans la spécification de la dynamique des objets, nous avons introduit
la notion d'opérateur. Cette notion intègre les outils d'inférence utilisés, dans
une structure semblable à la composition HYPOTHESE => CONCLUSION qui
caractérise les règles de production.
Le formalisme que nous avons défini, a été mis en oeuvre dans une maquette
réalisée sur station Sun, à l'aide de Shirka, un système de représentation de
connaissances centrées objets.
1.3.2 -
Analyse du compte-rendu médical
Dans le dossier d'un malade en épilepsie, il n'est pas prudent de préjuger de
l'importance d'une information sans avoir fait un certain
nombre de
recoupements. Les reformulations ou
les formattages systématiques peuvent
être préjudiciables à la transmission des informations acquises. Ce risque est
par ailleur accru par la diversité des intervenants (médecin traitant, médecin
consultant, sécrétaires chargées de la saisie, entourage du malade ...) dans la
constitution et le traitement du dossier. Pour toutes ces raisons, il est
souhaitable de garder le compte-rendu de consultation en langage naturel ou en
style télégraphique pour certaines parties. Le problème abordé dans la
deuxième partie de ce travail, est celui de l'analyse d'un compte-rendu
médical, en vue d'en produire une représentation dans le formalisme évoq~.é.
-.!' - ....-
ci-dessus.

---

9
L'approche sugérée consiste à considérer l'ensemble des concepts définis
par l'expert comme une spécification du sous-langage de formulation du
compte-rendu de consultation. Cette approche s'apparente à celle des
grammaires casuelles. En effet, si on considère que le but de l'analyse est
d'identifier les instances de concept décrites dans le texte, ces concepts peuvent
être vus comme des "gouverneurs" et leurs attributs comme des "cas" qui s'y
rattachent.
Nous préconisons l'utilisation d'un analyseur à démons pour l'analyse du
compte-rendu de consultation, car, les analyseurs à démons peuvent être
utilisés sur un texte dont les contraintes syntaxiques n'ont pas été formulées.
Leur utilisation permet de préserver la liberté dont le médecin a besoin dans la
formulation du compte-rendu de consultation.
1.4 - ORGANISATION DE LA THESE
Ce document comporte deux parties. Dans la première partie, nous
présentons le formalisme que nous avons défini pour la représentation des
connaissances, ainsi que son implémentation en Shirka. La deuxième partie est
consacrée à l'analyse d'un compte-rendu médical. Chacune des deux parties
commence par une étude bibliographique destinée à éclairer les choix effectués.
- f ... ·- _.-

---

1 0
2.1
- INTRODUCTION
Du point de vue historique, les premiers
représentation des connaissances sont les formalismes procéduraux. Ils sont
fondés sur le principe que la connaissance dans un domaine est donnée dès lors
que l'on sait comment se servir de cette connaissance. En fait, dans ces
formalismes, l'expression de la solution du problème que l'on veut résoudre est
plus influencée par l'architecture de la machine de Von Neuman que par la
nature des problèmes abordés; les connaissances et les inférences exprimées
en sont trop dépendantes et manquent de généralité.
Sur la base de cette constatation, Mc Dermott [DERM 87] formule le critère
d'évaluation d'un bon formalisme de représentation des connaissances, comme
étant la possibilité de représenter les connaissances et les inférences
indépendamment des problèmes particuliers. Les formalismes basés sur ce
principe se caractérisent d'un part, par leur affranchissement de toute
structure de machine, et d'autre part, par le fait qu'ils visent l'axiomatisation
d'un
domaine et non pas la formulation de la solution d'un problème
particulier. Ce sont des formalismes dits déclaratifs. Ils peuvent être divisés
en deux groupes:
- les formalismes relationnels qui reposent sur une base formelle solide,
inspirée de la logique. Leur utilisation se fonde sur l'hypothèse qu'une partie
importante du processus de raisonnement est de nature déductive, ce qui
d'après Mc Dermott [DERM 87] n'est pas le cas.
- Les formalismes objectaux qui constituent la forme la plus évoluée de
l'amélioration de la notion de type dans les langages de programmation. A
l'inverse des formalismes relationnels ils ne possèdent pas de base formelle
très rigoureuse. mais permettent de constituer facilement
un environnement
... !"
.
d'objets structurés basé sur le principe de aénéricité. '

---

1 1
Dans un tel environnement, on peut définir facilement des opérations
propres à une classe d'entités; de plus, en utilisant l'appariement structurel,
on peut modéliser aisément certaines formes de raisonnement non déductifs.
Dans ce chapitre, nous analysons les principaux formalismes ou modèles de
représentation des connaissances. La trame de l'analyse réside dans la dualité
procédural-déclaratif d'une part, et la dualité relationnel-objectal d'autre
part. Pour chacun des formalismes présentés, nous nous appliquons à montrer
dans quelle mesure, il répond aux impératifs que nous avons exposé au
paragraphe 1.3.1. Nous essayons de dégager de cette analyse les" points
suivants:
- la solidité de la base formelle du modèle, car elle constitue une garantie de
rigueur dans l'expression et la mise en oeuvre;
- le caractère déclaratif du formalisme, car il conditionne ('indépendance des
connaissances spécifiées par rapport à un problème particulier et détermine
donc son expressivité;
- la capacité du formalisme à représenter des informations incomplètes ou
approximatives:
- la possibilité de structurer les entités du domaine. En plus de l'expressivité
des spécifications obtenues, la structuration permet de définir des opérations
propres aux différentes entités, facilitant ainsi l'intégration de plusieurs
fonctionnalités dans un système et contribue à l'expression de raisonnements
non déductifs.
Dans la suite de ce chapitre, nous examinons successivement la logique, les
règles de production, le modèle des réseaux sémantiques, et les formalismes
basés sur la notion d'objet.
2.2 - LOGIQUE
La logique classique rSMUL 68] est un système formel composé d'un langage,
d'un ensemble d'axiomes et d'un ensemble de règles d'inférence. Les axiomes
sont exprimés en terme de propositions ou de prédicats, et l'inférence est basée
sur le modus ponens, le modus tollens et la règle de spécialisation.

---

1 2
Les formalismes fondés sur la logique disposent d'une base théorique solide.
Leur sémantique dénotationnelle est claire et indépendante de toute structure de
machine. Ils font une nette distinction entre la définition d'un problème et la
formalisation du raisonnement, évitant la confusion observée dans les
formalismes procéduraux, entre l'axiomatisation et les inférences. Cependant,
ils présentent quelques carences quant à leur utilisation en représentation des
connaissances. On peut citer par exemple:
- la difficulté à exprimer un raisonnement non déductif; un schéma de
raisonnement par généralisation inductive est difficilement exprimable à
partir du modus ponens ou du modus tollens.
- La
difficulté à
exprimer des
raisonnements
dans
un
contexte
d'informations incomplètes ou
approximatives; le raisonnement en logique se
fonde sur un ensemble d'axiomes considérés comme vrais. "Or dans la vie
courante, face à la limitation de nos connaissances, nous tirons souvent des
conclusions sans preuve rigoureuse, à partir de faits considérés comme
plausibles" [BONNET 86].
- La structuration des entités est frustre et non expressive. Les outils
offerts pour la spécification servent pour l'essentiel à décrire des propriétés
d'entités (ou des relations entre les entités) qui sont utiles au mécanisme
d'inférence, sans qu'il y ait une description intrinsèque et complète de ces
entités.
Dans Prolog par exemple, la seule structure de donnée utilisée est la
structure d'arbre. Quel que soit l'objet que l'on cherche à manipuler, cet objet
doit se fondre dans cette structure, l'essentiel étant d'exprimer les relations
nécessaires aux inférences. Cette spécification diffuse des entités est très peu
expressive. D'autre part, les entités n'étant pas explicitement définies, la
possibilité de définir des opérations propres à une classe d'entités est
relativement restreinte.

---

1 3
Les
efforts
pour
remédier aux
carences
de
la
représentation
des
connaissances en logique, ont amené à proposer des formes de logiques non
classiques ( logiques intuitionistes, logiques modales, logiques multivaluées...).
Chacune de ces formes de logique vise à pallier un défaut précis de la logique
classique. Par exemple, les logiques modales visent à mieux formaliser
l'implication. En autorisant des formes de déduction nuancées, elles rendent
l'implication plus conformes à notre intuition. La notion de vérité y est relative
(à la personne, à l'instant...). Les logiques multivaluées visent à définir des
valeurs de vérité plus élaborées que la simple dualité vrai/faux. Certains auteurs
ont proposé des formes de logiques typées pour résoudre le problème de la
structuration des entités; cette structuration reste cependant élémentaire.
2.3 - REGLES DE PRODUCTION
Les règles de production [LAURI 82] [FARR 84], permettent de formaliser un
raisonnement suivant le schéma HYPOTHESE => CONCLUSION. Elles émanent de la
logique formelle dont elles conservent le schéma d'inférence basé sur le modus
ponens, le modus tollens, et la séparation entre les axiomes(les faits) et les
règles d'inférence. L'émergence des règles de production en intelligence
artificielle est dûe à la nécessité de rapprocher les schémas d'inférence logique du
raisonnement de bon sens. Les principales améliorations portent sur les deux
points suivants:
a) Les assertions peuvent être pondérées par des coefficients de vraisemblance.
Ceci permet par l'utilisation de connaissances incertaines et des faits non avérés,
de pallier la limitation de nos connaissances.
b) Les règles de production peuvent s'appliquer en "chaînage avant", "chaînage
arrière" et "chaînage mixte". Elle permettent ainsi d'exprimer des raisonnements
à la fois complexes et naturels.
-."'-' _.-

---

14
Les règles de production ont connu dans le domaine des systèmes experts, un
succès qui est surtout dû à leur format très simple et à leur modularité. Elles
permettent par leur intégration du schéma d'implication, de simuler les
déductions et les raisonnements logiques. Elles permettent également par l'usage
des coefficients de plausibilité et de règles heuristiques, de simuler les
perceptions et les prises de décision subjectives.
Malheureusement, la sémantique des règles de production est moins claire
que celle de la logique. Par exemple les coefficients de vraisemblance ne possèdent
pas d'axiomatisation rigoureuse. De plus, comme pour la logique, il manque aux
règles de production les possibilités d'une bonne description symbolique des
objets manipulés.
D'après Ph. Vignard [VIGN 85]. "dans les systèmes à base de règles de
production, l'objet modèle n'existe pas. Les objets ne sont décrits qu'à travers des
propriétés disséminées dans les règles de production". Bien que permettant
d'exprimer facilement des actes de calcul précis, les règles de production ne sont
pas universellement compréhensibles, et ne peuvent pas se replacer d'elles
mêmes dans un contexte d'interprétation plus large que leurs prémisses. Dans le
système MYCIN [SHORT 76], par exemple, la notion d'arbre de contexte semble
avoir été motivée par la nécéssité de pallier ce manque.
2.4 - RESEAUX SEMANTIQUES
Les réseaux sémantiques [aUILL 68], [HAYES 81] peuvent être considérés
comme des modèles de mémoire associative. Sur le plan technique, ce sont des
graphes dont les noeuds représentent des concepts, et les arcs, les relations entre
ces concepts. Chaque concept peut être relié à une famille à laquelle il appartient.
Ce type de liaison (arc sorte-de) a été repris dans les formalismes objectaux
pour exprimer la relation de hiérarchie entre les classes. Certains noeuds
peuvent être complexes et représenter des sous-réseaux.
Exemple
-/".- .-.-
Si on cherche à représenter le fait que "monsieur Chazal souffre d'une
épilepsie sensible à la dépakine", on peut utiliser le réseau ci-dessous:

---

1 5
sorte-de
sorte-de
orte-de
Chazal
souffre-de
Dans les réseaux sémantiques, le raisonnement est représenté par une table de
composition des relations. Par exemple R3 = R1 0 R2 exprime le fait que si deux
concepts C1 et C2 sont reliés par la relation R1, et les concepts C2 et C3 reliés
par la relation R2, alors C1 et C3 sont implicitement reliés par la relation R3.
Dans l'exemple ci-dessus, si l'on fait abstraction des effets secondaires et des
réactions d'intolérance médicamenteuse, on a la composition suivante:
SOIGNE-PAR = SENSIBLE-A 0 SOUFFRE-DE
Les réseaux sémantiques peuvent également être utilisés pour la recherche
d'informations. Etant donné des connaissances représentées sous forme de réseaux
sémantiques, on peut chercher à obtenir des réponses à des questions portant sur
ces connaissances. On construit alors un réseau représentant la question et une
comparaison structurelle de graphe permet de répondre à la question.
En considérant l'exemple ci-dessus, si on cherche à répondre à la question
"Que peut-on prescrire à monsieur Chazal?", le graphe représentant la question.
peut se présenter comme suit:

---

1 6
médicament
sorte-de
sorte-de
orte-de
Chazal
souffre-de
sensible-à
épilepsie
X?
Une comparaison avec le réseau précédent permettra de répondre "X = dépakine".
L'inconvénient majeur des réseaux sémantiques réside dans le fait que Les
travaux ont davantage porté sur la réalisation d'applications pratiques, que sur la
normalisation et la cohérence de la représentation. L'utilisation des réseaux
sémantiques se heurte à un manque de normalisation et à l'absence de sémantique
précise et non ambigüe, notamment quant aux caractéristiques de ce qu'on peut
représenter sur les arcs.
2.5 - REPRESENTATIONS OBJECTALES
2.5.1
- Introduction
La représentation de la connaissance en objets structurés est née de la
conjonction d'idées de sources différentes dont la plus connue, est celle des
FRAMES [MINSK 75]. Celle-ci part du principe que nous avons en mémoire des
structures stéréotypées d'informations, et que nous sélectionnons chaque fois
qu'une situation nouvelle se présente, un de ces stéréotypes en tentant de le faire
coïncider avec la situation courante. Ces stéréotypes sont généralement spécifiés
par des formalismes de représentation centrée objet (R.C.O)[FIKES 85], [RECH 83].
Ces formalismes rejoignent en certains points les langages orientés objets (L.O.O.)
-.!"- .....-
[BAIL 87], [BEN 85], [COINTE 83] dont les langages d'acteurs [HEW 77] constituent
un sous-groupe particulier. Les L.O.O dérivent de la notion de type dans les
langages de programmation alors que les acteurs ont pour origine la modélisation
des problèmes de simulation.

---

1 7
Malgré leurs différences d'origine et les nuances d'implémentation, les
formalismes basés sur la notion d'objet adoptent tous, une approche similaire en
ce
qui concerne
la structuration
des entités (à partir d'attributs),
leur
organisation en classe et le principe d'héritage. Par contre, l'aspect dynamique
des objets fait apparaître deux approches différentes. Dans les L.o.o., la
dynamique des objets est exprimée à l'aide de messages, qui peuvent être
considérés comme des opérations agissant sur l'objet en tant qu'entité atomique.
Leur sémantique est spécifiée à l'aide de méthodes. Dans les R.C.O., la dynamique
des objets est exprimée à l'aide d'attachements procéduraux, qui servent très
souvent à compléter la description des attributs.
Dans ce chapitre, après une présentation des concepts de base de la
représentation objectale, nous analysons les avantages et les inconvénients de ce
type de représentation.
2.5.2 - Concepts de base
a) Notion d'objet
Un objet [FERB 88] est un assemblage structuré de toutes les caractéristiques
se rapportant à un élément conceptuel. La spécification de cet assemblage se fait
d'une part, par des attributs pour sa partie statique, et d'autre part, par des
méthodes et des attachements procéduraux pour sa partie dynamique. Ces
caractéristiques peuvent être encapsulées dans une boîte noire (type abstrait)
comme dans les L.O.O., ou être un regroupement transparent comme les
stéréotypes définis dans les R.C.O.. Dans les L.O.O. et les R.C.O , les objets sont des
entités statiques, alors que dans les langages d'acteurs [HEW 77], ce sont des
entités dynamiques assimilables à des processus. L'ensemble des objets d'un
domaine est généralement organisé dans une structure hiérarchique formant un
treillis de classes qui se transmettent des informations par le mécanisme
d'héritage. Selon les systèmes, la dynamique des objets est contrôlée soit par
l'envoi de message, soit par des attachements procéduraux.

---

1 8
b) Classe et instance
Une classe est un moule à partir duquel on fabrique des exemplaires. Les
exemplaires fabriqués à partir d'une classe sont les instances de cette classe. Dans
les L.O.O et les R.C.O., la relation entre la classe et l'instance est une relation
verticale, dominée par la classe. Dans les langages d'acteurs par contre, les
acteurs sont reliés entre eux par une relation horizontale. Un acteur se duplique
pour former un autre acteur, le nouvel acteur ayant le statut et toutes les
potentialités de l'acteur qui "a créé. Dans les langages d'acteurs, la
notion
d'intanciation est très proche de la notion d'héritage.
c) Méta - Classe
Par souci d'uniformisation (rendre les classes instances des méta-classes,
de la même manière que les objets sont instances des classes), certains modèles
introduisent la notion de méta-classe [BRIOT 85], [BAIL 87]. Une méta-classe est
une classe dont les autres classes sont des instances.
L'intérêt de la notion de méta-classe est essentiellement théorique. Comme il
est démontré dans [BAIL 87], elle est implicite et virtuelle. Elle est souvent
implicite, car elle n'est pas explicitement créée par l'utilisateur, mais induite
par les classes qui lui appartiennent. Elle est également virtuelle, car elle n'est
pas accessible à "utilisateur.
d) Héritage
L'héritage, est le mécanisme par lequel une classe transmet des informations
à ses sous-classes ou à ses instances. Les informations transmises sont les
attributs et les méthodes.
L'héritage peut être simple ou multiple. Dans le cas d'un héritage multiple,
une sous-classe hérite de plusieurs super-classes. L'héritage multiple ne pose
aucun problème si les ensembles d'attributs ou de méthodes des super-classes de
la classe qui hérite sont disjoints deux à deux. Cette classe hérite alors de l'uniQI1
.... ...-
",.-
des informations contenues dans ses super-classes. Si tel' n'est pas le cas, il y a
alors conflit d'héritages.

---

1 9
Le conflit d'héritage apparaît lorsqu'une classe a plusieurs super-classes
comportant des informations incompatibles, (méthodes ou attributs de même nom,
mais de spécifications différentes, ou des contraintes contradictoires). Résoudre
ce conflit, revient à déterminer les informations dont il faut hériter. Ce problème
est abordé de manières différentes suivant les systèmes:
- la plupart des systèmes font un choix arbitraire, introduisant ainsi une part de
flou dans la sémantique du formalisme;
- d'autres systèmes, comme KEE [STEFIK 79] et ACT1 [HEW 77] utilisent des
opérateurs d'héritage. Ces opérateurs permettent par exemple, de spécifier selon
les circonstances s'il faut prendre la différence des informations contenues dans
les super-classes ou au contraire les informations communes à toutes les
super-classes.
- Dans OBJLOG enfin, le problème d'héritage est réglé de manière très originale à
l'aide de la notion de point de vue [DUGER 87]. Elle part de la constatation que le
mécanisme d'héritage généralement offert, a des résultats dépendant de
l'organisation des super-classes de la classe qui cherche à hériter de
l'information. Or, cette organisation évolue au fur et à mesure des ajouts ou
retraits de classe dans le système. Le résultat de l'héritage est donc aléatoire. La
solution adoptée consiste à éviter les déclarations qui créent des conflits. Chaque
attribut est spécifié de sorte qu'à l'aide de l'unification sémantique [DUGER 88], on
détermine la super-classe d'où elle hérite des informations. Ainsi un objet peut
avoir plusieurs super-classes,
mais
l'héritage
est
spécifié
de
manière
déterministe.

---

20
2.5.3 - Dynamique des
représentations objectales.
Le traitement de la dynamique des objets varie suivant les systèmes. Il peut
être fait par des attachements procéduraux ou par des méthodes; suivant le cas, le
modèle peut être classé comme L.O.O. ou comme R.C.O.
2.5.3.1 - R.C.O.
et
attachements
procédu raux
Les R.C.O. découlent directement de la notion de FRAME. Toutes les primitives
offertes servent à étoffer la description du stéréotype. Il n'y a pas comme dans les
L.O.O, une division de l'objet en liste d'attributs et liste de méthodes. Les
procédures sont directement attachées aux attributs et servent à compléter leur
description. Ce rattachement se fait à ('aide des facettes. L'objet, tel qu'il est
décrit, est une entité passive. Il est généralement utilisé par un mécanisme de
filtrage, global au système. Le filtrage est une forme d'appariement structurel; à
partir d'un filtre représentant un ensemble de conditions, il germet de retrouver
}hllli!Rcbe
les instances d'objets compatibles au filtre.
\\~ <:,....
.boQ
'l>
/'
....\\.>
/)
./..
...;.
"/1)
~
T
"PI
.•
-::::
C , ) - /
'"'
~
0
.....JI
0"
.;;;
r c
."
<9
:l
~
V
.<,
"<\\>
-
2.5.3.2 - L.O.O, méthodes et messages.
'..l
?]
c/
'J/
.
(
' /0.,
<::-"
f
,0
Dans les L.O.O., la dynamique des objets est exprim èZl2,ar ~Ie'~~~ssages et les
méthodes. Les méthodes sont activées par l'envoi de message. Lorsqu'un objet
reçoit un message, il exécute la méthode ayant le même identificateur que le
message reçu. Si on considère l'objet comme un type abstrait, un message peut
être vu comme un opérateur servant à manipuler l'objet, la sémantique de cet
opérateur étant spécifiée par la méthode correspondante. La méthode agit sur
l'objet en tant qu'entité atomique et n'est donc pas rattachée à un attribut
particulier comme dans les R.C.O. En revanche, la description des attributs est
très pauvre. Ce sont en général de simples variables locales.

---

21
2.5.3.3 - Evolution de la distinction entre L.O.O. et R.C.O.
Dans les L.O.O. la présentation d'un objet comme un type abstrait, sur lequel
on peut appliquer les opérateurs que sont les messages, semble plus cohérente et
plus facile à formaliser que la notion de stéréotype décrite dans les RC.O. En
revanche, la pauvreté de la description des attributs dans les L.O.O. (les attributs
sont de simples variables locales) rend leur utilisation en représentation des
connaissances très difficile.
D'autre part, on peut constater que parmi les facettes rattachées à un
attribut dans les RC.O., certaines s'apparentent plus à des opérateurs qu'à des
outils de description. S'il est tout à fait naturel de considérer qu'une contrainte
d'intégrité (généralement exprimée comme attachement procédural)
sert
effectivement à compléter la description d'un attribut ou d'un objet, une facette de
visualisation s'apparente par contre beaucoup plus à un opérateur servant à
manipuler une instance déjà créée, qu'à un outil de description du modèle. Ainsi,
en s'inspirant des R.C.O. on peut attacher des facettes aux attributs d'un objet tel
qu'il est défini dans les L.O.O. pour compléter sa description, et définir en même
temps des opérateurs. Le filtrage peut dans ce cas être aussi formuler comme un
opérateur.
En fait, certains formalismes tentent de combiner les avantages des L.O.O. et
ceux des RC.O.. Le procédé généralement suivi consiste à modifier un L.O.O. pour
lui permettre de prendre en compte les attachements procéduraux. Ainsi dans
Loops [BOBR 83], on tente de considérer certaines variables comme des valeurs
actives. Dans Mering [FERB 83], on considère que les attributs sont des objets à
part entière, permettant ainsi d'assimiler la notion de message à celle
d'attachement procédural.
2.5.4 - Avantages de la représentation objectale
Le principal avantage des représentations objectales, vient des outils qu'elles
,
offrent pour la structuration des entités du domaine à formaliser. Ces outils se
fondent sur les principes de généricité et de modularité. La définition
(en terme
de classes) du modèle des objets à formaliser, permet d'éviter le défaut de
description évoqué dans les formalismes relationnels.

---

22
La modularité se traduit ici par la répartition de la spécification du système
dans des objets; elle permet d'envisager une spécification incrémentale.
L'inférence n'est plus basée uniquement sur l'implication logique; de plus on
distingue les éléments d'inférence structurelle (héritage et valeurs par défaut),
des éléments d'inférence opératoire (attachements procéduraux, méthodes,
filtrage).
2.5.5 - Inconvénients de la
représentation
objectale
L'utilisation des formalismes objectaux pose des problèmes dûs à la faiblesse
de formalisation et de normalisation de la notion d'objet. Par ailleurs, comme
nous l'avons déjà souligné, le traitement des éléments procéduraux est abordé de
manière différente suivant les systèmes, et les conflits d'héritage sont parfois
résolus par des méthodes donnant des résultats aléatoires.
Cette faiblesse de normalisation entraîne naturellement des problèmes
d'interprétation. En effet, à part Smalltalk, qui dispose d'une machine virtuelle,
tous les autres systèmes basés sur la notion d'objet sont des systèmes hybrides. Ce
sont pour la plupart des extensions objectales d'un langage hôte.
-."" - _..-

---

23
2.6 - QUELQUES SYSTEMES INTEGRANT REGLES ET OBJETS
Dans ce paragraphe, nous illustrons la complémentarité des formalismes
objectaux et des règles de production par la présentation de quelques systèmes
utilisant un formalisme mixte. Signalons que le cas de Mycin [SHORT 76]
présenté au paragraphe 2.6.1 est très particulier:
bien que la notion d'objet
n'y soit pas explicitement définie, la notion de contexte qu'il utilise s'y
apparente. Ce cas illustre la difficulté de résoudre un problème réel en
utilisant exclusivement les règles de production.
2.6.1 - Mycin
intégration implicite des règles et des objets
Dans la représentation des connaissances à l'aide des règles de
production, se pose le problème de la distinction entre la connaissance
experte et le contexte d'utilisation de cette connaissance [AIKINS 79]. Ce
problème a été implicitement résolu dans Mycin par la définition de la notion
de contexte et d'arbre des contextes. L'arbre des contextes constitue la trame
du raisonnement du système. Dans ce paragraphe, nous présentons la
définition et l'utilisation des contextes dans Mycin en montrant le lien avec la
notion d'objet.
2.6.1.1
- Notion de contexte
Dans Mycin, la prise de décision fait intervenir, outre les attributs du
patient, des entités telles que la culture qui a été réalisée, les organismes
identifiés et les médicaments prescrits. Chacune de ces entités se définit
comme un contexte. Chacun de ces contextes peut être instancié une ou
plusieurs fois lors d'une consultation. L'ensemble des contextes instanciés est
organisé dans une structure formant l'arbre des contextes. Cet arbre peut
être représenté comme suit:

---

24
patient-1
(personne)
/ culture-1 ......
/
culture-2
cu Itu re-3
(culture)
(culture)
(culture)
'-
~
l'
organisme-1
organisme-2
organisme-3
(org. courant)
(org. courant
org. courant)
médicament-1
médicament-1
(médicament)
(médicament)
L'arbre des contextes joue deux rôles fondamentaux dans Mycin :
a) Il sert à spécifier les relations entre les différentes instances de contexte.
Si on considère par exemple "arbre des contextes ci-dessus, la liaison entre
organisme-1
et culture-1, permet de spécifier que organisme-1
a été
identifié dans culture-1.
b) Il sert également à décrire la structure du problème à résoudre. L'arbre
des contextes ci-dessus a pour racine une instance du contexte personne; à la
profondeur 1 de l'arbre, on trouve des instances du contexte culture; à la
profondeur 2, des instances du contexte organisme et à la profondeur 3, des
instances du contexte médicament.
Ceci traduit le fait que pour une
consultation quelconque, on commence par identifier le patient qui est une
instance du contexte personne, puis on développe des cultures à partir des
prélèvements réalisés sur le patient, ensuite on identifie
les organismes
présents dans ces cultures, et enfin on prescrit des médicaments pour les
organismes identifiés.

---

25
Il existe un seul modèle d'arbre de contexte dans Mycin. L'exemple
ci-dessus en est une instance. A chaque étape. le rôle du système est donc
avant tout, d'instancier ces contextes suivant un ordre de précédence fixé par
avance dans J'arbre des contextes. Les règles de production sont utilisées à
chacune de ces étapes pour exprimer la sémantique de cette instanciation.
2.6.1.2 - Regroupement des règles dans les contextes
Les règles de Mycin sont regroupées par contexte. Chaque règle est
associée à un contexte et participe à son instanciation. Ainsi, les classes de
règles suivantes font partie de celles définies dans Mycin.
REGLE-CULT: règles qui peuvent être appliquées à une culture quelconque;
REGLE-CULT-COUR : règles qui peuvent être appliquées à la culture courante;
REGLE-ORG : règles qui peuvent être appliquées à un organisme quelconque;
(culture et organisme sont des contextes)
Par exemple. la règle suivante appartient à la classe REGLE-ORG :
SI
1) le site de culture est l'oesophage
2) l'identité de l'organisme est streptococcus
ALORS il Y a une évidence suggestive (0.8) que le sous-type de l'organisme
est groupe-O.
Cette règle peut être appliquée sur un organisme quelconque. Elle ne sera
jamais activée avant que le patient n'ait été identifié et que les cultures
réalisées
sur
le
patient n'aient été
décrites.
Par contre.
elle
est
potentiellement activable dès qu'on cherche à identifier un organisme,
c'est-à-dire dès que l'on cherche à instancier le contexte organisme. La
plupart des règles de Mycin peuvent être vues comme des primitives
exprimant la sémantique de l'opération d'instanciation du contexte auquel
elles sont attachées.

---

26
2.6.1.3 - Contexte
et
objet
Les contextes sont des entités regroupant des informations formant une
unité dans le domaine médical. Chaque contexte est décrit par un ensemble de
paramètres cliniques qui le caractérisent. Ainsi le contexte organisme peut
être caractérisé comme suit :
ORGANISME
- identité
- morphologie
- mode de développement
- coloration
Chaque paramètre clinique est spécifié par un ensemble de descripteurs
qui sont les primitives du système. Ainsi, le paramètre identité du contexte
organisme, est spécifié par les descripteurs suivants :
IDENTITE
- catégorie : un organisme
- domaine : parmi (organisme)
- condition pour: <liste de règles>
ce sont les règles qui référencent identité dans leur prémisses
- modifié par :<liste de règles>
- manipulé par <liste de règles>
- laboratoire : oui/non
Etant donné cette définition de la notion de contexte, on peut établir entre
les contextes et les objets tels qu'ils sont définis dans les R.C.O (cf § 2.5.3.1)
la correspondance suivante:
MYCIN
R.C.O.
contexte
objet
... / .. - ....-
paramètre clinique
attribut
descripteur
facette

---

27
Par rapport aux R.C.o., on peut relever sur la définition et l'utilisation des
contextes dans Mycin, les inconvénients suivants:
- il n'y a pas de regroupement syntaxique de la spécification des contextes, ce
qui rend ces derniers moins expressifs;
- en définissant explicitement les contextes comme étant des objets, on
pourrait leur associer des messages pour faciliter leur gestion;
- la représentation de l'arbre des contextes comme un regroupement d'objets,
permettrait d'en utiliser plusieurs modèles; or Mycin en a un seul, ce qui le
rend moins flexible.
En définitive, le fait que les contextes de Mycin ne soient pas
explicitement définis comme étant des objets dissipe leur rôle, et pénalise la
représentation des connaissances et la structure de contrôle du système.
2.6.2 - K 0 0 1
KOOL
(Knowledge Oriented Object Language) [ALBERT 83] est un
environnement de programmation destiné à l'écriture de systèmes experts. La
représentation des connaissances y intègre la notion d'objet et celle de règle
de production. Dans ce paragraphe, nous donnons un aperçu de la spécification
et de l'utilisation des connaissances dans Koo!.
2.6.2.1
- Les
objets
Kooi est basé sur le principe de modélisation du domaine par création de
hiérarchies de classes, puis réalisation d'une session particulière par
instanciation de ces classes. Un objet Kooi est défini parles traits suivants :
- sa classe,
- un ensemble d'attributs,
- un ensemble de comportements.

---

28
Les attributs peuvent être des propriétés ou des relations. Une propriété
est un attribut auquel est associé une valeur unique. Une relation est un
attribut pouvant relier l'objet auquel il est associé, à plusieurs objets du
système. Un attribut est spécifié par des descripteurs d'attribut, qu'on peut
assimiler à des facettes. Ils servent notamment à préciser le type, la valeur
initiale, la valeur par défaut, et la manière de calculer en cas de besoin, la
valeur de l'attribut. Les objets peuvent également répondre à des messages.
L'envoi de message dans Kooi est une extension de l'invocation de fonction.
2.6.2.2 -
Les
règles
Les règles sont des objets instances de la classe GENERALRULE. Cette classe
est composée des sous-classes suivantes:
- Rule+ : classe des règles utilisées en chaînage avant,
- Rule- : classe des règles utilisées en chaînage arrière,
- Rule : classe des règles utilisées en chaînage mixte.
Une règle en tant qu'objet peut répondre aux messages suivants:
- write, qui imprime la règle sur le support de sortie courant;
- edit, qui édite le corps de la règle;
- kill,
qui supprime la règle;
- trace,
qui trace la règle;
- Newsession, qui réinitialise les informations relatives à un déclenchement
particulier de la règle.
L'utilisation explicite de la notion d'objet dans le système, donne la
possibilité de modéliser les règles sous forme d'objet, ce qui rend leur
gestion plus rigoureuse, car les opérations utilisées à cet effet sont
exprimées sous forme de méthodes et de messages associés aux règles.

---

29
2.6.2.3 - Intégration des règles et des objets
Les règles sont généralement attachées aux attributs d'un objet, et
interviennent lors de l'évaluation de ces attributs; par exemple, pour un
objet OBJ 1 ayant les attributs attO et att1 avec les règles R1, R2, R3, R4, RS,
on peut avoir les associations suivantes:
OBJ1
attO :
nil
to-fil 1
(R1,
R2)
att1:
ni 1
to-fill (R3, R4, RS)
(ni! traduit le fait qu'il n'y pas de valeur initiale)
R 1 et R2 seront utilisées pour calculer la valeur de attO; R3, R4 et R S
seront utilisées pour calculer la valeur de att1.
L'interprétation opérationnelle des règles peut être réalisée par des
démons. Ils invoquent la règle (en chaînage avant) lorsqu'une référence citée
dans la règle prend une valeur. Ainsi, si on considère la règle suivante:
[rule+ : R01
IF I*child:age GT 18
*subjectchildren = *child
THEN *subject:mod <-- sad.
Une reférence à *subject:children entraîne le déclenchement de la règle
ci-dessus. Ce n'est pas le cas pour *child:âge car le symbole "/" permet de
spécifier qu'on n'utilisera pas une reférence comme déclencheur. On peut
également lancer le système en chaînage arrière pour le calcul d'un attribut
d'un objet donné en utilisant le message til/-aft ou le message til/ défini dans
la classe abject. et qui tente de déduire tous les attributs d'un objet.

---

30
2.6.3
-
Classic
et
y sont représentées
2.6.3.1
Prototypes et arbre des prototypes
Un prototype est un type structuré dont les champs peuvent
intervalle, un ensemble, ou un prototype.
Par exemple, pour décrire un individu, on peut définir le prototype
physique avec les attributs taille, yeux, cheveux, stature. Les champs d'un
prototype sont décrits par les facettes nom, type, valeur-demandable,
valeur-par-défaut, commentaire, importance.
L'expert organise l'ensemble des prototypes en un arbre dont les noeuds
sont des prototypes tels que chaque fils soit sous-prototype de son père. Un
objet est une instance de prototype.
Classer un objet revient à chercher le ou les prototypes qui lui
correspondent le mieux dans l'arbre des prototypes. A partir du type
PHYSIQUE défini ci-dessus, on peut définir le type PYGMEE qui se distingue par
le fait que le champ stature a pour valeur "petite", et le type FOULBE qui se
distingue par le fait que le champ stature a pour valeur "grande". L'arbre des
prototypes aura alors la forme suivante:

---

31
2.6.3.2 -
Les
règles
Chaque règle est associée à une classe d'objets. Les règles sont utilisées
pour compléter la description d'un objet en cours de classement en calculant
la valeur de certains champs de l'objet à partir de la valeur d'autres champs.
Une règle est un objet possédant les champs suivants:
nom
: nom de la règle.
~
: prototype auquel est rattaché la règle,
s.1
: partie hypothèse de la règle,
a!.2r.s.
: partie conclusion de la règle.
exemple:
règle R1
nom
R1
~ physique
.s.l
taille < 160
.a..!.Q.r.s.
stature <- "petite"
Cette règle peut être utilisée pour compléter une instance de la classe
PHYSIQUE, et si cette règle est appliquée avec succès, l'instance de PHYSIQUE en
cours de classification pourra ensuite être déplacée de la classe PHYSIQUE vers
la sous-classe PYGMEE.
2.6.4
- Smeci
Smeci [llog 87b] est un générateur de systèmes experts en conception,
simulation, planification, et diagnostic. La connaissance y est définie en
termes de catégories, prototypes, objets, tâches et règles.
La structuration du système est faite en trois niveaux de la manière
suivante:

---

32
1 - une règle est associée à une ou plusieurs bases de règles;
2 - une base de règles est associée à une ou plusieurs tâches;
3 - une tâche représente l'un des objectifs du système expert.
2.6.4.1
Catégorie,
prototype et
objet
Une catégorie est une structure de donnée générique organisée en champs
dont chacun est défini par un ensemble de facettes. La notion de prototype
permet d'associer à chaque catégorie une hiérarchie de sous-classes de même
structure que la catégorie associée. Chaque noeud permet de définir les
méthodes ainsi que les domaines de valeur des champs. Un prototype
correspond à une catégorie à laquelle on a associé des méthodes et des
domaines de valeur d'attributs spécifiques. Un objet est une instance d'une
catégorie; la catégorie définit la structure de "objet.
Chaque objet est également associé à un prototype qui décrit ses champs
et les messages auxquels il peut répondre. La racine d'une arborescence de
classes est appelée catégorie, et l'ensemble des spécialisations de cette racine
constitue un prototype.
Les objets décrivent un environnement de raisonnement et sont utilisés
pour modéliser l'ensemble des objets référencés dans le problème à résoudre.
Les méthodes servent à définir des comportements typés.
2.6.4.2 -
Les règles
Les règles sont regroupées logiquement dans des bases de règles. Une
règle est considérée comme un objet possédant en plus des attributs prémisse
et conclusion, les attributs, nom, auteur, explication. application.
exemple:

---

33
~
llQill
: R01
auteur
: PA
explicalion:X devient majeur parce que son âge âge"X est supérieur à 18
fin explication
.s..QÜ
: X un humain
.sl
: X"âge > 18
a1QŒ
: X"majeur = oui
.aQ.Û..Q..O.
: $(print prenom"X "est majeur ")
fin rèale
Dans les autres systèmes que nous avons présentés, les règles sont
utilisées pour compléter la description des objets. Elles sont considérées
comme valeurs des facettes attachées aux attributs de ces objets. Dans Smeci
par contre, une règle rassemble des objets déjà spécifiés (valeurs de
l'attribut SOIT de la règle), pour constituer son contexte d'évaluation comme
si c'était les objets qui servaient à décrire les règles.
2.6.4.3 - Les tâches
Les tâches servent à modéliser le raisonnement du système. Une tâche
possède les champs suivants: base-de-règles, sous-tâche, succès, si-blocage
et importance. Le champ base-de-règles décrit l'action réalisée par la tâche.
Le champ sous-tâche sert à définir l'arbre des tâches du système expert. Une
sous-tâche peut être assimilée à une action non terminale susceptible d'être
décomposée en plusieurs actions terminales dont chacune est exécutable à
l'aide d'une base de règles.
- f'· ... -

---

34
2.7 - CONCLUSION
Les formalismes présentés se répartissent en deux groupes: les
formalismes relationnels et les formalismes objectaux. Un troisième groupe
de formalismes, les formalismes mixtes, tentent d'intégrer à la fois les
avantages des formalismes relationnels et ceux des formalismes objectaux.
Les formalismes relationnels ont émergé des formalismes procéduraux
par introduction des propriétés caractérisant la déclarativité. Leur base
théorique est souvent inspirée de la logique. Le formalisme des règles de
production en est le représentant le plus expressif. Du fait de leur
modularité, ce sont de bons outils de transfert d'expertise, bien que
présentant
quelques carences sur le plan de la structuration des entités du
domaine à formaliser.
Les formalismes objectaux ont des origines diverses mais, ont une
caractéristique commune essentielle, qui est d'offrir de nombreux outils
permettant la description générique, aussi bien sur le plan statique que
dynamique, des entités que l'on veut manipuler. L'absence d'une bonne base
théorique pose pour ces formalismes des problèmes de normalisation et
d'interprétation.
La représentation des connaissances s'oriente de plus en plus vers des
formalismes mixtes associant les règles de production aux représentations
objectales. Les formalismes mixtes visent à conjuguer les avantages de l'une
et l'autre représentation. La notion d'objet y est utilisée pour structurer les
informations. La connaissance que recouvre un objet est exprimée par un
ensemble d'attributs. Dans certains systèmes, les objets peuvent également
répondre à des messages, intégrant ainsi les R.C.O. et les L.O.O. Les règles sont
les actions élémentaires exécutables par le système. Elles sont généralement
regroupées (par contexte dans Mycin, par base de règles dans Smeci, par
paquets dans Kool) pour former des unités fonctionnelles.

---

35
L'utilisation explicite de la notion d'objet permet de représenter aussi
les règles sous forme d'objet. On peut ainsi leur associer des messages
utilisés pour leur gestion (comme dans Kooi par exemple), ou utiliser
certains attributs pour représenter des informations de contrôle servant par
exemple à indiquer le mode de déclenchement des règles (chaînage avant,
chaînage arrière ou chaînage mixte).
La trame du raisonnement du système (arbre des contextes dans Mycin,
arbre des prototypes dans Classic et tâches dans Smeci) peut être représentée
comme un regroupement d'objets.
On distingue dans les systèmes mixtes, deux modes d'intégration entre les
objets. et les règles. Dans Mycin, Kooi et Classic, les règles sont utilisées
pour compléter la spécification des objets. Elles servent de valeur aux
facettes associées soit globalement à ces objets, soit rattachées à leurs
attributs.
Dans ces systèmes, c'est l'envoi d'un message à un objet ou la référence
aux attributs de cet objet qui active les règles associées à l'objet. Dans Smeci.
ce sont les instances d'objets qui sont utilisées pour compléter la
spécification des règles.
Elles servent à constituer l'environnement
d'évaluation de celles-ci. Ce mode d'association apparaît plus puissant car le
fait d'encapsuler les règles dans l'environnement d'un objet. rend caduque la
notion de méta-règle. dans la mesure où les règles ne reférencent plus que les
attributs des objets auxquels elles sont attachées.
.... f'·" ... -

---

36
3 - SPECIFICATION DES CONNAISSANCES DANS LE SYSTEME GIDE
Le système GIDE (Gestion Intelligente de Dossiers médicaux en Epilepsie) a
pour but d'assister le médecin neurologue dans la manipulation du dossier d'un
malade. Nous présentons dans ce chapitre la spécification des connaissances
utilisées dans ce système. Le chapitre est divisé en deux parties. Dans la
première partie, nous présentons le formalisme utilisé, et dans la deuxième
partie nous présentons la maquette du système.
3.1 - FORMALISME DE SPECIFICATION
3.1.1
-
Présentation
générale
Dans le chapitre précédent, nous avons constaté la convergence des
formalismes de représentation des connaissances vers des formalismes mixtes.
Ces formalismes intègrent généralement aux représentations objectales, des
formalismes plus adaptés aux inférences et au transfert d'expertise, notamment
les règles de production.
Dans ce paragraphe, nous présentons le formalisme utilisé pour la
représentation des connaissances dans le système Gide. Les constructions de ce
formalisme découlent des remarques ci-dessus. A ces remarques, il faut ajouter
la nécessité de proposer un langage à la portée de l'expert, c'est-à-dire simple
et naturel. Dans cette optique, nous l'avons voulu moins général et prenant en
compte les spécificités de l'application Gide. Les connaissances y sont exprimées
en terme de CONCEPTS, d'OPERATEURS, d'OPERATIONS et de TACHES. Ce sont des
notions inspirées de la notion d'objet telle qu'elle est utilisée dans les R.C.O. et
les L.O.o..
.- .!""- .... -

---

37
La notion de concept s'apparente à la notion d'objet. Elle est spécifiée de
façon plus simple et possède un attribut particulier de nom STATUT, dont le but
est d'améliorer le traitement des informations imprécises dans les concepts.
La formulation des opérateurs, quant à elle, découle des remarques
suivantes: les règles de production sont de très bons outils d'inférence, et leur
modularité facilite le transfert d'expertise. Cependant les hypothèses des règles
ne référencent que des entités élémentaires et non structurées. De ce fait, les
inférences exprimées par les règles ne portent pas sur des objets en tant que
type abstrait, mais sur leurs attributs. Ceci entraîne une certaine difficulté à
exprimer des inférences globales portant au-delà de l'environnement d'un objet.
Or, dans le système Gide, la plupart des inférences portent sur l'ensemble du
dossier, c'est-à-dire sur un ensemble de concepts. Les opérateurs reprennent la
composition HYPOTHESE => CONCLUSION et la modularité, qui caractérisent les
règles de production. Toutefois, à la différence des règles de production, les
opérateurs permettent de référencer les entités structurées que sont les
concepts. La partie condition (que nous avons appelée contexte) regroupe un
ensemble de concepts. Le succès de l'évaluation du contexte constitue la condition
d'activation de l'opérateur.
Une opération est un regroupement fonctionnel d'opérateurs. On peut la
comparer à la notion de paquet de règles habituellement utilisée dans les
systèmes utilisant des règles de production, ou à la notion de base de règles
définie dans Smeci. Toutefois, il ne s'agit pas d'un simple regroupement
d'opérateurs, car les différents opérateurs composant une opération sont reliés
par des connecteurs spécifiant le contrôle de leur activation. La notion
d'opération permet aussi de faciliter l'utilisation polymorphe des opérateurs.
Une tâche regroupe un ensemble d'opérations, dont l'évaluation constitue
une unité de travail à exécuter par le système. La notion de tâche, telle que nous
l'avons définie dans Gide, peut être rapprochée de l'arbre de contexte de Mycin
(§ 2.6.1) ou de la notion de tâche telle qu'elle est définie dans Smeci (§ 2.6.4).
- ~/I.-"'-
Dans les paragraphes qui suivent, nous présentons successivement les
concepts, les opérateurs, les opérations et les tâches.

---

38
3.1.2 - Les concepts
Le dossier d'un malade en épilepsie se construit et s'étoffe progressivement
au fil des consultations, et il est difficile de faire des hypothèses sur l'ordre dans
lequel les différentes informations sont acquises, ou sur l'éventualité de leur
remise en cause.
Ceci nous a amené à décrire les informations factuelles du
dossier en terme d'entités autonomes, pouvant exister et être utilisées en dehors
de toute hypothèse sur les autres éléments du dossier. La description des
concepts présentée ci-dessous répond à ces préoccupations.
Un concept est une entité élémentaire pouvant être utilisée dans la
description du dossier d'un malade. Ce peut être un examen tel que la prise de la
tension artérielle ou la pesée, une pathologie telle que le diabète, une crise
d'épilepsie, un diagnostic etc...
La définition des concepts tire de la notion
d'objet, la structuration en classes, le mécanisme d'héritage, la valeur par
défaut, la généricité et l'encapsulation des spécifications.
Un concept est spécifié par un nom, qui permet de le référencer (ce nom
doit être unique dans le système), une description de sa STRUCTURE qui permet
d'appréhender sa sémantique, et par un ensemble d'opérations qui lu; sont
associées. Deux opérations particulières que nous appelerons VISU et EVAL, qui
sont utilisées pour la visualisation et l'évaluation du concept, ont une
spécification par défaut intégrée à la définition de tous les concepts. La définition
d'un concept est organisée suivant le schéma ci-dessous:
(nom du concept)
STRUCTURE
composé-de
(liste des attributs)
vérifiant
(contraintes d'intégrité)
.s..t.aM
(structure par défaut du concept)
OPERATIONS
Y.l.s..u.
(opération de visualisatIon)
~
(opération d'evaluation)

---

39
Dans le schéma de concept ci-dessus, en dehors des parties introduites par les
mots clés vérifiant et.s.taM, (parties qui sont optionnelles) toutes les autres
parties doivent être spécifiées dans tout concept. Cette spécification peut se faire
soit explicitement dans la définition du concept, soit indirectement
par voie
d'héritage. La description complète de la syntaxe des concepts, est donnée en
annexe 1.
Pour illustrer le schéma de description des concepts ci-dessus, nous allons
utiliser, dans les paragraphes qui suivent, un exemple qui est celui du concept
TENSION. Le résultat d'une prise de la tension artérielle est généralement décrit
par une phrase dans le style suivant:
"la tension prise le 12/10/88 est de 17/11; il s'agit d'un examen de contrôle
car le malade est sous di-hidan".
Nous montrons, dans les paragraphes qui suivent, comment la description
du concept TENSION permet d'intégrer les informations ainsi exprimées. Nous
utilisons également le concept EXAMEN·GENERAL, en supposant qu'il est composé
des attributs catégorie, date-de-réalisation et remarque. Nous supposons aussi
que le concept TENSION est une sorte d'EXAMEN-GENERAL possédant les attributs
spécifiques premier-chiffre et deuxième-chiffre.
3.1.2.1
Structu re
La structure d'un concept est exprimée par ses attributs, son statut, et les
contraintes qui peuvent être spécifiées sur ces attributs. Nous décrivons, dans
ce paragraphe, la spécification des attributs et des contraintes d'intégrité.
a} Les attributs
Dans le concept TENSION, le résultat de l'examen est caractérisé par les.
deux attributs premier-chiffre et deuxième-chiffre. Chacun de ces attributs se
définit par des facettes permettant d'indiquer:

---

40
- son type; ce
type
peut être entier,
réel,
chaîne,
booléen,
un
intervalle d'entiers ou de réels, un ensemble d'identificateurs.
- sa cardinalité qui spécifie si l'attribut est multi ou mono valué,
- sa valeur par défaut, s'il en existe une.
Ainsi, à ce niveau, les attributs du concept TENSION peuvent être complétés
de la manière suivante:
concept TENSION
structure: composé-de
premier-chiffre: 0-25, monovalué;
deuxième-chiffre: 5-25, monovalué;
Parmi les facettes habituellement utilisées pour décrire les attributs dans
les R.C.O., nous n'utilisons, pour les attributs de structure, que celles
permettant de décrire le type, la cardinalité et la valeur par défaut. Les facettes
de type et de cardin alité sont obligatoires; la facette "défaut" est par contre,
optionnelle.
\\}AaJgllcb
. ~ e
e))
'/1'>
o~
,(,
1;)
...
<,
'lA
.
"'.0
~
b) Statut
.....
"....
-l..;.
~
,~
0
\\ . 1 " " "
<ll
r.l
rC\\I)~. o~<}
Q(j.
8
~f].,
~
:<>~
;; .
Lors de l'utilisation -<dKn conc~pt, il' 'J}èst pas toujours nécessaire de
reférencer les valeurs des a1tr.ibU~e~e?pt. Une estimation de ces valeurs
peut être suffisante sans q~?-~0ii'-.nécê~saire de les énumérer de manière
explicite. Par exemple, pour un examerT" relativement coûteux comme le
scanner, si le malade l'a déjà fait (dans un autre hôpital par exemple), sans
avoir le résultat dans le détail, on peut se contenter de noter s'il était "normal",
ou "anormal". Dans le cadre d'un résumé du dossier par exemple, il peut être
plus opportun de présenter un examen dont on aurait tous les détails de
réalisation
par les qualificatifs "normal" et "anormal" "à refaire" etc ...
L'attribut
ST AT UT permet de représenter ces informations. Il peut être
considéré comme une sémantique abrégée du concept, utilisée lorsque la
sémantique complète ne peut être évaluée ou paraît moins adaptée. L'attribut
STATUT peut aussi être considéré comme un outil d'abstraction pour le médecjnl
....'"' ....-
car il lui permet d'utiliser des concepts sans se soucier précisément de leur
structure réelle. C'est également un moyen de représentation et d'utilisation
d'informations imprécises. Cet attribut est spécifié à l'aide d'une opération
(§3.1.8).

---

41
c) bes contraintes
La structure d'un concept peut comporter un prédicat qui exprime des
restrictions portant sur un ou plusieurs attributs. Lorsque ce prédicat est
présent dans la description, il est introduit par le mot clé vérifiant. Dans fa
description du concept, ce prédicat est spécifié par un identificateur qui se
réfère au corps du prédicat.
Ce prédicat doit avoir été au préalable défini. Ces prédicats sont en fait des
opérateurs dont le résultat est de type booléen. La description du concept TENSION
peut ainsi être complétée de la manière suivante:
concept TENSION
structure: composé-de
vérifiant concordance
La contrainte concordance exprime le fait que le premier chiffre doit toujours
être supérieur au deuxième.
d) Héritage d'informations
Un concept peut être défini à partir d'un autre concept dont il hérite les
caractéristiques, mais auquel il peut ajouter de nouveaux attributs ou de
nouvelles contraintes. La spécification de l'héritage tel qu'il est actuellement
réalisé dans Gide, n'aborde pas le problème de l'héritage multiple et des conflits
d'héritage.
Par exemple, si on suppose que la tension artérielle est une variété
d'examen général, ceci peut être spécifié de la manière suivante:

---

42
concept TENSION sorte de EXAMEN GENERAL
structure: composé de
vérifiant...
Selon cette définition, en plus de ses attributs propres qui sont premier-chiffre
et deuxième-chiffre, le concept TENSION possède les attributs
catégorie,
date-de-réalisation, et remarque, qu'il hérite du concept EXAMEN GENERAL. Il en
hérite également les opérations et les contraintes.
3.1.2.2 - Dynamique des concepts
Les concepts, tels que nous les avons présentés, peuvent être considérés
comme des types abstraits. On peut donc définir des opérations applicables à une
classe de concepts donnée. Actuellement, il existe deux opérations prédéfinies
applicables à tous les concepts. Ce sont les opérations EVAL et VISU,
respectivement utilisées pour l'évaluation et la visualisation des concepts.
Comme nous le verrons au paragraphe 3.1.8, la notion d'opération est une
notion générique qui s'exprime à l'aide des opérateurs, que nous définissons au
paragraphe suivant.
3.1.2.3 - Famille d'un concept
Dans l'ensemble des sous-classes d'un concept, nous regroupons sous la
notion de famille, celles qui sont constituées d'éléments ayant les mêmes
attributs et qui ne diffèrent que par les contraintes exprimées dans leur
spécification.
- f .. ·· _.-

---

43
Exemple de famille
Si on considère les concepts PERSONNE, ADULTE, HOMME. FEMME, GARCON,
FILLE liés par les relations de spécialisation représentées par l'arbre suivant:
PERs::l\\lNE
~
ADULTE
ENFANT
HOMME
FEMME
GARCOO
FILLE
L'ensemble de ces concepts forme une famille dont l'ancêtre est le concept
PERSONNE. Tous les concepts de cette famille ont les mêmes attributs. Ces
attributs ont été hérités du concept PERSONNE. A ces attributs, chacun de ces
concepts ajoute des contraintes qui lui sont spécifiques. L'association de
contraintes à ces différents concepts peut être schématisée de la manière
suivante:
age <= 12
sexe = M
sexe =F
7\\
sexe = M
sexe = F
Tous les concepts de cette famille peuvent être définis par raffinement
progressif à partir de "ancêtre. Suivant l'arbre ci-dessus, on peut reformuler
le concept HOMME de la manière suivante:
HOMME= ADULTE vérifiant (sexe = M)
ADULTE = PERSONNE vérifiant (âge> 18)
HOMME = (PERSONNE vérifiant (âge> 18}) vérifiant (sexe=M})

---

44
Une famille peut être définie simplement par la donnée de l'ancêtre de la
famille, et pour chaque membre de la famille, la donnée des contraintes qui le
distinguent de l'ancêtre. Toute instance appartenant à la famille est d'emblée,
instance du concept qui est ancêtre de la famille, mais peut également appartenir
à plusieurs sous-familles. On peut considérer que la classification des instances
de concepts dans une famille, (cette classification est inhérente à l'organisation
des concepts en classes) est une opération générique et que les opérateurs
utilisés pour son instanciation sont les contraintes d'intégrité. C'est de cette
perception que découle la notion d'expression de concept présentée au paragraphe
3.1.5.
Rappelons aussi, qu'une classe peut être sous-classe d'une autre classe sans
que les deux classes appartiennent à la même famille. C'est par exemple, le cas
des concepts TENSION et EXAMEN-GENERAL, car le concept TENS/ON a des attributs
n'appartenant pas au concept EXAMEN-GENERAL.
3.1.2.4 -
Propagation des informations par mimétisme
dans un famille
Dans la hiérarchie des classes, le transfert d'informations par héritage se
fait toujours de haut en bas, c'est-à-dire, d'une classe vers ses sous-classes.
Dans une famille, en considérant la proximité de structure. qui prend mieux en
compte la sémantique des concepts que la relation de descendance existant dans
une classe, on peut autoriser une forme de propagation d'informations plus
générale que l'héritage. Nous appelerons cette forme de propagation mimétisme.
Le principe du mimétisme, est qu'un concept copie les opérateurs de ses proches
(père, fils, ou frère) de la même famille, pour les opérations qu'il n'arrive pas
à réaliser. Soulignons que seuls les opérateurs et les opérations sont
transférables par mimétisme, car les attributs sont par définition communs a
tous les membres de la famille, et les contraintes constituent la spécificité
irréductible de chaque membre.
-."-- ...-

---

45
A l'intérieur d'une famille, un concept peut ainsi utiliser les opérateurs
intégrés
dans
la spécification de ses sous-classes. Dans ce cas, le transfert
d'informations dans la hiérarchie des classes se fait de bas en haut, et non du
haut vers le bas, comme dans le cas de l'héritage. Cette notion peut également
permettre un transfert horizontal d'information entre des concepts se trouvant
au même niveau dans la hiérarchie des classes, mais appartenant à la même
famille.
La notion de famille peut également être utilisée lorsqu'on référence un
concept (dans le contexte d'un opérateur par exemple), et qu'on ne peut avoir
une instance de ce concept. Par mimétisme, un autre concept de la même famille
peut lui être substitué.
En guise d'illustration, considérons la famille ATCO structurée comme dans
le schéma ci-dessous. Supposons que l'on cherche à évaluer l'expression de
concept (cf § 3.1.5) ATCO-AUTRE. L'évaluation de cette expression est
équivalente à celle de l'expression A TCO vérifiant (C 1 puis C2). Si l'évaluation
de cette expression échoue, on tente l'évaluation de l'expression ATCO vérifiant
C2, et si cette dernière échoue aussi, on tente l'évaluation de ATCO. L'echec n'est
total que si l'évaluation des trois expressions échoue successivement.
ETCO-FAMILlA0
D'une manière générale, pour une expression de la forme
CONCEPT vérifiant (C1 puis C2 ... puis Cn).
On peut avoir n+1 reformulations, le passage d'une formulation à une autre se
faisant en relachant une contrainte. Le mimétisme permet mieux que "héritage,
de faire face au traitement des informations incomplètes.

---

46
3.1.3 -
Les
opérateurs
Dans ce paragraphe, nous présentons la notion d'opérateur sur laquelle
s'appuie la spécification de la dynamique des concepts.
a) Présentation aénérale
La formulation des opérateurs reprend la composition CONDITION => ACTION
des règles de production. Ils sont notamment constitués d'un contexte, qu'on peut
assimiler à leur condition d'activation, et d'une action qui est exécutée si le
contexte est évalué. L'évaluation d'un opérateur comporte donc deux étapes:
l'évaluation de l'ensemble des éléments constituant son contexte et l'exécution de
l'action associée. si tous les éléments du contexte sont évalués avec succès. Cette
évaluation peut être schématisée de la manière suivante:
opérateur
CD-
en
c
--
Les opérateurs doivent avoir une description qui facilite leur utilisation
dans le cadre d'une opération polymorphe; en effet, pour la plupart des
opérations à réaliser sur un concept, il existe
plusieurs façons de procéder et
donc plusieurs opérateurs candidats; le choix de l'opérateur à utiliser dépend en
général des informations figurant dans le dossier, et des objectifs fixés par
l' uti1isateur.
-F ..-

---

47
Le contexte de J'opérateur permet de spécifier la connaissance justifiant ce
choix. Par exemple, pour établir le diagnostic de l'épilepsie (créer une instance
du concept épilepsie), on peut procéder suivant les cas, par l'analyse de la
sémiologie, ou par l'analyse des résultats du scanner ou de l'EEG, ou par une
combinaison de ces différents procédés. Ceci se traduit par l'existence de
plusieurs
opérateurs d'évaluation du concept épilepsie. De même, pour
visualiser l'identité du patient dans le cadre d'une synthèse du dossier, il est
nécessaire de procéder de manière différente suivant que le patient est un
homme ou une femme, un enfant ou un adulte. Ceci se traduit par la définition de
plusieurs opérateurs de visualisation du concept personne dont le patient est une
instance.
La spécification d'un opérateur se fait selon le schéma suivant:
nom de l'opérateur
CQ\\JTEXTE
ensemble des instances de concepts constituant le contexte dans
lequel s'applique l'opérateur.
RESULTAT
type du résultat produit par l'opérateur
ACTION
procédure ou
fonction dont l'exécution est déclenchée
si tous les éléments du contexte sont évalués avec succès
b) Contexte
Le contexte d'un opérateur regroupe l'ensemble des concepts qui doivent être
évalués lors de l'utilisation de cet opérateur. Il est spécifié par une liste
d'éléments de contexte, chaque élément de contexte étant soit une expression de
concept (§ 3.1.5). soit une expression de concept suivie d'un nom d'opération.
Dans le premier cas, l'évaluation de l'élément de contexte revient à vérifier
l'existence d'au moins une instance du concept référencé dans le dossier. Dans le
deuxième cas, l'opération spécifiée est utilisée pour évaluer l'élément de
contexte. La spécification complète de la syntaxe des opérateurs est donnée en.
--"-- ...-
annexe 1.

---

48
c) Résultat
Le résultat produit par un opérateur peut être un concept, un symbole un
booléen ou une structure de donnée vide. Un opérateur peut en outre produire des
effets de bord comme par exemple des affichages à "écran.
d) Action
L'action associée à un opérateur peut être une procédure, une fonction, ou un
opérateur déjà défini. Cette action n'est exécutée que si le contexte de l'opérateur
est évalué avec succès. L'action est spécifiée par un identificateur de fonction ou
de procédu re.
e) Exemple
L'opérateur ci-dessous peut être utilisé pour évaluer le concept épilepsie,
c'est-à-dire en créer une instance.
opérateur IN8T-EP/L
contexte:
atcd-épil.
(eeg vérifiant contrainte-anormale)<- calcul-eeg,
tension <- inst-tension;
résultat: épilepsie;
action: proc5.
D'après la spécification ci-dessus, le contexte de l'opérateur inst-epil est
évalué avec succès s'il existe au moins une instance d'antécédent épileptique
(atcd-epil) dans le dossier, si l'utilisation de l'opération calcul-eeg conduit à
"obtension d'un eeg anormal et si l'opération inst-tension permet d'obtenir une
instance du concept tension. Le résultat produit par l'action attachée à cet
opérateur est une instance du concept épilepsie.
- f"" ... -

---

49
3.1.4 - L'opérateur ENVIRONNEMENT
Lorsque plusieurs opérateurs sont utilisés, l'un dans le contexte de l'autre,
ou lorsqu'ils sont utilisés simultanément dans le contexte d'un même opérateur,
ils contribuent à l'élaboration du même résultat. \\1 peut parfois être nécessaire
de préciser que certains éléments de leur différents contextes se refèrent à la
même instance. La notion d'environnement permet de référencer les instances
partagées par le contexte de plusieurs opérateurs contribuant à l'évaluation du
même résultat. L'opérateur ENVIRONNEMENT permet de spécifier une action se
ramenant à une recherche dans l'ensemble des instances partagées.
Considérons par exemple, l'opération consistant à prescrire un médicament,
c'est-à-dire, indiquer sa posologie pour un patient donné. Cette opération doit
tenir compte d'un certain nombre d'éléments, entre autre, le type de crise pour
lequel on cherche à prescrire le médicament. Ces éléments sont spécifiés dans le
contexte de l'opérateur PRESCRIRE présenté ci-dessous. Le choix d'un médicament
à prescrire doit également tenir compte du type de crise que l'on cherche à
soigner. Cette situation est en partie spécifiée par les opérateurs PRESCRIRE et
CHOIX-MED présentés ci-dessous. Dans cette spécification, il faut pouvoir
indiquer que l'instance de crise référencée dans les deux opérateurs est la même.
En supposant qu'on ne peut s'engager à choisir un médicament que si le diagnostic
a déjà été fixé, le concept crise est spécifié dans le contexte de l'opérateur
CHOIX-MED, par "opérateur ENVIRONNEMENT.
opérateur PRESCRIRE
contexte:
crise <- (crise vérifiant plu-récent) sinon diagnostic,
patient,
médicament <- choix-med;
résultat: prescription;
.a..c.1l.Qn: proc7.
opérateur CHOIX-MED
contexte:
- .!'-- _.-
crise <-environnement,
atcd-autre,
résultat: médicament;
.a..çliQn: proc8.

---

50
----I.~ appel d'un opérateur
'''''''''''~'évaluatjon de l'opérateur environnement
L'utilisation de l'opérateur ENVIRONNEMENT permet aussi d'induire un ordre de
précédence sur l'évaluation des éléments de contexte des opérateurs imbriqués.
3.1.5 - Expressions de concepts
Le dossier d'un malade est constitué de l'ensemble d'instances de concepts
créées à partir des comptes-rendus de consultations. La plupart des actions à
réaliser sur le dossier reviennent à sélectionner des instances remplissant des
conditions données. Par exemple, on peut consulter le dossier pour chercher
l'ensemble des crises primaires, des E.E.G. présentant des anomalies ou des
traitements efficaces. Les expressions de concepts servent à spécifier ce genre
actions.
Une expression de concept est spécifiée soit par un nom de concept, soit par
un nom de concept suivi d'une contrainte. La contrainte utilisée dans ce cas peut
-
être assimilée à un opérateur de classification. Une eXp'ression de concept e"st"
/,." ...-
donc utilisée comme une opération de classification, suivie d'une opération de
sélection.

---

51
L'application d'une expression de concept à une instance, consiste à vérifier
si cette instance appartient à la classe spécifiée par l'expression. Si tel est le
cas, "instance est sélectionnée; sinon, on considère que l'exécution de l'opération
a échoué.
exemple
L'expression
(TENSION vérifiant
(premier-ciffre
>15))
permet de
référencer
toutes
les
instances
du
concept
TE N SION
dont l'attribut
premier-chiffre a une valeur supérieure à 15.
Une expression de concept peut également permettre de décrire un ensemble
d'instances, en indiquant simplement la classe à laquelle ces instances ne doivent
pas appartenir. Considérons par exemple la classe EPILEPSIE composée de trois
sous-classes et schématisée de la manière suivante:
EPILEPSIE vérifiant cl
EPILEPSIE vérifiant c3
La recherche des instances du concept épilepsie correspond au parcours intégral
de cet arbre. L'évaluation de l'expression (EPILEPSIE vérifiant (non C2)) est
équivalente à la recherche de toutes les instances de la classe épilepsie, sauf les
instances appartenant à la sous-classe EPILEPSIE INCLASSABLE.
-,"".- ...-

---

52
3.1.6 - Exemple de spécification de concept: le concept TENSION
concept TENSION sorte-de EXAMEN-GENERAL
structure: composé-de
premier chiffre: 0-25, monovalué;
deuxième chiffre: 5-25, monovalué;
vérifiant roncordance;
.s..t.a1.u.1:0P1 ;
.é.Y..al: inst-tension .s.lD..Q.n (tension vérifiant plus-recent);
~: vi-tension .sl.!:!.Qn resumer-tension.
Dans cet exemple, le concept TENSION a cinq attributs; les attributs date,
catégorie, remarque qu'il hérite de EXAMEN-GENERAL et les attributs
premier-chiffre et deuxième-chiffre
qui
lui sont propres.
Lors de
l'instanciation, l'instance créée ne sera considérée comme valide que si le
prédicat concordance appliqué à ces attributs donne la valeur "vrai".
Son STATUT peut être calculé à l'aide de l'opérateur OP 1. Pour l'évaluation
du concept tension, le système essaiera dabord "opérateur inst-tension. Si on ne
peut obtenir une instance à l'aide de cet opérateur, on cherche s'il y a dans le
dossier une instance du concept TENSION vérifiant le prédicat plus-recent. Ce
prédicat est un prédicat prédéfini, applicable à une instance d'un concept
quelconque et rendant le résultat "vrai" si l'instance à laquelle il est appliqué,
est la plus récente instance de ce concept créée dans le dossier.
3.1.7 - Opérateurs, règles et messages
Si on considère le fait que l'évaluation du contexte d'un opérateur est une
condition préalable au déclenchement de l'action de celui-ci, on peut le ramener
au schéma ANTECEDENT => CONSEQUENT qui caractérise les règles de production.
Toutefois,
alors que
la partie
"antécédent" des
règles
ne
reférence
habituellement que des entités élémentaires, le contexte d'un opérateur est
- ,,--
composé de concepts structurés. Ceci facilite l'expression d'inférences globales à
l'ensemble de la base des connaissances et pas simplement cantonnées à
"ensemble des attributs d'un oblet.

---

53
Les messages tels qu'on les utilise habituellement dans les L.o.o., peuvent
être assimilés à des opérateurs unaires, c'est-à-dire des opérateurs dont le
contexte est réduit à un seul élément. Cet élément est l'objet dans lequel est
intégré la méthode servant à interpréter le message.
D'autre part, le contexte d'un opérateur intègre des informations qui font de
ce dernier, le support de la connaissance experte. La notion d'opérateur permet
d'étendre celle de message de la façon suivante:
- l'opérateur a une arité supérieure au message qui est en principe d'arité
1, puisqu'il (l'opérateur) regroupe dans son contexte plusieurs types
de concepts.
- les opérateurs permettent d'intégrer des connaissances d'expertise.
- la possibilité de regrouper plusieurs opérateurs dans un agrégat formant
une opération, permet d'augmenter le degré de polymorphisme et
d'indéterminisme dans leur utilisation.
3.1.8
-
Opérations
Une opération est une composition non déterministe permettant de
regrouper l'ensemble des opérateurs candidats à l'exécution d'une action donnée.
On peut la rapprocher de la notion de paquet de règles, habituellement utilisée
dans les systèmes à base de règles de production. Elle est formée d'opérateurs ou
d'expressions de concepts. Elle peut être élémentaire, c'est-à-dire réduite à un
opérateur ou à une expression de concept, ou formée de plusieurs éléments
composés à l'aide des connecteurs OU,
SINON et PUIS
qui spécifient
respectivement la composition indéterministe, alternative et séquentielle. Par
exemple, si pour une opération 0 donnée, les opérateurs op1, op2 et op3 sont
candidats, cette opération pourra être spécifiée comme suit:
opération 0 =
op1 .s.i.n.Qn op2 ~ op3.
suivant cette spécification, l'opérateu r à utiliser pour
l'~xécution de l'opération
-!'
_.-
o est le premier de la liste dont Je contexte est évalué avec succès. L'expression
suivante:

---

54
opération 0 =
op1 Q.U op2 Q.U op3.
spécifie que l'opération 0 aura pour effet l'évaluation simultanée des opérateurs
op1, op2 et op3.
L'opération peut avoir plusieurs résultats suivant le nombre d'opérateurs
évalués avec succès. Si le résultat est monovalué, une valeur quelconque de
('ensemble des résultats est retenue. L'expression suivante:
opération 0 =
op1 P.Ul.s. op2 Q..U.lli op3.
spécifie qu'il faut exécuter op1 ensuite op2 et enfin op3. Si l'exécution de l'un
quelconque de ces opérateurs échoue, on considère que l'opération a échoué. Une
opération peut être constituée d'une combinaison quelconque de ces trois types de
connecteurs;
Exemple d'opération
opération calcul-eeg =
(eeg vérifiant anormal)
s..in.Q.n (eeg vérifiant plus-récent)
Q.l.!. inst-eeg.
D'après cette spécification, l'exécution de l'opération calcul-eeg consiste à
chercher s'il y a une instance du concept eeg-anormal dans le dossier; si ce n'est
pas le cas, on cherche le plus récent eeg et s'il n'y a pas d'eeg dans le dossier, on
utilise l'opérateur inst-eeg pour en calculer un.
-
_f"'." _ . -

---

55
3.1.9 - Les tâches
La finalité de chaque fonctionnalité du système (diagnostic, thérapeutique ..)
consiste à extraire du dossier et à visualiser, les informations intéressant
l'utilisateur dans un contexte donné.
Une tâche est une unité de travail à exécuter par le système. Elle sert donc
à regrouper les instances de concept dont la visualisation constitue la synthèse
du dossier. Une tâche est formée de deux parties que nous appelons
respectivement STRUCTURE et PRESENTATION. Dans ce paragraphe, nous
présentons ces deux parties d'une tâche.
3.1.9.1
• Structure d'une tâche
La structure d'une tâche est formée d'une liste d'opérations et de
sous-tâches. Les sous-tâches composant une tâche sont spécifiées par des
identificateurs référençant des tâches préalabement définies. Les opérations,
quant à elles, peuvent être spécifiées par des identificateurs ou des expressions
conformes à la syntaxe d'une opération. L'évaluation de ces opérations et de ces
tâches permet de construire un ensemble d'instances à partir desquelles est
effectuée la synthèse du dossier. La structure d'une tâche se rapproche sur le
plan syntaxique et sémantique du contexte d'un opérateur. Il y a cependant des
différences portant notamment sur les points suivants:
- les opérations référencées dans une tâche peuvent être multivaluées.
L'évaluation d'une expression de concept par exemple, ne se borne pas
à
vérifier l'existence d'une instance de ce concept dans le dossier, mais sélectionne
toutes les instances de ce concept contenues dans le dossier;
- l'évaluation d'une tâche peut être partielle dans la mesure où "échec de l'une
des opérations composant la tâche n'affecte pas
forcément
l'utilisation des
autres opérations, alors que dans le cas d'un opérateur, il est nécessaire que tous
les éléments du contexte soient évalués avec succès;
- l'action associée à une tâche est implicitement la visualisation des instances
qu'elle a rassemblées.

---

56
3.1.9.2 - Présentation d'u ne tâche
La présentation d'une tâche joue le même rôle pour la tâche. que le statut
pour le concept. La présentation d'une tâche est formée d'une liste d'attributs
dont chacun est décrit par un identificateur et sa liaison
avec un attribut de
structure. Cette liaison est spécifiée par une expression de concept suivie du
nom d'un d'attribut du concept référencé par l'expression. L'évaluation de cette
expression permet de choisir dans l'ensemble des instances formées par
l'évaluation de la structure de la tâche, celle d'où sera extraite la valeur de
l'attribut de présentation.
Exemple de spécification de tâche: la tâche "résumé"
Le dossier du malade est constitué de l'ensemble des concepts et des tâches
crées au fil des consultations. La tâche RESUME que nous décrivons ci-dessous
permet de regrouper "ensemble des instances susceptibles d'intéresser le
médecin lorsqu'il cherche à avoir une vision exhaustive du dossier sans le
parcourir intégralement. Ce sont des instances des concepts personne,
antécédent, crise, eeg, épilepsie, traitement, état. Les méthodes d'évaluation
utilisées sont, pour la plupart, des filtres qui permettent de choisir l'instance la
plus adaptée au cadre du résumé.
tâche RESUME
Structure:
personne,
atcd-epil sinon inst-atcd1,
(crise vérifiant plus-recent) sinon inst-crise1,
épilepsie,
(eeg vérifiant anormal) ou (eeg vérifiant plus-récent),
scanner,
traitement vérifiant plus-récent,
(etat verifiant plus-récent) sinon inst-etat1;
présentation:
nom <- personne.nom,
epiJ <:- epilepsie.type,
- .!'"" .... -
crise <- crise.sémiologie.
atcd <- (atcd vérifiant personnel).nature,
trait <- traitement.medicament,
etat <- etat.description.

---

57
L'évaluation de chaque opération composant la tâche, permet de constituer un
paragraphe du résumé. Les opérations utilisées pour la visualisation de ce
résumé sont celles intégrées à la spécification des concepts dont les instances
sont sélectionnées pour constituer le résumé. Celui obtenu par l'évaluation de la
tâche RESUME se présente comme suit:
- le premier paragraphe est utilisé pour la présentation de l'identité du patient.
Elle est obtenue par la visualisation de l'instance du concept personne
sélectionnée dans le dossier. En principe, le dossier contient une seule instance
de ce concept;
- le deuxième paragraphe est consacré à la description des antécédents. Les
antécédents sélectionnés sont ceux appartenant à la classe atcd-epil (antécedent
épileptique). S'il n'existe pas de tels antécédents dans le dossier, on tente d'en
créer en utilisant l'opérateur inst-atcd1;
- le troisième paragraphe est consacré à la description de l'épilepsie. Toutes les
instances du concept épilepsie se trouvant dans le dossier sont sélectionnées;
- le quatrième paragraphe est consacré à la description des E.E.G .. Les E.E.G.
jugés intéressants sont ceux présentant des anomalies et le plus récent, quel
qu'il soit.
De la même manière il y a des paragraphes consacrés au scanner, au
traitement, et à la description de l'état global du patient.
3.1.10 -
Conclusion
Le formalisme que nous avons proposé est fondé sur la notion d'objet. Il se
veut simple et naturel afin d'être à la portée d'un expert non informaticien, et
bien ciblé sur les besoins quotitiens de l'épileptologue. Sa spécificité est basée
sur la classification des facettes habituellement utilisées dans les R.C.O.. Ainsi,
nous avons distingué les trois groupes de facettes suivants:
- les facettes servant à décrire le type des attributs,
- les facettes servant à exprimer des contraintes d'intégrité,
- les facettes servant à exprimer des opérations sur les objets.
Ces trois groupes se retrouvent dans la structuration du concept en trois
parties,
respectivement
introduites
par
les
mots
clés
"composé-de.\\.
"vérifiant", "opé ration".

---

58
Le premier objectif auquel répond le formalisme, est de garder les
potentialités de description des RC.O. et de permettre en même temps, de
spécifier, comme dans les L.O.O. un concept sous forme de type abstrait sur
lequel on puisse définir des opérations spécifiques.
Nous sommes arrivé à la formulation d'un concept suivant le schéma
<liste d'attributs> <contraintes> <liste d'opérations>
Cette formulation peut être rapprochée de la formulation
<liste d'attributs> <liste de méthodes>
obtenue dans les L.O.O.
La partie <contrainte>, nécessaire pour compléter la spécification des
attributs s'impose surtout par la nécessité de prendre en compte l'opération de
spécialisation inhérente à l'organisation des objets en classes.
La notion d'opérateur permet d'exprimer la dynamique des concepts sous la
forme HYPOTHESE => CONCLUSION qui caractérise les règles de production tout en
offrant la possibilité de référencer des objets structurés.
Le deuxième objectif visé est le naturel et la simplicité. Le nombre de
facettes utilisées est de six au lieu de la trentaine de facettes habituellement
définies dans les RC.O .. La formulation des opérations de filtrage en termes
d'expressions de concepts, nous semble également plus simple et plus naturelle
que les filtres habituellement utilisés dans les RC.O ..
En
plus de cette structuration, la définition des opérateurs et leur
regroupement en opérations, dans le modèle proposé dans Gide, introduit
l'indéterminisme et le polymorphisme dans la dynamique des spécifications,
rendant ainsi le système plus flexible. Cela permet par exemple, de résumer un
dossier de manière diffférente suivant les circonstances.
Par ailleu!.s!
l'introduction de l'attribut s ta tu t et la propagation' des informations par
mimétisme dans une famille, répond à la nécessité d'utiliser des informations
incomplètes ou approximatives dans le dossier.

---

59
3.2 - PRESENTATION DE LA MAQUETrE
3.2.1
-
Utilisation du système
Le dossier du malade peut être consulté par divers utilisateurs (médecin,
parents du malade ....), mais pour illustrer l'utilisation de la maquette, nous
prendrons le cas de l'épileptologue, qui est un utilisateur privilégié. Celui-ci
peut par exemple consulter le dossier pour préparer la prochaine entrevue
avec le patient, évaluer l'effet de la thérapeutique sur la sémiologie des
crises, établir ou changer la thérapeutique ou le diagnostic. Le système
participe à chacune de ces opérations en fournissant au médecin une synthèse
du dossier. Cette synthèse peut être exhaustive mais résumée, ou être
contextuelle et orientée par un objectif bien précisé. Pour la préparation
d'une entrevue avec le patient par exemple, si on suppose que la précédente
entrevue remonte à plusieurs années, il faut que le médecin ait une vision
exhaustive du dossier sans toutefois être submergé d'informations si le
dossier est déjà volumineux. La synthèse à lui proposer dans ce cas, doit
intégrer toutes les variétés de concepts représentés dans le dossier du
malade, le phénomène de résumé se traduisant alors, par le choix des
instances de chaque variété de concept à inclure dans le résumé et par les
modalités de visualisation. Pour le concept TRAITEMENT par exemple, on peut
n'inclure dans Je résumé que l'instance représentant le plus récent
traitement qui a été prescrit au malade. Pour la visualisation de cette
instance, on ne mentionne que le nom du médicament prescrit, en omettant la
posologie.
Il peut aussi arriver qu'après avoir parcouru le résumé du dossier, le
médecin ait besoin d'informations complémentaires sur
une donnée
particulière. Par exemple, après avoir étudié le résumé du dossier, le
médecin peut souhaiter avoir plus d'informations sur les antécédents de la ".
maladie chez le patient.

---

60
L'ensemble des informations nécessaires pour préparer une consultation
peut être obtenu à partir de l'évaluation de la tâche RESUME telle qu'elle a été
présentée au paragraphe 3.1.9.2. D'une manière générale, la synthèse du
dossier fournie par le système, est le résultat de l'évaluation d'une tâche ou
d'une opération. L'extrait de dossier obtenu à partir d'une opération décrit
généralement une seule variété de concept. Elle peut être utilisée pour servir
de complément à une synthèse obtenue à partir d'une tâche.
A travers son interface graphique, le système propose à l'utilisateur, une
liste de tâches et d'opérations. Celui-ci choisit selon ses besoins, la tâche ou
l'opération qui lui convient.
La maquette actuelle comporte les tâches DEMARRAGE,
RESUME,
DIAGNOSTIC, FIN-DE-SESSION. L'évaluation de la tâche démarrage est déclenchée
automatiquement au début de chaque consultation. Elle permet d'obtenir des
informations générales sur le malade, l'utilisateur et les consultations
antérieures. L'évaluation de cette tâche se ramène à l'instanciation des
concepts prédéfinis UTILISATEUR et CONSULTATION, présentés plus en détail au
paragraphe 3.2.2.3. Ces informations peuvent par exemple être utilisées
pour moduler le niveau de détail à adopter dans la visualisation des instances
constituant la synthèse du dossier.
Par rapport à la tâche RESUME, la tâche DIAGNOSTIC privilégie les
informations susceptibles d'aider le médecin lorsqu'il cherche à réaliser le
diagnostic. Par exemple, elle ne mentionne ni les traitements, ni les
intolérances médicamenteuses; par contre, elle donne tous les détails existant
. dans le dossier, sur les antécédents de nature épileptique.

---

61
3.2.2 • Achitecture du
système
3.2.2.1
-
Présentation
générale
La maquette actuelle du système, élaborée sur la base du formalisme
présenté au paragraphe précédent, peut être schématisée par la figure
suivante:
VISUALISATION
TACHES
OPERATIO'S
TRADUCTION
.. f' - _.-

---

62
3.2.2.2
-
Le dossier
Le dossier du malade est composé de comptes-rendus de consultations
initialement rédigés en langage naturel. Ces comptes-rendus sont analysés
pour produire des instances de concepts. Cette phase d'analyse est présentée
au chapitre 5. Du point de vue interne, le dossier du malade est représenté
par un ensemble d'instances de concepts.
3.2.2.3 -
La
consultation
et de l'utilisateur
Pour avoir une réaction intelligente, le système a besoin d'informations
autres que le dossier. Par exemple, il serait souhaitable de moduler le niveau
de détail à adopter dans les réponses en fonction de l'utilisateur et des
précédentes consultations. Au début de chaque consultation, le système crée
une représentation de l'utilisateur et une description de la consultation. Ce
sont des concepts prédéfinis qui peuvent être reférencés par le contexte des
opérateurs utilisés pour formuler les réponses et conditionner de ce fait la
formulation de celles-ci.
al L'utilisateur
Le concept UTILISATEUR est une sous-classe du concept PERSONNE. " a un
attribut supplémentaire permettant de préciser à quel titre l'utilisateur
intervient dans le dossier. Cet attribut spécifie s'il s'agit du médecin traitant,
du médecin consultant, du malade ou d'une autre personne. Le concept
utilisateur est intégré dans une famille structurée comme suit:
... f"· _.-

---

63
utilisateur
traitant
autre
b) La consultation
Le concept CONSULTATION regroupe un ensemble d'informations
informelles permettant d'apprécier la connaissance que l'utilisateur a du
malade et de son dossier. Cela recouvre par exemple:
- le fait que le malade soit présent ou absent lors de la consultation
dossier: si par exemple le malade est présent, il n'est pas nécessaire
de renseigner le médecin sur son âge ou sur son sexe;
- la date de la dernière consultation: on donne d'autant plus de détails
que la date de la dernière consultation est éloignée. D'autre part,
certaines informations très périssables, comme la pesée ou la tension
artérielle, peuvent ne plus être valables et être réévaluées;
- le nombre total de consultations dont le malade a déjà fait l'objet,
- la liste des informations que le médecin a déjà communiqué au
malade,
- "objectif de l'utilisateur; si ('utilisateur c'est le médecin par exemple,
il peut fixer comme objectif la remise en cause d'un diagnostic ou d'une
thérapeutique, ou tout simplement la préparation d'une prochaine
entrevue avec le malade.
.. -"'.- -..-

---

64
3.2.2.4 - Réalisation de la synthèse du dossier
L'ensemble d'instances représentant le dossier, l'utilisateur et la
consultation, constituent la base de faits utilisée pour la synthèse du dossier.
Partant de cette base des faits, la synthèse du dossier se fait en deux temps:
1) à partir de l'évaluation d'une tâche ou d'une opération, le système
construit un ensemble d'instances en les sélectionnant dans le dossier ou
éventuellement en les créant. Dans la suite, nous appelerons cet ensemble
d'instances, .extr.al.1 de dossier. Les instances créées pendant l'évaluation d'une
tâche ou d'une opération sont intégrées au dossier.
2) La visualisation de l'extrait de dossier construit à l'étape précédente
permet d'obtenir la synthèse. A partir d'un même extrait, on peut obtenir
plusieurs synthèses. La différence entre ces synthèses dépend du degré de
détail, adopté dans la visualisation. A terme, on peut envisager des
visualisations sous forme de courbes ou d'histogrammes.

---

65
4 - IMPLEMENTATION DE GIDE A L'AIDE DE SHIRKA
Dans ce chapitre, nous décrivons les principes de la traduction des
spécifications de Gide en termes de "schémas" Shirka. En effet, sur le plan
opérationnel, les outils disponibles en Shirka permettent une implémentation
aisée de Gide. Shirka offre notamment:
- un jeu de facettes couvrant celles utilisées dans Gide pour la description des
concepts,
- un mécanisme de filtrage facilitant la mise en oeuvre des expressions de
concept,
- une fonction de spécialisation permettant la gestion dynamique de la
position d'une instance de concept au sein d'une famille,
- des schémas méthodes, dont la spécification autorise l'indéterminisme et le
polymorphisme, et qui sont utilisés dans Gide pour implémenter les
opérateurs.
Après une rapide présentation de Shirka, nous décrivons les principes de
traduction des notions définies dans Gide, (concepts opérateurs, opérations,
tâches) en schémas Shirka.
4.1 • PRESENTATION DE SHIRKA
Shirka [RECH 89] est un système de gestion de bases de connaissances
centrées objets qui utilise un modèle de représentation inspiré des frames.
Dans Shirka, un objet est appelé schéma. Un schéma représente une classe
d'objets ou un objet particulier (une instance). Avec Shirka, on peut définir
plusieurs sortes de schémas; on distingue par exemple, les schémas "objet",
qui permettent de spécifier la connaissance statique du système, et les
schémas "méthode", qui permettent de spécifier la dynamique du système.
L'une des originalités de Shirka, et aussi sa caractéristique la plus
_
importante pour Gide, c'est son mécanisme de filtrage. 1'1 permet d'évaluer un
schéma par recherche dans une base d'instances.

---

66
4.1.1
- Structure d'un schéma
Un schéma est décrit par son nom et la liste de ses attributs. Chaque
attribut est à son tour décrit par un nom et une liste de facettes. Les noms de
schémas et d'attributs sont spécifiés par l'utilisateur et les facettes sont
choisies dans un ensemble prédéfini. Chaque schéma possède implicitement
un attribut de nom LUI-MEME qui permet de référencer le schéma dans sa
globalité et qui joue un rôle important dans la spécification des concepts et
des tâches.
Exemple de schéma
Si on se propose de décrire un schéma DATE, on peut le caractériser par
les attributs JOUR, MOIS, ANNEE. La sémantique de chacun de ces attributs est
à son tour décrite par des facettes comme dans la spécification ci-dessous:
(DATE
(sorte-de
(=
objet))
(JOUR
($un
entier)
($intervalle
(1
31 )))
(MOIS
($un chaine)
($domaine "janv" "févr".... "déc"))
(ANNEE
($un
entier))
Dans cet exemple, $un, $intervalle, $domaine sont des facettes.
Une instance de cette classe peut se présenter comme suit:
(D 1
est-un
date;
jou r
20;
mois
"aout";
année
1988;
-'" ~--

---

67
4.1.2 - Les facettes
La sémantique du modèle Shirka est en grande partie définie par les
facettes. Il en existe environ une trentaine répartie dans les différentes
catégories ci-dessous:
a) Facettes de type et d'ordinalité.
Ce sont les facettes
$un et $/iste-de. Elles permettent d'introduire le
type d'un attribut en précisant si cet attribut est multi ou monovalué. Le type
d'un attribut multi-valué est introduit par la facette $liste-de et celui d'un
attribut mono-valué est introduit par $un. Ce type peut être un entier, un
réel, une chaine de caractères ou une référence à un nom de schéma.
b) Facettes de restriction,
- La facette $domaine permet de préciser la liste des valeurs
possibles.
- La facette $intervalle permet de spécifier une liste d'intervalles de
valeurs admissibles dans le cas d'un type ordonné.
- Les facettes $card-min et $card-max permettent d'indiquer le nombre
minimum
et
maximum
de
valeurs
autorisées
pour
un
attribut
multivalué.
- La facette $à-vérifier permet d'attacher un prédicat à un attribut.
c) Facettes de valeur.
- La facette $va/eur définit une valeur assignée à l'attribut pour toute
les instances de la classe.
- La facette $défaut joue un rôle similaire à celui de la facette $valeur,
mais la valeur associée peut être redéfinie dans les instances.
- La facette $sib-exec (si besoin, exécuter) permet d'attacher à un
attribut une procédure qui servira à calculer sa valeur.
- La facette $sib-fiItre (si besoin, filtrer) permet d'attacher à un
attribut un filtre servant à extraire la valeur de cet attribut d'une
instance existant déjà dans la base de connaissances.

---

68
d) Facettes de liaison.
Ce sont les facettes $var<-, $var-> et $var-nom. Les deux premières
permettent d'associer deux attributs (pouvant appartenir à des schémas
différents) en indiquant lequel prendra la valeur de l'autre dès que cette
valeur sera calculée. La troisième permet de renommer un attribut pour
lever les ambiguïtés lorsque dans des reférences imbriquées, deux attributs
de schémas différents ont le même nom.
4.1.3 - L'attachement procédural dans Shirka
L'attachement procédural dans Shirka présente deux originalités dont il
est tiré profit dans Gide pour l'implémentation des opérateurs. Il s'agit de la
représentation externe des méthodes sous forme de schémas et de
l'indéterminisme dans l'application des méthodes.
a) représentation des attachements procéduraux sous forme de schémas
Dans Shirka, une procédure attachée à un attribut est définie du point de
vue externe par un schéma de classe. Ce schéma a un attribut de nom nom-fct
dont la valeur est le nom d'une fonction Lisp. Les autres attributs sont les
paramètres de la procédure. Activer un attachement procédural, consiste à
créer une instance de cette classe, et à la transmettre à la fonction qui est
valeur de l'attribut nom-fcL
L'avantage de ce mécanisme est que lors de
l'activation de l'attachement procédural (instanciation du schéma de classe
correspondant), les différents mécanismes d'inférences de Shirka (dont
l'attachement procédural!) sont utilisés pour instancier les attributs du
schéma. D'autre part, l'appel d'une fonction peut être précédé
d'un filtrage
sur les instances du schéma d'appel que l'on cherche à activer. En cas de
succès de cette étape de filtrage. le résultat est directement extrait de
l'instance retenue et la procédure n'est pas appelée.

---

69
b) Indéterminisme dans l'utilisation des méthodes
Comme toutes les autres facettes, les facettes d'attachement procédural
peuvent être
multivaluées, ce
qui
facilite
dans
le
système
Gide,
l'implémentation d'opérations composées de plusieurs opérateurs. Dans la
liste des schémas (méthodes) constituant l'ensemble des valeurs de ces
facettes, le premier schéma instancié avec succès est utilisé.
4.1.4
-
Filtrage
Le filtrage est l'un des mécanismes d'inférence utilisés dans Shirka. Il
consiste à calculer des valeurs, en les extrayant des instances existant déjà.
Un filtre est en partie composé des conditions que doivent satisfaire les
instances desquelles seront extraites les valeurs à considérer comme résultat
du filtrage. Il est spécifié en terme de spécialisation
d'un schéma de classe
dont il porte le nom. Les instances satisfaisant le filtre, sont donc instances de
cette classe. Un filtre est très proche dans son principe et sa spécification de
la notion d'expression de concept définie dans Gide.
Exemple
l'expression (DATE jour $valeur 25) est un filtre qui peut permettre de
retrouver les instances de la classe DATE dont l'attribut jour a pour valeur
25.
4.1.5 - Spécialisation de schéma
Shirka propose également une fonction de spécialisation qui, étant donnée
une instance, détermine les sous-classes auxquelles cette instance est
susceptible d'appartenir. Cette fonction est utilisée dans Gide pour réaliser la
classification dynamique d'une instance dans une famille.

---

70
4.2 - PRINCIPES DE TRADUCTION D'UN CONCEPT GIDE
A un concept Gide, on va associer les quatre groupes de schémas
ci-dessous:
a) un schéma objet qui permet de décrire les attributs du concept. Ce schéma
est l'élément central de la description; en effet, les autres schémas entrant
dans la spécification du concept, sont utilisés comme valeur des facettes
d'attributs de ce schéma. Ce schéma correspond à la description de la
structure du concept. Pour assurer la perception du concept comme type
abstrait, les schémas entrant dans la description de sa dynamique sont
rattachés aux facettes de l'attribut lui-même de ce schéma et agissent donc
sur ce schéma en tant qu'entité atomique et non pas sur ses attributs.
b) un ou plusieurs schémas prédicats qui permettent de décrire les
contraintes attachées au concept;
c) un ou plusieurs schémas méthodes permettant de décrire l'opération
d'évaluation associée concept;
d) un ou plusieurs schémas méthodes permettant de décrire l'opération de
visualisation associée au concept.
Les prédicats, les méthodes de visualisation et les méthodes d'évaluation
sont respectivement attachés aux facettes
$à-vérifier, $pour-vi, $sib-exec
de "attribut lui-même du schéma utilisé pour la description des attributs du
concept. Chacun de ces schémas est sous-classe de l'une des classes
contrainte, filtre, concept et opérateur. Dans ce paragraphe, nous donnons la
définition de ces classes, les principes de traduction des spécifications de Gide
en schémas Shirka. Un exemple complet de traduction de concept est donné en
annexe 2.

---

71
4.2.1 - Les classes OPERATEUR et CONTRAINTE
Les opérateurs
de Gide se traduisent schéma Shirka à partir des
spécialisations du schéma opérateur qui est lui-même une spécialisation du
schéma méthode de Shirka. La classe opérateur a un attribut résultat
permettant de reférencer le résultat de l'exécution de l'opérateur. La
spécification de la classe opérateur en Shirka est la suivante:
(def-sh '(opérateur
(sorte-de
(= méthode)}
(résultat
($liste-de
objet»
}}
Les contraintes sont des instances de la classe contrainte définie dans
l'environnement Gide. Cette classe est elle-même une spécialisation de la
classe prédicat de Shirka. Elle a un attribut de nom argument qui représente
l'instance sur laquelle on veut vérifier la contrainte. Sa spécification
s'exprime comme suit:
(def-sh '(contrainte
(sorte-de
(=
prédicat»
(argument
($un
objet»
}}
La classe contrainte hérite l'attribut nom-fct du schéma prédicat prédéfini
dans Shirka. La traduction ci-dessus est équivalente à la suivante:
(def-sh
'(contrainte
(sorte-de
(= prédicat»
(nom-fct
($un symbole»
(argument
($un
objet»
} }

---

72
4.2.2 - La classe CON CE PT
La classe concept étend la définition des schémas objets de Shirka en leur
ajoutant l'attribut ~. La spécification de cet attribut est complétée lors de
la spécification de chaque concept par l'ajout d'attachements procéduraux. La
spécification de cette classe se présente comme suit:
{def-sh '{concept
{sorte-de
(=
objet))
{statut
($un
objet))
) )
Tous les concepts définis dans Gide sont des spécialisations de ce schéma.
4.2.3 - La classe FILTRE
La classe filtre est utilisée pour formuler un filtre sous forme de
méthode. Cela permet de combiner plus aisément les deux types d'inférence
(filtrage et attachement procédural). Cette classe se définie comme suit:
{def-sh
'{fi Itre
{sorte-de
(=
opérateur))
{nom-fct
($valeur
$$))
{réévaluation ($un objet))))
$$ correspond à une fonction qui n'a pas d'argument et qui ne calcule rien.
C'est un attachement procédural fictif puisque le résultat d'une opération de
filtrage est choisie dans un ensemble d'instances existant déjà..
La définition d'un concept dans Gide s'accompagne toujours de la
génération d'un filtre à "vrai", utilisé pour évaluer les expressions de '-,-
concepts. Par exemple, au concept ATCD est associé automatiquement le filtre
'. -
l~
ci dessous:

---

73
(def-sh '(filtre-atcd
(sorte-de
(=
filtre))
(résultat
($sib-filtre
(atcd
(lui-même
($var-> resultat))))))
Si le concept défini n'est pas ancêtre de sa famille, l'attribut réévaluation"du
filtre associé, sera complété pour permettre la reformulation de la sélection
en cas de l'échec de la formulation initiale (cf 3.1.2.4).
Par exemple. la définition du concept ATCD-AUTRE s'accompagne de la
génération du filtre ci-dessous:
(def-sh
'(fi Itre-atcd-a utre
(sorte-de
(=
filtre))
(résultat
($sib-filtre
(atcd-autre
(lui-même
($var->
resultat)))
(réév alu ation
($sib- fi Itre
(atcd-patient
(lui-même ($var-> resultat)))
(atcd
(lui-même ($var-> resultat)))
) )
Lorsqu'une opération de filtrage sur le concept ATCD-AUTRE est
demandée, une instance d'atcd-patient est également recherchée en prévision
d'un éventuel échec d'évaluation de l'attribut résultat. S'il n'y a aucune
instance du schéma atcd-patient, le filtre sur atcd est essayé à son tour. Dans
l'utilisation du schéma ci-dessus, la valeur de l'attribut réévaluation n'est ~"
-- .!',-- ...-
-
,
donc utilisée que si l'évaluation de l'attribut résultat a échoué.

---

74
4.3 - TRADUCTION DES EXPRESSIONS DE CONCEPTS
La définition d'une expression de concept doit être conforme à la
syntaxe (cf annexe 1)ci-desous:
<expression de concept> ::= <concept>
1 <concept> vérifiant <contrainte>
Elle correspond à un filtre permettant de choisir les instances vérifiant les
conditions spécifiées dans <contrainte>. ou à un filtre à "vrai" s'il n'y pas de
<contrainte> dans la spécification. Une expression de concept se traduit par
l'association d'une contrainte au filtre à "vrai" du concept référencé introduit
par l'expression de concept. Ainsi l'expression
(A TC 0 vérifiant contrainte-atcd)
sera traduit de la manière suivante:
(def-sh '(filtre-atcd-contraint
(sorte-de
(=
filtre-atcd))
(résultat
($à-vérifier
(con train te-a tcd
(argument ($var<- résultat)
) ) ) ) )
... !', .. -
-

---

75
4.4 - LES OPERATEURS ET LES OPERATIONS
Les opérateurs se traduisent par des schémas "méthode" dont tous les
attributs possèdent des facettes d'évaluation. Dans beaucoup de cas, l'évaluation
des attributs d'un schéma méthode se ramène à une opération de filtrage sur
l'ensemble des instances existant déjà (dossier) et est donc spécifié dans le
formalisme de Gide par une expression de concept.
4.4.1
- Traduction d'un opérateur
Les opérateurs sont transformés en schémas Shirka suivant les principes
ci-dessous:
a) un opérateur de Gide est traduit en un schéma opérateur tel que nous l'avons
défini au paragraphe 4.2.1;
b) "attribut nom-fet de ce schéma, prend pour valeur, l'action spécifiée dans
l'opérateur;
c) l'attribut résultat du schéma, prend pour valeur, le résultat spécifié dans
"opérateur;
d) Dans le contexte de l'opérateur, les expressions de concept ne comportant pas
de contrainte sont traduits par un attribut ayant pour type, ce concept, et dont la
valeur est calculée par
le filtre associé à ce concept à sa création. si
l'expression de concept est suivi d'une contrainte, l'attribut créé dans le cas
ci-dessus sera complété par une facette $a-vérifier ayant pour valeur la
contrainte spécifiée;
e) quand un élément de contexte est suivi d'un opérateur (d'évaluation), les
spécifications de type et les contraintes se font comme dans le cas ci-dessus,
mais l'évaluation est réalisée par l'appel de l'opérateur référencé dans la
spécification.
._!,.~"-
Dans le schéma méthode ainsi généré, tous les attributs ont une méthode
d'évaluation sauf l'attribut résultat.

---

76
Exemple
considérons l'opérateur suivant:
opérateur INST-EPIL
contexte
atcd-epil,
eeg vérifiant anormal,
tension <- inst-tension;
résultat: épilepsie;
.aQ1iQn: proc5.
En suivant les principes ci-dessus, cet opérateur sera traduit par le schéma
ci-dessous:
(def-sh '(INST-EPIL
(sorte-de
(= opérateur))
(nom-fct
($valeur
procS))
(resultat
($un epilepsie))
(atcd-epil%($un
atcd-epil)
($sib-exec
(filtre-atcd-epill
(resultat
($var->atcd-epil%
)))))
(eeg%
($un eeg)
(sib-exec
(filtre-eeg
(resultat ($var-> eeg%)))
($a-verifier
(anormal (argument ($var<- eeg%)))
(tension% ($un tension)
-- 1'"'--'-
($sib-exec
(inst-tension
(resultat
($var->
tension)))
) ) ) )

---

77
4.4.2
-
L'opérateur
environnement
L'opérateur environnement (§3.1.4) permet de spécifier une action se
ramenant à une recherche dans l'ensemble des instances partagées par des
opérateurs, contribuant à l'élaboration d'un même résultat. Il est implémenté à
l'aide
de la facette $var<-;
cette facette (§4.1.2) permet d'associer deux
attributs (pouvant appartenir à des schémas différents), en indiquant que l'un
des deux attributs prend la valeur de l'autre, dès que cette dernière est connue.
L'environnement d'évaluation est composé de l'ensemble des attributs des
méthodes actives à un moment donné. Ces attributs sont des traductions des
contextes des opérateurs correspondants. Une référence à l'opérateur
environnement est replacée par la facette $var<-, dont la valeur est calculée à
partir de l'environnement d'évaluation.
exemple
Considérons la traduction de l'opérateur INST-EPIL ci-dessus et supposons
que l'attribut tension% est évalué par l'opérateur suivant:
opérateur INST-TENSION
contexte
atcd-epil <- environnement;
résu Itat: tension;
.a.Q.1lQ.rl: proc6.
Lors de la traduction de l'opérateur INST-TENS\\ON,
l'environnement
d'évaluation est composé des attributs de la méthode INST-EP/L qui sont résultat,
atcd-epi/%, eeg%, tension%, et des attributs de la méthode INST-TENSION qui
sont résultat et tension%. La traduction de l'opérateur environnement tel qu'il
est spécifié revient à établir la liaison entre l'attribut tension% de l'opérateur
INST-TENSION, et celui de l'opérateur INST-EPIL. Cette liaison leur permettra de
référencer la même valeur. Pour faire la différence entre les différents
attributs de même nom, les ensembles d'attributs des opérateurs actifs sont
gérés sous forme de pile. La traduction correspondante se fera de la manière
suivante:

---

78
(def-sh '(INST-EPIL
(tension% ($un tension)
($sib-exec
(inst-tension
(a tcd-epi/%($var-nom
tensio-a tcd-epi/)
(tension-atcd-epi/
($var<-
atcd-epi/%
(resultat
($var-> tension)))
4.4.3 - Traduction des opérations
Une opération peut être utilisée dans les circonstances suivantes:
- elle peut être invoquée directement par l'utilisateur,
- elle peut être utilisée pour compléter la spécification d'un concept.
Dans ce paragraphe, nous présentons le schéma de traduction d'une opération.
Cette traduction présente quelques variations selon les cas.
al Invocation directe d'une opération par l'utilisateur
La définition d'une opération d'évaluation s'accompagne de la génération
automatique d'un schéma objet qui est évalué chaque fois que l'utilisateur
demande l'évaluation directe de l'opération. Par exemple, considérons
l'opération 0 définie comme suit:
opération 0 =
OP1 ~ OP2 .s.l.o..Qn OP3.
La définition de cette opération s'accompagnera de la génération du schéma ci
dessous:

---

79
(def-sh '(opération-o
(sorte-de (= objet))
(lui-même
($sib-exec
(OPt (resultat ($var-> lui-même)))
(OPt (resultat ($var-> lui-même)))
(OP3
(resultat ($var-> lui-même)))
) )
Si l'opération 0 est définie de la manière suivante:
opération 0 =
OP1 QJJ OP2 .Q.U. OP3.
sera traduite comme suit:
(def-sh '(opération-o
(sorte-de (= objet))
(0 p 1-a tt (liste-de CEt)
($sib-exec
(OPt (resultat ($var-> opt-att))))
(op2-att (liste-de CE2)
($sib-exec
(OP2 (resultat ($var-> op2-att))))
(op3-att(liste-de CE3)
($sib-exec
(OP3 (resultat ($var-> op3-att))))
) )
CEl, CE2 et CE3 sont les résultats spécifiés des opérateurs OP1, OP2 et OP3.
b) Utilisation d'une opération pour compléter la spécification d'un concept
Lorsqu'une opération est utilisée pour compléter la spécification d'lHJ
concept, elle est transformée en une liste de références à des schémas méthodes
rattachées à "attribut lui-même du schéma servant à traduire la structure de ce
concept.

---

80
La traduction des opérateurs composant cette opération présente quelques
différences selon qu'il s'agit d'un opérateur d'évaluation ou d'un opérateur de
visualisation. Dans le premier cas, l'opérateur a un résultat qui sera utilisé
pour compléter le concept, et dans le deuxième cas, le contexte de l'opérateur
doit être complété par la valeur du concept.
Exemple
Considérons l'opération 0 spécifiée de la manière suivante:
opération 0 =
OP 1 .s.i..o.Q.o. 0 P2 .sln.Q.o. 0 P3.
Supposons que cette opération soit utilisée pour l'évaluation d'un concept C1
suivant la spécification ci-dessous:
concept C1
eval: 0;
cette spécification sera traduite de la manière suivante:
(def-sh '(C1
(sorte-de
(= objet»
(lui-même
($var-nom
lui-c1)
($sib-exec
(OPt
(resultat ($var-> lui-c t)))
(OPt
(resultat ($var->
lui-ct)))
(OP3 (CE% $var-nom CE-TT)
(CE- TT ($var<- CE%))
-.!" .......-
-
(resultat ($var-> lui-ct))
'.-
t~

---

81
Cette traduction intègre la spécification d'une liaison ($var-»
entre l'attribut
résultat du schéma méthode et l'attribut lui-même du concept. Cette liaison
permet de considérer le résultat de la méthode comme valeur du concept.
Si l'opération est utilisée pour la visualisation c'est à dire rattachée à la
rubrique EVAL du concept, la traduction se fera comme suit:
(def-sh '(C1
(sorte-de
(= objet))
(lui-même
($var-nom
lui-c1)
($sib-exec . . .)
($pour-vi
(OPt (valeur
($var<-Iui-ct)))
(OPt (valeur ($var<- lui-ct)))
(OP3 (CE% $var-nom CE-Ct)
(CE-Ct ($var<- CE%))
(valeur ($var<- lui-ct))
Cette traduction intègre la spécification d'une liaison ($var<-) entre l'attribut
valeur du schéma méthode et l'attribut lui-même du concept. Cette liaison
permet d'utiliser la valeur du concept pour compléter le contexte de "opérateur
de visualisation.
4.4.4 -
L'attribut STATUT
L'évaluation du statut d'un concept peut être assimilé à une opération au
même titre que la visualisation et l'évaluation; en effet, elle se traduit par une
opération spécifiant sa sémantique. Sur le plan de l'implémentation en Shirka,
elle se traduit par un attribut de type "objet" ayant une facette $sib-exec. Les
méthodes associées à cette facette permettent de calculer la valeur de cet attrj~~!
---!", .. -
-
en fonction de celle des attributs de structure. L'attribut' statut se distingue des
autres attributs (sauf l'attribut implicite "lui-même") par le fait qu'il a une
.facette
$sib-exec, alors que les autres n'ont que des facettes de définition de
type.

---

82
4.5 - CONCLUSION
La plupart des notions définies dans Gide se traduisent par des
combinaisons relativement simples, de schémas Shirka; un opérateur se traduit
par un schéma de type méthode et une contrainte se traduit par un schéma de
type prédicat. La spécificité de Gide dans ces deux cas, consiste à intégrer
(parfois implicitement) à chaque schéma généré, un moyen de calculer chacun
de ses attributs. Les schémas méthodes utilisés sont des instances (et non des
classes), et sont de ce fait facile à utiliser et très proches des règles de
production.
Les expressions de concept se traduisent par des filtres permettant de
choisir des instances de concepts dans le dossier du malade.
Un concept est un regroupement de trois types de schémas: un schéma de
type objet, un ou plusieurs schémas de type prédicat, et un ou plusieurs
schémas de type méthode; ces trois types de schéma permettent de reprendre
facilement la structuration <attribut><contrainte><opération>. D'autre part, les
outils d'inférence utilisés dans Gide émanent de ceux de Shirka et ne posent
presque pas de problème d'implémentation.
Toutefois, certaines notions et compositions de Gide s'avèrent de traduction
complexe; la traduction des opérations par exemple varie selon le contexte de
référence, et la traduction de "opérateur environnement est soumise à la gestion
d'une pile des contextes des opérateurs actifs
Ces schémas de traduction ont été implémentés en Aida, un langage de
représentation d'image. Le choix de Aida a été motivé par les facilités de
représentation graphique qu'il offre et le fait qu'il soit un langage orienté objet.
L'utilisation de l'environnement graphique de Aida permet d'alléger les
contraintes syntaxiques des spécifications. D'autre part, les concepts de Gide
peuvent être assimilés à des objets Aida, ce qui facilite leur représentation
graphique.
- .!"."""-

---

83
5 - ANALYSE D'UN COMPTE-RENDU
MEDICAL
Le problème abordé dans ce chapitre est celui de l'analyse d'un compte-rendu
de consultation. Dans le cas du système Gide, il s'agit de le traduire en instances de
concepts. Ce compte-rendu est rédigé dans un style présentant des différences très
marquées (notamment sur le plan syntaxique) avec le Français courant. Ce
sous-langage s'avère être plus caractérisé par sa sémantique que par des
spécifications syntaxiques. Après avoir présenté le langage utilisé, nous présentons
les grammaires casuelles et les grammaires sémantiques, qui s'avèrent être de bons
outils pour spécifier et analyser un langage indépendamment de sa syntaxe. Nous
terminons par la présentation de la méthode sugérée dans Gide. Cette méthode nous a
permis, en spécifiant les démons par des opérateurs, d'illustrer la facilité avec
laquelle on peut implémenter un analyseur à démons à l'aide de la notion d'objet.
5.1 - LE LANGAGE UTILISE DANS LE COMPTE-RENDU
Le compte-rendu est formulé de façon à permettre, une transmission fidèle des
informations collectées pendant la consultation, et en faciliter l'utilisation par les
différentes personnes accédant au dossier, (le médecin traitant, le médecin
consultant, les sécrétaires chargées de la saisie). Ce compte-rendu est organisé en
paragraphes et chaque paragraphe ou sous-paragraphe, décrit une famille de concepts
(antécédents, examens, crises ....). Pour bien cerner les caractéristiques du langage
utilisé, nous allons examiner l'extrait de compte-rendu ci-dessous, qui décrit les
antécédents de la maladie.
ANTECEDENTS
Sur le plan personnel
Convulsions hyperthermiques à 8 mois. Convulsions souvent déclenchées lors des
orages quand il y a des coupures de courant.
Sur le QIan familial
crises de l'une de ses soeurs dans adolescence, avec photosensibilité.
..
-~.-
-.-

---

84
On trouve dans cet extrait de compte-rendu, deux caractéristiques principales:
a) pour les informations que le médecin peut cerner sans aucun risque d'ambiguïté, il
adopte un style laconique avec une syntaxe très dépouillée. " se contente d'énumérer
les formules décrivant les attributs des concepts qu'il cherche à exprimer, en
omettant certaines tournures nécessaires
à la correction syntaxique de la phrase,
mais qui ne sont pas porteuses d'information. C'est le cas, dans l'extrait de
compte-rendu ci-dessus, des formules telles que:
"convulsions hvperthermigue à 8 mois" et
"crise de l'une de ses soeurs dans adolescence avec photosensibilité"
Dans ces expressions, si on admet que le médecin cherche à décrire des antécédents de
la maladie, on peut facilement comprendre (malgré la syntaxe approximative) que
les mots soulignés, constituent les valeurs caractéristiques des antécédents décrits (
valeurs d'attributs du concept ATCD). Cette formulation facilite la rédaction du
compte-rendu et dans une certaine mesure sa compréhension.
b} Le texte comporte des passages n'ayant en apparence aucun rapport avec le sujet
traité, comme par exemple, le passage relatif à l'orage ou aux coupures de courant.
Cependant, en tenant compte des caractéristiques de l'épilepsie (cf § 1.2), et du fait
que le dossier s'étoffe au fil des consultations, on ne peut se permettre d'omettre ou de
reformuler ces passages. En effet, lorsqu'on mentionnera la photosensibilité de
l'épilepsie chez la soeur du patient (ceci peut se faire au bout de plusieurs
consultations), on pourra alors faire le rapprochement avec les jeux de lumière dûs
à l'orage ou aux coupures de courant, et s'orienter vers un diagnostic d'épilepsie
génétique. Même si le système n'a pas la connaissance nécessaire pour réaliser de
manière autonome ces rapprochements, il est important de garder ces passages dans
le dossier.
Le langage utilisé par le médecin dans le compte-rendu est un langage composé
de rubriques sans contraintes syntaxiques fortes, mais qui autorise également des
enrobages car ils peuvent après apport de nouvelles informations, s'avérer porteurs
de renseignements utiles.

---

85
5.2 - ANALYSE
D'UN TEXTE NE REPONDANT PAS
A DES CRITERES
SYNTAXIQUES PRECIS
Dans ce paragraphe, nous présentons quelques formalismes de spécification du
langage naturel. Nous nous attachons surtout à ressortir leur capacité à représenter
un texte ne répondant pas à des critères syntaxiques précisées d'avance. Cette capacité
est liée pour un formalisme donné, aux outils dont il dispose pour prendre en compte
de la sémantique du langage. Pour chacun des formalismes abordés, nous tenterons
d'évaluer cette possibilité.
5.2.1 - Limites des méthodes basées
sur des critères
essentiellement
syntaxiques
Le langage utilisé dans la formulation d'un compte-rendu de consultation en
épilepsie, ne répond pas à des critères syntaxiques très stricts; c'est d'ailleurs le cas
dans beaucoup de domaines de la vie courante (télégraphie, petites annonces,
bulletins météo ...). Les méthodes d'analyse basées sur la notion de grammaire telle
qu'elle fut axiomatisée à l'origine par Chomsky [CHaM 59] s'avèrent inadaptées, car
elles accordent une trop grande importance à la forme syntaxique de la phrase. D'une
manière générale, les formalismes liant systématiquement la sémantique à la
syntaxe, comme les grammaires attribuées [KNUTH 71] et les grammaires logiques
[COLM 78] ne conviennent, pour une large part, qu'aux langages artificiels utilisés en
informatique. En effet, leur sémantique comporte un "point fixe" qui est la structure
de l'ordinateur. Les tentatives d'utilisation des grammaires attribuées pour l'analyse
du langage naturel montre bien les limites de ces formalismes. Par exemple, Bien
[BIEN 81] propose une méthode basée sur les grammaires attribuées pour l'analyse
des phrases du Polonais. Cette méthode repose sur la caractérisation d'un type précis
de relâchement syntaxique qui est "ordre libre des mots. Toutes les autres
caractéristiques syntaxiques de la phrase doivent être définies et respectées. D'autre
part, cette méthode n'envisage pas l'existence de termes non significatifs dans la
phrase. En outre, pour résoudre le problème des déclinaisons, elle utilise un
dictionnaire très volumineux.

---

86
Pour remédier aux limitations des grammaires attribuées, Chomsky [CHOM 65]
propose les grammaires transformationnelles. Celles-ci tentent de dinstinguer la
structure profonde (sémantique) de la phrase, de sa forme de surface (syntaxe),
mais l'influence de la syntaxe sur la forme profonde de la phrase reste très forte.
5.2.2 - Les grammaires casuelles
Comme les grammaires transformationnelles, les grammaires casuelles [FILM
68] sont fondées sur l'hypothèse qu'une phrase a une forme profonde différente de sa
forme de surface, et que la sémantique de la phrase dérive de sa forme profonde. Ce
qui distingue les deux types de grammaire c'est le fait que
les gammaires casuelles
démarquent très nettement, la structure profonde de la phrase, de sa syntaxe.
D'après [FILM 68]. l'analyse d'un texte vise à reconnaître les concepts qui y
sont développés, ainsi que les relations entre ces concepts. Par exemple, si on
considère que la structure profonde d'une phrase est centrée sur le verbe, chaque
expression dans la phrase doit être liée au verbe selon une relation particulière.
Dans le formalisme des grammaires casuelles, ce sont ces relations qui déterminent
les Q.aS.. Cette notion de cas est à rapprocher de la notion de dépendance conceptuelle
[8HANK 77] dont le principe général est d'associer à un gourverneur, des dépendants.
Le cas, en tant qu'expression de relation entre concepts, doit être distingué de la
fonction syntaxique du groupe de mots qui représente le concept. L'exemple
ci-dessous, développé dans [ZWEI 85], montre que le sujet d'un verbe n'est pas
toujours l'acteur de l'action décrite par la phrase:
1 - Olivier casse la vitre avec un marteau.
2 - Le marteau casse la vitre.
3 - La vitre casse.
Les trois phrases décrivrent le même événement mais voient successivement le
sujet du verbe "casser" représenter l'acteur, l'instrument et l'objet de l'action.

---

87
La définition des cas varie selon les auteurs. Leur nombre est cependant limité
à moins d'une dizaine par chacun d'eux. Les cas ci-dessous sont les plus couramment
utilisés :
ao..e.o.1 (ou acteur)
celui qui exerce l'action
instrument
moyen utilisé par l'acteur
locatif
lieu
d.atif
bénéficiaire
neutre
(objet, patient, thème)
: celui qui subit l'action.
Dans les trois phrases ci-dessus, Olivier est l'acteur, la
vitre est l'objet et le
marteau
l'instrument.
Avec
le
formalisme
des
grammaires
casuelles,
la
compréhension d'un texte est basée sur l'identification des .c..a..s. des verbes ou des
concepts spécifiés dans le texte. Dans certains systèmes, la définition des cas, n'est
pas exclusivement centré sur le verbe mais représente d'une manière générale, les
liens entre concepts. Les groupes de mots remplissant un cas sont sélectionnés sur
des critères essentiellement sémantiques. La forme syntaxique de la phrase, peut
cependant être accessoirement utilisée pour déterminer les cas des verbes.
Le principal problème posé par l'utilisation des grammaires casuelles, est la
difficulté de définition de cas suffisamment généraux, pour s'adapter à tous les
domaines.
5.2.3 - Les grammaires sémantiques
Les grammaires sémantiques [BURT 76] ne constituent pas une théorie à
proprement parler. Il s'agit d'une extension des grammaires à contexte libre dans
laquelle la classification des mots n'est plus basée uniquement sur des critères
grammaticaux, mais aussi sur leur signification. Les grammaires sémantiques
permettent de comprendre un texte même si certaines contraintes syntaxiques (non
caractérisées par avance), ne sont pas respectées. La compréhension des petites
annonces immobilières telle qu'elle est faite dans le système Havane [COUR 87],
[ROBIN 87], est basée sur la subdivision d'une annonce en rubriques. Ces rubr:.i.Ques
peuvent être considérées comme les non-terminaux d'une grammaire sémantique
(grammaire d'archipels dans Havane).

---

88
Ces non-terminaux ne sont pas définis à partir de critères grammaticaux
«nom>, <adjectib, <verbe>), mais prennent en compte la sémantique de "annonce. Ce
sont par
exemple
<sens-transaction>,<nature-habitation>,
<nbre-de-pièces>.
L'utlilisation de ce formalisme dans Havane permet de faire une analyse plus flexible,
autorisant l'ordre libre des mots, et l'existence de bruit entre les rubriques.
Les grammaires sémantiques permettent de construire des analyseurs
efficaces. Leur utilisation pose cependant un problème de portabilité. On se rend
facilement compte que la définition des symboles d'une grammaire sémantique, dépend
du domaine d'application. Cette utilisation, démontre surtout qu'un modèle sémantique
n'est précis que s'il s'applique à un domaine bien circonscrit.
5.2.4 - Notion de sous-langage
La
constante
de
la
démarche
utilisée
dans
les
grammaires
transformationnelles, les grammaires casuelles et les grammaires sémantiques, est
la recherche d'un moyen de prendre en compte la sémantique du langage à analyser.
Une remarque originale faite sur ce point par Harris [HARRIS
68], est que la
sémantique dérive des différentes combinaisons syntaxiques, or ces combinaisons
traduisent les schémas d'actions ou d'évènements caractéristiques du domaine. Dans le
même ordre d'idée, d'après [FRIED 87] il suffit de dépouiller le texte relatant les
évènements d'un domaine spécialisé, de ses tournures de style et des accords
grammaticaux, pour voir emmerger les structures décrivant la sémantique du
domaine sous-jacent. Ces structures, définisssent le ~ous-Iangage propre à ce
domaine. Dans le traitement du dossier d'un malade en épilepsie par exemple, le
sous-langage de formulation du dossier est déterminé par avance, par la donnée des
concepts utilisables dans un compte-rendu.
Les expressions significatives du texte
sont celles qui décrivent les attributs de tels concepts. Toute autre expression est
considérée comme du bruit.
Le principal défaut des grammaires casuelles était de chercher à définir des
"cas" généraux, adaptables à tous les domaines. En se restreignant à un domaine
précis, les schémas d'action du domaine peuvent être pris comme base de départ pour
. - j"""'-
la définition des "cas" spécifiant la sémantique de ce domaine.

---

89
La notion de sous-langage, apparaît comme une synthèse des grammaires
sémantiques et des grammaires casuelles. En effet, la définition d'un sous-langage
implique l'étude d'un domaine bien circonscrit. Cette étude permet d'identifier les
structures sémantiques du domaine étudié et ces structures sont généralement très
proches des structures de cas. En outre, l'identification des schémas d'action du
domaine, peut permettre de dissocier les caractéristiques linguistiques du langage, de
ses fonctions communicatives et donc d'envisager la compréhension du message porté
par un texte, même si sa forme syntaxique n'est pas bonne.
5.2.5 - Les analyseurs à démons
Les grammaires casuelles et les spécifications sémantiques qui s'en
rapprochent, peuvent être facilement interprétées par des analyseurs à démons [ZWEI
85]. [COMM 86]. Les analyseurs à démons permettent de réaliser une analyse guidée
par les événements. Leur principe consiste à cerner d'abord le thème central de la
phrase ou du texte, puis à chercher (à l'aide des démons), les informations
complémentaires qui viennent qualifier ce thème. Ce principe est assez proche de
celui des grammaires casuelles, où on identifie dabord le verbe ou le concept, et où ce
dernier permet de prédire les "cas" qui lui sont associés.
Contrairement aux analyseurs construits à partir des règles de réécriture et
des réseaux de transition augmentés, les analyseurs à démons ne se rattachent pas
directement à une représentation syntaxique élaborée de la phrase. Leur but est de
construire une compréhension de la phrase ou du texte en utilisant les démons et en
s'appuyant en certains points seulement sur une analyse syntaxique. Un analyseur à
démons n'examine pas tous les mots d'une phrase, mais concentre son attention sur
certains concepts. Chaque fois qu'il rencontre un nouveau concept, il mémorise sa
signification et crée des démons chargés de compléter sa compréhension.
Globalement, un analyseur à démons peut être scindé en deux tâches: une tâche
qui traite les mots, et une tâche qui gère les démons. A chaque concept reconnu, les
démons associés sont activés. Le processeur de démons teste ensuite tous les démons
encore actifs. L'activité d'un analyseur à démons est organisée autour des trois
""':"
-,r:- ....-
structures de données [ZWEI 85] :

---

90
- la mémoire de travail où est assemblée la représentation du sens du texte,
- le concept courant qui est formé de l'ensemble d'informations s'attachant au
dernier mot lu,
- la pile des démons indiquant les prédictions engendrées par la lecture de la
phrase jusqu'au mot courant.
A la lecture de chaque
mot, son concept associé est chargé en mémoire
conceptuelle et devient le concept courant; son paquet de démons est ajouté à la
pile des démons; chaque démon de la pile est ensuite examiné en partant du plus
récent au plus ancien.
5.3 - COMPREHENSION DU COMPTE-RENDU DE CONSULTATION
DANS
GIDE
L'analyse d'un compte-rendu telle que nous la décrivons ici, consiste à
déterminer les concepts et les tâches qui peuvent être instanciés à partir de ce
compte-rendu. Cette analyse peut être vue comme la recherche des relations de
taxonomie et de méronomie (relation partie de) qui existent entre les mots du
texte. Le principe de cette analyse est basé sur la similitude entre les relations
liant les différents "cas" au verbe dans les grammaires casuelles, et les relations
entre un concept et ses attributs dans le formalisme utilisé dans Gide.
L'algorithme sugéré est celui d'un analyseur à démons. Ce choix évite d'imposer de
nouvelles contraintes syntaxiques au médecin. En outre, les démons peuvent être
spécifiés dans certains cas par des opérateurs tels que nous les avons définis au
chapitre 3. L'analyse se fait en trois phases :
- l'analyse atomique qui a pour but d'identifier les mots ou groupe de mots
susceptibles de contribuer à la transmission d'informations dans le compte
rendu. Les formules de politesse et plus généralement les termes d'enrobage
sont abandonnés à cette étape.
- la prédiction des concepts susceptibles d'être instanciés à partir de la
phrase lue.
. -- !".- .....- -

---

91
- l'analyse conceptuelle qui permet de déterminer les attributs des concepts
prédits à l'étape précédente en utilisant les informations enregistrées dans la
mémoire de travail.
Cette
structuration
de
l'analyse
est
basée
sur
le
principe
que la prédiction d'un concept est équivalente à l'identification des gouverneurs
dans les grammaires casuelles, les cas à identifier étant les attributs du
concept prédit.
5.3.1
-
L'analyse atomique
L'analyse atomique correspond à la phase d'analyse lexico-morphologique
habituelle des analyseurs de langages naturels. Cette phase utilise le dictionnaire
des atomes et les démons décrits ci-dessous au paragraphe 5.3.1.2, ainsi qu'une
mémoire de travail constituée de la liste des mots ou groupe de mots considérés
comme porteurs d'information dans le texte lu.
Les démons utilisés à cette phase de l'analyse servent à regrouper les mots
formant la même entité sémantique. L'analyse morphologique est résolue par
l'inclusion dans une entrée du lexique, des variantes orthographiques du mot
considéré. Cela est rendu possible par le fait que le domaine d'application est
restreint et surtout parce que l'élément central de J'analyse est "identification du
concept à instancier. Une fois ce concept identifié, les variations morphologiques
de ses attributs ont moins d'impact sur son instanciation que s'il s'agissait de
l'analyse syntaxique d'une phrase.
5.3.1.1
- Structure du dictionnaire des atomes
Chaque entrée du dictionnaire des atomes décrit une famille de mots
susceptibles d'apparaître dans le compte rendu médical en précisant les actions
découlant de son apparition dans Je texte. Elle est composée des champs suivantes:
.--1''' ...-
-
,-

---

92
- l'identificateur de sa catégorie sémantique,
- la liste des formes orthographiques de "atome décrit,
- la liste des attentes inconditionnelles,
- la liste des attentes optionnelles.
Une entrée du dictionnaire des atomes se présente comme suit:
(c12
(crise crises)
- ((c13
1)
(c14
1))
Cette entrée décrit un atome de catégorie c12. La liste de ses formes
syntaxiques est (crise crises). Elle n'a pas d'attente inconditionnelle. Elle peut
être immédiatement suivi (position 1) d'un atome de catégorie C13, ou d'un atome
de la catégorie c14.
a) variantes syntaxiques ou orthoaraphiques
Ce champ permet de présenter les différentes façons dont l'atome peut être
orthographié dans le texte. D'après l'exemple ci-dessus "'crise" et "crises" sont
considérés comme signifiant la même chose.
b) catégorie sémantique
Il s'agit d'un
identificateur permettant de référencer l'atome.
c) liste des attentes inconditionnelles
Chaque élément de cette liste est composé d'un identificateur d'atome et d'un
entier. L'identificateur reférence un atome qui doit être regroupé avec l'atome
décrit. L'entier indique la position à laquelle doit se trouver le nouvel atome dans
la phrase relativement à l'atome décrit.
Dans l'exemple
ci-dessus, il n'y a pas d'attente inconditionnelle. Lorsqu'il y
en a une, l'apparition de l'atome dans le texte n'est considéré comme significative
que si toutes ses attentes inconditionnelles sont satisfaites à la fin de la phrase.
,-

---

93
d) liste des attentes optionnelles
Les éléments de cette liste ont la même structure que ceux de la liste des
attentes inconditionnelles. La différence entre les deux types d'atome tient au fait
que les attentes optionnelles peuvent ne pas être satisfaites en fin d'analyse.
Les
attentes
(inconditionnelles ou
optionnelles)
sont les paramètres
d'activation des démons.
5.3.1.2 - Les démons
Tous les démons utilisés pendant l'analyse atomique sont des représentants d'un
processus générique dont le rôle est de chercher les atomes à regrouper. Certains
de leurs paramètres prennent pour valeur une attente optionnelle ou une attente
inconditionnelle de l'atome qui les active. Ces démons ont les quatres paramètres
ci-dessous :
- l'atome demandeur de la recherche ; il s'agit de l'atome dont
la
reconnaissance a provoqué l'activation du démon. C'est avec cet atome que va
être associé celui que le démon est chargé de repérer;
- la catégorie de "atome à rechercher; il s'agit de l'atome que le démon doit
rechercher dans la mémoire du travail;
- la position de la recherche, est un entier permettant de préciser dans quelle
zone de la mémoire de travail l'atome commandé doit être cherché. Elle a la
même signification que la deuxième rubrique d'un élément de la liste des
attentes que nous avons présentées dans la description du dictionnaire des
atomes;
- condition de désactivation du démon.
Du point de vue des conditions de désactivation, il y a deux sortes de démons:
. Les démons qui se tuent dès que leur première tentative de recherche
se termine,
. les démons qui continuent la recherche jusqu'à la fin de la Jecture<p~ la
phrase.
,.
Tous les démons se tuent dès que leur recherche aboutit à un succès.

---

94
Exemple
Considérons maintenant l'extrait du dictionnaire des atomes ci-dessous.
1- (C12 (crises crise)
- ((c13 1) (c14 1)))
2 - (C11
(frère, soeur, mère)
-)
3 - (C13
(généralisé
généralisée partiel)
-
-)
4 - (C14
(secondaire primaire)
-)
5 - (C9 âge âgé) ((C10 1)) -
6 - C10 (an ans) ((C1
- 1))
7- Les valeurs numériques sont de catégorie C1;
8 - Les chaines n'appartenant à aucune classe (considérées comme du bruit) sont
classées CO.
A l'aide de cet extrait du dictionnaire, nous allons faire l'analyse atomique de la
phase suivante:
"Son frère a eu une crise unique de type généralisée à l'âge de 15 ans"
· Le mot "son" est lu ; aucun atome du dictionnaire ne lui correspond. Il est enregistré
dans la mémoire de travail M-T avec la cétégorie Co (considéré comme un bruit).
· Le mot "frère" est lu ; d'après le dictionnaire des atomes, ce mot correspond à un
atome de catégorie C11. JI est enregistré comme tel dans la mémoire de travail.
Comme la liste de ses attentes est vide, aucun démon n'est activé.
· "a" est considéré comme un bruit ;
· "eu" est considéré comme un bruit;
· "une" est considéré comme un bruit;
._.!" .... --.
· "crise" correspond à un atome de catégorie C12. D'après le dictionnaire, il peut'ètre
complété par un atome de la catégorie C13 ou par un atome de la catégorie C14.

---

95
Des démons d'attente de ces catégories d'atome sont activés. La mémoire de travail
contient: Cornp1 (C11 frère) ; Comp2(C12 crise) et la pile des démons contient:
démon 1 (comp2 C13 1); démon2 (comp2 C14 1)
Ce contenu de la pile des démons, indique qu'un démon attend un atome de la
catégorie C14 pour compléter la composante comp2 de M-T et un autre démon attend
un atome de la catégorie C13 pour compléter la composante comp2 de la mémoire de
M-T.
"unique" est comme un bruit;
"de" est considéré comme un bruit;
"type" est considéré comme un bruit;
"généralisé" correspond à un atome de catégorie C13.
Le composé comp3 (C13 généralisé) est créé en mémoire de travail.
Le traitement des démons est lancé.
Le test d'exécution de dem2 (comp2 C14
1) n'est pas vérifié. Il est désactivé sans
autre effet. Le test d'exécution de dem1 (comp2 C13 1) est vérifié; il met à jour la
mémoire de travail et est désactivé. Cette mise à jour combine les composés comp2 et
comp3 et les met sous la forme suivante:
Comp2 (C12 crise (C13 généralisée))
Il n'y a plus de comp3 en mémoire de travail et la pile des démons est
actuellement vide.
· "a" est considéré comme un bruit;
· "1" est considéré comme un bruit;
· "âge" correspond à un atome de la catégorie C9. Le composé comp3 (C9 âge) est créé
en mémoire de travail. Le démon dem1 (comp3 C10 1) est empilé.
· "de" est considéré comme un bruit
· "15" correspond à un atome de la catégorie C1 (un nombre)
Le composé comp4 (C1 15) est créé en mémoire de travail.

---

96
."ans" correspond à un atome de la catégorie C1 0
Un composé compS (C10 ans) est créé en mémoire de travail.
Le démon dem1 (compS C1
-1) est empilé.
Le test d'activation de dem1 (compS C1
-1) est vérifié. Il s'exécute et met les
composés comp4 et compS sous la forme suivante:
comp4 (C10 ans (C1
1S))
Le test de dem1 (comp3 C10 1) est également vérifié. Il s'exécute et modifie
la mémoire de travail de la manière suivante:
comp3 (C9 âge (C10 ans (C1
1S)))
On arrive à la fin de la phrase. La pile des démons est vide. Elle peut ne pas
l'être dans certains cas; tous les démons encore actifs sont alors désactivés.
Les atomes suivantes ont été reconnus:
(C11
frère)
(C12 crise
(C13
généralisée))
(C9 âge (C10 ans (C1
1S)))
Les mots "son"
"a"
"fait"
"une"
"unique"
"de"
"type"
"a"
"1"
sont
considérés comme du bruit.
Lorsqu'un atome de la classe Co (du bruit) est lu, il est gardé en mémoire de
travail mais n'entraîne ni d'activation de démon, ni d'incrémentation du nombre
d'atomes reconnus. Ainsi, dans l'exemple ci·dessus, l'atome "frère" est considéré
comme le premier de la phrase puisque "son" est considéré comme du bruit. L'analyse
atomique permet de construire le domaine d'évaluation des opérateurs qui seront
utilisés dans la phase de prédiction et d'instanciation.
-- !"'.- ....-

---

97
5.3.2 - PREDICTION DES CONCEPTS DEVELOPPES DANS
LE COMPTE-RENDU
Après chaque nouvelle identification d'atome dans le texte, la phase de
prédiction est lancée pour sugérer les concepts à instancier à partir de la mémoire de
travail. Nous distinguons deux types de prédiction:
Les prédictions heuristiques: ce sont les prédictions déclenchées par l'ajout
d'un nouvel atome dans la mémoire de travail. Dans l'exemple présenté au paragraphe
précédent, l'identification de l'atome (c11 frère) peut déclencher la prédiction du
concept ANTECEDENT sous "hypothèse que la seule occasion où on parle de quelqu'un
d'autre que le patient dans un dossier, c'est lors de la description des antécédents. De
même "identification, de l'atome (c12 crise (c13 généralisée)) entraînera la
prédiction du concept CRISE.
Les prédictions structurelles sont induites par la prédiction heuristique d'un
concept dont certains attributs sont structurés en concept. Par exemple, si on
suppose définis les concepts PERSONNE, DATE, ADRESSE et que le concept PERSONNE a
un attribut de type DATE (pour date de naissance) et un attribut de type ADRESSE, la
prédiction du concept PERSONNE entraîne la prédiction structurelle des concepts DATE
et ADRESSE.
L'ensemble des prédictions heuristiques est gérée sous forme de pile. Chaque
élément de cette pile constitue la racine de l'arbre des prédictions structurelles
qu'elle induit. Le concept actif (concept en cours d'instanciation) est le concept se
trouvant au sommet de la pile des prédictions. Il cesse d'être actif lorsqu'il est
entièrement instancié ou lorsqu'une nouvelle prédiction heuristique est faite. A la fin
de la lecture de la phrase, l'instanciation des concepts prédits et non instanciés est à
nouveau tentée. Si elle échoue à nouveau, on considère que la prédiction a
définitivement échouée.
-l"':-""-

---

98
a)Spécification d'une prédiction
Les prédictions heuristiques telles que nous les avons présentées, constituent
une catégorie de connaissance experte qui doivent être formulées par un médecin
ayant une bonne expérience de la lecture des dossiers.
Une prédiction est spécifiée par un opérateur (cf § 3.1.4). Les conditions (ou
motivations) de la prédiction sont spécifiées par le contexte de cet opérateur, et
l'action d'un tel opérateur consiste à modifier la liste des prédictions en y ajoutant sa
propre prédiction. Les motivations de la prédiction (contexte de l'opérateur) peuvent
porter sur les prédictions déjà réalisées, sur les concepts déjà instanciés ou sur le
contenu de la mémoire de travail. Les expressions de concept spécifiées dans le
contexte d'un opérateur de prédiction, s'évaluent à partir des instances identifiées
dans le compte-rendu en cours d'analyse et non pas à partir du dossier dans son
intégralité. La référence à la liste des prédictions se fait à l'aide de "opérateur
PREDICTION et la référence au contenu de la mémoire de travail se fait à l'aide de
l'opérateur ATOME.
L'opérateur ATOME permet de rechercher un atome d'une catégorie donnée dans
la mémoire de travail. Le résultat produit c'est la représentation orthographique
qu'avait cet atome dans la phrase. Le schéma Shirka définissant cet opérateur se
présente comme suit:
(def-sh '(atome
(sorte de
(=
opérateur))
(nom-fct
($valeur chercher-atome))
(argument
($un
symbole)))
Lors de l'utilisation de cet opérateur, l'attribut
araument prend pour valeur
le nom de la catégorie dont on cherche une variante orthographique. L'attribut
résultat (implicite dans les schémas opérateurs) prend pour valeur (après exécution
de la méthode). la variante orthographique de cette classe, utilisée dans le texte. La
recherche effictive est réalisée par la fonction "chercher-atome".
- !,.~ ,..-
L'opérateur PREDICTION permet de vérifier si un concept de type donné a été
'. -
,-
prédit en consultant la liste des concepts prédits.

---

99
Sa spécification en terme de schéma Shirka se présente comme suit:
(def-sh
'Prédiction
(sorte-de
(= opérateur)
(nom-fct
($valeur chercher-prédiction))
($argument ($un
symbole)))
b) Exemple de prédiction
opérateur PRED1
contexte
C11
<- atome,
ATCD <- Prédiction,
Crise;
Résultat : crise.
Cet opérateur exprime la prédiction suivante :
Si l'atome C11
a été identifié dans la dernière phrase lue, si le concept
ATCD a déjà été prédit et si le concept CRISE a déjà été instancié, prédire à nouveau le
concept CRISE.
d) Déclenchement des prédictions
L'ensemble des opérateurs de prédiction sont regroupées par une opération.
C'est l'évaluation de cette opération qui déclenche l'évaluation de ces opérateurs et
réalise les prédictions.
Si on suppose par exemple qu'il y a trois opérateur de prédiction PRED1,
PRED2, PRED3, ces opérateurs sont regroupés dans l'opération PREDIRE de la manière
suivante:
opération PREDIRE =
PRED1 ou PRED2 ou PRED3.
-l" ....'- .
L'évaluation de l'opérateur PREDIRE, entraîne l'évaluation de tous les opérateurs de
prédiction. Ceux-ci agissent par effet de bord sur la liste des concepts prédits

---

100
5.4 - Instanciation des concepts prédits
A chaque concept défini, est associé une tâche servant à l'instancier lors de
l'analyse du compte-rendu. Chaque opération composant cette tâche permet d'évaluer
un attribut élémentaire de ce concept. L'évaluation des attributs structurés est
spécifié par des sous-tâches.
Exemple
Considérons le concept ATCD composé des attributs
personne, époque, nature,
mesure-prise.son instanciation peut être spécifiée par la tâche suivante:
tâche EVAL-ATCD
Structure:
C11,
EP1 ou cs,
OP2 sinon OP3,
C17;
Présentation:
personne <- C11,
époque <- EP1 ou cs,
nature<- OP2 sinon OP3,
mesure-prise <- C17;
fin.
Malgré le rapprochement apparent sur le plan syntaxique, cette tâche présente sur le
plan sémantique des différences importantes
par rapport aux tâches définies au
paragraphe 3.1.?Ces différences portent sur les points suivants:
-les expressions utilisées dans la structure de cette tâches se refèrent soit au
contenu de la mémoire de travail créé lors de l'analyse atomique, soit aux instances de
concepts créées à partir de la phrase en cours d'analyse. Ces expressions sont soit des
expressions d'atomes, soit des expressions de concepts;
- sur le plan de l'utilisation du résultat de l'évaluation, tous les éléments résultant
~.':"
-:!'l',,.,- -
de l'évaluation de la structure de cette tâche sont destinés â composer sa présentation.
cette tâche peut être assimilée à un opérateur d'évaluation du concept pour lequel il
est défini.

---

101
Dans l'exemple ci-dessus, CS, C11 et C17 sont des identificateurs d'atome. EP1, OP2
et OP3 sont des opérateurs.
La première ligne de cette tâche permet de spécifier que s'il existe dans la
mémoire de travail un atome de type C11 alors, considérer cet atome comme valeur
de "attribut personne du concept ATCD en cours d'instanciation.
Supposons que "attribut EP1 soit spécifié comme suit:
opérateur EP1
contexte:
C9,
C1,
C10;
action: transformer-age-epoque;
resultat: entier.
Cet opérateur spécifie que s'il y a dans la mémoire de travail un atome de type C9, un
atome de type C1
et un atome de type C10, alors on exécute
l'action
transtormer-age-epoque. Cette action permet de convertir l'âge en "enfance",
"adolescence".... Dans la spécification de l'évaluation du concept ATCD. Si la période où
a été constaté l'antécédent est exprimée par l'âge, cette opérateur sera utilisé pour
faire la conversion.
5.5 • CONCLUSION
Les deux objectifs visés par la méthode proposée consistent à comprendre le
compte-rendu de consultation sans passer par une spécification syntaxique
encombrante, et construire un système qui forme avec la représentation du dossier,
un ensemble homogène.
La methode d'analyse proposée est une adaptation des analyseurs à démons. Cela
permet de s'affranchir pour une large part, des contraintes syntaxiques; d:avtre
-!".~ ---
part, la prédiction et f'instanciation de concepts à partir du compte-rendu est
spécifiée à "aide d'opérateurs, d'opérations et de tâche, ce qui permet d'utiliser le
même formalisme que pour la représentation sémantique du dossier.

---

102
CONCLUSION
Nous avons proposé un formalisme pour la représentation sémantique· du
dossier d'un malade en épilepsie. Ce formalisme doit également être un outil de
spécification,
utilisable par un
épileptologue qui est un
expert non
informaticien;
à ce titre, ce formalisme doit être simple, et prendre en
compte les spécificités de ('épilepsie.
Le formalisme proposé est une synthèse des L.O.O. et des R.C.O.; en effet, la
structuration des concepts en <attributs><contraintes><opérations> est une
extension de la structuration <attributs><méthodes> qui caractérise les L.O.O ..
Cette structuration est basée sur la classification des facettes habituellement
utilisées dans les R.C.O..
Dans ce formalisme, les éléments de base que sont les concepts et les
opérateurs sont indépendants les uns des autres. A la différence des L.O.O. où
les méthodes sont intégrées à l'environnement d'un objet donné, les opérateurs
et les concepts ont une indépendance réciproque assez grande, bien qu'il soit
possible pour un opérateur de référencer un concept dans son contexte. Cette
autonomie des éléments de base facilite la multi-utilisation et les références
globales dans les spécifications.
Le formalisme proposé possède également les avantages essentiel des
formalismes mixtes; en effet, la formulation et la sémantique des opérateurs et
des opérations intègrent les caractéristiques essentielles des règles de
production que sont la modularité, l'indéterminisme, et le polymorphisme. La
définition des concepts permet de guarantir une bonne structuration des
informations statiques du dossier. Elle permet d'ajouter aux éléments
d'inférence dynamique que sont les opérateurs et les opérations, des éléments
d'inférence structurelle que sont l'héritage et l'utilisation des valeurs par
défaut. L'association des opérations aux concepts permet d'avoir le pouvoir
d'expression des formalismes intégrant les règles de production et la notion
- rI' -- .
d'objet.

---

103
Ce
formalisme
offre
également des notions originales telles que
l'organisation des concepts en famille, la propagation des informations par
mimétisme et le statut des concepts. La propagation des informations par
mimétisme
améliore
les
possibilités
de
traitement des
informations
imprécises ou approximatives. Le statut d'un concept permet d'une part de
synthétiser les informations que regroupe ce concept, et d'autre part de
formuler des abstractions à partir d'instances incomplètes.
Ce formalisme est utilisé pour élaborer la synthèse du dossier; le dossier
original est maintenu sous une forme non structurée, formée d'un ensemble
d'instances de concepts, ce qui facilite la collecte d'informations à partir de
sources éparses. De cette forme non structurée, le système peut produire des
synthèses appropriées en utilisant des bases de
structuration virtuelle que
sont les tâches, et palier ainsi au caractère volumineux et touffu du dossier. La
spécification des entités composant le dossier en terme de concepts, facilite la
constitution incrémentale du dossier, car chaque concept est une entité
autonome.
Ce formalisme sert également
à spécifier (à partir de sa sémantique) le
langage utilisé pour la formulation d'un compte-rendu de consultation.
L'algorithme proposé pour l'analyse du compte-rendu peut ainsi être spécifié à
l'aide de la notion d'objet et constituer
avec le sous-système réalisant la
synthèse, un ensemble homogène.
la maquette actuelle du système est programmée en Shirka et en Aida.
Shirka est utilisé pour la gestion de la base des connaisances, et Alda est utilisé
pour
la
programmation
de
l'interface
avec
l'expert
et
l'utilisateur.
L'utilisation des primitives graphiques de Aida permet d'obtenir très
facilement un interface agréable à utiliser mais pourrait s'avérer inadapté
pour un système d'analyse du compte-rendu prenant en compte le traitement de
certaines ambigüités, des énumérations et des conjonctions.
. -!"'-~ ..,-.-
,-

---

104
BIBLIOGRAPHIE
(ADA 85]
An object design handbook for ADA software,
EVB Software Engineering Inc., janvier 1985.
[AIKINS 79]
J. Aikins
Prototypes and production rules. An approach to knowledge
representation for hypotheses formations,
Stanford Heuristic Programming Project, july 1979.
[ALBERT 83]
P. Albert
KOOL : représentation des connaissances,
Bigre + Globule, journées d'études sur les langages orientés objets,
décembre 1983.
(ALTY 84]
J.L. Alty, M.J. Coobs
Expert systems: concepts and examples,
NCC Publication 1984.
[BAIL 87]
C. Bailly, J.F. Chaline, H.C. Ferri, P. Y. Gloess, B. Marchesin
Les langages orientés objets,
Cepadues édition, août 1987.
[BEN 851
Ch. Benoit, Ch. Pherivon
Le modèle objet: analyse et évolution,
Bigre + Globule N° 45, Octobre 1985.
[BIEN 81]
J. S. Bien
~arsing free word order langage in prolog,
Computation al Iinguistics ii UW report n° 107, 1982.
[BIRTS 73]
G. Birtswistle, O. Aahl, B. Myhrhang, K. Nygoard
SIMULA begin,
Oetrocelli charter, New-york 1973.

---

105
[BRIOT 85]
J. P. Briot
Les méta-classes dans les langages orientés objets,
congrès AFCET-RF lA, Grenoble, novembre 1985.
[BOBR 82]
D. Bobrow, M. Stefik
Rule-oriented programming in loops,
Knowledge-based VLSI Design Group, Memo KB-VLSI-82-22,
Xerox corporation, 1982.
[BONN 86]
A. Bonnet
Intelligence artificielle : promesses et réalités,
interédition, 1986.
[BRAC 83]
R. J. Brachman
What is IS-A is and isn'nt: an analysis of taxonomie links in sémantic
network,
COMPUTER (Knowledge representation) oct. 1983.
[BURT 76]
R. R. Burton
Semantic grammars : an engineering for constructing natural langage
understanding systems,
BBN report n° 3453, 1976.
[CHOM 59]
N. Chomsky
On certain formai properties of grammars,
Information and Control, 1959.
[CHOM 65]
N. Chomsky
Aspects of the theory of syntax,
MIT press, Cambridge Ma 1965.
[COINTE 83]
P. Cointe
The evolution of object oriented programming from SIMULA
to SMALL TALK,
_:1"1' .......
proc.11 th SIMULA Users conference, Paris 1983.
'.-
;-

---

106
[COLM 78]
A. Colmerauer
Metamorphosis grammars,
Bolc
ed.,
Natural
language
communication
with
coputer,
Springer-Verlag, 1978.
[COMM 87]
A. E. Commare
Interface coopérative langage naturel base de données,
Thèse de doctorat d'ingénieur, ENST, mars 1987.
[COUR 87J
M. Courant
La compréhension de petites annonces dans le système-expert Havane,
Thèse de l'université de Rennes1, nov. 1987.
[COUl 86J
D. Coulon
Informatique et langage naturel: présentation générale des méthodes
d'interprétation des textes écrits,
TSI, fév. 1986.
[OERM 87J
Mc Dermott
Artificial intelligence, logic and frame problem,
in the frame probJem in artifical intelligence, proc. of the 1987
workshop, F. M. Brown ed., Morgan Kaufman pub!. inc.
[OEGO 83J
P. Degoulet, J. P. Chantalou, G. Chatellier, C. Devies, P. Zwelgenbaum
Structured and standardized medical records,
in Medinfo 83, Van Benmel, Bali and Wigertz (ed.), Amsterdam:
North Holland, 1983.
[OUGER 88J
Ph. Dugerdil
Contribution à l'étude de la représentation des connaissances fondée sur
les objets; le langage OB.JLOG,
Thèse de docteur en sciences Université d'Aix-Marseille Il,
décembre 1988.
'--
,~

---

107
[OUGER 87]
Ph. Dugerdil
Les mécanismes d'héritage d'OBJLOG : vertical et sélectif multiple avec
point de vue,
Congrès AFCET-RFIA, Antibes, 1987.
[OUNH 86]
G. Dunham
The role of syntax in the sublanguage of medical diagnostic statements,
in analyzing language in restricted domains: sublanguage description and
processing, edited by R. Grishman and R. Kittredge, L.E.A. publisher,
Hillsdale, New Jersey 1986.
[EMIL 87]
C. Emile
Creating a database from processed narrative
in Medical language processing, pp 113-134,
Addison-Wesley Publishing Company - 1987.
[FARR 84]
H. Farreny
Les systèmes experts : principes et exemples,
Cepadues édition, 1984.
[FERB 85a]
J. Ferber
Définition récursive et évaluation distribuée; un modèle rigoureux de
langage objet,
AFCET-RFIA Grenoble, novembre 1985.
[FERB 85b]
J. Ferber
Les langages objets dans les systèmes experts,
Bigre + Globule W 47.
[FERB 88]
J. Ferber
Table ronde sur la notion d'objet,
Journées PRC-IA pôle 1, juillet 1987.
[FIES 84]
M. Fieschi
-."''-'''- -
Intelligence artificielle en médecine,
'. -
1-
Masson, 1984.

---

108
[FIKES 85]
R. Fikes, T. Kehler
The role of frame-base representation in reasonning,
Communications of the ACM, Vol 28, sept. 1985.
[FILM 68]
Ch. Fillmore
The case for cases,
in universals in Iinguistic theory edited by E. Bach, R. T. Harms, Holt,
Rinehart, winston Inc Chicago 1968.
[FRIED 87]a
C. Friedman
Information structure in clinical narrative
in Medical language processing, pp 61-80,
Addison-Wesley Publishing Company - 1987.
[FRIED 87]b
C. Friedman
A sublangage narrative processor
in Medical language processing, pp 81-112,
Addison-Wesley Publishing Company - 1987.
[FITZ 86]
E. Fitzpatrick, J.Bachenko, D. Hindi
The status of telegraphic sublangage
in analyzing language in restricted domains: sublanguage description and
processing, edited by R. Grishman and R. Kittredge, L.E.A. publisher,
Hiflsdale, New Jersey 1986.
[GOLO 83]
A. Goldberg
Smalltalk 80. The langage and its implementation,
Addison-Wesley Publication Compagny, 1980.
[GOND 83]
M. Gondran
Introduction aux systèmes experts,
Eyrole, 1983.
[HARR 68]
Z. S. Harris
Mathematical structure of langages
Wiley-intersience, New-york, section 5.9.

---

109
[HIRS 86]
L. Hirshman
Discovering sublangage structures.
in analyzing language in restricted domains: sublanguage description and
processing, edited by R. Grishman and R. Kittredge, L.E.A. publisher,
Hillsdale, New Jersey 1986.
[ILOG 87a]
ILOG
Classic:manuel de l'utilisateur,
ILOG, déc. 1987.
[ILOG 87b]
ILOG
AIDA version 1-2 Manuel de référence,
ILOG 1987.
[ILOG 87e]
ILOG
CLASSIC version 2.1 Manuel de référence,
ILOG 1987.
[ILOG 87d]
ILOG
SMEC/ version 1.3 Manuel de référence,
(LOG 1987.
[HAYES 81]
P. Hayes
The logic of frames,
Readings in Artificial Intelligence, ed. B. L. Webber, N. J. Nilsson
P. 451-458, Tioga publishing company, Palo Alto california, 1981.
[HEW 77]
C. Hewitt
Viewing Control structures as patterns of passing messages,
Artificial Intelligence 8,
1977.
[KITT 86]
R. Kittredge
The significance of sublanguage for automatic translation,
in Machine translation, edited by Nirenburg, CambridgE!.yniver3J!L.
press, 1987.

---

110
[KNUTH 71]
D. Knuth
Semantic of context-free languages,
Mathematical system theory, vol.
5,
n° 1, 1971.
[KaNO 79]
K. Konolige
An inference net compiler for PROSPECTOR rule-based consultation
system,
Proc International joint conference on artificial intelligence, 1979.
[LAURE 74]
J. P. Laurent
La structure de contrôle dans les systèmes experts,
T81 n° 3, 1984.
[LAURI 82]
J.L. Laurière
Représentation et utilisation des connaissances. Première partie : les
systèmes experts.
T81 n01, 1982.
[MAR8H 86]
E. Marsh
General semantic patterns in different sublanguages.
in analyzing language in restricted domains: subJanguage description and
processing, edited by R. Grishman and R. Kittredge, L.E.A. publisher,
Hillsdale, New Jersey 1986.
[MIN8K 75]
M. Minsky
A framework for representing knowledge,
MIT press, 1975.
[MITT 80]
S. Mittal, B Chandrasekaran
Conceptual representation of patient data bases,
Journal of Medical System, vol. 4, n° 2, 1980.
[MITT 84]
S. Mittal, B Chandrasekaran, J. Sticklen
Patrec: a knowledge-directed database for a diagostic expert .5y:stem
Journal of Medical System,vol. 4, no' 2, 1984.

---

1 1 1
[PALIK 76]
S. G. Pauker, G. A. Gorry, J. P. Kassirer, W. B. Swartz
Toward the simulation of clinical cognition
American journal of medecine, Vo1.60, june 1976.
[QUILL 68]
M. R. Quillian
Semantic Memory
Semantic Information Processing, MIT Press, 1968.
[RECH 88]
F. Rechenman, P. Fontanille, P. Uvietta
SHIRKA- système de gestion de base de connaissances centrées
objets-manuel d'utilisation,
INRIA et laboratoire ARTEMIS/IMAG, 1988.
[RECH 83]
F. Rechenman
Shirka : mécanismes d'inférence sur une base de connaissances centrées
objets,
AFCET-RFIA, Grenoble, novembre 1985.
[ROCHE 84]
Ch. Roche
EAQUE-LRO Génération de systèmes experts. Application à des problèmes
d'ordonnancement,
Thèse de 3 ième cycle INPG -Grenoble, mars 1984.
[ROCHE 89]
Ch. Roche, J. P. Laurent
Les approches objets et le langage LR02(KEOPS)
TSI, Vol. 8, n° 1 Janv. 1989.
(SAGE 86]
N. Sager
Sublanguage: Iinguistic phenemenon, computational tool
in analyzing language in restricted domains: sublanguage description and
processing, edited by R. Grishman and R. Kittredge, L.E.A. publisher,
Hillsdale, New Jersey 1986.
-- .!"-' .... -
(SHANK 77]
R. Shank, Abelson
'.-
-e-
Scripts, Plans, Goals and understanding,
Hiiisdale, N. J.
Lawrence Erlbaum, 1977.

---

112
[SHORT 76]
E. H. Shortliffe
Computer-based medical consultation: Mycin,
American Elsevier, 1976.
[SCHU 61]
M.P. Schiitzenberger
Some remarks on Chomsky's context-free language,
RL.E Prog. Report n063, Cambridge, 1961.
[SMUL 68]
RM. Smullyan
First order logic,
Springer-Verlag, 1968.
[STEFIK 85]
M. Stefik, O.G. Bobrow,
Object-Oriented Programming : Themes and variations,
The A.I. magazine, 1985.
[VIGN 85]
Ph. Vignard
Un mécanisme d'exploitation à base de filtrage flou pour une
représentation des connaissances centrée objets,
Thèse de docteur en informatique, INPG grenoble, juin 1985.
[WEIS 86]
R M. Weishedel, L. A. Ramshaw
Reflexion on the knowledge needed to process iIIform language,
in Machine translation, edited by Nirenburg, Cambridge university
press, 1987.
[WIED 86]
G. Wiederhold
Views, objects and databases,
IEEE, computers, dec. 1986.
(ZWEI85]
P. Zweigenbaum
Compréhension de phrase rédigée en style laconique,
INSERM -Laboratoire d'intelligence artificielle, rapport interne n017,
mars 1985.
- .1' .....-
(ZWEI 89]
P. Zweigenbaum, B. Bachimont, J. Bouaud, M. Couazza, L. Doré,
' . -
f
J. F. Boisvieux, A. Aurengo
Hélène: Understanding naturallanguage medical reports
IEEE, Engineering and biology society, nov. 1987.

---

11 3
ANNEXE 1
Spécifications syntaxiques des notions utilisées
dans le formalisme de Gide
Concepts
<concept>::= concept <nom> <spécif-structure> ; <spécif-opération>.
<nom>::= identificateur
<spécif-structure>::= structure: <spécif-attribut><spécif-contrainte> <spécif-statut>
<spécif-atribut> ::= composé-de <Iiste-d-attributs>
<1iste-d -attribut>: :=<attri bu t> ;<1iste-d-attributs>
<Iiste-d-attribut>::=
<attribut>:::
identificateur: <liste-de-facettes>
<1 iste-de-facettes>: :=<type>,<cardin alité>. [d-défaut>]
<type>::=entier! réel! chaÎne! booléen! <ÎnteNal/e>
<intervalle>::= entier - entier
<cardinalité>::= monvalué 1multivalué
d -défaut>::= défau«ide ntificate ur)
<spécif-contrainte> ::= vérifiant identificateur
<spécif-statut>::=statut <opération>
<spécif-opération>::= eval: <opération> 1visu: <opération>
Opérateurs
<opé rateu r> ::= opérateur identificateur <contexte> ;<résult> ;<act>.
<résult>::= résultat: identificateur
<act>::= action: identificateur
<contexte>::= contexte: <liste d'éléments de contexte>
<liste d'éléments de contexte>::= <élément de contexte>, <liste d'éléments de contexte>
1<élément de contexte>
<élément de contexte>::= <expression de concept>
- !"'..... .:-
kexpression de concept> <- <identificateur d'opération>
<expression de concept>::= <concept>
1<concept> vérifiant <contrainte>

---

' .."~.. '-
114
Opérations
<opération»
opération identificateur <corps-opération>.
<corps-opération>::= <comp-alternative> ou < corps-opération>
! <comp-alternative>
<comp-alternative»
<comp-conditionelle> sinon <comp-alternative>
! <comp-conditionelle>
<comp-conditionelle>::= <comp-séquentielle> puis <comp-conditionelle>
! <comp-séquentielle>
<comp-séquentielle>::=«opération» 1<élément>
<élément>::= identificateur! <expression de concept>
Tâches
<tâche>::= tâche identificateur <structure>; <présentation>.
<structure»
structure </iste-d-elements>
<liste-d-elements>::= <element>, <Iiste-d-elements>
<element»
<corps-opération> ! <ope rat> 1<tachh>
<operat>::= identificateur
<tachh>::= identificateur
<presentation>::= presentation <liste-presentation>;
<1iste-presentatio n> ::=<eIt-pres entatio n>,<liste-presentatio n>
<Iiste-presentation>::=
<elt-presentation>::= identificateur <- <element>. identificateur

---

115
ANNEXE 2
EXEMPLE COMPLET DE TRADUCTION DE CONCEPT:
TRADUCTION DU CONCEPT TENSiON
a) Les attributs
telle que présentée au paragraphe 3.1.2 la structure du concept TENSION est
décrite comme suit:
concept TENSION sorte-de EXAMEN-GENERAL
structure: compose-de
premie r-chiffre: 0-25,
monovalué;
deuxième-chiffre :5-25, monovalué;
remarque: chaine, multivalué;
Cette spécification sera traduite par le schéma suivant:
(def-sh
'(TENSION
(sorte-de
(= examen-général))
(lui-même
($nom-var lui-tension ... )
(premier-chiffre
($un
entier)
($i n te rv aile (0
25))
deuxième-chiffre
($un
entier)
($intervalle(5,
25))
(remarque
($Iiste-de
chaine))))
Cette définition s'accompagne de la génération automatique du schéma filtre-tension
suivant:
(def-sh
'(filtre-tension
(sorte-de
(=
filtre))
(resultat
($si b-fi It re
(tension
(lui-même ($var-> resùltat))))

---

116
b) Les contraintes d'intégrité
Pour spécifier le fait que le premier chiffre doit être toujours supérieur au
deuxième, l'expert doit compléter la spécification ci-dessus en lui ajoutant l'assertion
suivante;
"vérifiant concordance12" (1 )
Ceci suppose que la contrainte concordance12 a été définie; elle peut être faite dans
l'environnement GIDE de la manière suivante:
contrainte: concordance12 spécifiée par prédicat1 sur tension.
Ceci a pour effet de générer le schéma suivant:
(def-sh '(CONCORDANCE1-2
(est-un
(=
contrainte))
(nom -fct
($valeur
predicat1))
(argument
($un
tension))))
L'assertion (1) va permettre de compléter le schéma TENSION de la manière suivante:
(def-sh '(TENSION
(sorte-de
(= examen-général))
(lui-même ($var-nom
lui-tension)
($à-vérifier
(concordance 1-2
(argument ($var<- lui-tension))
<le reste sans changement>
.--:!" .....-- -

---

117
c)Les opérateurs d'évaluation
Dans le cas du concept TENSION
(ref. paragraphe 4.1.1), l'opérateur
d'évaluation est spécifié comme suit:
eval: (tension vérifiant plus-recent) SINON inst-tension.
Cette specification est interprétée de la manière suivante: s'il y a des instances du
concept TENSON dans le dossier on en choisit la plus écente; sinon on instancie la
tension en questionnant "utilisateur.
Ceci suppose que l'opérateur inst-tension et le filtre lié à la contrainte plus-récent
ont été définis.
L'opérateur inst-tension est définie comme suit:
opérateur
INST-TENS/ON
contexte
adulte;
résultat:tension;
action :interview.
Cette définition est traduite par le schéma shirka suivant:
(def-sh
'(in st-tension
(sorte-de
(=
opérateur))
(nom-fct
($valeur
interview))
(adulte%
($un adulte)
($sib-exec
(filtre-personne
(résultat
($var-> adulte%))))
(resultat
($un
tension))))
-
j'o'- _ .•-
-

---

11 8
L'expression "TENSION vérifiant PLUS-RECENT" sera traduite par le schéma suivant:
(def-sh
'(pl us- rece nt -te nsion
(sorte-de
(=
filtre-tension))
(résultat
($à-vérifier
(plus-recent
(argument ($var<- résultat))
(objet ($valeur tension)))))
La contrainte Plus-recent est une contrainte légèrement différente du schéma de
contrainte défini précédemment; elle peut s'appliquer à tous les concepts ayant un
attribut "date-de-réalisation". Elle possède un attribut de de type objet que les autres
contraintes n'ont pas. Cet attribut permet de spécifier le type de concept sur lequel
cette contrainte va être appliquée. Elle rend la valeur "vrai" si l'instance à la quelle
elle vient d'être appliquée est celle qui a été la plus récemment créer dans le dossier.
A partir des deux schémas méthodes ci-dessus, le shéma TENSION sera complété de la
manière suivante:
(def-sh '(TENSION
(sorte-de
(=
examen-général))
(lui-même
($var-nom
lui-tension)
($à-vérifier. .....
($sib-exec
(plus-récent-tension
(resultat-tension ($var->Iui-tension))
)
(inst-tension
(resultat-tension ($var->Iui-tension))
)
<le reste sans changement>
... .1':-"'--

---

119
Dans le cas du schéma TENSION l'attribut statut est défini comme suit:
(def-sh
'(tension
(sorte-de
(=
examen-général))
(statut
($sib-exec
(conclure-tension
(argument1 ($var<-
lui-tension))
(resultat
($var->recap))
. . ./1.,- • •-
-
'-
,-

---

120
ANNEXE 3
Exemple de base d'instances représentant un dossier
La base d'instances présentée ici a été contruite manuellement à partir du dossier d'un
patient. Quelques instances y ont été introduites pour la rendre plus complète. Chaque
instance est présentée suivant le format suivant:
<nom de concept>
/ <commentaire>/ <valeur d'attribut>
fin.
C'est à partir de cette base d'instances qu'ont été édités le dossier et le résumé
présentés en annexe 4.
... !'., ....-
,-

---

121
$nom-dossier dl
patient
/
nom et prenom /
"Durand Albert"
/
telephone /
12-34-56-78
/
adresse /
/
numero /
10
/
rue /
Foch
/
code postal /
29000
/
ville /
Brest
/
sexe /
masculin
/ profession /
garagiste
/
date de naissance /
/
jour /
21
/ mois /
juillet
/
annee /
1936
fin
prise-en-charge
/
nbre de consultation /
1
/
date de premiere consultation /
/
jour /
17
/ mois /
juin
/
annee /
1977
/
date de derniere consultation /
/
jour /
7
/ mois /
juillet
/
annee /
1987
/ medecin /
/
intervention /
consultant
/
nom prenom /
"Pinel Jean-francois"
/
te1ephone /
"99-28-43-21 poste 85268"
/
specialite /
neurologue
/ medecin /
/
intervention /
traitant
/
nom prenom /
"Pinel Jean-francois"
/
telephone /
"99-28-43-21 poste 85268"
/
specialite /
neurologue
fin
epilepsie
/
type d'epilepsie /
/
age de debut /
/
foyer focal /
<
>
/
facteurs favorisants /
< reveil fatigue >
/ ethiologie /
< isolee provoquee >
fin
poids

---

122
/
premier chiffre /
20
/
deuxieme chiffre /
14
/
remarque /
"tension anormalement for'
fin
rendez-vous
/
objet du rendez-vous /
hospitalisation
/
date du rendez-vous /
/
jour /
12
/ mois /
fevrier
/
annee /
1985
/
realisation /
prevu
/
remarque
/
"on envisage une associat.
fin
etat-du-patient
/
date de realisation /
/
jour /
7
/ mois /
juillet
/
annee /
1987
/
frequence des crises /
/
qualification /
stable
/
remarque /
"l'etat est
juge stable c;
fin
electro-encephalogramme
/
date de realisation /
/
jour /
5
/ mois /
avril
/
annee /
1987
/
condition de realisation /
nuit
/
rythme de base /
10
/
onde lente /
< aucun >
/
photo-sensibilite /
minime
/
pointes /
< frontal droite >
/
poly-pointes
/
< occipital gauche >
/
pointes-ondes /
< parietal >
/ poly-pointes-onde /
< temporal >
/
remarque /
"cet examen sera a recomm.
fin
scanner
/
date de realisation /
/
jour /
10
/ mois /
avril
/
annee /
1987
/
lesion focale /
< hypodensite prise-de-co:
/
localisation /
< frontal gauche >
/
les ion diffuse /
atrophie
/
remarque /
"ce scanner montre une an.
fin
antecedent
/
personne /
"son frere"
/
epoque /
20
/
nature /
"crise epileptique ... ·"··-
/
description /
< "crise unique sans suit,
"crise de type gene~a"
/ mesure prise /
"aucune"
fin

---

123
antecedent
/ personne /
patient
/
epoque /
1.5
/
nature /
"crise epileptique"
/
description /
< "convulsion hypertermiq
/ mesure prise /
fin
antecedent
/ personne /
"sa soeur"
/
epoque /
1.4
/
nature /
"crise epileptique"
/
description /
< "actuellement elle a 32
" avec photo-sensibilit.
/ mesure prise /
fin
antecedent
/
personne /
"sa soeur"
/
epoque /
/
nature /
"encephalite-rougeole"
/
description /
< "il s'agit d'une autre
"actuellement elle va b
/ mesure prise /
fin
traitement
/ medicament dose /
< depakine -
phenobarbital -
>
/
age de debut /
12
/
effet /
/
remarque /
fin
traitement
/ medicament dose /
< depakine "9.9"
di-hidan "9.1"
rivotril -
>
/
age de debut /
20
/
effet /
/
remarque /
fin
crise
/
type de crise /
"crise generalisee"
/
age d'apparition /
20
/
classification des signes /
< absence >
/
semiologie /
< "les crises sont devenu.
" surtout le matin" >
fin
crise
/
type de crise /
"crise generalisee"
/
age d'apparition /
15
/
classification des signes /
< tonico-clonique >
/
semiologie /
<
>
fin
crise
/
type de crise /
"crise generalisee"
/
age d'apparition /
5

---

124
/
classification des signes /
< absence >
/
semiologie /
<
>
fin
crise
/
type de crise /
"crise generalisee"
/
age d'apparition /
20
/
classification des signes /
< clonique >
/
semiologie /
< "un etat prolonge ayant
"alors que le patient e-
"il existait peut etre 1
fin
fin-dossier

---

125
Annexe 4
Le dossier présenté dans les pages qui suivent est une édition intégrale de la base
d'instances présentée en annexe 3
.... !" .... -

---

126
dossier-resume
IDENTITE DU PATIENT
Nom et prenom: Durand Albert
Age: 52 ans
MEDECIN TRAITANT: Pinel Jean-francois
CRISE
-- crise generalisee
observee pour la premiere fois a
20
ans
differents signes observes:clonique,
semiologie
(un etat prolonge ayant dure 20 minutes en juillet dernier
alors que le patient etait dans une voiture ou i l ne pouvait bouger
i l existait peut etre des clonies palperales)
CRISE
-- crise generalisee
observee pour la premiere fois a
20
ans
differents signes observes:absence,
semiologie
(les crises sont devenues plus frequentes et les absences se manifestent
surtout le matin)
EPILEPSIE
facteur favorisants:
reveil,fatigue,
etiologie: isolee,provoquee,
%epilepsie-360
ELECTRO-ENCEPHALOGRAMME
condition de realisation nuit
anormal~
-- cet examen sera a recommencer
SCANNER
-- anorma]
POIDS: 115 Kg
-- trop lourd pour sa taille
TENSION: tension anormalement forte
ETAT GLOBAL DU PATIENT
l'etat est juge stable car la derniere grande crise avec generalisation remonte;
is ans
TRAITEMENT
medicaments prescrits depakine 9.9
... l":- ...-
di-hidan 9.1
rivotril -

---

127
Annexe 4 (suite)
Le texte présenté dans les pages qui suivent est un résumé obtenu à partir de la base
d'instances présentée en annexe 3. Il est difficile de le juger sur le plan qualitatif,
mais sur le plan quantitatif, on peut constater que le dossier initial a été réduit de
moitié.
- .f"I""';-

---

128
Apr 19 11:43 1989
original Page 1
IDENTITE DU PATIENT
Nom et prenom: Durand Albert
Age
52 ans
ne le
21 juillet 1936
Sexe
: masculin
Adresse
rue
foch brest
Profession
garagiste
Telephone
: 12-34-56-78
MEDECIN traitant
nom
Pinel Jean-francois
specialite
neurologue
telephone
99-28-43-21 poste 85268
MEDECIN consultant
nom
Pinel Jean-francois
specialite : neurologue
telephone
: 99-28-43-21 poste 85268
la premiere consultation a eu lieu le
17 juin 1977
ANTECEDENT
ceci concerne sa soeur
i l s'agit d'une autre soeur. Elle a deja fait une crise d'encephalite-rougeole.
actuellement elle va tout a fait bien
ceci concerne sa soeur
a l'age de 1.4 ans
actuellement elle a 32 ans elle a presente une crise dans ladolescence
avec photo-sensibilite depuis elle n'aurait fait qu'une seule crise
ceci concerne patient
a l'age de 1.5 ans
convulsion hypertermique
ceci concerne son frere
crise unique sans suitecrise de type generalisee
mesure prise: aucune
CRISE
-- crise generalisee
observee pour la premiere fois a
20
ans
differents signes observes:clonique,
semiologie
(un etat prolonge ayant dure 20 minutes en juillet dernier
- 1'-' ---...

---

129
Apr 19 11:43 1989
original Page 2
alors que le patient etait dans une voiture ou i l ne pouvait bouger
i l existait peut etre des clonies palperales)
CRISE
-- crise generalisee
observee pour la premiere fois a
5
ans
differents signes observes:absence,
semiologie
()
CRISE
-- crise generalisee
observee pour la premiere fois a
15
ans
differents signes observes:tonico-clonique,
semiologie
()
CRISE
-- crise generalisee
observee pour la premiere fois a
20
ans
differents signes observes:absence,
semiologie
(les crises sont devenues plus frequentes et les absences se manifestent
surtout le matin)
EPILEPSIE
facteur favorisants:
reveil,fatigue,
etiologie: isolee,provoquee,
ELECTRO-ENCEPHALOGRAMME
condition de realisation nuit
rythme de base la
photosensibilite ,minime,
pointes
( frontal droite )
poly-pointes
( occipital gauche
pointes-ondes
( parietal )
poly-pointes-ondes
( temporal )
anormalanormalanormalanormal
cet examen sera a recommencer
5 avril 1987
SCANNER
hypodensite frontal
prise-de-contraste gauche
lesion diffuse ,atrophie,
ce scanner montre une anomalie dans le lobe cerebral gauche
-- anormalanormal

---

130
Apr 19 Il:43 1989
original Page 3
scanner realise le
la avril 1987
POIDS: 115
-- trop lourd pour sa taille
22 mars 1987
TENSION:
20 /
14
--tension anormalement forte
22 mars 1987
ETAT GLOBAL DU PATIENT
frequence des crises:
a
--stable
l'etat est
juge stable car la derniere grande crise avec generalisation remonte.
is ans
7 juillet 1987
TRAITEMENT
medicaments prescrits depakine 9.9
di-hidan 9.1
rivotril -
TRAITEMENT
medicaments prescrits depakine -
phenobarbital
R
RENDEZ-VOUS
motif du rendez-vous:
hospitalisation
on envisage une association de zarotin-urbanyl ceci impliquera une diminution de
epakineet du di-hidan que le patient souhaite ne pas faire chez lui car i l vit SI
12 fevrier 1985

---

131
Annexe 5
Les deux pages qui suivent présentent des copies d'écran du sous-système de synthèse
du dossier. Sur la deuxième page, un éditeur de texte présentant plus en détail l'histoire de la
maladie, recouvre partiellement la synthèse initiale.
·.. :!"'r ..."-

---

Iül
~ xsnap
~6îl
( CHARGER ~ essai
1
(EDITER) c::ITEJ
dossier-resume
IDENTITE DU PATIENT
Nom et prenom: Durand Albert
OPERATIONS
TACHES
Age: 53 ans
[i;r,...........,..~......
~m;:__
~resume
MEDECIN TRAITANT: Pinel Jean-francois
lM diagnostic
····histoire
.... suivi
COUPER 0
IMPRIMER D
RESUMER D
SYNTHESED
CRISE
-- crise generalisee
identite
observee pour la premiere fois a
20
ans
Ûencadrement
differents signes observes:clonique,
,
<atcd
histoire
i
semiologie
cr se
Lcrises
(un etat prolonge a~ant dure 20 minutes en Juillet
pathologie~ePilepsie
alors que le patient etait dans une voiture ou il nd
il existait peut etre des clonies palperales>
.
autre
N
doss~er
C')
,..-
~scanner
CRISE
examen
eeg
pesee
-- crise generalisee
tension
observee pour la premiere fois a
20
ans
differents signes observes:absence,
etat
L
sUivie~traitement
semiologie
rendez-vous
(les crises sont devenues plus frequentes et les ab
surtout le matin)
EPILEPSIE
facteur favorisants: reveil,fatigue,
etiologie: isolee,provoquee,
Yoepilepsie-379
ELECTRO-ENCEPHALOGRAMME
I?
condition de realisation nuit
(eeg dont statut est anormal> 1
lQgl
-- anormal anormal anormal anormal
-- cet examen sera a recommencer

---

'Ir
"'~ b"?' (:-
~
.~
o
'r;
.:r ,f1.J ~
~
~
ft,
~; u-- .f
~@]
J
~
.
~c
·.~1
TACHES
Age: 53 ans
"-t"' • • "'"t"'~.\\"
MEDECIN TRAITANT: Pinel Jean-francois
... crise
=eeg
.... atcd
--_ ..... _...
Iresume
. . diagnostic
~'hi~t~ire
su~v~
EFFA CER t_.._
_
_.._ _
_ __.
.
COUPER 0
IMPRIMER ~
RESUMER ~
SYNTHESED
Attention~ redefinition du schema aida-sh
11
ceci concerne sa soeur
identite
il s'agit d'une autre soeur. Elle a deja fait un~ cr
actuellement elle va tout a fait bien
fencadrement
('''I!lmrmlEK atcd
ceci concerne sa soeur
~
crise
a l'age de 1.4 ans
Lcrises
actuellement elle a 32 ans elle a presente une crise
pathologie~ePilepsie
avec photo-sensibilite depuis elle n'aurait fait qu
autre
doss i er
ceci concerne patient
scanner
(Y)
a l'age de 1.5 ans
(Y)
convulsion h~pertermique
,....
examen
eeg
{
pesee
ceci concerne son frere
tension
crise unique sans suitecrise de t~pe generalisee
etat
mesure prise: aucune
L
sUivie~traitement
Attention: redefinition du schema aida-sh
rendez-vous
i1
CRISE
-- crise generalisee
observee pour la premiere fois a
20
ans
differents signes observes:clonique,
··ë:ëirïartrëïn..···aË~··..·r·e"iiiTrsiiïHë)r;-·-rïü"ft"·····
_
.
?<eeg dont statut est anormal)
1®
-- anormal anormal anormal anormal
-- cet examen sera a recommencer
SCANNER
- -
~~~~~~1~~~~~~1

---