previous up next contents


Applicabilité et objectifs

La modélisation d'un cadre de compréhension de textes, présenté tout au long de ce travail et plus précisément dans les deux chapitres précédents sous le nom de Sémantique Interprétative Intertextuelle ( SII), a la particularité à la fois, d'une généralité et d'une généricité.

Bien sûr nous ne prétendons pas qu'il s'agisse d'un modèle universel de la compréhension. Par contre, en étant fondé sur une théorie linguistique d'interprétation sémantique, il n'est pas tributaire de manière inhérente de la spécificité d'un domaine d'application particulier. Si une certaine tâche comprend une phase de compréhension de textes, alors elle constitue déjà un candidat pour l'application de notre approche.

Par exemple, des pratiques aussi diverses que la critique littéraire ou la création de messages publicitaires, comme nous allons voir (cf. 6.2), sont des tâches qui intègrent une phase -- plus ou moins étendue -- de compréhension. Dans le premier cas, analyser un texte littéraire demande tout d'abord de le comprendre : l'application doit assister directement la compréhension d'un texte dans un univers textuel littéraire. Dans le cas de l'assistance à la conception publicitaire, le message produit est adressé à (et sera lu par) différents milieux sociaux : une application dans ce cas assiste la simulation des << compréhensions >> particulières au sein de certains milieux sociaux ciblés (qui peuvent être << modélisés >> à l'aide, précisément d'une anagnose, cf. p.[*]).

En réalité, même si elle est indépendante d'un domaine d'application, la méthode de compréhension présentée ici est issue d'une théorie linguistique dont les principes fondamentaux imposent un certain nombre de contraintes d'applicabilité. Une tâche de compréhension de textes peut être candidate d'une application de la SII, si elle remplit les conditions suivantes :

1.
La tâche ne doit pas exiger une compréhension automatique.

Un des principes fondateurs de la Sémantique Interprétative et par conséquent de la SII, est que le sens est le produit d'une interprétation par un agent humain. La construction de l'interprétation est le résultat de l'interaction d'un utilisateur avec le système informatique qui contient l'information sémique déjà explicitée. Au fur et à mesure de cette interaction, l'information est contrôlée, modifiée, sauvegardée et réutilisée de manière plus ou moins automatique. Mais le rôle de l'utilisateur est principal et irremplaçable pour cette modification de la matière sémantique.

La tâche de compréhension doit donc être en concordance avec un modèle d'assistance à la compréhension (cf. sur l'anthropocentrisme, la section 2.1.2) et rester loin d'un objectif d'automatisation complète de ce processus. Par contre, l'automatisation informatique peut être envisagée en tant que source de suggestions, en utilisant des heuristiques de recherche d'une information sémique pertinente pour un type d'analyses spécifique. Même si elle est automatique, cette fonctionnalité est totalement compatible avec le principe d'assistance.

2.
La tâche de compréhension doit concerner des textes écrits. Les méthodes décrites sont issues d'une sémiotique textuelle et le passage à d'autres formes de sémiotique demande un travail supplémentaire important (cf. aussi le commentaire sur la multimodalité dans la section 6.2.3).

3.
Le cadre méthodologique de la SII est mieux adapté aux textes sémantiquement riches, i.e. acceptant plusieurs interprétations, tels les textes journalistiques, littéraires, etc. Sans que cela constitue une contrainte, la méthodologie peut être mieux exploitée sur de tels textes5.1.

Même en respectant ces contraintes, les applications où la SII peut soutenir la tâche de compréhension textuelle restent nombreuses. Comment mettre en \oeuvre l'implantation informatique d'un modèle qui, donc, se veut aussi général ? Nous en voyons deux possibilités :

1.
Première, choisir arbitrairement une application particulière (e.g. critique littéraire) et implanter l'assistance d'une SII selon les besoins spécifiques de l'application
2.
Seconde, découper l'application en deux parties :
(a)
implanter un modèle générique qui est responsable de toute l'information sémantique issue d'une interprétation, c.-à-d. de tout ce qui constitue la partie statique et persistante de la SII, et
(b)
prévoir des facilités pour la mise en \oeuvre de la partie interactive, c.-à-d. de l'interaction spécifique avec le modèle statique selon les besoins d'une application

La première solution est directe, normalement plus rapide à implanter et probablement plus efficace, car toutes les structures de données sont conçues pour les besoins de l'application en question. Par contre elle oblige à refaire tout le travail de mise en place si nous voulons appliquer le même type de méthode de compréhension à une autre tâche.

De plus, l'information sémique explicitée lors de l'interaction avec l'utilisateur dans le cadre d'une application ne peut pas être réutilisée par une autre application. Ceci est très handicapant. D'autant plus que la SII est adaptée à une telle réutilisation : toute interprétation est décrite de manière uniforme, à l'aide de classes sémantiques ( CS) qui intègrent toute l'information nécessaire (c.-à-d. les entités textuelles, les sources sémiques et le type de construction sémantique).

