Dans MACAO, le modèle conceptuel est considéré avant tout comme un support pour comprendre et interpréter les informations provenant de l’expert et, seulement dans un deuxième temps, comme un moyen de formalisation.
De ce fait, la représentation des connaissances cherche à favoriser des mises à jour faciles ou des représentations provisoires, utiles pour clarifier les idées du cogniticien. Elle sert de base à des visualisations simples et faciles à comprendre par un expert. Cette représentation des connaissances offre ainsi d’abord un cadre minimal pour assurer la compréhension de l’expertise, puis elle permet de nouveaux raffinements avant d’être formalisée.
1.12.3.1 Des primitives paramétrables : MONA
Afin de faciliter le passage d’un modèle conceptuel à un modèle opérationnel, la représentation des connaissances dans le modèle conceptuel a été adaptée d’un langage opérationnel. Ce nouveau langage, MONA, un des résultats de la thèse de N. Matta, est le formalisme de représentation des connaissances défini pour MACAO-II [thèse-MATTA, 95] [rapport IRIT/94-02-R]. Il a été codé comme une surcouche de Le_Lisp (produit Ilog) et intégré au sein de la plate-forme MACAO-II.
107
Caractéristiques communes
L’originalité des structures MONA se situe dans leur découpage en trois parties, chacune étant relative à un degré de formalisation pertinent au cours de l’acquisition. La description de la structure conceptuelle comprend deux vues complémentaires : graphique et langage naturel. Une structure MONA est formée des trois parties suivantes :
- Dans la description en langage naturel, le cogniticien décrit les connaissances représentées, argumente et exprime ses choix de modélisation.
Découpée selon un plan prédéfini que le cogniticien est libre de modifier, cette description est complétée par des liens vers des extraits de documents de l’expertise, les références.
- Une expression formelle rend explicites les relations entre structures pour rendre plus précise l’organisation des connaissances au sein du modèle.
Les différents éditeurs graphiques du logiciel associé à MACAO-II facilitent la définition de ces relations car ils rendent transparente la syntaxe formelle.
- Une expression opérationnelle établit le lien entre la structure MONA et la partie correspondante dans le modèle opérationnel en LISA (Delouis et Krivine, 1995). Le passage des structures MONA vers le code LISA se déroule en deux temps : une traduction automatique génère un cadre opérationnel puis un codage manuel vient le compléter. Ceci permet de respecter le plus possible l'organisation des connaissances du modèle conceptuel dans le modèle opérationnel.
Structures du langage MONA
De manière très classique, les connaissances du domaine sont représentées, au niveau terminologique, par des termes, et, au niveau conceptuel, à l’aide de concepts et de relations étiquetées entre concepts. Les concepts sont génériques. Leurs instances peuvent également être représentées. Les termes sont associés aux concepts qu’ils désignent. Tout nouveau type de relation doit être situé dans une hiérarchie de relations prédéfinies. Cette classification des relations a pour objectif de mieux en comprendre leur signification avant que leur sémantique ne soit définie par le typage des concepts reliés (co-domaine - valeur).
La représentation du raisonnement a évolué par rapport à MACAO. À partir d’une collaboration avec I. Delouis, le langage LISA (Delouis et Krivine, 1995) a été retenu comme point de départ. LISA est un langage de modélisation opérationnel, réflexif, et permettant d’adapter dynamiquement la résolution de problème à l’utilisateur. Le contrôle gérant l’exécution tient compte du contexte pour choisir, pour chaque tâche, la méthode qui va la réaliser. Le langage MONA, correspondant à l’équivalent, au niveau conceptuel, des primitives de LISA, a alors été défini. MONA propose donc, comme LISA, des structures de tâche et de méthode pour représenter le raisonnement.
Comme montré sur la figure 4.3.3.1, tâches et méthodes sont d’abord décrites par des commentaires puis à l’aide de concepts, de rôles et de relations avec d’autres tâches, et enfin opérationnalisées en LISA.
À la différence de LISA, MONA propose aussi une structure de rôle pour décrire les entrées et sorties des méthodes. Notion reprise à de nombreux travaux comme OMOS (Linster, 1993), CML (Schreiber et al., 1994) ou VITAL (Leroux et al., 1993), un rôle est utilisé pour nommer de manière abstraite les objets du raisonnement. Cette structure a été retenue dans MONA afin de
de connaissances
parvenir à une meilleure lisibilité des modèles et à une meilleure caractérisation de la résolution de problème dans le schéma du modèle conceptuel. Ainsi, on espère pouvoir plus facilement réutiliser des modèles empruntés à d’autres projets et aboutir à des modèles plus réutilisables.
Tout comme dans MACAO, le modèle du domaine forme un réseau proche d'un réseau sémantique : le Graphe du domaine, générique ou instancié suivant que sont représentés des concepts ou leurs instances. Ces graphes peuvent être vus, entièrement ou partiellement, à l'aide d’éditeurs de graphe, qui en facilitent la construction progressive.
Tâche
nom : Affectation-bureau
définition : cette tâche concerne ....
but : personnes-placées
contraintes/contexte : les bureaux doivent contenir toutes les personnes contraintes/but : toutes les personnes doivent être placées
critère de satisfaction : on ne cherche pas une solution optimale.
Méthode
nom : Affecter
définition : c’est une méthode ...
paramètres : personnes, bureaux, contraintes.
résultats : personnes-placées
contraintes/paramètres : les bureaux doivent contenir toutes les personnes contraintes/résultats :
contexte favorable : l’affectation se fait en respectant des contraintes
traitement : TANT QUE il-existe-des-critères : choix-critère, affectation-personnes/critère Rôle
nom : composant
définition : un composant à placer connaissances du domaine : personnes.
Figure 4.3.3.1 : Exemples de structures de représentation du raisonnement en MONA.
1.12.3.2 Simuler le comportement du modèle conceptuel
À l’issue du processus de modélisation, la version formelle du modèle des connaissances en LISA est appelée modèle formel ou modèle opérationnel.
L’opérationnalisation permet entre autres de valider le comportement du modèle et de le vérifier syntaxiquement. La correspondance entre structures des modèles conceptuel et opérationnel a pour but de propager facilement au niveau conceptuel les modifications requises à partir de problèmes constatés au niveau opérationnel. Parvenir jusqu’au modèle opérationnel présente plusieurs avantages : on en attend une meilleure précision du modèle et un passage plus facile à la base de connaissances finale.
La méthode MACAO-II prévoit plusieurs étapes dans le passage du modèle conceptuel au modèle opérationnel : au début, des structures LISA incomplètes correspondant aux structures MONA du modèle sont générées automatiquement ; ensuite, le cogniticien doit interpréter le contenu des structures MONA pour les compléter. La plate-forme MACAO-II intègre le support de cette transition. Enfin, cette possibilité a ouvert des perspectives de prototypage et de construction incrémentale du modèle.
109
1.12.3.3 Une autre forme d’opérationnalisation : prototypage avec ZOLA
En LISA, il n’y a pas de rôle : les tâches et les méthodes manipulent directement les objets du domaine (concepts et relations). Les concepteurs de LISA justifient ce choix par le fait qu’au niveau opérationnel, le modèle n’a plus lieu d’être générique ou abstrait : il doit être le plus adapté possible au domaine pour être performant.
Une nouvelle expérimentation de l’opérationnalisation des modèles MONA
a donc été menée à l’aide d’un autre langage réflexif, Zola (Isténès et Tchounikine, 1996), qui permet de coder des primitives opérationnelles adaptées à des structures conceptuelles. En développant ce langage opérationnel, appelé ZTM, dans un premier temps, les définitions des structures MONA ont été précisées, puis la notion de rôle a été redéfinie [IRIT-96-23-R]. Ainsi, le passage des rôles à des concepts opérationnels a souligné l’importance de conserver une trace du contexte dans lequel les connaissances du domaine peuvent jouer ce rôle. Le contexte associé à un concept est précisé à l’aide d’un nom de tâche ou de méthode et du nom du champ (entrée-sortie-ressource) qui indique comment les connaissances sont utilisées dans la structure. De plus, afin de bien gérer l’association entre rôles et concepts du domaine tout au long d’une résolution, des liens fixent les concepts pouvant jouer chaque rôle dans les différents contextes de leur utilisation, comme illustré sur la figure 4.3.3.3 pour le rôle « ensemble de composants ».
Rôle : ens-de composants Valeurs Possibles:
Val 1 Lien vers un concept: ens-de-personnes
Contexte : entrée, tâche Affecter-emplacement-composant
Val 2 Lien vers un rôle: ens-de-composants, entrée, tâche Affecter-emplacement-composant Contexte: paramètre, méthode affectation-selon-critères
Val ...
ens-de-composants désigne les entrées de la tâche Affecter-emplacement-composant (valeur 1) et les paramètres de la méthode Affectation-selon-critères (value 2). Pour la valeur 1, ens-de-composants peut être assimilé à un rôle statique : il indique les concepts du domaine pouvant être utilisés en entrée de la tâche Affecter-emplacement-composant. Pour la valeur 2, ens-de-composants peut être assimilé à un rôle dynamique ; il n’est pas relié à des connaissances du domaine, mais fait référence à un autre rôle. Il signifie que les paramètres de la méthode Affectation-selon-critères correspondent aux entrées de la tâche Affecter-emplacement-composant.
Figure 4.3.3.3 : La notion de rôle dans MACAO-II.
Le parti retenu dans MONA est de représenter les rôles par des structures indiquant en extension les connaissances du domaine pouvant les jouer mais ne les caractérisant pas. La limite évidente de ce choix est qu’on doit prévoir tous les concepts susceptibles de jouer le rôle, ce qui rend la description du rôle dépendante du domaine, ce qui limite l’intérêt de les définir.
1.12.3.4 Complémentarité avec ASTREE
Mis au point par F. Tort et C. Reynaud au LRI, ASTRÉE est un logiciel d’aide à la modélisation du raisonnement à partir d’une analyse des caractéristiques structurelles des concepts, définis au sein d’une ontologie du domaine (Tort, 1996). Le modèle du raisonnement est décrit sous forme de tâches et méthodes adaptées de LISA, comme pour MONA. Les entrées et sorties d’une méthode (appelées paramètres et résultats) sont les mêmes que les entrées et sorties (contexte et but respectivement) de la tâche qu'elle réalise, et font dans les deux cas référence aux termes de l'ontologie du domaine. Les
de connaissances
méthodes sont identifiées par interprétation des connaissances du domaine et notamment de la sémantique du langage Entité-relation (E/R) utilisé pour les représenter. L’originalité d’ASTRÉE est aussi de permettre d’exprimer des contraintes sur les concepts ou sur leurs valeurs.
Plusieurs convergences fortes justifient d’essayer d’intégrer ASTRÉE et MACAO : un des points faibles de MACAO-II est la représentation du domaine ; le modèle du raisonnement dans ASTRÉE utilise les mêmes structures que celui de MACAO ; enfin, ASTRÉE est un outil supplémentaire pour aider à organiser systématiquement le modèle du raisonnement en adéquation avec celui du domaine (l’ontologie). Pratiquement, une expérience a été conduite en collaboration avec le LRI au sein du projet Hyperplan (chapitre 6). Le langage de type entité-association d’ASTRÉE a été utilisé pour représenter le modèle du domaine. Les règles de normalisation et de structuration associées se sont avérées des aides pertinentes pour définir un modèle plus compact et vraiment en adéquation avec les raisonnements effectués. Elles influencent également le niveau auquel sont définis les propriétés des concepts et leur nature. Au final, ce modèle comporte moins de concepts qu’un premier modèle fait avec MACAO-II, il est plus explicite et mieux structuré. Cette expérience a confirmé l’intégration possible entre MACAO-II et ASTRÉE, et l’importance de règles de structuration comme celles de normalisation en base de données [CMKB, 97].
1.12.3.5 La notion de rôle
Ces deux collaborations ont souligné le besoin d’approfondir la notion de rôle avec l’équipe de l’IRIN, qui a défini une surcouche de ZOLA, le langage DSTM, et l’équipe du LRI développant ASTRÉE. Cette analyse conjointe a eu aussi pour but de mieux faire converger les différents travaux liés à MACAO, en particulier ASTRÉE, en s’appuyant sur la philosophie de DSTM. À partir d’une étude de l’état de l’art, il est ressorti que la notion de rôle recouvrait des réalités très différentes qu’une étude conjointe avec le LRI et l’IRIN a permis de sérier [JICAA, 97] [EKAW, 97]. A minima, le rôle est juste un label qui, parce qu’il est plus abstrait, indépendant du domaine et relatif au raisonnement, permet au lecteur du modèle de changer de point de vue sur les connaissances du domaine. Les rôles sont parfois exprimés sous forme de contraintes portant sur les concepts du domaine et leurs propriétés, sans pour autant être étiquetés. Enfin, dernier cas de figure, les rôles peuvent être définis explicitement, soit en tant que tels comme dans VITAL (Leroux et al., 1994) soit au sein des méthodes.
Bien que n’utilisant pas la notion de rôle, ASTRÉE permet de caractériser les entrées et sorties des tâches et méthodes au même niveau d’abstraction, et ceci grâce à des contraintes et à un degré élevé de structuration. Il est non seulement possible de définir la nature et la structure des entrées et sorties mais aussi leur syntaxe et leur statut. Ce choix correspond au 2e cas ci-dessus.
Dans ASTRÉE, l'absence de structure rôle est justifiée par le fait que l'objectif n'est pas la description de méthodes génériques. Néanmoins, son ajout a été envisagé pour mieux articuler raisonnement et modèle du domaine.
DSTM est un noyau d’opérationnalisation de modèles conceptuels qui propose une architecture en 3 niveaux de manière à définir des systèmes réflexifs raisonnant sur leur contrôle. Les primitives de modélisation du raisonnement (tâche et méthode) se trouvent au niveau le plus bas. Ensuite, des notions abstraites sont définies au niveau au-dessus, comme la notion de
« méthode déclenchable » ou de « méthode-favorable ». Ces notions sont
111
manipulées par des actions de haut niveau (comme « identifier les méthodes déclenchables ») définies au 3e niveau de l’architecture. La notion de rôle peut donc intervenir à deux niveaux : au niveau du raisonnement, les rôles caractérisent les manières dont les connaissances du domaine sont manipulées dans le raisonnement, et au niveau abstrait, les notions abstraites définissent les rôles que jouent des méthodes au sein des actions de haut niveau.
Enfin, dans MONA, la première manière de représenter les rôles en ZOLA
correspond non à une caractérisation mais à un lien fixe entre domaine et raisonnement. Ce choix, bien que non satisfaisant si on cherche à rendre indépendant du domaine le modèle du raisonnement, est pratique du point de vue opérationnel. Il souligne l’importance de définir les rôles comme des structures à part entière, ainsi que l’atout de la souplesse de ZOLA pour les définir facilement avec les opérateurs qui les manipulent dans le système opérationnel. Les propositions d’Astrée fournissent alors des outils pour une caractérisation syntaxique qui réponde à l’exigence d’une définition explicite et indépendante du domaine. Cependant, ces perspectives n’ont pas été poursuivies.