Les sessions suivies jusqu'à présent avaient comme objectif de montrer comment il était possible pour un système informatique de mettre en place des mécanismes de "raisonnement" fondés sur l'exploitation de "connaissances" déclaratives et plus particulièrement de connaissances déclarées sous une forme logique. Tous les guillemets sont là pour rappeler à quel point il s'agit de métaphores pour les termes "raisonnement" et "connaissances" alors que la forme logique n'est pas métaphorique mais correspond à un modèle mathématique précis autorisant le calcul.
De ce fait, la déclaration des connaissances suppose la capacité à formaliser sous forme de règles et de faits tout « ce que l’on sait comme étant VRAI » sur le domaine d'expertise de façon à établir la forme logique autorisant le calcul. Cette formalisation, bien que simple dans son principe, « atomise » les connaissances en une liste de déclarations indépendantes syntaxiquement mais fortement dépendantes sémantiquement les unes des autres. La structure de ces dépendances, c’est-à-dire les relations existantes entre chaque déclaration, sont définies également par des déclarations. Cette déclaration des dépendances n'est pas évidente à la simple lecture et surtout ne peut pas servir facilement de support à l’expression de ces connaissances. Bien que le texte des déclarations soit théoriquement lisible par l'utilisateur (après tout, c'est du texte!), il n'offre qu’une aide très limitée à sa compréhension par manque d'une structure syntaxique interprétable par l'homme selon la sémantique exprimée dans les déclarations. Par exemple, il est bien évident que la déclaration d’une liste de personnes avec sa relation hiérarchique avec les autres (relation chef_de) est beaucoup moins rapide à interpréter qu’un organigramme équivalent très simple.
Le développement d'un système informatique "à base de connaissances" nécessite donc un va-et-vient incessant entre une représentation adaptée à la logique du premier ordre telle qu'elle vous a été présentée dans ce cours et des représentations "équivalentes" à destination des utilisateurs. Les "ingénieurs de la connaissance" sont ces développeurs chargés de trouver les méthodes permettant de réaliser cette acquisition de connaissances à partir des expertises disponibles pour les traduire plus ou moins efficacement dans un système d'inférence logique. Ces méthodes existent et sont instrumentées par des outils informatiques accompagnant l'acquisition des connaissances (visiter le site du GRACQ pour en savoir plus). On peut faire le rapprochement entre cette évolution et le génie logiciel qui a développé des méthodes et des outils (voir la liste impressionnante des outils disponibles sur le web et/ou un cours proposé sur le web sur une méthode OBJECTORY représentative du génie logiciel objet) permettant de passer plus facilement des spécifications d'un système informatique par les utilisateurs à la réalisation de système par les informaticiens. La tâche d'acquisition des connaissances est en effet très lourde et se rapproche de la tâche d'analyse qui conduit au développement d'applications informatiques. Dans le cas du génie logiciel, un code informatique "exécutable" est généré à partir des modèles issus de l'analyse. Ce code intègre sans distinction données et procédures de traitement. Dans le cas du "génie cognitif", les connaissances sont générées en tant que telles et restent distinctes des procédures de traitement (que l'on appelle le moteur d'inférence). Ces connaissances sont représentées sous une forme symbolique : chaque concept est "nommé" par un symbole différent pour être manipulé en tant que tel. Pour des raisons évidentes, les noms donnés à ces concepts doivent être ceux qui correspondent aux usages des utilisateurs. Ce qui n'est qu'un dictionnaire de données en génie logiciel devient essentiel puisque le même concept doit porter bien entendu obligatoirement le même nom mais surtout posséder les mêmes caractéristiques sémantiques (provoquer les mêmes inférences) à chaque usage dans une déclaration de connaissance.
On peut imaginer l'effort fait pour réaliser un système à base de connaissances dans ces conditions. Cet effort consenti, on comprend que l'on souhaite réutiliser au maximum le résultat quand il s'agit de réaliser un nouveau système à base de connaissances. En pratique, l'idée s'impose d'essayer de définir un corpus de connaissances sur la sémantique des quelles un maximum d'utilisateurs soient d'accord.
En guise d'illustration, voici les déclarations typiques permettant de décrire un véhicule pour sa vente (les informations qui "font sens" pour fixer le prix d'un véhicule)
alphabet (des symboles)
Renault
Peugeot
Ford
Citroën
Marque
Modèle
R5
Clio
Névada
206 coupé
307 familial
2CV
Fiesta
Berline
Break
Coupé
(
)
non //(négation)
^ //(et, ou conjonction)
-> //(implique)
v //(ou, ou disjonction)
procédé de formation des expressions
expression <= symbole
expression <= ( expression )
expression <= non expression
expression <= expression1 ^ expression2
expression <= expression1 v expression2
expression <= expression1 -> expression2
axiomes
R1 : (Clio v R5 v Névada) -> Renault
R2 : (206 Coupé v 307 familial) -> Peugeot
R3 : (2CV) -> Citroën
R4 : (Fiesta) -> Ford
R5 : (Névada v 307 familial) -> break
R6 : (R5 v Clio v 2CV)-> berline
R7 : (206 coupé) ->Coupé
règle de dérivation (Cette règle est connue sous le nom de "modus
ponens" )
Si A est un théorème, et si
A -> B est un théorème, alors
B est un théorème