La représentation des connaissances et les points de vue en IC

4.5.1. Diversité des formes de modélisation des

connaissances en IC

L’IC a pris l’habitude se définit comme « étude des concepts, méthodes et techniques permettant de modéliser et/ou d’acquérir les connaissances dans des domaines se formalisant a priori peu ou pas » [CHARLET 03]. Dans ce contexte général où l’IC vise depuis ses débuts une modélisation explicite des connaissances, il s’agit classiquement pour l’IC de construire des modèles adaptés à la nature des connaissances à décrire. Dans notre approche où les connaissances sont de même nature que l’action, la connaissance étant notamment ce qui permet de répéter l’action, quelle est la conséquence de cette définition sur les « modèles à construire ? Comment « le modélisateur » peut-il représenter suivant, des formalismes adéquats, une part des connaissances que les acteurs mettent en jeu dans leur activité ?

Dans notre cas, nous avons vu que « le modélisateur » pouvait être l’ingénieur de la connaissance ou le spécialiste de RTO, qui va alors chercher à se mettre à la place des acteurs (en dialoguant avec eux, en transposant ou paraphrasant leur discours dans les termes de ses connaissances personnelles, en anticipant leurs besoins et points de vue sous forme d’expérience de pensée, etc.). Mais nous avons vu aussi que, dans notre cas, selon le principe de « modélisation engagée », les modélisateurs peuvent être aussi les acteurs eux-mêmes.

La nature des modèles proposés en Ingénierie des Connaissances peut viser des niveaux d’ambition différents.

- Parmi les approches d’IC qui visent le plus d’exhaustivité dans la représentation des situations, nous trouvons des formes de représentation pour la conception d’un SBC, s’appuyant sur des formes de modélisation « fermées » : le système obéit à un « modèle conceptuel », à la fois des connaissances du domaine, des tâches et des méthodes, en recourant pour chacun de ces trois types à de modèles distincts, avec chacun leurs propres primitives de modélisation. En particulier la modélisation rend alors compte du contrôle interne du système à implémenter, comme dans le cas des systèmes experts.

- Au contraire, dans les approches d’IC « ouvertes », qui sont celles sur lesquelles nous nous appuyons, l’IC se démarque du formalisme comme principe de modélisation, en insistant sur le caractère effectif et symbolique des représentations formelles qu’une démarche formaliste permet d’élaborer [CHARLET 03]. Ce n’est pas la formalisation qui permet de dégager le contenu des connaissances, c’est l’effectivité de la formalisation et la signifiance linguistique des représentations symboliques qui permettent à l’humain de construire un système de représentations interprétées, c’est à dire un modèle. Les représentations symboliques du système formel ont un corrélat dans la langue, ils sont donc interprétables et de ce fait véhiculent des connaissances [BACHIMONT 96]. Dans notre cas, ce qui est formalisé au départ est un noyau générique, propre à accueillir sous une forme de réseau des éléments qui

sont des termes et expressions langagières, et qui se contente de modéliser une partie réutilisable et générique de connaissances pour la gestion de cette forme, concernant les aspects de domaine et les aspects d’activité. Comme nous l’avons vu, il n’y a donc pas de modélisation déterministe de la tâche mais plutôt des points d’entrée libres sur les composants de l’activité. Il n’y a pas non plus de méthode de raisonnement ni de modèle de contrôle qui seraient liés à un « modèle conceptuel » général. L’initiative est laissée aux modélisateurs/acteurs du système pour adapter le noyau générique à leur domaine et à leur activité.

Dans la suite, nous laisserons de côté l’aspect acquisition de connaissances, associé au cadre classique de conception d’un SBC et à une vision réifiée de la connaissance, dont nous avons expliqué pourquoi elle ne convient pas à notre projet. Nous nous concentrerons sur les approches d’IC « ouvertes », et plus particulièrement sur le cas où seul un noyau générique est formalisé au départ, fournissant la base d’un outil de représentation de connaissances.

4.5.2. Nature du langage de représentation des

connaissances Hypertopic

Plus précisément encore, dans notre approche, la part de connaissance réutilisable fournie par le noyau générique n’est pas une ontologie de domaine, mais une ontologie générique. Cette dernière ne porte pas de connaissances abouties, ni sur le domaine ni sur l’activité, mais se situe à un niveau intermédiaire que l’on peut qualifier avec [BRACHMAN 79] de « niveau épistémique »17. Une telle ontologie générique permettant aux modélisateurs/acteurs de construire eux-mêmes une ontologie plus aboutie, qui dans notre cas est une ontologie sémiotique. L’IC désigne aussi ce type de noyau d’ontologie générique sous l’expression de « langage de représentation des connaissances », que nous préférerons.

