Structure de la base

Comme les SRI traditionnels, XFIRM propose la construction de struc- tures d’index pr´e-calcul´ees qui sont utilis´ees pour l’´evaluation des diff´erentes conditions de recherche ´enonc´ees dans les requˆetes. Ces index sont bas´es sur la mod´elisation des noeuds que nous avons pr´esent´ee ci-dessus.

Les index sont stock´es sous forme de tables dans une base de donn´ees relation- nelle MySQL. Afin d’obtenir les diff´erents index, les documents `a indexer sont parcourus `a l’aide d’un parseur de type SAX On trouvera un sch´ema g´en´erique de la base sur la figure3.10.

IC id_chemin id_doc pre post parent attribut id_balise IT id_terme id_chemin frequence_totale nb_doc nb_element frequences IE id_chemin nb_termes nb_total_termes IA id_chemin id_attribut valeur DICT id_balise liste_id_balise Documents id_doc document nb_termes Balises id_balise balise Attributs id_attribut attribut IC : Index des Chemins

IA : Index des Attributs IT : Index des Termes IE : Index des Elements

DICT : Index Dictionnaire

Fig. _{3.10 – Sch´ema de la base de donn´ees contenant les index}

Trois tables g´en´eriques, utilis´ees par les index principaux, sont pr´esentes dans la base de donn´ees : la table Documents, la table Balises et la table

Attributs. Le sch´ema de ces tables est d´etaill´e dans le tableau 3.2. Table Description

Documents Documents(doc id, document, date, nb termes)

doc id est l’identifiant unique de chaque document, docu- ment est le nom de fichier du document, date est la date d’insertion dans l’index du document, et nb termes est le nombre total de termes du document

Balises Balises(balise id, balise)

balise id est l’identifiant unique de chaque nom de balise et balise est le nom de la balise

Attributs Attributs(att id, attribut)

att id est l’identifiant unique de chaque nom d’attribut et attribut est le nom de l’attribut

Tab. _{3.2 – Tables g´en´eriques du mod`ele physique de XFIRM}

Les index principaux, au nombre de cinq, sont les suivants :

– L’index des chemins(IC) permet de reconstituer la structure des docu- ments ;

– L’index des termes (IT) donne pour chaque terme de la collection les ´el´ements associ´es et permettra de calculer diverses mesures de pertinence en fonction du mod`ele de recherche choisi : il correspond en fait `a un fichier inverse traditionnel ;

– L’index des ´el´ements (IE) d´ecrit le contenu de chaque noeud feuille, et permettra de faire des ´evaluations de pertinence sur des noeuds pr´ecis ; – L’index des attributs (IA) donne pour chaque attribut ses diff´erentes va-

leurs ;

– et enfin le dictionnaire (DICT) permet de regrouper les balises de la col- lection ayant la mˆeme s´emantique. En effet, la qualit´e des recherches sur des donn´ees semi-structur´ees peut ˆetre am´elior´ee en utilisant la s´emantique du nom des ´el´ements [201]. L’utilisation du dictionnaire permet d’´etendre les requˆetes des utilisateurs et d’´etablir des liens entre des documents suivants des DTDs diff´erentes. Par exemple, les balises titre et sous-titre peuvent ˆetre consid´er´ees comme ´equivalentes.

On trouvera enfin dans le tableau3.3 la description d´etaill´ee de ces index prin- cipaux.

Notons de plus que les termes contenus dans l’IT sont lemmatis´es. La lem- matisation peut ˆetre effectu´ee avec l’algorithme de Porter [160] pour les docu- ments de langue anglaise ou bien en effectuant des troncatures pour les autres langues. Une liste de mots vides est utilis´ee pour supprimer les termes qui n’ap- portent pas de sens au contenu des ´el´ements, comme par exemple les pronoms ou les d´eterminants.

Index Description

IC Chemins (chemin id, doc id, pre, post, parent, attribut, ba- lise id)

chemin id est l’identifiant unique de chaque chemin, doc id est l’identifiant du document concern´e, pre et post sont les va- leurs de pr´ed´ecesseurs et successeurs, parent est la valeur de pr´ed´ecesseur du parent de l’´el´ement, attribut est un bool´een indiquant la pr´esence d’attribut pour l’´el´ement concern´e, et ba- lise id est l’identifiant de la balise de l’´el´ement concern´e. Si le champ balise id est nul pour un certain chemin id, l’´el´ement est alors un ´el´ement feuille de type #PCDATA et on trouvera son contenu dans l’index des ´el´ements.

IT TermesElements (terme id, terme, total fr´equence, nb doc, nb elt, fr´equences)

terme id est l’identifiant unique de chaque terme, terme est le terme lui mˆeme, total fr´equence est la fr´equence totale du terme dans la collection, nb doc est le nombre total de documents dans lesquels le terme apparaˆıt, nb elt est le nombre total d’´el´ements (c’est `a dire de chemins) dans lesquels le terme apparaˆıt et fr´equences est un champ de type BLOB (Binary Long Object) contenant pour chaque ´el´ement o`u le terme apparaˆıt (´el´ement repr´esent´e par chemin id ) le nombre d’occurrences du terme, ainsi que les positions auxquelles il apparaˆıt. Par exemple, la chaˆıne ” 2 1 2/ 21 2 4 8 ” indique que le terme t est pr´esent 1 fois dans l’´el´ement 2 `a la position 2 et 2 fois dans l’´el´ements 21 aux positions 4 et 8.