Cette spécificité du modèle de la SII, présentée sous un point de vue formel dans le chapitre 4, apporte un poids important en faveur de la deuxième solution. La structure sémique intertextuelle de toutes les analyses, résultat des interprétations effectuées jusqu'à un moment, reste relativement autonome. Nous pouvons dire qu'elle peut être sauvegardée et récupérée plus tard, pour être utilisée dans de nouvelles interprétations. Il s'agit de la partie statique (une prise de vue instantanée sur les structures de données) et persistante (à travers la sauvegarde électronique des structures de données) de toute application qui est fondée sur la SII.

Sur cette partie statique peut opérer une deuxième partie dynamique qui concerne plutôt la modification de ces structures de données lors du processus d'interaction avec l'utilisateur. Ainsi, dans une application de critique littéraire on va se concentrer plutôt sur la charge sémantique de l'intratexte ou la spécificité d'un texte dans son univers textuel d'analyse. Tandis que dans une application de conception publicitaire une grande importance sera donnée à la constitution de l'intertexte représentatif d'une clientèle ciblée.

Alors, même si la deuxième solution paraît plus difficile à mettre en \oeuvre et, de prime abord, moins efficace que l'implantation directe et complète d'une application précise, nous estimons qu'elle comporte par ailleurs d'importants avantages :

1.
Elle permet de mettre en \oeuvre la SII dans sa naturelle généralité.

Différentes applications peuvent être conçues au dessus du cadre d'un même modèle.

2.
Chacune des applications peut utiliser les mêmes ressources sémiques (appartenant au modèle commun).

Si l'on arrive à gérer efficacement les conflits de concurrence, cette approche bénéficie d'un enrichissement constant de la base sémique, ce qui implique un espace de suggestion sémique plus riche.

3.
Elle permet, en outre, une implémentation rapide de nouvelles applications, puisque la grande partie du modèle (partie statique) est déjà programmée.

4.
Elle rejoint, enfin, une vision d'actualité en ce qui concerne le développement objet, modulé par le travail coopératif en réseau. Les fondements pour une application multi-utilisateur, travaillant et modifiant une base commune d'informations sémiques, à travers le réseau, sont déjà présents dans les choix que nous avons effectués pendant la modélisation et la mise en \oeuvre.

Nous voyons ainsi mieux les arguments de notre choix de la voie vers l'implantation. Nous choisissons de mettre en \oeuvre une assistance informatique à la compréhension conçue dès le départ dans un processus d'évolution vers des usages variés en rapport parfois de coopération. Pour cela, la mise en \oeuvre informatique de la SII doit remplir les objectifs suivants :

Dans le même contexte, l'objectif concernant une application précise, basée sur le cadre informatique décrit auparavant, est le suivant :

Par rapport à ces objectifs, l'implémentation informatique est découpée en deux grands morceaux. D'une part un modèle de données (modèle statique) qui contient les informations sémantiques réutilisables et d'autre part un ensemble d'applications qui utilisent et modifient ces informations en interagissant d'une part avec le modèle statique et d'autre part avec l'utilisateur.

Cette deuxième partie est centrée autour de l'interface utilisateur et, comme nous venons de mentionner, elle se pose comme objectif principal celui d'une meilleure convivialité et d'une ergonomie intégrée. 

Rappelons que l'ergonomie d'une interface utilisateur a quatre aspects principaux (cf. [61], [74]) :

Pour spécifier et construire, alors, une interface utilisateur il faut poser des objectifs qui sont souvent concurrents [73] :

Par exemple, pour éviter les erreurs, on peut ajouter des fenêtres de dialogue et de confirmation, ce qui ralentit la performance [61].

Ces objectifs impliquent un travail important d'analyse de besoins auprès des personnes qui utiliseront le système. Cependant, les résultats de ce travail ne concerneront que le style et le contenu des fenêtres, ainsi que le protocole de l'interaction (quelle fenêtre est présentée avant quelle autre, etc.). Le modèle sous-jacent reste le même, sa dynamique interne servira toujours à la récupération des bonnes données ainsi qu'à leur modification cohérente.

D'un autre côté, faire cette analyse et la présenter dans ce travail aurait l'avantage de donner un exemple précis d'une utilisation concrète du système, mais entraînerait l'inconvénient de conduire le lecteur vers une vision restreinte du champ applicatif du modèle de données. Proposer une vision ciblée du modèle, à travers une vue concrète (cf. fig.5.1), c'est cacher son objectif premier, qui est de constituer un modèle d'une théorie générique de l'interprétation (la Sémantique Interprétative) intertextuellement étendue.

Au lieu de fixer une interaction utilisateur concrète dès la conception du modèle, nous avons choisi de penser l'interaction utilisateur comme un client, attaché au modèle (qui devient serveur commun à plusieurs clients).

Tel est le cadre général de la mise en \oeuvre informatique. Outre le modèle en soi, nous avons implémenté une interaction et une interface génériques -- et donc utiles uniquement comme prototypes ainsi que pour tester toutes les fonctionnalités du modèle. Nous présentons ici uniquement la partie du modèle des données et leur interaction interne (appelé modèle statique ou modèle logique selon les terminologies) et nous présentons très succinctement les axes de l'interaction et de l'interface graphique génériques dans l'annexe A.

Nous laissons en perspective (cf. chap.6) la description d'un certain nombre d'applications ciblées qui peuvent opérer sur le même modèle.


previous up next contents
Theodore Thlivitis, 1998