BottinBot5

Langue

Français

Résumés des fonctionnalités

Ce bot a pour but d'extraire en grande quantité des informations à partir de la base de données créée en 2019 par l’équipe du DHLAB, qui contient quatre millions d’adresses issues d'anciens annuaires de la ville de Paris. Dans un second temps, le bot devra créer les pages correspondantes dans Wikipast.

Notre BottinBot5 traitera un sous-ensemble de cette base de donnée : données groupe 5. A savoir les annuaires des années 1880 à 1887 (soit un total de 790405 entrées non traitées).

Description technique

Lecture du bottin

Une fois les données récupérées, nous les avons ordonnées par année croissante puis, au sein d'une même année, les informations étaient triées par nom (ordre alphabétique). Cela a permis notamment que, pour une même page Wikipast, les entrées (rappel : 1 entrée = présence de la personne dans l'un des 8 annuaires étudiés) soient classées par ordre chronologique. Nous avons dans un second temps réutilisé les fonctions mises à notre disposition qui permettent d'ajouter à chaque entrée de notre bottin, l'URL Gallica associé (création d'un nouvel attribut).

Vérification d'existence

Il s'agit désormais de charger toutes les pages du Wikipast (afin d'avoir la dernière version en date), puis de vérifier pour chacune des personnes de notre bottin, si il/elle possède une page. Les 2 cas à traiter sont donc les suivants :

• La personne existe déjà sur Wikipast : On récupère la page existante, on ajoute (.join) une entrée à celle-ci via la fonction modify_page.
• La personne n'existe pas sur Wikipast : On utilise la fonction new_page qui crée la page souhaitée.

Exécution du BottinBot

Syntaxe sélectionnée :

 [[year]]/[[Paris]], [[street]], [[number]]. [[nom]] est mentionné dans la catégorie [[job]]. 

Exemple d'entrée générée :

Stratégies adoptées

Stratégie générale

Dans la perspective de ce projet d'Humanités Digitales, nous avons délibérément choisi d'adopter une méthode (d'extraction-création) itérative, à savoir en traitant un maximum de données à chaque exécution du code. En cas de problème rencontré pour une entrée particulière, nous cherchions alors à fixer l'erreur correspondante et nous reprenions ensuite l'exécution de notre code à partir du dernier conflit. Cela nous a permis, assez tôt, de produire des pages dans Wikipast en grande quantité.

Toutefois, nos premières modifications du code ont entraînées un certain nombre de doublon parmi les premières entrées donc notamment pour le début des A de l'année 1884 (notre base de donnée allant de 1880 à 1887 mais commençant par l'année 1884). Nous avons donc écrit un code suppr_doublon qui supprime les entrées similaires à la première de la page.

Stratégie pour les erreurs d'homonymie

Pour limiter la création de page pour une seule et même personne, nous avons décider de grouper les entrées ayant le même nom et le même métier. Pour ce faire, nous avons nommé les pages selon ces deux critères, comme s'en suit :

"Aubry - vins". 

Nous avons également regroupé certains métiers qui se recoupaient, par exemple :

"Aubry - vins" 

a été intégré à la page

"Aubry - vins et traiteur".

Stratégie pour les erreurs d'OCR

Pour limiter les erreurs d'OCR qui posent parfois problème lors de recherche de pages ou autre, nous avons décidé de regarder les erreurs se produisant le plus souvent, comme notamment la présence de caractères particuliers (cf. char_err).

           err_char ='|#*'
           for char in nom:
              if char in err_char:
                 nom = nom.replace(char, )

Après avoir effectué ces opérations, nous nous sommes rendus compte que cet algorithme s'avérait être coûteux en temps de calcul. Nous avons donc choisi de modifier directement notre base de donnée, c'est à dire notre fichier csv (via l'outil "Rechercher & Remplacer d'excel), afin de supprimer définitivement les erreur d'OCR. Nous n'avons cependant pas pu corriger les erreurs plus complexe tel que le mot "boulanger" quelque fois orthographié en "boulinger".

Évaluation des performances

Nous avons réussi à créer des pages globalement complète par rapport à notre bottin. Toutefois, notre bottin était ordonnée par année puis par ordre alphabétique. Toutefois, les années n'étaient pas ordonnées par ordre chronologique mais dans celui-ci 1884 - 1882 - 1880 - 1886 - 1883 - 1885 - 1887 - 1881. Ayant choisi de parcourir notre bottin dans l'ordre de ces indentations, nous avons tenté de le trier par ordre chronologique avant de faire tourner notre code dans le but que les années s'ajoutent chronologiquement dans les pages des personnes récurrentes au fil des ans.

Comme vous pouvez le constater, nous avons utilisé la fonction sort_values et lorsque l'on affiche les 10 premiers, on obtient bien des entrées de l'année 1880 la première année de notre base de données. Cependant, lorsque l'on demande le premier nom, on obtient Aaquien (Camille) qui se trouve être la première entrée initiale de notre bottin en 1884.

Nous avons eu du mal à comprendre ce problème et nous avons préféré passer à autre chose quitte à écrire plus tard une fonction qui pourrait parcourir nos pages pour remettre leurs entrées dans l'ordre chronologique. Cette solution nous paraît même préférable car d'autres groupes pourraient également ajouter des entrées non chronologiques sur les pages que nous avons crées ou modifiées.

Analyse critique

Nous avons plusieurs critiques à faire sur notre travail :

• Tout d'abord, nous avions partagé lors d'un zoom avec les autres groupes la syntaxe utilisée pour nos entrées et nous sommes plus ou moins arrivés à un compromis. Cependant, en ce qui concerne le choix du titre des pages et donc indirectement au choix de la sélection plus ou moins fine des homonymes, nous avons chacun présenté nos choix mais aucun consensus n'a été adopté entre les différents groupes. Nous avons trouvé cela dommage car ayant choisi de créer nos pages sous le format nom - métier, nous avons été les créateur de quasiment la totalité de nos pages. Des personnes présentes dans les jeux de données de deux groupes différents seront donc représentées par plusieurs pages sur le wikidata avec des titres différents certains groupes ayant choisi de ne pas y inclure le métier et d'autres d'y inclure également la rue.

• Nous pensons également que la méthode que nous avons choisi n'est pas la plus rapide. En effet, le temps d’exécuter notre code pour chaque ligne de notre base de donnée est extrêmement long et nous avons fait tourner nos codes pendant plusieurs jours sans réussir à parcourir toute celle-ci. Certains groupe ont l'air d'avoir crée des dictionnaires au préalable ce qui semble avoir été un meilleur parti pris en terme de temps d’exécution.