D’un schéma à l’autre - Archives, fragments Web et diasporas. Pour une exploration désagrégée d

jointure par id indexer

méta id = data id

fragmenter Rivelaine

Figure 4.22: Intégration de la fragmen- tation au pipeline de transformation des archives (Voir Figure 3.7)

D’un point de vue pratique, l’extraction des fragments s’intègre à l’ensemble des traitements supervisés par Spark (Section 4.3). Une fois la jointure effectuée entre méta-données et données, notre moteur demande à Rivelaine de segmenter les pages archivées avant de les envoyer dans Solr pour indexation (Figure 4.22).

Un nouvel index doit alors être créé pour accueillir les fragments, le premier étant pensé pour les pages Web uniquement. Deux stratégies s’offrent ici à nous. Tout d’abord, conserver la page comme élément de référence, à laquelle nous subordonnons les fragments (Figure 4.23, (a)).

Ou éliminer la notion même de page et n’indexer que les fragments (Figure 4.23, (b)).

(a)

page_id page_info frag_id_1 frag_info_1 frag_id_2 frag_info_2 frag_id_2 frag_info_2

(b)

page_id page_info frag_id_1 frag_info_1 page_id page_info frag_id_2 frag_info_2 page_id page_info frag_id_3 frag_info_3

Figure 4.23: Différentes stratégies d’indexation du fragment Web dans un moteur de recherche et

complexité de la recherche (bleu) _{La première option, plus intuitive, conserve le lien ontologique entre} la page et ses fragments Web. Elle nécessite la mise en place dans Solr, d’une structure dite de nested documents46

. Dans un même index, 46. Documents imbriqués,http:

//yonik.com/solr-nested-objects/ _{deux types de documents cohabiteraient, un document page et des}

documents fragments. Malheureusement, cette stratégie est couteuse, notamment lorsqu’il s’agit d’identifier et de retourner des résultats. En effet, dans les moteurs de recherche, il est toujours conseillé (surtout lorsque le nombre de documents est important) de dupliquer au besoin les documents indexés. L’espace disque occupé par l’index sera plus important, mais les performances du search, en tant que tel, seront améliorées, la complexité d’une recherche par documents à plat étant moindre que celle par documents imbriqués pour laquelle toute la structure doit être retournée (Figure 4.23, tracés bleus).

Nous nous orientons donc vers la seconde option, qui a pour effet de dupliquer les informations associées à une page à l’intérieur de chaque fragment. Si l’utilisateur veut, au besoin retrouver l’ensemble des fragments d’une même page, il pourra s’orienter vers une requête group by sur le champpage_iddans Solr.

Soit le schéma d’indexation des fragments Web présenté par la Figure 4.24. Dans ce schéma, l’id de chaque document correspond à l’identifiant unique d’un fragment. Les champs issus de Rivelaine (frag_type,frag_offset. . .) sont intégrés à l’index et la recherche plein texte est maintenant réalisée sur le seul champfrag_text. Pour retrouver l’ensemble des fragments d’une même page, on se servira du champ

page_url_idet pour dédupliquer les fragments (Section 4.4), on s’ap- puiera sur la valeur defrag_text_id47

. Les différents niveaux de notre 47. Clé SHA-256 unique

échelle de datation (Table 4.1) sont indexés, le champpage_datecor- respondant à la date de création d’une page (Section 4.1). Le champ

frag_dateest, lui, supposé contenir les dates d’édition de chaque fragment. Néanmoins, si nous sommes dans l’impossibilité d’associer une date d’édition à un fragment, le champfrag_datese verra attribuer la valeur depage_date, voire de la date de téléchargementdownload_date

dans le pire des cas. Sur ce point, le typedateLvlnous renseigne sur le niveau de précision alloué au champfrag_date.

Figure 4.24: Schéma d’indexation des fragments Web

Dans le document Archives, fragments Web et diasporas. Pour une exploration désagrégée de corpus d’archives Web liées aux représentations en ligne des diasporas (Page 124-127)