Intégration homogène de l’interaction spontanée : gérer les pro-

Jusqu’à présent, les opérateurs de description proposés permettent de mettre en place une interaction dirigée, c’est à dire basée sur la détection automatique de problèmes et la réponse ciblée à l’extérieur du module d’interprétation de page. Pour faire face aux cas où la détection automatique de problème n’est pas possible, il est nécessaire de permettre la mise en place d’une interaction dirigée qui autorise la détection et la correction de problèmes à l’extérieur du module d’interprétation de page.

Les raisons pour lesquelles certains problèmes ne peuvent pas être détectés automati- quement peuvent être multiples, et on peut citer :

– le manque de connaissance à propos du contenu réel des document d’un fonds ; – la difficulté à détecter un problème et à le localiser précisément ;

– l’absence d’implémentation du mécanisme de détection, par manque de temps ou de moyens lors de la conception du système.

Nous proposons ici un nouvel opérateur capable d’exprimer l’incertitude d’une partie de la description. Il autorise les modifications spontanées, c’est à dire multiples et option- nelles, des résultats hors du module d’interprétation de page qui réintégrera ces nouvelles données. Cet opérateur doit être couplé à l’utilisation de l’opérateur get_answer_or_try pour permettre l’exploitation des réponses. Il est parfaitement compatible avec le méca- nisme d’interaction dirigée qui peut être utilisé simultanément.

6.3.3.1 Syntaxe du nouvel opérateur

L’opérateur que nous proposons délimite une portion de description incertaine pour laquelle des éléments pourront être remplacés ou ajoutés grâce à une interprétation externe intégrant plus de connaissances et de contexte.

Concernant le choix du nom de l’opérateur, nous avons pensé qu’il était judicieux d’avoir un nom assez générique pour pouvoir représenter les différentes situations dans lesquelles il est utile d’exprimer la possibilité de modifications externes. Le nom et le type de cet opérateur sont donc les suivants :

spontaneous(T, Rauto)