IE ElementsTermes (chemin id, nb termes, nb total termes) chemin id est l’identifiant de chaque chemin, nb termes est le nombre de termes uniques inclus dans l’´el´ement concern´e, nb total termes est le nombre de termes inclus dans l’´el´ement concern´e

IA ValeursAttributs (chemin id, attribut id, valeur)

chemin id est le noeud auquel se rattache l’attribut, attribut id est l’identifiant de l’attribut (en r´ef´erence `a la Table Attributs) et valeur est une chaˆıne de caract`ere contenant la valeur de l’attribut.

DICT Dictionnaire (balise id, ListeBalise id)

balise id est un identifiant de balise et ListeBalise id est une liste d’identifiants de balise ayant une s´emantique proche de balise id.

Les structures de stockage que nous venons de pr´esenter contiennent toutes les informations n´ecessaires pour appliquer diff´erents mod`eles de RI, tant sur des requˆetes portant seulement sur le contenu des documents que des requˆetes plus pr´ecises portant aussi sur leur structure. Les diff´erents index ´etant stock´es dans une base de donn´ees, toutes les fonctions usuelles des bases de donn´ees (comme les jointures, les projections ou le tri) ne sont pas `a r´eimpl´ementer. De plus, la mise `a jour des index dans le cas de suppression ou d’insertion de documents est relativement simple.

3.9

Conclusion

Dans ce chapitre, nous avons pr´esent´e XFIRM, un mod`ele flexible pour la recherche d’information dans des documents structur´es. Le but de notre mod`ele est de renvoyer `a l’utilisateur les unit´es d’information (c’est `a dire les noeuds des documents XML) les plus sp´ecifiques et exhaustives r´epondant `a son besoin en information.

Ce mod`ele repose sur un mod`ele de repr´esentation g´en´erique des donn´ees, per- mettant de stocker l’arborescence des documents XML tout en gardant les fonctionnalit´es orient´ees RI traditionnelles. Le mod`ele de repr´esentation per- met en outre l’impl´ementation de nombreux mod`eles de recherche ainsi que le traitement de collections h´et´erog`enes (c’est `a dire ne suivant pas la mˆeme DTD). Nous avons propos´e un langage de requˆete associ´e, qui autorise l’utili- sateur `a exprimer son besoin selon divers degr´es de pr´ecision. Si l’utilisateur a un besoin peu d´efini ou qu’il ne connaˆıt pas du tout la structure des documents qu’il interroge, il pourra exprimer son besoin `a travers de simples mots-cl´es, et il laissera le syst`eme d´ecider de la granularit´e appropri´ee de l’information `a renvoyer. Si au contraire l’utilisateur a un besoin pr´ecis, il pourra introduire des conditions de structure dans sa requˆete, ´eventuellement reli´ees de mani`ere `a exprimer une hi´erarchie.

Le mod`ele de recherche que nous proposons repose sur une m´ethode de propa- gation des pertinences dans l’arbre du document. Le traitement des requˆetes diff`ere selon leur type :

– pour les requˆetes orient´ees contenu, nous nous sommes attach´es `a mod´eliser la notion d’informativit´e d’un noeud. Cette informativit´e d´epend non seulement de la pertinence des descendants du noeud (et plus parti- culi`erement des plus petits d’entre eux) mais aussi de la pertinence de son contexte, puisque les noeuds sont organis´es en document, et que les documents suivent une certaine unit´e de pens´ee, mˆeme s’ils poss`edent un contenu h´et´erog`ene.

– pour les requˆetes orient´ees contenu et structure, nous avons propos´e plu- sieurs fonctions de propagation, qui nous permettent d’effectuer une com-

