« BottinBot2 » : différence entre les versions

De Wikipast
Aller à la navigation Aller à la recherche
Aucun résumé des modifications
Aucun résumé des modifications
Ligne 14 : Ligne 14 :




la similarité entre deux entrées est définie à l'aide d'une fonction <code>score(entry1, entry2)</code>, qui pour deux entrées données, retourne un score de ressemblance compris entre 0 (aucune ressemblance) et 1 (identiques). Ce score est définis simplement comme le produit des trois scores de ressemblances <code>resemblance(entr1.X, entry2.X)</code>, pour <code>X</code> égal à ''''name_pp'''', ''''job_pp'''' et ''''street_pp''''. Cette deuxième fonction <code>resemblance(s1, s2)</code>, elle, calcule la distance de Levenshtein entre les chaînes <code>s1</code> et <code>s2</code> normalisée par la taille la plus longue, réduit artificiellement cette distance si il a une inclusion d'une des chaînes dans l'autre, et enfin retourne 1 moins le résultat, de sorte à produire un score de ressemblance entre <code>s1</code> et <code>s2</code> bien compris entre 0 et 1.  Le fait d'étudier le score final comme produit de ces 3 scores permet en quelque sorte d'autoriser que certaines des 3 variables soient un peu éloignées mais pas d'autres.
La similarité entre deux entrées est définie à l'aide d'une fonction <code>score(entry1, entry2)</code>, qui pour deux entrées données, retourne un score de ressemblance compris entre 0 (aucune ressemblance) et 1 (identiques). Ce score est définis simplement comme le produit des trois scores de ressemblances <code>resemblance(entr1.X, entry2.X)</code>, pour <code>X</code> égal à ''''name_pp'''', ''''job_pp'''' et ''''street_pp''''. Cette deuxième fonction <code>resemblance(s1, s2)</code>, elle, calcule la distance de Levenshtein entre les chaînes <code>s1</code> et <code>s2</code> normalisée par la taille la plus longue, réduit artificiellement cette distance si il a une inclusion d'une des chaînes dans l'autre, et enfin retourne 1 moins le résultat, de sorte à produire un score de ressemblance entre <code>s1</code> et <code>s2</code> bien compris entre 0 et 1.  Le fait d'étudier le score final comme produit de ces 3 scores permet en quelque sorte d'autoriser que certaines des 3 variables soient un peu éloignées mais pas d'autres.





Version du 19 mai 2020 à 16:08

Présentation du bot

En 2019, l'équipe du DHLAB a effectué une extraction de 4 Million d'adresses dans les anciens annuaires de la ville de Paris [1]. Les donnée sont mis sous forme d'un pandas.dataframe dans la langue Python, utilisant la library Pandas. Les lignes sont les entrées des bottins, chaque entrée contient les informations suivantes:

index, directory, page, row, year, name, job, street, number, street_clean, street_only


La fonction de ce bot est d'automatiser la création d'articles biographiques à partir de ces données. Le BottinBot2 travail sur les données des années 1849 à 1956.

Fonctionnement du bot

Traitements des données du bottin

En premier lieu, les entrées contenant des valeurs NaN sont éliminées. Ensuite, trois nouvelles colonnes sont ajoutées : 'name_pp', 'job_pp' et 'street_pp'. Elles correspondent respectivement à pre_process_str(s), pour s égal aux colonnes name, job et street_only ; où pre_process_str(s) prends une chaîne de caractères s et en renvoie une version qui s'est successivement vu supprimée de sa dernière éventuelle paire de parenthèse, supprimée de tout éventuel whitespace aux extrémités, supprimée de tout éventuel accent sur ses lettres, et mise en minuscules.


La similarité entre deux entrées est définie à l'aide d'une fonction score(entry1, entry2), qui pour deux entrées données, retourne un score de ressemblance compris entre 0 (aucune ressemblance) et 1 (identiques). Ce score est définis simplement comme le produit des trois scores de ressemblances resemblance(entr1.X, entry2.X), pour X égal à 'name_pp', 'job_pp' et 'street_pp'. Cette deuxième fonction resemblance(s1, s2), elle, calcule la distance de Levenshtein entre les chaînes s1 et s2 normalisée par la taille la plus longue, réduit artificiellement cette distance si il a une inclusion d'une des chaînes dans l'autre, et enfin retourne 1 moins le résultat, de sorte à produire un score de ressemblance entre s1 et s2 bien compris entre 0 et 1. Le fait d'étudier le score final comme produit de ces 3 scores permet en quelque sorte d'autoriser que certaines des 3 variables soient un peu éloignées mais pas d'autres.