Dans le prolongement lointain du système KL-One de [BRACHMAN 79] ou des travaux de [WINOGRAD 88], le langage de représentation que nous proposons est aussi basé sur l’utilisation de réseaux sémantiques ou des graphes. Nous ne visons pas à utiliser ces structures en réseaux pour des calculs automatiques de graphes, comme l’autorisent par exemple les graphes conceptuels [RIBIERE99], ni pour faire des calculs automatiques de distances et de « clusters » dans des cartes de thèmes [LE GRAND 02], mais bien dans le sens de la recherche de l’intégration la plus importante possible avec la pratique langagière humaine. Nous aurons l’occasion d’approfondir ce point dans le chapitre 5, consacrée au lien de notre approche avec les Sciences du Langage. L’utilisation de réseaux sémantiques nous intéresse dans la mesure où ils servent d’appui à des pratiques de navigation et de construction collective de la signification. Dans ces pratiques les réseaux sémantiques ne sont pas des modèles calculables, mais des outils d’aide à la navigation, à la communication et au partage d’information, qui ne lèvent pas complètement l’équivocité et la polysémie des expressions langagières qu’ils incluent. Ces structures sémantiques qui interviennent en tant qu’artefacts s’adressant à des usages humains (cf. §4.6), peuvent également être considérées comme des Ressources Terminologiques et Ontologiques (RTO) telles que les étudient les Sciences de l’information et de la documentation (cf. §4.7).

Les éléments sémantiques portés par l’artefact naissent alors des transactions ordinaires, au sens de [DEWEY 38], sans qu’il soit besoin de les imposer « d’en haut » depuis une source a priori ou

17_{Le modèle Hypertopic est un modèle de représentation des connaissances qui l’on peut situer au niveau « épistémologique » de la} signification des réseaux sémantiques défini par [BRACHMAN 79] comme « structure formelle des unités conceptuelles et de leurs interrelations (…) permettant de donner une définition formelle des primitives structurant la connaissance, plutôt que des primitives de connaissance particulière (comme dans les réseaux de Schank) ». Ce modèle s’applique à l’information non-structurée ou semi-structurée, qui repose sur l’aspect pragmatique de l’usage d’un outil et sur la façon dont un groupe s’organise pour réguler les significations.

Avec cette approche, nous ne sommes pas en présence de concepts formels comme dans les modélisations de domaine des SBC, mais de simples inscriptions d’expressions linguistiques - les thèmes (en anglais, topic) - requérant la présence des acteurs pour réguler la représentation. Dans les ontologies sémiotiques telles que nous les envisageons, il n’existe pas, ou très peu, de régulation interne par le modèle: « la sémantique » est recréée de façon externe, en permanence, dans l’activité et l’interaction des acteurs.

depuis une perspective de modélisation.Mais (comme dans les règles de droit) dès que les structures sémantiques sont formées, elles deviennent aussi formatives: elles règlent la propre conduite des activités dont elles proviennent.

En anticipant légèrement sur la présentation plus détaillée qui en sera faite, nous pouvons aussi préciser que le modèle Hypertopic que nous proposons, est un langage qui va permettre non de catégoriser, mais de rendre pérenne sur l’artefact des jalons et des traces de l’activité dans le domaine et dans le groupe, traces que les acteurs vont pouvoir ensuite réutiliser et partager. En nous référant à la grille que nous avons évoquée au §4.3, le langage proposé n’est pas donc pas un système de résolution de problème de classification, encore moins un système-expert de catégorisation. Compléter le dessin d’une carte en se conformant à une légende, en nommer les ingrédients, y déposer des marques pour les retrouver soi-même ensuite, ou pour que d’autres les y retrouvent, ce n’est pas classifier ni catégoriser (bien que cela puisse l’être, dans certains cas). Nous préférons considérer que le langage de représentation proposé vise non une tâche de classification, mais une activité de conception plus générale et plus riche, apparentée à la conception cartographique.

Le langage Hypertopic (Fig.1.1 et Fig.2.4), que nous décrirons en détail au Chapitre 6, est donc une légende, en même temps qu’un noyau formel générique, susceptible d’être exécuté par un ordinateur pour faciliter la gestion de la cartes de thèmes en tant que « document » (cf. §4.6). Hypertopic n’est en lui-même ni un SBC, ni un modèle conceptuel complet, mais il permet ensuite à des modélisateurs/acteurs de le personnaliser, c’est à dire de construire suivant ce modèle une ontologie sémiotique correspondant à leurs domaine, situation et activité. A son tour, cette ontologie sémiotique ne constitue ni un modèle conceptuel complet ni un SBC abouti (au sens où elle modéliserait de façon « fermée » le domaine, les taches et les méthodes), mais un artefact informatisé. Cette ontologie sémiotique reste « ouverte », dans le double sens où elle reste perfectible en permanence par les acteurs (malléabilité de représentation) et où ce sont toujours les utilisateurs qui décident du sens qu’ils donnent à l’ontologie sémiotique dans leurs actions.