Type : (TypeDonnée × (() → (Zone × A)) → (Zone × A)

De même que pour les autres opérateurs, c’est au concepteur de définir, dans la descrip- tion de la page, quand il souhaite utiliser spontaneous.

6.3.3.2 Structures de données nécessaires

Pour indiquer la possibilité d’apporter zéro, une ou plusieurs informations d’un type donné à un endroit précis dans l’image, nous proposons d’introduire une nouvelle sorte de question optionnelle (toujours de type DonnéeMémoire) de la forme suivante :

(zoneQuestion, question_optionnelle, { txt : Q,

type_attendu: T,

zone_acceptation: zoneAcceptation, . . . })

(6.48) Cette question pourra accepter aucune, une ou plusieurs réponses de la forme classique suivante :

(zonePrecise, T, { valeur : Val, . . . }) (6.49) où zonePrecise ∩ zoneAcceptation 6= /0.

6.3.3.3 Compilation et sémantique

Si on considère qu’il est possible d’utiliser la gestion de variables dont nous nous sommes servis pour simplifier l’écriture des descriptions précédentes, alors cet opérateur

peut être mis en œuvre de la façon suivante, directement dans le langage de description : spontaneous(T, Rauto) −→ var zR

zR← acces_zone_recherche

a jouter_mem(zR, question_optionnelle,

{ type_attendu : T }) Rauto

(6.50)

L’opérateur pose systématiquement une question optionnelle, et appelle la règle de descrip- tion Rauto.

Pour simplifier la description, nous avons introduit un nouvel opérateur acces_zone_recherche qui renvoie la zone de recherche courante. Son type est :

() → Zone (6.51)

et sa définition est :

T

6.3.3.4 Exemple

Pour illustrer l’intérêt de ce nouvel opérateur, on reprend l’exemple des numéros d’ordre contenus dans la colonne de gauche des tableaux tels que celui rappelé dans lafigure 6.5.

FIGURE6.5 – Extrait d’un registre de ventes dont on souhaite extraire les numéros de vente

(colonne de gauche). Rappel des figures6.3et6.4. Dans ce cas, on va supposer :

1. que le seul problème pouvant se poser est de « manquer » un numéro de vente qui serait effacé ;

2. qu’il n’est pas possible de détecter automatiquement ce problème.

Description avec interaction spontanée Nous allons donc nous baser sur une description simplifiée, présentée ci-après, du contenu de la page. La seule utilisation de l’opérateur

spontaneousconcerne l’appel à reconnait_no. colonne_no −→var posCol

@(gauchePage)

(posCol, _) ← localiser_colonne_no @(posCol)

spontaneous(no_vente, localiser_lire_no) localiser_lire_no −→var posNo posPreciseNo ResReco

(posNo, _) ← localiser_no @(posNo)

(posPreciseNo, ResReco) ← get_answer_or_try(no_vente, reconnait_no) @(sous posNo)

localiser_lire_no localiser_lire_no −→ passer

(6.53) Stratégie globale De même que précédemment, il est nécessaire de définir une stratégie globale minimaliste pour pouvoir imaginer le comportement du module d’interprétation de page et visualiser l’évolution du contenu de la mémoire associée à une page donnée. L’algorithme 3présente une stratégie adaptée à une interaction spontanée où chaque page est traitée séparément, en étant d’abord interprétée par le module d’interprétation de page, puis contrôlée par un opérateur humain qui peut proposer des corrections et déclencher une nouvelle passe le cas échéant. Une page sera considérée comme complètement traitée si l’opérateur humain ne fait aucune modification dans la mémoire visuelle associée.

Algorithm 3 Exemple de stratégie globale pour l’interaction spontanée

1: procedureTRAITER_LOT(lot) 2: while lot 6= /0 do

3: p ← lot.extraire()

4: p.cpt ← p.cpt + 1 ⊲ p.cpt compte le nombre de passes sur p

5: m ← BDC.extraire_memoire(p) 6: (r, ∆m) ← MIP. interpreter(p, m) 7: m ← f usionner(m, ∆m) ⊲ point A 8: ∆m ← IHM. controler(p, m) 9: if ∆m 6= /0 then 10: m ← f usionner(m, ∆m) ⊲ point B

11: lot.a jouter(p) ⊲ Il faut réinterpréter p

12: end if

13: DBC.stocker_memoire(m)

14: end while 15: end procedure

Évolution du contenu de la mémoire visuelle associée à l’image En supposant que le second numéro de vente est effacé, voici l’évolution de la mémoire associée à la page de la figure 6.5. Nous nous intéressons, comme précédemment, au contenu de la mémoire visuelle m associée à la page p après l’exécution des instructions aux points A (après la réponse du module d’interprétation de page) et B (après la réponse d’un opérateur humain) dans l’algorithme 3.

Contenu de la mémoire visuelle Itération 1, point A

{ (zoneColonne, question_optionnelle, { type_attendu : no_vente }), (zoneNo1, no_vente, { valeur : 131 }),

(zoneNo3, no_vente, { valeur : 133 }) }

Observations : Le module d’interprétation de page n’a localisé que deux nombres sur les trois à extraire, mais une question optionnelle autorise l’ajout (et éventuellement la modifi- cation) d’éléments.

Contenu de la mémoire visuelle Itération 1, point B

{ (zoneColonne, question_optionnelle, { type_attendu : no_vente }), (zoneNo1, no_vente, { valeur : 131 }),

(zoneNo2Precise, no_vente, { valeur : 132 }), (zoneNo3, no_vente, { valeur : 133 }) }

Observations : Un opérateur humain a localisé et donné la valeur du nombre manquant. Il est inutile de supprimer la question optionnelle.

Ensuite, lors de la seconde itération, les données sont réintégrées par le module d’interpré- tation de page, validées par l’opérateur humain, et la page est sortie du lot à traiter.

Pour conclure, notons que l’opérateur proposé permet d’identifier l’information à pro- pos de l’image considérée qu’il est possible d’apporter spontanément au module d’inter- prétation de page pour faire progresser son interprétation. Apporter d’autres informations n’aurait, à priori, pas d’impact et il faudrait passer à une édition manuelle pour dépasser les limites de la description pour corriger d’autres problèmes.