Choisir un type d’espace géographique

Après avoir vu comment le composant d’orchestration gère les différents états que prennent les objets géographiques durant leur généralisation dans CollaGen, nous détaillons notre proposition pour choisir le prochain type d’espace géographique à généraliser à un moment donné. De manière complémentaire à notre proposition de règles d’orchestration, nous proposons que ce choix soit fait par un système expert intégré au composant d’orchestration capable d’inférences à partir des règles d’orchestration telles que nous les avons modélisées en C.8. Un système expert possède trois composants principaux : une base de règles, des faits et un moteur d’inférence permettant de prendre une décision sur un fait à partir des règles (Jackson, 1998). Dans notre cas, les règles sont les règles d’orchestration et les faits la position courante dans le processus CollaGen. La position dans le processus est modélisée de la manière suivante (Figure C-75) : elle contient l’étape de généralisation courante (par exemple, l’étape de Sélection), l’espace géographique généralisé juste avant (par exemple, l’unique instance de type Réseau hydrographique) et le processus utilisé juste avant pour généraliser l’espace (par exemple, le processus issu de (Touya, 2007)) ; un attribut booléen signale également si l’on se situe au début d’une étape (i .e. la décision précédente du moteur d’inférence a été de changer d’étape plutôt que de généraliser un type d’espace).

Figure C-75. Diagramme de classe UML de la représentation de la position dans le processus de CollaGen.

Le moteur d’inférence que nous proposons doit gérer trois contraintes : il doit pouvoir donner un type d’espace à généraliser à tout moment du processus, il doit pouvoir gérer un jeu incomplet de

règles et il doit éviter de rester coincé dans une étape. Le moteur fonctionne avec l’algorithme suivant :

Le moteur cherche d’abord la prémisse la plus proche du fait (la position dans le processus) par chainage avant (Russell et Norvig, 2006).

o Si le moteur trouve une règle avec une prémisse assez proche, il applique directement la conclusion de la règle (qui est le prochain type d’espace à généraliser).

o Sinon (cas d’un jeu de règles incomplet), la priorité du moteur est de sortir de l’étape courante pour passer à la suivante. Il cherche donc par chainage arrière la règle qui permet de sortir de l’étape et remonte la chaîne (Si les règles sont

et C est le passage à l’étape suivante, la chaîne trouvée sera A, B, C). Afin d’éviter l’oubli d’espaces à généraliser, le moteur cherche alors les espaces clés, non traités dans cet espace et non présents dans la chaîne arrière.

 S’il y en a, il choisit parmi ces espaces celui qui a le plus besoin d’être généralisé.

 Sinon, le moteur choisit l’espace qui correspond à la première prémisse de la chaîne arrière, ce qui permet de se raccrocher aux règles qui aboutissent à la fin de l’étape.

Nous détaillons maintenant le fonctionnement de chacun de ces points. Tout d’abord, le moteur cherche la prémisse la plus proche par chainage, la proximité étant calculée par une distance utilisant notamment la hiérarchie des concepts de l’ontologie. Pour établir la distance entre fait et prémisse d’une règle, nous appliquons la méthode suivante :

Distance(fait, règle) : double

// on vérifie qu’ils concernent bien la même étape courante

Si (regle.etape = ) Alors

Initialisation distance ← 1

Sinon Si (fait.etape != regle.etape) Alors Initialisation distance ← +∞

Fin Si

Initialisation PremisseRegleOrchestration premisse ← regle.premisse()

// on compare prémisse et fait par rapport à l’espace précédent

Si (fait.espacePrécédent est un premisse.espacePrécédent) Alors

distance ← distance + nb de concepts entre les deux

Sinon

Initialisation distance ← + Fin Si

// on compare prémisse et fait par rapport au processus précédent

Si (fait.processusPrécédent est un premisse.processusPrécédent) Alors

distance ← distance + nb de concepts entre les deux

Sinon

Initialisation distance ← + Fin Si

// on traite le cas d’une prémisse de début d’étape

Si (premisse.espacePrécédent = et premisse.processusPrécédent = et fait.debutEtape = faux) Alors

Fin Si

Pour résumer, le concept de l’ontologie décrit dans le fait (que ce soit l’espace précédent ou le processus précédent) doit être le même que dans la prémisse, ou plus spécifique, auquel cas la distance est augmentée. Par exemple, si nous avons dans l’ontologie les concepts suivants réseau routier est un réseau de transport est un réseau est un espace thématique, alors le fait ayant pour espace précédent réseau routier est compatible avec une règle de prémisse sur réseau avec une distance de 2.

Si aucune règle n’est à une distance finie de la situation courante dans le processus, le moteur cherche la règle qui termine l’étape courante pour passer à la suivante et réalise le chainage arrière en utilisant cette même distance pour trouver de manière itérative (en partant de cette dernière règle) la règle dont la conclusion est la plus proche de la prémisse courante. Le résultat de ce chainage arrière est un ensemble de règles qui mène d’une prémisse à la fin de l’étape courante, en passant par la généralisation d’un certain nombre de types d’espaces géographiques.

