Openlibrary: Correction des titres de livres avec Unicode mutilé

Ces deux enregistrements proviennent d'archive.org.

J'ai regardé les fichiers _marc.xml sur archive.org. L'heure de la dernière modification des deux fichiers marc.xml date de 2007 et ces enregistrements ont été créés en 2008. Il semble que le problème soit lié au script qui a analysé ces titres.

Il existe des milliers de notices d'importation MARC dans lesquelles les caractères accentués ont été modifiés ou manipulés de manière incorrecte. Un autre scénario courant est que les accents ou autres signes diacritiques ont été remplacés par un espace avant ou après la voyelle.

Voir par exemple :

http://openlibrary.org/authors/OL4459814A/Heinrich_Schro_der

http://openlibrary.org/works/OL10684450W/Tonbandgera_te-Messpraxis

http://openlibrary.org/show-records/talis_openlibrary_contribution/talis-openlibrary-contribution.mrc :299045317:529

Dans l'auteur et le titre, le tréma a été remplacé par un espace après la voyelle. La notice MARC liée s'affiche correctement dans le navigateur.

Doit-on envisager de réimporter ? Et le #149, qui fait également référence à https://bugs.launchpad.net/openlibrary/+bug/598204 , est-il une dépendance ?

Certains que j'ai trouvés récemment : https://openlibrary.org/works/OL17670297W
https://openlibrary.org/works/OL17677126W
plusieurs ouvrages de cet auteur :
https://openlibrary.org/authors/OL2450531A/Matthieu_Joseph_Bonaventure_Orfila

https://openlibrary.org/search?q=title%3A+%22 ©♭%22&mode=everything Trouve toujours bien plus de 17 millions de correspondances. Ceci pour "é", probablement la lettre accentuée la plus courante. Les éditions comme https://openlibrary.org/books/OL26303038M/Anatomie_générale_appliquée_à_la_physiologie_et_à_la_médecine?b=3&a=1&_compare=Compare&m=diff ne doivent pas être forcément manuelles.

@hornc re votre commentaire du 8 mai, ces œuvres ont été créées à partir d'éditions créées à partir de l'importation
https://openlibrary.org/show-records/ia :b28044277_0001
et
https://openlibrary.org/show-records/ia :b2202010x
Jusqu'à ce qu'ils soient corrigés dans les enregistrements ia MARC, il n'y a aucune valeur à réimporter à moins que l'importation ne les fasse passer par la normalisation

@LeadSongDog intéressant, l'affichage MARC https://ia800202.us.archive.org/34/items/b28044277_0001/b28044277_0001_marc.xml, l'e accentué s'affiche correctement . Il peut y avoir un problème avec les types d'encodage mal définis ? Je reprendrai cela sous peu, le nouveau client openlibrary est maintenant dans un état où il peut être utilisé pour effectuer des corrections de données en masse.

@LeadSongDog J'ai peut-être compris comment se passe la mutilation, dans cet exemple marc xml
https://ia600208.us.archive.org/25/items/b2202010x/b2202010x_marc.xml

le a-grave de "Secours à donner" s'affiche correctement en utf-8

a-grave est U+00E0, qui en binaire (notation pythonique) est \xC3\xA0

si ces octets étaient interprétés comme MARC8 et "convertis", C3 devient le symbole du copyright, et 'A0' devient un espace, ce qui est exactement ce que l'on voit sur les pages OL avec "Secours © donner"

Je pense maintenant que ces notices MARC ont des encodages de caractères utf-8, mais ont été importés vers OL comme s'il s'agissait de MARC8, ce qui explique la modification.

J'ai fait la conversion MARC8 manuellement à partir des tableaux trouvés ici https://memory.loc.gov/diglib/codetables/45.html Je vais devoir utiliser yaz ou quelque chose pour tester cela correctement, mais cela fournira un bon chemin à corriger les erreurs MARC par programmation.

Je sais qu'il existe d'autres erreurs de manipulation unicode affectant les enregistrements importés par Amazon, mais je pense que cela provient d'une conversion incorrecte à partir de jeux de caractères Windows ou ISO

Merci pour votre commentaire @LeadSongDog , en essayant de déterminer si les enregistrements MARC étaient réellement erronés ou non, je pense que je suis tombé sur la cause première du problème !

@hornc des mises à jour sur la mutilation MARC et/ou si nous avons résolu ce problème ?

Le problème n'est certainement pas résolu. Lorsque le script d'importation est corrigé, @bfalling suggère de réimporter sera probablement nécessaire.

Du point de vue du triage, il serait probablement utile d'avoir un décompte réel. "Des milliers" n'est pas un très gros pourcentage de 25 millions d'éditions.

Cela a-t-il été résolu avec nos modifications Python 3 ou quelqu'un peut-il fournir des étapes pour reproduire sur Python 3 ?

Bon https://openlibrary.org/books/OL12903648M/Etudes_Conomiques_De_L 'Ocde n'est certainement pas réparé, mais peut-être avons-nous fini de creuser le trou...
Il y avait au moins trois classes de problèmes :

1. Mauvaise importation de bonnes données
2. Importation littérale de mauvaises données
3. Mauvaises données en place à partir d'anciens cas de 1 ou 2 depuis corrigés.
   Le passage à py3 corrigera tout au plus le numéro 1.

Étapes à suivre pour reproduire le problème de classe 1 ?

Les exemples précédents sont meilleurs que le plus récent qui est une importation de données Amazon de merde (que nous ne devrions
https://openlibrary.org/books/OL7165183M/The_Vikramorva%C2%A9%C3%98s%C2%A9%C4%90iyam
https://openlibrary.org/authors/OL4459814A/Heinrich_Schro_der
https://openlibrary.org/books/OL13956174M/Tonbandgera_te-Messpraxis
https://openlibrary.org/books/OL26280693M/Secours_%C2%A9_donner_aux_personnes_empoisonn%C2%A9%E2%99%ADes_ou_asphyxi%C2%A9%E2%99%ADes_suivis_des_moyens_propres_%C2%A9_reconna%C2%A9%CA%BEtre

Si le bogue a été corrigé, la réimportation des enregistrements devrait aboutir à l'encodage correct. Ensuite, la tâche consiste simplement à réimporter les millions d'enregistrements corrompus.

La recherche qui était censée renvoyer plus de 17 millions d'enregistrements auparavant : https://openlibrary.org/search?q=title%3A+%22%C2%A9%E2%99%AD%22&mode=everything
renvoie maintenant 23,4 millions de résultats, mais je pense qu'il s'agit en fait d'un bogue distinct et qu'il renvoie simplement tous les travaux de la base de données.

@tfmorris Comme https://openlibrary.org/search?q=title%3A+%22+%22&mode=everything obtient le même résultat, il semble que oui, il s'agit d'un simple cas de recherche de titre pour une chaîne effectivement vide.

J'ai créé #4223 pour le bug de recherche.