Lorsqu’ils construisent une ontologie sémiotique avec le langage Hypertopic, les acteurs décident quels sont les objets qu’ils retiennent comme importants dans leur activité et qu’ils veulent repérer sur la carte, en décrivant les caractéristiques de ces objets de façon peu contrainte à l’intérieur de « points de vue ». Ce faisant, ils restent dans leur univers langagier habituel, tout en se conformant aux quelques règles du « guide de pensée » que constitue le langage de représentation, comme légende préétablie pour la carte. L’outil canalise la réflexion des acteurs et leurs discussions, en leur imposant par cette légende imposée une forme légère de « raison computationnelle ». Les acteurs de la modélisation collective sont ainsi amenés à s’interroger collectivement, tout en étant guidés, pour déterminer quels points de vue, thèmes, entités, relations, etc., possèdent pour eux une consistance, par rapport aux objectifs et aux usages qu’ils assignent à l’artefact.

4.5.3. Langages de représentation en IC et Génie Logiciel

Il faut également noter une importante différence entre les méthodes du génie logiciel, où les modèles conceptuels constituent la spécification des rouages internes d’un système à implémenter, et les modèles de l’IC, qui en particulier dans notre cas ne vont pas servir avant tout à constituer un système informatique, mais à appuyer un système d’usages sur des documents dont l’ordinateur se contente de faciliter le partage et la communication18.

Alors que pour le génie logiciel, les informations ne sont sémiotisées qu’à la périphérie du système, à l’occasion de certains événements d’interaction humain-machine, pour l’IC basée sur les artefacts, la question de la sémiotisation se pose en permanence. Rappelons qu’il y a connaissance et représentation des connaissances quand les manipulations symboliques, effectuées de façon dé-sémiotisée par la machine via des programmes, prennent un sens et une justification pour les

18_{C’est aussi à notre sens un point commun important entre les modèles de l’IC et ceux du TCAO évoqués dans les chapitres 2 et 3.} C’est pourquoi nous tenterons aussi dans la suite d’aligner les deux notions d’usage et d’activité qui nous semblent au même niveau, afin de rechercher un langage commun entre ces deux disciplines

utilisateurs interagissant avec ces programmes. Le système que nous considérons est une activité humaine qui place donc les usages en son centre, et non un système informatique qui place les usages à sa périphérie. Cela signifie que les utilisateurs interprètent d’abord le comportement de la machine, ce qu’elle leur donne à voir sur l’écran, etc., comme des connaissances qui viennent nourrir leur activité.

Cela permet de mieux comprendre la situation à laquelle nous sommes confronté avec notre modèle Hypertopic, modèle que nous proposons pour la représentation des connaissances basée sur les ontologies sémiotiques. En termes de génie logiciel, le modèle intervient à la fois de façon désémiotisée au niveau computationnel (notamment comme base du modèle de données interne à l’outil d’aide à la navigation, à l’édition et à la manipulation des informations de la carte), et en termes d’IC il intervient de façon re-sémiotisée par les acteurs interprétant l’ontologie sémiotique.

Le langage de représentation de connaissances est un outil d’IC en ce qu’il participe comme « légende » à l’interprétation, avec de nombreux autres facteurs, de la carte de thèmes qui se donne à voir sur l’écran. Ces « nombreux autres facteurs » sont des facteurs qui proviennent de l’expérience de l’acteur, de la situation et du contexte, et sont pour la plupart des facteurs également langagiers, Leur possibilité d’influer indique ici que le modèle proposé ne vise pas à fermer l’interprétation. L’ontologie sémiotique est un document, et la signification des connaissances n’est encadrée que partiellement par le modèle19.

4.5.4. IC et « points de vue »

Parce que la connaissance pour l’IC est a priori un affaire d’interprétation, la notion de « point de vue » exprime d’une certaine façon tout le trajet qui va mener de l’acteur à la signification qu’il se forge, en passant par l’objet considéré et par les expressions de langage rencontrées en chemin. La notion de « point de vue » est donc implicitement présente dans les fondamentaux de l’IC. Cependant cette notion a été jusqu’ici plutôt implicite et discrète, notamment du fait que l’IC ne s’intéresse que depuis peu au collectif.

