Nous avons expliqué précédemment que les modèles de raisonnement à partir de cas se base sur un élément central qui est le Cas. Pour définir ce qui est un Cas, pour notre problème, il faut identifier les deux parties du couple problème-solution. Or comme nous l’avons vu dans la partie 5.1.3, pour notre cas d’application, il n’y a pas de distinction précise de ce que représente le problème et la solution, ou pour être plus précis, ces deux éléments peuvent être différents selon la manière dont on aborde le problème.
Nous proposons donc de ne pas créer de Cas à proprement parler, ou du moins, qu’il n’existe pas dans notre mo- dèle en tant qu’élément pré-établi. Au contraire, on se propose de stocker uniquement la connaissance sous forme simple et de générer ce qui sera utilisé comme Cas, en fonction du besoin. Par conséquent, il s’agit plus d’une génération de cas suite à un besoin dans le système, qu’a une représentation formelle du Cas. Cela génère plu- sieurs conséquences et font émerger plusieurs difficultés. Premièrement, même si un Cas n’est pas formellement représenté dans le modèle, la structure proposée implique de savoir le générer à partir de l’information dispo- nible. Deuxièmement, il est nécessaire de disposer de suffisamment d’information afin de pouvoir répondre aux sollicitations du système pour générer un Cas dynamiquement. Ceci implique la première difficulté de représenter la connaissance afin qu’elle puisse être traitée.
5.4.1
Représentation des données par un réseau sémantique
Nous avons choisi de représenter l’information que nous utiliserons pour le système de RàPC que nous proposons sous forme de réseau sémantique (voir section2.7.1.1). Ce réseau, qui s’apparente à une ontologie ne suit aucun formalisme, et donc répond aux besoins exprimés mais aussi de la façon dont nous comptons traiter l’information stockée (qui sera expliquée par la suite). Il s’agit de relier un ensemble d’éléments de manière logique par des relations. D’un certain point de vue, la manière dont ces éléments sont mis en relation n’est pas formalisée. Nous verrons néanmoins qu’une structure a été établie permettant le fonctionnement du système. De ce fait, il n’y a pas de formalisme pour la conservation des données mais uniquement pour leur traitement par le système.
5.4. DESCRIPTION DU CAS, UN ÉLÉMENT ABSENT DU SYSTÈME
5.4.2
Traitement logique de l’information
Comme nous venons de l’expliquer, les informations stockées dans le système vont être traitées dynami- quement afin de satisfaire les besoins de flexibilité liés à la représentation et à la résolution du problème. En complément du réseau sémantique, nous proposons d’utiliser des mécanismes d’inférences qui vont permettre de traiter les données et de retourner l’information nécessaire structurée si besoin. Ces mécanismes sont souvent présents dans des systèmes dits intelligents, comme les moteurs de parcours d’ontologie. L’inférence est un moyen de vérifier ou d’arriver à une vérité en passant par d’autres vérités (ou assertions).
Exemple 2 — Je sais que C est vrai si A et B le sont — Je sais que A est vrai
— Je sais que B est vrai
— => inférence => j’en déduis que C est vrai
De ce fait, même si l’information n’est pas structurée, elle peut être analysée de manière logique pour en tirer des informations ou des constatations. L’inférence peut aussi permettre l’extraction de nouvelles données par l’utilisation de règles définissant de nouvelles assertions.
Exemple 3 — Si X est père de Y et si Y est père de Z alors X est grand père de Z => règle d’inférence — Je sais que A est père de B
— Je sais que B est père de C
— inférence => j’en déduis que A est grand-père de C
Au travers de cet exemple, on voit que des informations non existantes de manière explicite dans la base de données peuvent être extraites grâce aux mécanismes d’inférence. Dans l’exemple précédent, nous ne savons pas que A est grand-père de C mais nous le déduisons de manière logique. La construction de règles d’inférences repose néanmoins sur de la connaissance qui doit être introduite. Elle a l’avantage de permettre l’extraction de connaissances implicites mais oblige à que cette connaissance soit valide pour tous les Cas (au sens RàPC). Pour exemple, si nous avons la règle d’inférence suivante :
— Si X est un homme, alors X est mortel,
il faut que cette règle soit vraie pour tout X tel que la condition est un homme soit vérifiée.
Ce mécanisme d’inférence a l’avantage de structurer notre information, et de générer nos cas en fonction des besoins.
5.4.3
Des cas dynamiques
Nous proposons donc pour notre modèle la création de cas dynamiques. Cette idée renvoie à la partie précé- dente, c’est-à-dire à la possibilité de créer un cas selon notre besoin indépendamment de la structuration de nos données dans la base de cas. Par conséquent, un cas n’est structuré dans le système que comme une inférence. C’est une règle qui va définir ce qui est à considérer comme cas et plus précisément ce qui constituera la partie solution et la partie problème. Ainsi, sur la figure 5.6, on peut voir qu’à partir d’une structure de données, le mécanisme d’inférence identifie ce qui pourrait être un cas avec sa composante problème et sa composante solution. Une telle définition du cas permet une grande souplesse quant à l’utilisation de la connaissance puisque la structuration de l’information ne limite pas la manière dont elle peut être utilisée. Ainsi, ce même système peut résoudre un ensemble différents de problèmes selon l’approche souhaitée. Par exemple, un problème peut être décomposé en sous-problèmes distincts, ayant une définition du cas différente.
Pour le sujet traité ici, nous proposons plusieurs structurations du cas, permettant ainsi d’adapter l’ensemble du système aux différents sous-problèmes rencontrés.
5.4.4
Structuration d’un cas
Dans cette partie, on souhaite définir nos différentes structures de cas. Pour ce faire, on s’appuie sur la partie exposant le problème et les différentes approches retenues. Il en découle trois principales structures de cas pour notre problème :
— Je suis dans une situation, j’applique une opération (ou une action), mon inconnue est le résultat (l’objet valorisé)
— Je suis dans une situation, je veux atteindre un résultat, mon inconnue est comment je fais
— Je veux un résultat, je sais que c’est le résultat d’une opération, mon inconnue est la situation initiale En représentant par + l’élément connu et par ? l’inconnue, on en déduit la matrice suivante :
BASÉE SUR LE RAISONNEMENT À PARTIR DE CAS
Données : Mécanismes d'inférence Objet Relation Solution ProblèmeFigure 5.6– Génération dynamique de cas
Structuration d’un cas Situation initiale Transformation Situation finale
1 + + ?
2 + ? +
3 ? + +
Lors de la résolution d’un problème, c’est trois types de structuration peuvent intervenir. Cette matrice sou- ligne l’intérêt du cas dynamique. En effet, l’introduction d’un cas typique dans le système peut produire trois cas utilisables par ce dernier. Ceci permet par conséquence de résoudre un nombre plus important de problème et ceux avec un nombre de cas introduits dans le système nettement inférieur à un système utilisant des cas classiques.
Nous entrevoyons ici la structure des données de notre base de connaissances, maintenant, nous allons voir comment elle est construite et quels sont les différents éléments qui la composent.