« BottinBot5 » : différence entre les versions
(→Code) |
|||
(12 versions intermédiaires par le même utilisateur non affichées) | |||
Ligne 61 : | Ligne 61 : | ||
Toutefois, cette stratégie présente tout de même des défauts. Par exemple, dans le cas d'un Barbier qui exerçait le métier de boulanger, on en retrouve plusieurs à diverses adresses et il est évident qu'il s'agit de personnes différentes. | Toutefois, cette stratégie présente tout de même des défauts. Par exemple, dans le cas d'un Barbier qui exerçait le métier de boulanger, on en retrouve plusieurs à diverses adresses et il est évident qu'il s'agit de personnes différentes. | ||
[[Fichier:BottinBot5_Barbier.png| | [[Fichier:BottinBot5_Barbier.png|500px]] | ||
Ce genre de problème se retrouve plusieurs fois lorsque l'on porte un nom aussi commun. Toutefois, nous avons estimé que rajouter une couche de tri par adresse serait contre contre-productive car nous trouvions plus intéressant de pouvoir observer la continuité de la vie d'une personne qui déménage avec pour désavantage d'avoir quelque homonyme regroupé sur la même page. | Ce genre de problème se retrouve plusieurs fois lorsque l'on porte un nom aussi commun. Toutefois, nous avons estimé que rajouter une couche de tri par adresse serait contre contre-productive car nous trouvions plus intéressant de pouvoir observer la continuité de la vie d'une personne qui déménage avec pour désavantage d'avoir quelque homonyme regroupé sur la même page. | ||
Ligne 69 : | Ligne 69 : | ||
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''). | 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 ='|#*' | err_char ='|#*{}[]<>' | ||
for char in nom: | for char in nom: | ||
if char in err_char: | if char in err_char: | ||
Ligne 79 : | Ligne 79 : | ||
== Évaluation des performances == | == Évaluation des performances == | ||
=== Évaluation des performances techniques === | |||
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. | 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. | ||
Ligne 87 : | Ligne 89 : | ||
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. | 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. | ||
=== Évaluation du nombre de pages générées et modifiées === | |||
Comme nous l'avons expliqué précédemment, vu le choix de titre que nous avons fait pour la réduction de page pour des homonymes, nous avons crée un très grand nombre de pages et modifié pour la plupart nos propres pages. Nous avons crée 175418 nouvelles pages et modifié 64492 pages crées au préalable par nous et déjà existantes. | |||
== Analyse critique == | == Analyse critique == | ||
Ligne 98 : | Ligne 104 : | ||
* Par ailleurs, une autre critique que l'on peut faire à notre code est sa gestion imparfaite des erreurs d'homonymie et d'OCR comme nous avons pu le voir plus haut. | * Par ailleurs, une autre critique que l'on peut faire à notre code est sa gestion imparfaite des erreurs d'homonymie et d'OCR comme nous avons pu le voir plus haut. | ||
== Code == | == Code & Présentation == | ||
Le code utilisé (format ''.ipynb'') peut-être trouvé à cette adresse : https://drive.google.com/open?id=1BJv3dyb36cbB2huYPA5uMPngamYgm1Cu. | |||
La présentation du projet (format ''.pptx'') peut-être trouvée à cette adresse : https://drive.google.com/open?id=1QX3_bCkiXlv8pCZRvUphT8UalqjmiZfT. |
Dernière version du 19 mai 2020 à 12:14
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 avons 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
L'exécution du bot se fait à partir d'une fonction BottinBot, prenant en argument les indices de début et de fin d'exécution. Nous avons choisi de conserver la syntaxe Wiki suivante :
[[year]]/[[Paris]], [[street]], [[number]]. [[nom]] est mentionné dans la catégorie [[job]].
Donnant ainsi lieu à des entrées de type :
1884/Paris, rue Pierrel'Ermite, 4.. Henon (E.) est mentionné dans la catégorie entrepositaire de bières. [1]
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".
Toutefois, cette stratégie présente tout de même des défauts. Par exemple, dans le cas d'un Barbier qui exerçait le métier de boulanger, on en retrouve plusieurs à diverses adresses et il est évident qu'il s'agit de personnes différentes.
Ce genre de problème se retrouve plusieurs fois lorsque l'on porte un nom aussi commun. Toutefois, nous avons estimé que rajouter une couche de tri par adresse serait contre contre-productive car nous trouvions plus intéressant de pouvoir observer la continuité de la vie d'une personne qui déménage avec pour désavantage d'avoir quelque homonyme regroupé sur la même page.
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 (cf. base de données pré-traitée [2]). Nous n'avons cependant pas pu corriger les erreurs plus complexe tel que le mot "boulanger" quelque fois orthographié en "boulinger".
Évaluation des performances
Évaluation des performances techniques
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.
Évaluation du nombre de pages générées et modifiées
Comme nous l'avons expliqué précédemment, vu le choix de titre que nous avons fait pour la réduction de page pour des homonymes, nous avons crée un très grand nombre de pages et modifié pour la plupart nos propres pages. Nous avons crée 175418 nouvelles pages et modifié 64492 pages crées au préalable par nous et déjà existantes.
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.
- Par ailleurs, une autre critique que l'on peut faire à notre code est sa gestion imparfaite des erreurs d'homonymie et d'OCR comme nous avons pu le voir plus haut.
Code & Présentation
Le code utilisé (format .ipynb) peut-être trouvé à cette adresse : https://drive.google.com/open?id=1BJv3dyb36cbB2huYPA5uMPngamYgm1Cu.
La présentation du projet (format .pptx) peut-être trouvée à cette adresse : https://drive.google.com/open?id=1QX3_bCkiXlv8pCZRvUphT8UalqjmiZfT.