Explorer le « Web caché »

Le World Wide Web est une vaste source d’informations à laquelle on accède principalement à l’aide de moteurs de recherche par mots-clefs, tels Google, Yahoo !, MSN ou Exalead. Ces moteurs de recherche indexent les pages de ce que l’on appelle le « Web de surface », c’est-à-dire l’ensemble des pages Web qui sont directement accessibles par des hyperliens. Ils laissent ainsi de côté l’énorme quantité d’informations, fortement structurées, qui sont cachées derrière des formulaires, formant le « Web caché » (on parle aussi de « Web profond » ou de « Web invisible »).

Une étude [1] a pourtant estimé que ce Web caché contenait 500 fois plus d’informations que le Web de surface. Si ce chiffre est à prendre avec précautions, il est certain qu’avec des sources de données comme les services d’annuaire (p. ex., les Pages jaunes), les services d’informations météorologiques ou géographiques, les catalogues de bibliothèque, les bases de données de publications scientifiques etc., le Web caché est une ressource précieuse qu’il serait utile de pouvoir indexer et interroger de manière uniforme. Le but est ainsi de permettre à un utilisateur de poser des questions telles que « Quels sont les co-auteurs de M. Untel ? » et de recevoir des réponses provenant de diverses sources du Web caché, sans avoir à les interroger une à une.

L’approche décrite ici est une approche entièrement automatique, ne nécessitant aucune supervision humaine, ce qui complique évidemment le problème. Afin de surmonter cette difficulté, l’approche va se baser sur une connaissance du domaine préalable, c’est-à-dire une description sous une forme prédéfinie des concepts d’un domaine d’intérêt particulier et d’exemples de ces concepts. Par exemple, dans le domaine des bases de données de publications scientifiques, les concepts pertinents seront Titre, Auteur, Journal, Date etc., tandis que les exemples de ces concepts pourront provenir d’une base de données préliminaire (nécessairement incomplète) telle que DBLP [2]. Cela n’enlève rien à la généralité de l’approche, puisque l’application à un autre domaine d’intérêt requiert simplement de fournir une connaissance du domaine différente.

Considérons maintenant un formulaire Web qui permet d’accéder à un service du Web caché pertinent au domaine d’intérêt. Comprendre la manière de l’interroger afin de pouvoir l’utiliser automatiquement comporte plusieurs parties : il faut tout d’abord comprendre la structure du formulaire lui-même (ses entrées), puis celle de la page Web résultant de la soumission de ce formulaire (ses sorties), et enfin comprendre les relations qui existent entre les différentes entrées et sorties.

Le système essaie tout d’abord d’analyser la structure d’un formulaire et de relier les différents champs de ce formulaire aux concepts du domaine. Pour cela, le contexte textuel de chaque champ de formulaire est extrait (le nom du champ, le texte qui se trouve juste avant etc.) et des outils classiques de traitement du texte sont utilisés pour trouver un appariement avec les concepts du domaine. Ainsi, un champ de formulaire précédé de l’étiquette « Créateur : » sera associé automatiquement au quasi-synonyme « Auteur ». Ces appariements peuvent toutefois être incorrects dans certains cas. Pour en améliorer la précision, le système va ensuite tenter de sonder le formulaire avec des exemples des concepts (par exemple « Dupont » comme exemple de nom d’auteur). Si les pages de résultats obtenues par ce sondage diffèrent de manière significative de pages de résultats obtenues par la soumission de mots absurdes (par exemple « ddsadfjsak »), le système confirmera l’appariement et l’infirmera dans le cas opposé.

Une fois comprise la structure d’un formulaire, le système va également chercher à comprendre la structure des pages Web obtenues comme résultat de la soumission du formulaire. Celles-ci présentent, en général sous la forme de listes ou de tableaux, l’ensemble des résultats à la requête (ou un sous-ensemble d’entre eux). La disposition des résultats aparaît relativement claire à un être humain mais n’est absolument pas standardisée et est donc a priori inintelligible pour un programme. Afin de déterminer la manière dont les résultats sont présentés, et de les extraire, il est possible de commencer par annoter quelques pages de résultat avec les exemples tirés de la connaissance du domaine (on reconnaîtra ainsi quelques noms d’auteurs, quelques titres de publications, quelques dates...), puis d’utiliser des techniques d’apprentissage sur la structure du document pour essayer de corriger et généraliser cette annotation, qui est évidemment à la fois imparfaite et incomplète. Ceci signifie par exemple que si le système constate que les noms d’auteurs apparaissent — à quelques exceptions près — dans la troisième colonne d’une table, et que cette colonne ne semble contenir rien d’autre de particulier, celui-ci apprendra que les noms d’auteurs sont toujours présentés dans cette même colonne. Cette localisation pourra de plus être réutilisée pour les autres pages de résultat générées par ce même formulaire.

Les deux étapes précédentes permettent de comprendre automatiquement la structure d’un formulaire et des pages de résultat, mais ne donnent pas d’informations sur les liens qui relient les concepts qui y apparaissent. Si un service du Web caché fournit un nom de personne à partir d’un autre, comment déterminer la relation entre ces deux personnes ? La première peut-être le fils de la seconde, ou le père, ou le supérieur hiérarchique, etc. Une façon de résoudre automatiquement ce problème, intrinsèquement très complexe, est encore une fois de faire appel à la connaissance du domaine, et, plus précisément, de comparer les relations que l’on connaît déjà entre exemples de concepts du domaine avec les occurrences de ces mêmes exemples fournies par le service considéré. Des travaux théoriques [3] ont montré cependant que, même dans des cas très simples, trouver le lien le plus naturel possible entre les relations entre exemples apparaissant dans la connaissance du domaine d’une part, et dans les services d’autre part, est très coûteux en terme de temps de calcul.

Les trois étapes décrites ici (compréhension de la structure d’un formulaire, de la structure des pages de résultats, et des relations entre concepts apparaissant dans ce formulaire et ces pages de résultats) permettent essentiellement de transformer un service du Web caché (un formulaire destiné à des humains) en un service Web , une source de données interrogeable automatiquement par une machine, ouvrant ainsi la voie à des moteurs de recherche sur les contenus du Web caché.

D’autres problèmes subsistent. Premièrement, comment découvrir ces services du Web caché (dans un domaine d’intérêt donné), toujours dans le cas d’un système entièrement automatique ? Des techniques de parcours dirigé (ou focused crawling) du Web peuvent être employés, avec un filtrage pour exclure les pages sans formulaires et les formulaires autres que ceux de recherche (réservation, inscription etc.). Deuxièmement, comment déterminer, à partir de la question d’un utilisateur en termes des concepts du domaine, quels services interroger pour répondre à cette question, ces services ayant été au préalable analysés de la manière décrite ci-dessus ? Ce problème n’est pas non plus évident à résoudre, car il faut dans certains cas faire appel à plusieurs services à la suite ou en parallèle pour répondre à une question donnée, ce qui renvoie à deux problèmes (réponse à des requêtes en utilisant des vues, et réponse à des requêtes en présence de contraintes d’accès) qui ont été en partie étudiés dans les travaux de recherche en bases de données.