A notre connaissance, après avoir lu un certain nombre de textes de base en IC, il apparaît que dans le schéma dominant de la discipline, il n’y a qu’un concepteur du système d’IC : l’ingénieur de la connaissance, ou l’ontologiste s’il s’agit d’ontologie de domaine. Si dans la réalité, comme cela est fréquent, il s’agit d’un groupe de concepteurs, l’IC considère que ce groupe débat, mais qu’ensuite il parle d’une seule voix au moment de la conception : il agit comme un ingénieur de la connaissance unique. Ce schéma reste très prégnant, y compris lorsque l’IC vise à faire des SBC s’appuyant sur la connaissances de multiples experts : l’ingénieur de la connaissances réalise alors l’acquisition auprès des experts avec des méthodes spécifiques à ce type de SBC multi-experts.

Dans le cadre de méthodes de l’IC, il n’y a aussi en général qu’un seul utilisateur (prototypal) envisagé pour le système (même dans le cas, qui est le plus fréquent, d’un système « multi-utilisateurs »). Ce schéma a été longtemps le modèle de la conception en IC comme d’ailleurs dans l’ensemble de l’ingénierie de logiciel et de système (cf. §2.3.1).

Dans ce schéma mono-concepteur, la notion de point de vue peut être considérée comme présente, mais celle-ci est une approche « faible » du Point de vue (cf. §5.4). Le concepteur expérimente alors la recherche d’un « jeu idéal de points de vue » dans une expérience de pensée. Le modélisateur peut également être confronté à un matériel d’acquisition de connaissances émanant de multiples experts ou de multiples sources, dont il doit effectuer la synthèse (par exemple dans [SIMON 99]). Cette activité, qui peut s’accompagner de problèmes techniques très difficiles d’alignement ou de fusion d’ontologies, se ramène, pour ce qui est des points de vue, à la recherche d’un schéma de classification optimal. Elle reflète toujours, au final, le point de vue surplombant du seul ingénieur de la

19 Par exemple dans une application selon le modèle Hypertopic, un arc de réseau sémantique liant un thème à un autre thème, ou liant un thème à une entité singulière, ne prendra un sens plus précis (tels que « est », « est un », « fait partie de », « traite de » ou tout autre sens mieux déterminé par le contexte et les savoirs antérieurs de l’acteur) qu’en fonction de la situation de l’acteur et de ses connaissances ici et maintenant. En comparant avec la situation de la consultation d’une carte géographique par un automobiliste perdu, celui-ci se sert de la carte, mais en même temps des signes qu’il voit dans son champ visuel (paysage, panneaux), de ses souvenirs, de ses connaissances de base sur la géographie, la voirie et la conduite automobile.

connaissance, artisan de ces compromis, ce qui présente certaines limites. En particulier cette conception d’un jeu de points de vue a tendance à faire « remonter » les points de vue des différentes facettes fonctionnelles du phénomène considéré, plutôt qu’à « descendre » de l’observateur/modélisateur, qui par définition dans ce schéma n’est pas multiple. La solution la plus simple que peut adopter le modélisateur unique est en effet d’adopter une posture de « point de vues multiples » pour considérer tour à tour des facettes fonctionnelles multiples de son objet, par exemple en s’imaginant successivement dans des rôles différents utilisant cet objet.

Nous devons donc considérer une différence entre :

- d’une part, dans le schéma mono-concepteur, la démarche pour un seul modélisateur d’imaginer un ensemble cohérent de points de vue (version « faible » du point de vue)20, - et d’autre part, dans le schéma de co-construction par des concepteurs multiples, la rencontre

voire le choc conflictuel de points de vue de modélisateurs / acteurs différents, éventuellement inconciliables pour des raisons épistémiques et sociales (version « forte » du point de vue). La plupart des approches qui ont été suivies jusqu’à présent dans le domaine de l’IC pour intégrer la notion de point de vue dans les systèmes d’IC ont reposé surtout sur le premier cas, de supervision du jeu de points de vue par un modélisateur unique. C’est l’ingénieur de la connaissance qui sert de pivot pour édifier ou unifier le jeu de points de vue comme configuration systémique cohérente (cf. Fig.1.3) Dans ce cadre, des recherches et des projets technologiquement ambitieux et difficiles ont été mis en œuvre, notamment pour des problèmes de partage ou de fusion d’ontologies formelles, dans une approche de points de vue multiples. On peut citer de nombreux travaux où des préoccupations de fusion ou rapprochement de points de vue (ou des notions approchantes) sont présentes, tels que [MARINO 93] [EUZENAT 96] [SIMON 99] [RIBIERE99] [NAPOLI 00] [NOY 00] [EUZENAT 01] [FALQUET 01].

A ce propos, notons que le point de vue, comme nous le verrons plus en détail au chapitre 5 est même dans sa version « faible » une approche reposant à part entière sur l’interprétation d’acteurs en situation. Il ne peut donc se réduire à la notion de vue telle qu’elle est utilisée de façon dé-sémiotisée dans le domaine de l’informatique des bases de données.21