Impact de la structure du document
6.1 Problematique generale
Notre problematique generale concerne l'indexation des documents structures, et donc la representation des informations decrivant ce type de documents.
d'une technique d'indexation qui puisse accueillir les caracteristiques des documents structures a n d'utiliser la liaison entre la structure et les informations exprimees par le document: contenu semantique et/ou attributs externes. Nous donnons tout d'abord un exemple qui nous permet de presenter certaines lacunes des systemes traditionnels et la problematique generale a laquelle nous sommes confrontes. Par la suite, nous presentons la notion d'attribut que nous adoptons dans notre modele de representation du document structure. Il s'agit d'une vision elargie et enrichie de l'attribut par rapport a l'approche traditionnellement rencontree dans les normes de representation des documents structures ou dans les SGBD.
6.1.1 Exemple Introductif: un document SGML
A travers cet exemple, nous montrons l'inter^et des attributs dans les documents structures mais aussi leur limite actuelle due principalement a la non prise en compte des caracteristiques structurelles lors de la de nition de ces attributs.
Nous allons considerer un type de document structure decrit par une DTD SGML donne partiellement dans la gure 6.1. Nous presentons cet exemple avec la syntaxe SGML car elle presente l'avantage d'^etre facilement comprehensible pour decrire les types d'elements structurels et les informations descriptives donnees sous la forme d'attributs au niveau de chacun de ces types.
Il s'agit ici de documents de type livre comportant un titre (type titreLivre) et un ou plusieurs chapitres (typeChapitre) qui sont eux-m^emes composes d'un titre (typetitreChapitre) et d'une ou plusieurs sections (type Section).
1.<! DOCTYPE Livre [
2.<! ELEMENT Livre - - (titreLivre,Chapitre+)>
3.<! ELEMENT titreLivre - - (#PCDATA)>
4.<! ELEMENT Chapitre - - (titreChapitre,Section+)>
5.<! ATTLIST Chapitre
auteur NMTOKEN #REQUIRED date NMTOKEN #REQUIRED
status ( naljbrouillon) brouillon #REQUIRED
numCh NMTOKEN #REQUIRED
6.<! ELEMENT titreChapitre - - (#PCDATA)>
7.<! ELEMENT Section - - (titreSection,Paragraphe+)>
::: ]>
Figure 6.1.
DTD d'un document de typelivreDans la gure 6.1 (ligne 5) le type structurelchapitrepossede quatre attributs:auteur,date,
status et numCh. Ces attributs permettent de caracteriser les elements de structure de type
chapitre. Pour chaque chapitre d'un document qui se conforme a ce DTD, nous conna^trons le ou les auteurs, la date de creation, l'etat du chapitre et le numero du chapitre dans le document complet.
6.1.2 Application de notre modele a l'exemple
Nous transposons une partie de la DTD de la gure 6.1 dans le modele de representation que nous avons de ni. Nous donnons ici quelques-uns des elements du modele de document, a savoir l'ensemble des types structurels, les relations entre ces types, l'ensemble des noms d'attributs ainsi que les attributs associes a chacun de ces types conformement a la DTD.
L'ensemble des types structurels est de ni par les elements de l'ensemble
TY PE
ST:TY PE
ST =fLivre;titreLivre;Chapitre;titreChapitre;Section;
titreSection;Paragraphe;:::
gLa relation de composition, noteetcomp, sur les types d'elements structurels de l'ensemble
TY PE
ST determine quels types d'elements structurels peuvent se composer (t
1 tcompt
2signi e qu'un element de type
t
2 peut ^etre un composant d'un element de typet
1):LivretcomptitreLivre LivretcompChapitre ChapitretcomptitreChapitre ChapitretcompSection SectiontcomptitreSection SectiontcompParagraphe
La relation de sequence, notee tseq, sur les types d'elements structurels
TY PE
ST de-termine quels types d'elements structurels peuvent se succeder dans la sequence (t
1 tseqt
2signi e qu'un element de type
t
2 peut ^etre le successeur sequentiel d'un element de typet
1):titreLivretseq Chapitre Chapitretseq Chapitre titreChapitretseq Section SectiontseqSection
titreSectiontseqParagraphe Paragraphetseq Paragraphe
Les attributs dont les noms sont regroupes dans l'ensemble
NAME
:NAME=fauteur;date;status;numChg
Parmi les noms de l'ensemble
NAME
nous decrivons par la relation RST les attributs structurels, c'est-a-dire les attributs attaches a un type d'element structurel. Comme l'in-dique la DTD de la gure 6.1, les quatre attributs de l'ensembleNAME
sont des attributs structurels rattaches aux elements de type Chapitre.RST(Chapitre;auteur) RST(Chapitre;date)
RST(Chapitre;status) RST(Chapitre;numCh)
On remarque que nous ne retrouvons pas dans notre modele l'ensemble des contraintes de nies dans la DTD. Par exemple, la notion d'alternative entre deux types structurels (notee
jdans SGML) qui est presente dans une DTD n'est pas representee dans notre modele car elle ne presente pas dans notre optique de travail une information immediatement pertinente. Nous avons de ni un modele capable de representer l'instance du document et non sa speci cation.
Notre modele permet donc de speci er moins d'information qu'une DTD SGML puisque son r^ole n'est pas la description de documents structures mais un usage particulier des docu-ments structures: leur recherche.
6.1.3 Exemples de recherche
Dans les systemes s'interessant a la recherche de documents representes a l'aide de SGML [BCK+94, Pep95, FFE96, Chr96, ACC+97], la notion d'attribut est utilisee telle qu'elle est de nie au niveau de la DTD. Il n'est donc pas possible de retrouver directement des elements de type Section a partir de leur auteur puisque l'attribut auteur porte uniquement sur les elements de type chapitre. Dans la de nition de type de document, il n'existe pas de speci -cation particuliere permettant de dire si l'information representee par l'attribut auteur peut caracteriser ou non les elements structurels qui sont lies par des relations de structure aux elements structurels de typechapitre.
Prenons l'exemple d'une requ^ete dans laquelle l'utilisateur speci e qu'il cherche un para-graphe ecrit par un auteur particulier. Dans les systemes adoptant une approche traditionnelle des attributs, que ce soit des systemes de recherche documentaire [Tha90] ou des systemes de gestion de base de donnees [Chr96, ACC+97], la recherche va s'e ectuer uniquement sur les elements de typeparagraphe. Or d'apres la de nition du type de document, ce type d'element n'admet pas cet attribut. Soit le systeme ne repond pas a la requ^ete, c'est a dire qu'il retourne un ensemble vide de reponses, soit il decide d'etendre la requ^ete selon des regles etendant la requ^ete en tenant compte des compositions structurelles (premier ascendant structurel d'une section admettant l'attribut requis). Dans le premier cas (ensemble vide), la reponse fournie ne peut pas satisfaire l'utilisateur: il peut exister des paragraphes qui composent un chapitre qui a ete ecrit par l'auteur requis. Le silence vient ici d'une non exploitation des relations de structure et d'une trop faible couverture des elements du document par l'attribut auteur qui est uniquement de ni sur les chapitres. Dans le second cas, c'est le processus de traitement de la requ^ete qui prend en charge la derivation et l'elargissement de la requ^ete selon des regles pre-de nies. La fonction de mise en correspondance execute des traitements a cause d'une defaillance de l'indexation.
Etudions maintenant un second exemple montrant l'ambigute des attributs dans le docu-ment structure pour les systemes de recherche docudocu-mentaire. Considerons qu'un utilisateur souhaite retrouver l'ensemble des livres qui sont a l'etat de brouillon. Nous voyons dans la de nition du type de structure des livres que seuls les elements de typechapitreadmettent un attributstatusindiquant son etat. A n de traiter cette requ^ete, plusieurs types de strategies peuvent se presenter pour repondre:
{ Un livre est a l'etat de brouillon si et seulement si au moins un chapitre est a l'etat de brouillon.
{ Un livre est a l'etat de brouillon si et seulement si tout les chapitres sont a l'etat de brouillon.
{ Un livre est a l'etat de brouillon si et seulement si un certain pourcentage de ses chapitres sont a l'etat de brouillon.
Ce m^eme type d'interrogation peut survenir lorsqu'un utilisateur recherche un element de type section ou paragrapheen fonction de son etat, brouillon ou nal.
Il est dicile d'exprimer jusqu'a quel point un element structurel tel que le livre est concerne par la valeur des attributs de ses composants, en d'autres termes quelle est la portee des attributs lorsque celle-ci n'est pas explicitee. Cet exemple tres simple montre que les choix sont nombreux et que la decision depend pleinement du type de structure et de l'information contenue dans l'attribut. Le processus de recherche est donc totalement dependant de ces decisions puisque c'est lui qui les traite.
Par ailleurs dans cet exemple se pose le probleme de la combinaison des informations pro-venant de di erentes sources: un livre comporte plusieurs chapitres et chaque chapitre admet un attribut indiquant son etat. A n de determiner dans quel etat nous devons considerer, les composants et/ou les composes de chacun de ces chapitres, il faut que nous combinions les valeurs provenant des di erentes sources pour exprimer leur etat, c'est-a-dire pour donner une valeur a cet attribut.
Nous avons montre a travers cet exemple certains problemes recurrents a la recherche des documents structures. La majeure partie de ces dicultes reside dans la non atomicite du document structure qui disperse l'information et la rend donc plus dicilement accessible.
Nous allons maintenant envisager une solution pour faire face a ces problemes en nous interessant particulierement au processus de traitement du document qui est prealable au processus de recherche, a savoir le processus d'indexation. Pour cela, nous revenons sur les etats du document au cours de ce processus.