Discussion : choix de modélisation et conséquences

5.4.1 Domaine de validité des propriétés : éléments individuels ou larges ensembles ?

Il est possible d’imaginer différents niveaux de granularité dans la définition desschèmesde classe Propriété, c’est-à-dire différentes partitions de l’espace des propriétés. Considérons par exemple la représentation de la couleur d’une référence. Pour simplifier, nous admettons que seules trois couleurs sont possibles (rouge, vert, bleu). Au moins trois manières de représenter cette notion sont disponibles et résumées dans le tableau5.7.

Représentation 1 2 3

Nombre de

propriétés ^{1 : color 3 :red,blue,green 3 :red,blue,green}

Domaine de validité ^δcolor = {“red”, “blue”, “green”} Pour chacune : δ = {True, False} Pour chacune : δ = J0, 1K (e.g. couleurs 16 ou 32 bits)

Pouvoir expressif Faible Moyen Fort

Informations implicites sur le domaine

Importante Faible Faible

Tableau 5.7 Trois représentations possibles pour la couleur d’une référence

En termes de pouvoir expressif, c’est-à-dire la capacité à représenter des éléments com-plexes du monde, nous avons 1 < 2 < 3, dans la mesure où :

− dans le cas 1, un objet a une et une seule couleur,

− dans le cas 2, un objet est ou n’est pas de chacune des couleurs possibles, − dans le cas 3, un objet peut être plus ou moins de chaque couleur.

Au contraire, en termes de connaissances du domaine ou de capacité de généralisation, en l’absence d’informations supplémentaires, 1 > 2 = 3 puisqu’il est alors implicite que le fait qu’un objet soit rouge l’empêche d’être également bleu et vert.

Par conséquent, le choix d’un sur-ensemble (cas 1) ou de plusieurs sous-ensembles (cas 2 et 3) implique que l’on facilitera soit l’expressivité, soit les capacités de déduction de l’agent rationnel. En effet, l’arbre des types n’est pas seulement utile pour la représentation des requêtes, mais peut aussi être utilisé pour raisonner sur le monde.

En pratique, plutôt que d’opter de manière arbitraire pour l’une ou l’autre des solutions, nous nous laissons donc guider par l’utilisation que l’agent rationnel ARest amené à faire de ces informations (cf. chapitre8). En effet, ce n’est pas tant la représentation interne que l’agent se fait de la requête que la manière dont il réagira à celle-ci qui compte. En règle générale, nous

avons choisi d’utiliser des propriétés individuelles, sauf quand il apparaît que ces propriétés sont réellement mutuellement exclusives. C’est par exemple le cas de la propriété type : si un élément est un bouton, il ne peut pas être aussi une fenêtre. Cela permet de fournir un peu de “sens commun” à l’agent, puisqu’il n’est alors pas nécessaire d’encoder explicitement dans l’agent rationnel des règles du type “un bouton n’est pas une fenêtre”. Néanmoins, il est clair que chacun de ces choix amène à une restriction de la vision du monde que l’agent peut avoir.

5.4.2 Actions génériques ou spécifiques ?

Dans le même esprit que ce qui a été vu pour les propriétés dans la section5.4.1, on peut se demander si pour atteindre une certaine généricité du langage, il n’est pas préférable de restreindre au maximum le nombre de schèmes disponibles pour les actions sur le monde, en optant plutôt pour des actions génériques dotées de nombreux attributs. Le tableau 5.8

montre le type de représentation possible pour quelques verbes d’actions. En optant pour la

Verbe d’action Représentation spécifique Représentation générique

Cacher Hide[...] Modify[ppt*={visibility[val=False]}]

Donner Give[...] Modify[ppt*={owner[]}]

Aller Go[...] Modify[ppt*={location[]}]

Complexifier Complexify[...] Modify[ppt*={difficult[val=+]}]

Tableau 5.8 Représentations générique et spécifique de quelques verbes d’action

représentation générique, on peut diminuer de manière très conséquente le nombre deentités

de classe Action nécessaire dans le langage (4 contre 1 dans le cas des verbes du tableau 5.8) et définir une sémantique très générique. Toutefois, on perd alors la structure fonctionnelle spécifique à chaque verbe. C’est-à-dire que dans les exemples considérés ici, l’entité Modify