paraison entre l’arbre de la requˆete et l’arbre des documents. Ces fonc- tions de propagation, selon la tˆache utilisateur `a laquelle on cherche `a r´epondre, permettent d’ajuster la fa¸con (stricte ou vague) dont sont trait´ees les conditions de structure. Lorsqu’une correspondance vague entre l’arbre de la requˆete et l’arbre du document est effectu´ee, des do- cuments poss´edant une structure diff´erente de celle la requˆete peuvent ˆetre renvoy´es `a l’utilisateur, mˆeme si leur pertinence est plus faible que celle des documents pour lesquels toutes les conditions de structure sont respect´ees. Par exemple, un document poss´edant la structure /a/b/c sera pertinent pour une requˆete /a/d/c, mais aussi pour une requˆete /a/c/b. Lorsque l’utilisateur ne sp´ecifie pas le type de l’´el´ement qu’il d´esire voir renvoyer (pas d’´el´ement cible), nous cherchons les noeuds les plus proches ancˆetres communs des noeuds qui r´epondent aux conditions de structure (requˆete de type P2) ou bien les noeuds r´epondant `a la premi`ere condition de structure des requˆetes de type P3 (noeuds situ´es le plus haut dans la hi´erarchie des documents).

Notre mod`ele apporte ainsi de la flexibilit´e dans la recherche `a plusieurs ni- veaux : la structure d’index est g´en´erique et permet de traiter des collections de documents h´et´erog`enes, le langage permet `a l’utilisateur d’exprimer son besoin selon plusieurs degr´es de pr´ecision, et les ´eventuelles conditions de structure des requˆetes peuvent ˆetre trait´ees de mani`ere vague. Les r´esultats obtenus par nos propositions sont pr´esent´es dans le chapitre suivant. Ils montrent les bonnes performances de notre approche par rapport aux approches propos´ees dans la litt´erature.

Exp´erimentations et r´esultats

4.1

Introduction

Dans ce chapitre, nous pr´esentons les exp´erimentations effectu´ees pour ´eva- luer l’apport des diff´erentes propositions faites au chapitre 3. Les ´evaluations portent sur le mod`ele de recherche propos´e pour les requˆetes orient´ees contenu (de type P1) et les requˆetes orient´ees contenu et structure (de type P2 `a P4). Nous avons `a cet effet organis´e nos exp´erimentations en deux grandes parties. La premi`ere partie concerne les ´evaluations effectu´ees sur les requˆetes orient´ees contenu. Nous avons ´evalu´e les points suivants dans notre mod`ele de propaga- tion de la pertinence :

– impact de la formule de pond´eration des termes utilis´ee pour le calcul du score de pertinence des noeuds feuilles (´equation 3.4) ;

– impact du param`etre distance dans la fonction de propagation (´equation

3.7) ;

– impact de la longueur des noeuds dans le calcul de la dimension d’infor- mativit´e ;

– impact du contexte des ´el´ements dans le calcul de la dimension d’infor- mativit´e.

Suite `a ces exp´erimentations, nous commentons les jugements de pertinence utilis´es dans le cadre de la campagne d’´evaluation INEX ainsi que le principal probl`eme auquel nos r´esultats sont soumis, `a savoir le probl`eme de l’imbrication des noeuds.

La seconde partie de nos ´evaluations concerne les requˆetes orient´ees contenu et structure. Pour ces requˆetes, les points suivants ont ´et´e ´evalu´es :

– impact de la formule de pond´eration des termes utilis´ee pour le calcul du score de pertinence des noeuds feuilles ;

– impact du param`etre distance dans les fonctions de propagation ; – comparaison de la gestion stricte ou vague des conditions de structure.

Nous nous proposons ensuite d’´evaluer l’impact de l’unit´e d’indexation mini- male choisie sur notre mod`ele ainsi que la faisabilit´e de notre approche sur une collection de donn´ees h´et´erog`enes (c’est `a dire ne suivant pas la mˆeme DTD).

Dans ce chapitre, nous commen¸cons par d´ecrire de mani`ere plus d´etaill´ee la collection de test utilis´ee pour nos exp´erimentations, `a savoir la collection INEX, ainsi que les jeux de requˆetes associ´es aux campagnes d’´evaluations 2003 et 2004 (section 4.2). La section 4.3 pr´esente nos conditions exp´erimentales, et les sections 4.4 et4.5 d´ecrivent nos exp´erimentations, respectivement pour les requˆetes orient´ees contenu (de type P1) et les requˆetes orient´ees contenu et structure (de type P2 `a P4), et ce selon les canevas d’exp´erimentations d´ecrits ci-dessus. Nous ´etudions dans la section 4.6 l’impact de l’unit´e d’indexation minimale choisie. La section 4.7 compare nos r´esultats avec les r´esultats des diff´erents participants `a INEX. Enfin, nous pr´esentons dans la section 4.8 les exp´erimentations que nous avons men´ees pour la tˆache h´et´erog`ene de la cam- pagne d’´evaluation INEX 2004.