6.5 Construire des requˆetes avec le langage XOR
6.5.2 Autres traitements
Le pr´edicat habituel about est le pr´edicat de base de la recherche d’information. Il laisse en fait le champ libre au moteur de recherche pour effectuer toutes sortes de traitement sur les termes. Une instruction plus stricte, demandant une simple recherche exacte de chaˆınes de caract`eres, peut ˆetre utile dans certains cas. Nous nommons cette relation contains. Nous l’avons d´ej`a utilis´ee `a la section 5.3.4.11; elle peut s’appliquer par exemple lorsque l’utilisateur a plac´e des termes entre guillemets2 :
(6.8) We are looking for articles whose abstracts contain “spatial join”.3
Le nouvelle r`egle qui s’applique dans ce cas est celle de la figure6.5, et la requˆete en XOR remplace la clause about par contains :
//article[contains(.//abs, "spatial join")] 6.5.2.2 Les liens entre documents
Nous avons montr´e plus haut4 comment il ´etait possible d’obtenir des relations
de type linkToAbout avec les r`egles s´emantiques. Il suffit d’utiliser ce mˆeme pr´edicat,
1Page139.
2Voir le traitement r´eserv´e aux termes entre guillemets `a la section5.2.3.1, page120. 3Extrait du topic 156, INEX 2004.
Construire des requˆetes avec le langage XOR 169 valeurs
⇒
valeurs E:(lem:contain, cat:v) A B:(type:quot) B relations relations sujet(E, A) objet(E, B) contains(A, B) cible cible – –Fig. 6.5 – Introduction du pr´edicat contains.
d´esormais admis par le moteur de recherche, dans la requˆete XOR. Ainsi, la requˆete de l’exemple 6.1permet d’aboutir `a la forme suivante :
//bb[linkToAbout(., "text categorisation")
AND linkToAbout(., Support Vector Machines SVM categoriser)] Notons que le moteur de recherche effectue ´egalement une recherche classique (de type about) en plus de la recherche des liens.
6.5.2.3 La taille des ´el´ements
Nos id´ees concernant la limitation de la taille des ´el´ements retourn´es, exprim´ees `
a la section 6.3, peuvent d´esormais ˆetre appliqu´ees grˆace `a la distinction possible des ´el´ements feuilles. Nous utilisons donc l’attribut ’type:leaf’, qui demande le renvoi des ´el´ements “les plus petits possibles” (les feuilles), lorsque les requˆetes sont de la forme “who”, “whose”, “which”, “where”, “when”, ainsi que les d´eriv´es de “how” : “how much”, “how many”, “how old”, “how long”, “how far”, etc.1
Exemple :
(6.9) Who is candidate to be president in 2007 ?
//*{type:leaf}[about(., candidate president 2007)] 6.5.2.4 Les ambigu¨ıt´es du mod`ele
Nous avons d´ecrit `a la section 5.3.52 le probl`eme potentiel des ambigu¨ıt´es provo- qu´ees par les r`egles s´emantiques de l’interface. La requˆete multiple nous offre un moyen imparfait mais simple de traiter ces ambigu¨ıt´es. En effet, si deux r`egles s’appliquent `a un ´enonc´e pr´ecis, provoquant la cr´eation de deux ´el´ements diff´erents, il est possible de g´en´erer deux constructions diff´erentes, chacune ´etant le r´esultat de l’application d’une r`egle. Nous ne r´esolvons pas l’ambigu¨ıt´e, mais proposons les deux possibilit´es.
1Ces requˆetes sont souvent des questions, mais les pronoms peuvent ˆetre ins´er´es dans le texte avec
la mˆeme signification (“I want to know how much. . .”).
6.6
Conclusion
Ce chapitre est une ´etude concernant l’utilisation de notre interface en langage naturel dans le but d’affiner les requˆetes g´en´er´ees et d’am´eliorer la recherche dans la structure des documents.
La premi`ere proposition est la mise en œuvre d’une recherche contextuelle qui, en utilisant des indicateurs linguistiques simples, permet de prendre en compte l’imbrica- tion des ´el´ements et la variabilit´e de l’unit´e d’information dans les documents XML. Nous avons vu qu’il ´etait possible de r´ealiser cette recherche contextuelle en utilisant NEXI, mais de fa¸con tr`es imparfaite.
Par ailleurs, deux autres caract´eristiques de la recherche semi-structur´ee ont ´et´e ´etudi´es : les liens entre les documents d’une part, et la taille de l’unit´e d’information recherch´ee d’autre part. Dans ces cas-l`a, les limites de NEXI semblent insurmontables. Au vu de ces difficult´es, ainsi que d’autres, exprim´ees par les chercheurs du domaine, nous avons cr´e´e le langage XOR, extension g´en´erique de NEXI, rendant possible la sp´ecification de nouvelles fonctionnalit´es.
Si la recherche contextuelle a pu ˆetre test´ee de fa¸con efficace, l’´etude des liens entre documents souffre d’un manque de requˆetes ´evalu´ees disponibles et pour lesquelles l’utilisation du pr´edicat linkToAbout pourrait apporter une plus-value. En effet, les ´evaluations d’INEX ´etant men´ees avec NEXI, les requˆetes que ce langage ne pouvait pas exprimer ´etaient, de facto, ´evit´ees. L’encyclop´edie Wikipedia, collection unique pour INEX 2006 et comportant beaucoup de liens, devrait permettre des exp´erimentations plus d´etaill´ees.
Enfin, les id´ees concernant la restriction de la taille des ´el´ements retourn´es d´epassent un peu le cadre de la RI au sens strict du terme, et sont orient´ees vers des requˆetes plus pr´ecises, de type question/r´eponse (domaine dans lequel ces techniques sont d’ailleurs tr`es utilis´ees, sans les probl`emes d’´el´ements structurels). Nous n’avons donc pas ´et´e en en mesure de les tester avec des collections existantes.
Le chapitre suivant d´etaille l’ensemble des ´evaluations qui ont pu ˆetre men´ees au sujet de l’interface en langage naturel.
Chapitre 7
Exp´erimentations et r´esultats
Et il se fˆut frott´e les mains, s’il eˆut ´et´e dans sa nature de faire un mouvement inutile. Jules Verne, Le tour du monde en 80 jours.
Nous abordons dans ce chapitre l’´evaluation des performances de notre syst`eme d’analyse des requˆetes en langage naturel pour l’interfa¸cage sur un moteur de recherche d’information dans des documents semi-structur´es.
Nos recherches comportent deux buts principaux. Le premier est de montrer qu’il est possible d’utiliser la formulation en langage naturel d’un besoin d’information pour effectuer une recherche dans des documents XML, et ce avec une efficacit´e comparable `
a celle obtenue avec une expression formelle de type NEXI. Le second but est d’utiliser la structure des documents pour am´eliorer encore les requˆetes produites, et donc la recherche d’information.
Dans le premier cas, l’´evaluation porte sur notre g´en´eration de requˆetes en langage NEXI, reconnu par de nombreux moteurs de recherche, ceci permettant l’utilisation de notre interface par n’importe quel syst`eme ; dans le second, nous utilisons notre langage XOR, impl´ement´e uniquement par le syst`eme GPX, mais comportant de nombreuses fonctionnalit´es suppl´ementaires.
Ces deux pistes ´etant nettement distinctes, nous pr´esentons s´epar´ement les r´esultats obtenus dans chacun des cas.
Ce chapitre rappelle bri`evement les conditions d’exp´erimentations propos´ees par la campagne d’´evaluation INEX 2005 (section 7.1) ; il d´etaille ensuite l’´evaluation de notre interface de traduction simple vers NEXI (section 7.2.1), puis d´ecrit l’ajout des techniques de recherche contextuelle avec NEXI (section 7.2.2) et les r´esultats officiels obtenus `a INEX 2005 (section 7.2.3). Enfin, il aborde les performances concernant le langage XOR (section7.3), avant de donner quelques exemples repr´esentatifs d’analyses compl`etes (section 7.4).