Variation du paramètre support

Rappelons que le template est composé de classes d’équivalence (EQs) formées à partir de tokens. Chaque EQ regroupe les tokens partageant le même vecteur d’occurrence. Toutes les EQs découvertes ne sont pas forcément gardées pour la construction du template, sauf celles qui sont fréquentes et larges. Plus précisément, les EQs dont le

support (le nombre de pages où les tokens de la EQ apparaissent) ou le size (le nombre

de tokens dans une EQ) insuffisants sont éliminées. Ces deux paramètres, le support et le

size, peuvent avoir un impact sur la qualité de l’extraction dans certains cas. Comme dans

notre approche, nous pouvons estimer automatiquement la qualité de l’extraction (en se basant sur les annotations conflictuelles 4.2.3.2, qui apparaissent sur les valeurs extraites pour le même attribut), nous varions ces paramètres et nous re-exécutons l’algorithme de construction du wrapper à nouveau, si nécessaire.

Pour les sources du domaine des publications, les pages sélectionnées ont été obtenues à travers des formulaires (Web caché), en spécifiant les mots-clés “Web information extraction” pour certains sites. Nous avons obtenus des listes de publications du domaine choisi (Web information extraction). En procédant ainsi, beaucoup de publications apparaissant dans les pages contenaient les mots web, information, ou d’autres mots-clés de ce domaine. Ainsi, ces mots peuvent se retrouver dans les EQs, alors qu’ils ne font pas partie du template. Afin d’éliminer ces EQs lors de la construction du template, nous avons essayé de jouer sur le paramètre support (entre 3 et 5 dans nos tests). Le Tableau 4.6 résume les résultats des tests effectués. Nous avons constater qu’en faisant varier le support et en re-exécutant l’algorithme, la précision de l’extraction peut être améliorée de manière significative.

3 4 5

Domaine Pc Pp Pc Pp Pc Pp

Publications 43.61 56.43 47.65 56.43 65.21 74

4.4

Conclusion

Ce chapitre présente une approche automatique d’extraction d’information à partir de pages Web structurées. Il défend l’idée d’une interrogation à deux étapes, dans laquelle une description intentionnelle des données ciblées est fournie avant la phase d’extraction. L’utilisateur spécifie une structure (SOD) des objets recherchés, qui sera utilisée dans la phase d’extraction pour annoter les pages sources et extraire les objets découverts.

Ce processus est indépendant du domaine, il s’applique à n’importe quelle structure, plate ou imbriquée, décrivant des objets du monde réel. Notre approche est complètement automatique et ne nécessite pas d’annotations manuelles ou des procédures d’apprentissage. Le principe général d’ObjectRunner est de privilégier les solutions flexibles, qui sont rapides, avec une bonne précision et un taux d’extraction satisfaisant. En pratique, il peut y avoir des sources traitées de manière peu satisfaisante, ce qui conduit à la perte de certains objets qui, étant donné la redondance du Web, pourraient très probablement être trouvés dans une autre source (voir même dans le même site).

Avoir une description intentionnelle des données ciblées a un double intérêt : (i) la qualité des données extraites peut être améliorée, et (ii) des traitements inutiles sont évités (ceux des données contenues dans les pages mais qui n’intéressent pas l’utilisateur). La qualité des extractions est améliorée grâce aux annotations qui permettent dans notre approche de distinguer de façon plus fine les rôles des tokens. La combinaison entre la structure des pages et les annotations donne les meilleurs résultats, comme le montre nos tests.

Nous validons notre approche par des expérimentations intensives et des comparaisons avec les deux systèmes les plus référencés pour l’inférence automatique de wrappers. Dans tous les cas, pour les cinq domaines choisis, notre système récupère plus d’instances d’objets avec moins d’erreurs. Nos résultats sont rendus plus pertinents par le fait que les sources testées n’ont pas été sélectionnées aléatoirement ou de manière subjective. Ces sources ont été fournies par des experts (de Mechanical Turk), comme étant les plus pertinentes pour chaque domaine.

Sélection de Sources Structurées

Dans ce chapitre nous détaillons le processus de sélection automatique de sources structurées pertinentes pour la phase d’extraction. Précisément, nous considérons le problème de pré-traitement, d’indexation et de sélection pour l’inférence de wrappers.

En suivant le paradigme d’ObjectRunner d’avoir une interrogation du Web à deux étapes, nous voulons intégrer l’inférence de wrappers dans un scénario complètement automatique où, étant donné la description intentionnelle (requête SOD), les sources les plus pertinentes doivent être sélectionnées à partie d’un répertoire de sources récupérées et indexées du Web (crawled).1

Sélectionner les sources prometteuses pour l’extraction au moment de l’interrogation (query time) nécessite une comprehension au préalable (offline) adaptée de la sémantiques des données, de la structure hiérarchique et des caractéristiques visuelles des pages. Nous présentons ci-dessous une approche – à notre connaissance, ce travail est le premier qui permet de déterminer les sources les plus pertinentes pour une requête donnée – pour traiter cette problématique. L’approche proposée est construite sur des techniques de : (i) recherche d’information basée sur des ontologies, (ii) indexation de données structurées, et (iii) recherche top-k sur des données semi-structurées (structures d’arbres).

5.1

Architecture générale

Le défi que nous considérons est de traiter, annoter sémantiquement, analyser et indexer de manière optimale et efficace un grand corpus de pages Web structurées. Nous proposons une approche guidée par des connaissances sémantiques, basée sur des ontologies populaires comme Freebase [BEP+_{08] ou Yago [SKW07].}

1. Dans nos expérimentations pour la tâche d’extraction du Chapitre 4, ces sources ont été simulées avec la plateforme Mechanical Turk.

Étant donné le SOD fourni par l’utilisateur, notre système analyse les sources et sélectionne celles (les top-k) qui sont les plus pertinentes pour la requête utilisateur.

! " # $ % && ' ( ) * * * * *+ *+ *+ , ) & - * *+ *+ *+ !

Figure 5.1 – Architecture générale pour la sélection de sources.

Nous présentons dans la Figure 5.1 un aperçu de l’architecture de notre système de sélection de sources, en termes de modules de traitement offline et online qui le composent.

1. Les sources Web (collections de pages) sont pré-traitées, ceci permet de déterminer la structure hiérarchique des blocs qui composent les pages de chaque source, en se basant sur les caractéristiques visuelles et structurelles des pages.

2. Une annotation sémantique est effectuée sur les contenus des blocs, en faisant correspondre les instances au sein d’un bloc aux concepts dans l’ontologie.

3. Une description est établie pour chaque source, en termes d’annotations, des caractéristiques structurelles et d’autres critères utiles pour la construction du template.

4. Les descriptions de sources sont indexées et stockées.

5. Un algorithme top-k permet de trouver les sources les plus pertinentes pour un SOD donné, en exploitant l’index construit précédemment.