Mais avant de réaliser cet enchaînement de règles, le moteur s’assure qu’il n’a pas oublié d’espace clé à généraliser. Pour cela, il cherche si des types d’espaces clés sont absents de la liste des espaces déjà traités dans cette étape et de la séquence de chainage arrière. S’il y en a, le moteur ne dispose d’aucune connaissance dans les règles pour guider son choix, il doit utiliser d’autres critères. Ce problème se rapproche beaucoup de celui de la stratégie d’activation des agents dans un système multi-agent, notamment ceux dédiés à la généralisation : quel est le prochain agent à activer à un moment donné du processus ? (Ruas, 1999) pose le problème de la stratégie d’activation à un niveau de granularité différent (au niveau des objets meso et micro) dans le modèle AGENT mais ses propositions restent valables dans notre cas. Deux approches complémentaires sont distinguées, la planification prédéfinie ou le choix à partir de l’état des contraintes. La planification prédéfinie correspond à notre cas général d’utilisation des règles d’orchestration donc l’état des contraintes peut être une bonne stratégie simple pour le choix du prochain espace quand aucune ne correspond à la position dans le processus CollaGen. Dans le modèle CartACom, le problème de l’ordre d’activation des agents à généraliser se pose aussi et deux stratégies sont proposées, une activation aléatoire par cycle et par meilleur prochain (Duchêne, 2004). La stratégie par meilleur prochain (guidée par la réception des messages de demande d’action échangés entre les agents) s’avère être la plus efficace et efficiente. (Altay, 2010) propose même une amélioration ad-hoc de la stratégie par meilleur prochain avec des résultats intéressants. Néanmoins, ces stratégies ne sont pas directement applicables à notre problème, donc, nous proposons d’utiliser simplement une méthode guidée par la satisfaction des moniteurs de contraintes à l’intérieur des espaces géographiques : le type d’espace, parmi les espaces clés restant, dont les instances sont les moins satisfaites en moyenne, est choisi par le moteur pour être le prochain à être généralisé.

Dernier cas, si le moteur ne trouve pas de règle permettant de terminer l’étape courante, il choisit simplement un des types d’espaces clés restant, les triant encore en fonction de la satisfaction des moniteurs dans les instances du type. Quand il ne reste plus de type d’espace clé à traiter, le moteur fait passer la généralisation collaborative à l’étape suivante.

Etant donné la difficulté relative de décrire des règles d’orchestration, d’autant plus dans un cadre formel comme CollaGen, nous avons doté le moteur d’inférence de notre composant d’orchestration

de capacités de vérification automatique de la base de règles. Ainsi, il est possible de vérifier si la base de règles d’orchestration contient les incohérences suivantes :

− Incompatibilité de deux règles (R1: Si A et B alors C; R2: Si A et B alors D;) − Redondance de deux règles (R1: Si A alors B; R2 : Si C alors B)

− Bouclage entre trois règles (R1 : Si A alors B ; R2 : Si B alors C ; R3 : Si C alors A ;)

Dans notre cas, la redondance n’est pas forcément un défaut de cohérence car la généralisation d’un espace donné peut être la conclusion de plusieurs règles avec des prémisses différentes (des étapes courantes différentes par exemple). Donc une base de règle redondante n’est pas jugée comme mauvaise. Mais la présence des deux autres types d’incohérences fausserait fortement les résultats du moteur d’inférence donc la vérification est systématique au lancement d’une généralisation par CollaGen.

Prenons maintenant un exemple simplifié pour illustrer le choix du prochain type d’espace à généraliser à partir des règles d’orchestration. Nous disposons dans la base de règles des règles d’orchestration suivantes :

(R1). On commence la généralisation cartographique par les espaces urbains. (R2). Si le type d’espace précédent est urbain alors on généralise le réseau routier. (R3). Si le type d’espace précédent est le réseau routier alors on généralise les espaces

ruraux.

(R4). Durant l’étape de sélection, si le type d’espace précédent est le réseau routier alors on généralise le réseau ferré.

(R5). Durant l’étape de généralisation cartographique, si le type d’espace précédent est un espace de montagne, on passe à l’étape suivante.

Dans notre exemple, le fait, c’est-à-dire la position dans le processus CollaGen, est le suivant : durant l’étape de généralisation cartographique, le système vient de généraliser les graphes de flexibilité par un processus spécialisant le modèle des Beams (Bader et al, 2005), sachant que dans l’ontologie, le concept graphe de flexibilité est un réseau routier. La distance de ce fait est infinie avec les règles R1 (car le fait n’est pas le début de l’étape de généralisation cartographique), R2, R5 (car l’espace précédent de la prémisse ne correspond pas, le graphe de flexibilité n’étant ni un espace urbain, ni un espace de montagne) et R4 (car l’étape courante n’est pas la même bien que la prémisse corresponde). Par contre la distance avec la règle R3 est de 2 (1 pour l’étape de la règle non précisée et 1 pour la distance dans l’ontologie entre graphe de flexibilité et réseau routier). La règle R3 est donc celle qui est choisie par le moteur d’inférence. Le prochain espace à généraliser est donc l’espace rural. Ensuite, une fois les espaces ruraux généralisés, le moteur est de nouveau interrogé avec ‘espace rural’ comme espace précédent mais il ne trouve aucune règle qui correspond. Il cherche donc la règle terminant l’étape courante et trouve la règle R5. Et par chainage arrière, le moteur infère que le prochain type d’espace à généraliser est ‘espace de montagne’ (en supposant qu’il ne reste plus d’autre espace clé à généraliser à cette étape).

Pour aller plus loin dans la conception d’une stratégie d’activation quand aucune règle n’est disponible, (Meurisse, 2001) propose dans le cadre de systèmes multi-agents, un modèle pour décrire les dépendances entre agents (tel agent doit être déclenché avant tel autre agent). Dans notre cas, une perspective serait de traduire l’ensemble des règles d’orchestration sous la forme de

dépendances pour que le choix d’activation fait en fonction des contraintes ne soit pas en contradiction avec les dépendances (règles d’orchestration).