Le fonctionnement de l'algorithme de regroupement (coûteux en temps) regroupement_personnes(df) est décrit par le pseudo-code ci-dessous :

def regroupement_personnes(df):
    
    Persons = [[entry] for entry in entrées de la df qui sont à l’année 1856]

    for year in range(1856-1, 1849 -1, -1): #Parcours déchronologique
            entries_year = entrées de la df qui sont à l’année year

            for P in Persons:
                P_lastentry = P[-1]

                Calcul des score(entry,P_lastentry) pour toute entry dans entries_year,
                (arrêt éventuel si on trouve un score parfait de 1)

                Si le meilleur de ces score est >= match_threshold:

                    P.append( cette entry la plus ressemblante ).
                    Suppression de cette entry la plus ressemblante de entries_year.
                Sinon:
                    pass
            new_Persons = [[entry] for entry in entries_year]
            Persons += new_Persons

    return transformer_en_DataFrame(Persons)


La création du dictionnaire contenant les entités distinctes se fait en comparant les entrées d'une année avec celles de l'année précédente et en groupant dans des dataFrames les entrées ayant les scores de ressemblance les plus élevés et ayant dépassé un seuil minimum de ressemblance (ceci évitant que deux entrées soient mises dans le même dataFrame avec un score de ressemblance très bas). L'approche anti-chronologique est justifiée par le fait que les données des bottins les plus récentes sont souvent les plus complêtes et plus consistantes avec les informations actuelles sur la ville. Le résultat de ce processus est une liste de dataFrame contenant les entrées attribuées à la même entité:

DataframePersonne.PNG

Cette liste est ensuite convertie en un dictionnaire à trois niveaux de clefs permettant de retrouver, à l'aide du nom, du métier et de l'adresse d'une entité, le dataFrame d'entrée correspondant.

structure du dictionnaire d'entités

Ecriture des articles

L'article pour chaque entité est composé d'entrées de la forme :

  • year / Paris. Mention de name dans la catégorie job à l'adresse number street_clean. [url]

