détection des changements depuis le flux de données,

2. dérivation des requêtes de modification à partir des changements détectés, 3. traduction des requêtes de modifications en modifications appliqués au modèle, et 4. application des modification (évolution du modèle)

La dernière étape considère la résolution des inconsistances résultant de l’application des modifications selon 4 sous-étapes : application des changements, vérification de la consistance, résolution des inconsistances et application définitive (commit) des modifi-cations.

Les changements de propriétés statistiques, sont nommées Input Changes dans le pro-cessus d’apprentissage. Les différents types de changements sont capturés par des cap-teurs (change sensors) dédiés. Le tableau 7.2 décrit chaque type de requête de modifi-cation qui affectent le modèle de classifimodifi-cation. Les changements détectés et validés en entrée, ou “Input Changes”, génèrent des “Requêtes de Modification” au cours du crawl pour adapter le modèle de classification. Chaque entrée de cooccurrence implique une mise à jour de la fréquence document du terme, ce qui impacte les proportions relatives aux termes cooccurrents. Les requêtes sont propagées en tant que “Modifications du modèle”, i.e. les mises à jour de l’ontologie. Les mises à jour du modèle peuvent être ef-fectuées après chaque cycle de crawl ou en parallèle du crawl, suivant le cas d’utilisation. Dans le second cas, le résultat de la classification d’un item est impacté après chaque changement du modèle de classification, issu d’autres items. Comme décrit dans la sec-tion précédente, l’architecture SemXDM effectue la classificasec-tion des nouveaux items au moment de la requête. L’évolution de modèle est donc prise en compte de façon trans-parente, sans interruption du processus.

7.4.5/ MODULE DE PRIORITÉ

L’objectif du module de priorité est de combiner les informations issues du graphe web et le contenu des items pour améliorer les décisions du crawler, i.e. pour redéfinir les

7.4. ARCHITECTURE SEMXDM POUR CRAWLER ET CLASSIFIER 105

priorités des items de la frontière de crawl. En opposition au module de classification qui calcule le score des items fetchés, le module de priorité calcule un score potentiel des items de la frontière (items non fetchés). Pour chaque item itemi, le module de priorité peuple l’ontologie avec les liens extraits des items en tant qu’instances (Abox).

Les liens sont mis à jour dans la base de connaissances après chaque cycle de crawl. Les liens sortants (outlinks) sont mis à jour en fonction des liens extraits des items lors du crawl. Les liens entrants (inlinks) sont la relation opposé des liens entrants et sont mis à jour en conséquence. L’ajout de liens entrants ne fait pas appel à un processus externe tel qu’une requête à un moteur de recherche², par conséquent les liens entrants sont incomplets. Le résultat du peuplement de l’ontologie est l’ensemble de propriétés hasInlink : ω^itemi

in = |item1, item₂, ..., itemn| et hasOutlink : ω^itemi

out = |item1, item₂, ..., itemm|, où n est le nombre total de liens entrants, et m le nombre total de liens sortants ex-traits des items. Pour identifier les chemins menant potentiellement vers des items per-tinents, l’approche graphe contextuel de [Diligenti et al., 2000] est utilisée. Dans cette approche, les items pertinents sont d’abord identifiés. A partir de ces items, les liens entrants de ces items sont extraits de façon récursive. L’ensemble des liens forme un sous-graphe, découpé en couches. Chaque couche correspond à une distance à un item pertinent. Après chaque cycle de crawl, les couches du graphe contextuel sont recal-culées à partir de l’ensemble des items pertinents à jour. Un seuil de pertinence défini par l’utilisateur permet de discriminer les pages non pertinentes. L’ensemble des items pertinents ω^itemi

rel est défini par : ω^itemi

rel = itemi|∀itemi∈ Item : Relevancei > θ où Relevancei

est le score de pertinence de l’item. Lors du premier cycle de crawl, l’ensemble d’items pertinents est composé des seed (pages initiales) fournies par l’utilisateur. A partir de l’ensemble ω^itemi

rel , chaque couche L_j du graphe contextuel est définie par l’ensemble des items à une distance de j liens entrants d’un item_i ∈ ωitemi

rel : Lj = ωitem_k = {itemk|∀itemk ∈ Item : ∃path(itemk, itemi)} où path(itemk, itemi) est le plus court chemin dans la base de connaissances entre itemi et itemk, composé de j relations hasInlink(|path|= j).

Chaque couche du graphe contextuel est mise à jour avec l’ensemble des termes con-tenus dans les items qui la composent : Lj est définie par un couple (termk, valeurk) tel que :

