Openlibrary: Corrigir títulos de livros com Unicode mutilado

Ambos os registros vieram de archive.org.

Eu olhei os arquivos _marc.xml em archive.org. A hora da última modificação de ambos os arquivos marc.xml foi em 2007 e esses recrods foram criados em 2008. Parece que o problema é com o script que analisou esses títulos.

Existem milhares de registros de importação MARC onde caracteres acentuados foram mutilados ou manipulados incorretamente. Outro cenário comum é que os acentos ou outras marcas diacríticas foram substituídos por um espaço antes ou depois da vogal.

Veja por exemplo:

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

Tanto no autor quanto no título, o trema foi alterado para um espaço após a vogal. O registro MARC vinculado é mostrado corretamente no navegador.

Devemos considerar a reimportação? E o nº 149, que também faz referência a https://bugs.launchpad.net/openlibrary/+bug/598204 , é uma dependência?

Alguns que encontrei recentemente: https://openlibrary.org/works/OL17670297W
https://openlibrary.org/works/OL17677126W
vários trabalhos deste autor:
https://openlibrary.org/authors/OL2450531A/Matthieu_Joseph_Bonaventure_Orfila

https://openlibrary.org/search?q=title%3A+%22 © ♭% 22 & mode = tudo Ainda encontra bem mais de 17 milhões de correspondências. Isso significa "é", provavelmente a letra acentuada mais comum. Edições como 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 não devem ser necessariamente manuais.

@hornc re seu comentário de 8 de maio, essas obras foram criadas a partir de edições criadas a partir de importação
https://openlibrary.org/show-records/ia : b28044277_0001
e
https://openlibrary.org/show-records/ia : b2202010x
Até que sejam fixados nos registros ia MARC, não há valor em reimportar, a menos que a importação os passe pela normalização

@LeadSongDog interessante, o display MARC ao qual você vincula mostra os caracteres distorcidos, mas se você clicar para a representação XML https://ia800202.us.archive.org/34/items/b28044277_0001/b28044277_0001_marc.xml o e acentuado será exibido corretamente . Pode haver um problema com os tipos de codificação configurados incorretamente? Pegarei isso em breve, o novo openlibrary-client está agora em um estado em que pode ser usado para fazer correções de dados em massa.

@LeadSongDog Eu posso ter descoberto como a mutilação está acontecendo, neste exemplo marc xml
https://ia600208.us.archive.org/25/items/b2202010x/b2202010x_marc.xml

o a-túmulo de "Secours à donner" é exibido corretamente na codificação utf-8

a-túmulo é U + 00E0, que em binário (notação pitônica) é \xC3\xA0

se esses bytes foram interpretados como MARC8 e "convertidos", C3 se torna o símbolo de copyright e 'A0' se torna um espaço, que é exatamente o que vemos nas páginas OL com "Secours © donner"

Agora acho que esses registros MARC têm codificações de caracteres utf-8, mas foram importados para OL como se fossem MARC8, o que explica a mutilação.

Fiz a conversão MARC8 manualmente a partir das tabelas encontradas aqui https://memory.loc.gov/diglib/codetables/45.html Vou precisar usar yaz ou algo assim para testar isso corretamente, mas isso fornecerá um bom caminho para corrigir os erros MARC de forma programática.

Eu sei que existem outros erros de unicode mutilados que afetam os registros importados da Amazon, mas acho que é devido à conversão incorreta de conjuntos de caracteres do Windows ou ISO

Obrigado pelo seu comentário @LeadSongDog , ao tentar descobrir se os registros MARC estavam realmente errados ou não, acho que descobri a causa raiz do problema!

@hornc alguma atualização sobre a

O problema definitivamente não foi resolvido. Quando o script de importação for corrigido, a sugestão de @bfalling de reimportação provavelmente será necessária.

Do ponto de vista da triagem, provavelmente seria útil obter uma contagem real. "Milhares" não é uma porcentagem muito grande de 25 milhões de edições.

Isso foi resolvido com nossas alterações no Python 3 ou alguém pode fornecer etapas para reproduzir no Python 3?

Bem, https://openlibrary.org/books/OL12903648M/Etudes_Conomiques_De_L 'Ocde certamente não foi consertado, mas talvez tenhamos terminado de cavar o buraco ...
Havia pelo menos três classes de problemas:

1. Importação ruim de dados bons
2. Importação literal de dados ruins
3. Dados inválidos de casos antigos de 1 ou 2 desde que corrigidos.
   A mudança para py3 corrigirá, no máximo, o número 1.

Etapas para reproduzir a classe de problema 1?

Os exemplos anteriores são melhores do que o mais recente, que é uma importação a partir de dados Amazon baixa qualidade (que não devem ser importados).
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_%Conna2%Conna2%CA

Se o bug foi corrigido, a reimportação dos registros deve resultar na codificação correta. Então, a tarefa se torna simplesmente reimportar os milhões de registros corrompidos.

A pesquisa que alegou retornar 17+ milhões de registros antes: https://openlibrary.org/search?q=title%3A+%22%C2%A9%E2%99%AD%22&mode=everything
agora retorna 23,4 milhões de resultados, mas acho que na verdade é um bug separado e está apenas retornando todos os trabalhos no banco de dados.

@tfmorris Como https://openlibrary.org/search?q=title%3A+%22+%22&mode=everything obtém o mesmo resultado, parece que sim, é um caso simples de busca de título para uma string efetivamente em branco.

Criei # 4223 para o bug de pesquisa.