où les variables year,name,job,number et street_clean sont tiré des entrées du dataframe correspondant à l'individu et l'url est crée à l'aide de la fonction entry2url. Le titre de l'article dépend de l'existence d'autres entités partageant le même nom ou métier. Il y a donc trois cas:

  1. Il n'existe aucune autre entité ayant le même nom et le même métier, dans ce cas : le titre de l'article sera simplement le nom de l'entité e.g Klosé.
  2. Il existe une entité ayant le même nom mais pas le même métier, dans ce cas :
    1. le titre de l'article sera "nom de l'entité(métier de l'entité)" e.g Sénéchal (boulanger).
    2. Le titre de cette article est ensuite rajouté sur une page désambiguisation regroupant les titres des articles des entités ayant le même nom. Le titre de la page de désambiguisation est "nom de l'entité (Page d'homonymie)" e.g Sénéchal (Page d'homonymie).
  3. Il existe une autre entité ayant le même nom et le même métier. Dans ce cas :
    1. le titre de l'article sera "nom de l'entité(métier de l'entité,adresse de l'entité)" e.g Piquot (tailleur, Caumartin).
    2. Le titre de cette article est ensuite rajouté sur une page désambiguisation regroupant les titres des articles d'entité ayant le même nom et le même métier. Le titre de la page de désambiguisation est "nom de l'entité(métier de l'entité)". Le titre de cette page dépend de l'existence ou non d'entité avec le même nom et un métier différent :
      1. S'il n'y a pas d'autres entité avec le même nom et un métier différent, le titre de la page de désambiguisation est "nom de l'entité(métier de l'entité) (Page d'homonymie)" e.g Vaury jeune (boulanger) (Page d'homonymie).
      2. S'il y a autres entité avec le même nom et un métier différent, la titre de la page de désambiguisation est simplement "nom de l'entité(métier de l'entité)" ( e.g Piquot (tailleur)) et cet titre est rajouté sur une autre page désambiguisation regroupant les titres des articles d'entité ayant le même nom e.g Piquot (Page d'homonymie).

Discussion qualitative

Les deux problèmes principales, soient le regroupement des entrées de personnes individuelles et le problème d'homonymie, ont étés abordés.

Le problème de regroupement de personnes

L'algorithme de regroupement intelligent de personnes semble d'avoir bien fonctionné. On présente ici quelques exemples de pages où le regroupement a été bien réussie :

  • Exemple déménagement : Gasnier (antiquités), noter le changement de numéro de 15. à 17. Il est quasiment sûr qu'il s'agit de la même personne.
  • Exemple appellation d'un métier et déménagement : Martin (avocat), noter le changement de l'appellation du métier ainsi que le changement de numéro d'adresse. Le métier dans le titre ("avocat") est celui qui apparaît le plus dans les entrées biographiques. Il est très probable qu'il s'agit de la même personne.
  • Exemple changement d'écriture du nom : Vooss, noter le changement du nom de "Vooss" à "Wooss". On y trouve également une faute de reconnaissance de text dans le métier, ainsi qu'un déménagement qui ont étés résolues par l'algorithme. Il semble toujours probable qu'il y s'agit de la même personne.

Le problème d'homonymie

Le problème d'homonymie est résolue par l'organisation des DataFrames des personnes individuelles sous forme de dictionnaire à plusieurs niveaux ("nested dictionary") (voir en haut pour la description). Celui-ci permet de boucler une seule fois sur ce dictionnaire ainsi que les sous-dictionnaires, pouvant facilement créer les pages de personnes individuelles y contenues, mettre des titres de page appropriés selon le niveau d'homonymie, et en même temps créer les pages d'homonymies décrites précédemment.

Un défaut important est l'interaction avec des pages déjà existantes sur le wiki. Notre hypothèse que les pages sous le format "[Nom] ([métier])" ou "[Nom] ([métier],[rue])" soient uniquement créées par nous, et donc qu'il soit justifié d'effacer et recréer ces pages chaque fois qu'on fait tourner notre bot, n'a pas été vérifiée et est donc peut-être un peu naïve. Également, le choix de rajouter la biographie à partir de notre données à la fin d'un article du format "[Nom]" n'était pas le meilleure. D'un côté, le format du page n'est plus consistant, en particulier l'ordre chronologique n'est plus conservé (voir la page Adam (A.) comme exemple). Dans cet exemple particulier un peut aussi constater deux autres problèmes :

  1. Il ne s'agit clairement pas de la même personne, malgré le même nom. Il aurait fallu procéder par une homonymie de noms.
  2. Dans le processus de testing notre bot avait déjà une fois bouclé sur la personne Adam (A.). En relançant le bot, la biographie a été rajoutée une deuxième fois, car le choix a été fait de ne pas effacer la page. Ce problème semble d'être assez répandu, on a trouvé plusieurs pages avec cet erreur.

Un meilleure choix à ce stade de développement aurait été de décider de ne jamais modifier ni effacer des pages à titre déjà existant. Le seul défaut de ce choix aurait été que les pages créées par le BottinBot2 pendant la phase de test, qui sont partiellement incomplètes dans leur biographies parce que le bot avait été testé sur un dictionnaire réduit ne pas contenant des entrées de toutes les années, n'auraient pas pu être mises à jour. On espère de pouvoir reverser les changement faites par notre bot pour pouvoir le relancer en ayant fait ce choix de ne pas effacer les pages.

On donne quelque propositions pour résoudre ces problèmes d'interaction avec des pages déjà existantes:

  • Convention d'écriture de pages : Dans le cas qu'une convention universelle d'écriture des pages biographiques soit établie entre les BottinBots, on pourrait s'imaginer une fonction qui, avant d'écrire un article, recherche si un article sous le titre souhaité existe, déjà, vérifie s'il peut s'agir de la même personne, et, dans ce cas, introduit les entrées bibliographiques au bon endroit.
  • Modification des propres pages : Afin de pouvoir effacer ou modifier d'une manière plus flexible les pages créées par le BottinBot2, on pourrait créer une structure de données (du type dict ou list) à laquelle sera rajoutée le titre d'une page une fois qu'elle est créée par le bot. Si on refait tourner notre bot, il pourrait ainsi distinguer si la page a été créée par lui même, et l'effacer et récrire sans problèmes. Alternativement, on pourrait aussi query l'utilisateur créateur de chaque page et ainsi déterminer si la page a été créée par le BottinBot2.

Code

Tout le code se trouve sur GitHub: MaximamongeissBot [2].