• ∀ j, itemj∈ Lj

• ∀k, termk ∈ T erm

• ∀k, ∃itemjhasT erm(labelk)

• ∀ j, valeurk = |itemj|, itemjhasT erm(termk)

Un vecteur pondéré v^term_i est créé pour chaque couche Li, où chaque dimension du vecteur est un terme. Chaque vecteur vterm

i est mis à jour après chaque phase de crawl avec les nouveaux termes et liens découverts. Un second vecteur vlabel

itemi est généré, où chaque dimension est un Label dans l’ontologie. La probabilité qu’un item appartienne à une couche Li est ensuite approximée par calcul de la distance entre les vecteurs de termes/labels d’une couche du graphe et du nouvel item.

cos(v^term_Li , vterm

itemj)= ^v term L_i · v^term_item j ||v^term_L i || · ||v^term_item j||

2. Certains moteurs de recherche peuvent être requêtés pour retrouver l’ensemble des liens entrant d’une page

106 CHAPTER 7. LE VOLUME ET LA PERTINENCE DES DONNÉES

Le calcul de similarité entre les deux types de vecteurs est identique. Les deux types de vecteurs sont ensuite utilisés dans le calcul du degré d’appartenance de chaque couche du graphe. On définit le degré d’appartenance di pour chaque couche du graphe comme la moyenne arithmétique deux deux vecteurs :

di = ^cos(v term Li v^term_item j)+ cos(vlabel Li v^label_item j) 2

Le score de pertinence final est définit ci-dessous. Une heuristique supplémentaire est employée pour palier les limitations du modèle de classification, qui ne peut permettre de décrire avec précision l’ensemble des items dans un environnement web³:

r_itemj = max(cos(vterm L_i v^term_item

j), di) où ritem_j ∈ [0, 1].

Cette heuristique permet de conserver une priorité importante pour les items dont seule la distance des vecteurs de termes est élevée. Le score de pertinence résultant, compris dans l’intervalle [0, 1] est utilisé pour estimer la distance, en nombre de liens, entre un nouvel item et un item pertinent (couche L0). Les priorités de la frontière de crawl sont mises à jour après chaque crawl en fonction de cette distance. Plus une page est proche de la couche L₀, plus sa priorité est élevée (une priorité fixe est attribuée à chaque couche du graphe). Les liens qui ne correspondent à aucune couche ont une priorité minimale dans la frontière. Après chaque cycle de crawl, le graphe contextuel est mis à jour : la première couche du graphe est composée de l’ensemble des items dont la pertinence ω^rel_L

0

dépasse un seuil Θ définit par l’utilisateur, i.e. tous les items dont le score de pertinence avec la première couche du graphe est supérieure au seuil : ritem_i > Θ. Pour le premier cycle, la couche L₀ du graphe est uniquement composée du vecteur de termes issu de la requête initiale. Les autres couches du graphe sont modifiées de façon dynamique, en fonction du graphe de liens mis à jour.

7.4.6/ CONCLUSION

Ce chapitre a décrit une architecture de recherche d’information basée sur un crawler ciblé, et tire partie de l’exploitation d’un modèle de classification sémantique pour décrire les items du web, dont la construction est basée sur l’approche SHMC. Afin de répon-dre aux limitations de l’état de l’art, l’approche considère premièrement l’adaptation du modèle de classification dans le temps; et deuxièmement, une nouvelle méthode de déf-inition de la priorité dans la frontière du crawl basée sur une approche de graphe con-textuelle. Une évaluation qualitative montre que notre approche semble être performante pour discréditer rapidement les informations pertinentes au départ de la recherche, mais ne parvient pas à maintenir une similarité moyenne élevée pendant toute la recherche contrairement à l’approche Best-N-First ayant servi à la comparaison. Afin de maximiser la performance de l’approche durant toute la recherche, modifier la stratégie du crawler durant le crawl semble être pertinent. Le changement de stratégie permet de maximiser la performance du crawler tout au long de la recherche.

3. Cette problématique nommée “incomplete label assignment”, est définie par le coût important de créa-tion d’un jeu de données complètement étiquetté, i.e. le jeu d’entraînement ne comprend pas tous les labels possibles. Cette problématique est d’autant plus importante dans un contexte Big Data, où le nombre d’items à étiqueter est important, rendant la création d’un modèle parfaitement représentatif des données quasiment impossible [Yu et al., 2014].

7.4. ARCHITECTURE SEMXDM POUR CRAWLER ET CLASSIFIER 107

8