devrait disposer d’un certain nombre d’attributs vagues qui n’auraient pas le même sens en fonction des propriétés liées àModify. Ainsi, dans les requêtes de contrôle “cache la fenêtre”, “donne la valeur” et “va à la page d’accueil”, “fenêtre”, “valeur” et “page d’accueil” jouant le même rôle d’objet sur lequel s’applique l’action seraient à rattacher à un même attribut de

Modify. De plus, on ne pourrait pas préciser le type de cet attribut qui devrait alors

corres-pondre soit à unobject (“fenêtre”), soit à unconcept (“valeur”) ou encore à un emplacement location (“la page d’accueil”) : on perd donc une partie de l’intérêt du typage des attributs comme aide à la construction d’une requête.

Une solution alternative pourrait être de faire une construction de la requête en deux étapes, en passant d’abord par la représentation spécifique pour permettre l’utilisation des types, puis une conversion de la représentation spécifique vers la représentation générique équivalente. Toutefois, c’est encore une fois le contexte dans lequel s’inscrit l’utilisation de ce langage qui permet de choisir : nous ne nous intéressons en effet pas tant à la représentation sémantique formelle pour elle-même qu’à la manière dont elle sera utilisée par l’agent rationnel par la suite. La question à se poser est donc de savoir si une représentation plus générique permet

ou non de faciliter la synthèse de réactions associées au sein des heuristiques de l’agent. Or si l’on veut réagir à “donner” et “cacher” différemment, il importe peu de savoir si la réaction est associée à une requête écrite de manière spécifique ou générique : c’est donc un faux problème. Afin de faciliter la lisibilité des actions qui nous intéressent, nous avons donc préféré de ma-nière générale une représentation spécifique, ce qui donne un langage plutôt riche en actions mais plus clair à comprendre.

5.4.3 Gestion de la position spatiale des références

Pour rappel, nous avons choisi de considérer toutes les propriétés comme étant d’impor-tance égale par rapport à une référence. À ce titre, la position spatiale doit être agrégée dans les valeurs de l’attribut à valeurs multiplesproperty*. Toutefois, les expressions spatiales pré-sentent certaines spécificités nous obligeant à les traiter de manière particulière. On peut ainsi distinguer deux types d’expressions de position :

− les positions absolues : ici, en haut, à droite, etc.

− les positions relatives : à droite de X, dans la page, sur le disque, en dessous de Y, etc. Si les positions absolues peuvent être représentées de la même manière que n’importe quelles autres propriétés, il n’en va pas de même des positions relatives : en effet, créer des entités

différentes pour “en-dessous du bouton”, “à droite du bouton” ou “sous le bouton” reviendrait à nier le fait qu’il s’agit d’une référence à un même bouton. De plus, on devrait alors avoir une liste d’emplacements extrêmement importante. Nous préférons donc définir les positions relatives comme étant la combinaison d’éléments de position (“dans”, “sur”, “en-dessous de”) avec d’autres références. À cet effet, nous avons donc défini une modalité particulière,PLACE, dont le type associé estlocation-relative, et ayant un attribut prenant pour valeur l’élément de référence par rapport auquel on se situe (voir l’exemple de la figure5.2– en anticipant sur le mode de représentation des requêtes DAFT 2.0 construites par l’outil DIG, décrit en6.1.2).

object

@PptD property* =

type

@selD val = button

quantity @selD val = 1 PLACE @objectD of = object @PptD property* = type

@selD val = webpage

quantity

@selD val = 1

location-relative-inclusion

@selD val = True

5.5 Conclusion

Nous avons introduit dans ce chapitre la syntaxe et la sémantique du langage DAFT 2.0 , défini à partir du corpus Daft. Ce langage repose sur un ensemble S de 237 schèmes qui peuvent se voir associer des valeurs et être combinés entre eux de manière à modéliser les requêtes en langue naturelle pré-analysées par GRASP. Ayant montré que ce langage était suffisant pour couvrir la majorité des requêtes d’assistance issues du corpus, il reste maintenant à automatiser leur production, ce qui fait l’objet du chapitre qui suit.

Génération automatique de