Openlibrary: Intentar fusionar algunos autores falla

Hay muchos libros de notación musical de 2008 de AMZ para los que el isbn parece ser un callejón sin salida en OCLC, o incluso la autoría se atribuye erróneamente al editor en amz. Para algunos de estos, BWB puede encontrar una cobertura por isbn, pero parece tener los mismos metadatos basura. Necesitamos lanzar una red más amplia en otras bases de datos, o simplemente ponerlas en cuarentena de alguna manera y confiar en que los libros reales resurgirán.
Consulte al autor Isagani Intano para ver algunos ejemplos.

El autor del problema es
https://openlibrary.org/authors/OL4357202A/Ludwig_Van_Beethoven
que no se fusionará con el maestro OL127077A

Rastreando el posible elemento problemático:
OL11122403M
https://openlibrary.org/books/OL11122403M/Piano_Literature_of_the_17th_18th_and_19th_Centuries_Books_6B

A través de la interfaz de usuario, esto ni siquiera parece un elemento LVB ya que los datos de la interfaz de usuario del autor provienen del trabajo https://openlibrary.org/works/OL15097322W/Piano_Literature_of_the_17th_18th_and_19th_Centuries_Books_6B

Sin embargo, si observa el mosaico de portada en blanco de la edición, muestra una lista ampliada de autores, que proviene de los metadatos de la edición: https://openlibrary.org/books/OL11122403M.json que muestra una lista de autores ...

authors: [ { key: "/authors/OL47923A" }, { key: "/authors/OL4357202A" }, { key: "/authors/OL2779314A" }, { key: "/authors/OL126336A" }, { key: "/authors/OL3338683A" }, { key: "/authors/OL2779506A" }, { key: "/authors/OL38111A" }, { key: "/authors/OL3551619A" } ],

OL47923A es una redirección ... a Mozart https://openlibrary.org/authors/OL5017833A/Wolfgang_Amadeus_Mozart

Entonces, hay un par de problemas aquí:

1. Fusionar autores es tragar errores sin ninguna indicación de cuál es el problema o dónde está.
2. La interfaz de usuario de la página de edición oculta los autores enumerados específicamente en los metadatos de la edición, que a veces pueden diferir del trabajo.

y tal vez 3., un factor que contribuye a que esto sea aún más difícil de depurar: # 183

y 4. ¿Por qué los autores de la fusión incluso están rompiendo con esto? ¿Por qué no puede simplemente actualizar los autores de los elementos afectados y seguir adelante?

RESPUESTA: Creo que se relaciona con # 1445 donde los datos de algunos elementos pueden estar en un estado en el que sus autores son redireccionamientos, pero volver a guardar arroja un error. <<< esta parece ser la causa principal de varios de estos problemas de redireccionamiento.

un PR anterior que trató de lidiar con un problema similar: # 2186 Necesito investigar si esa solución debe aplicarse en otra ubicación, o si hay una brecha en la solución. De cualquier manera, falta algo.

la página de vista de los autores se está tragando el progreso de fusión del autor y los errores, y creo que este problema está ocurriendo en otras páginas que solían tener un mensaje de error flash.

Al depurar esto, veo que hay un mensaje div
https://github.com/internetarchive/openlibrary/blob/17cd1728e21a8dafd3dffcebc93dee9a534c37ec/openlibrary/templates/type/author/view.html#L92 -L118

que tiene el estilo class.hidden: display: none !important; en page-user.css

Hay scripts que intentan .fadeIn() esos sub-divs ocultos. Creo que el !important está impidiendo el desvanecimiento, pero cuando lo elimino, se vuelven visibles permanentemente.

@jdlrobson , ¿alguna idea o consejo? Estoy interesado en hacer que esto funcione para ordenar esta función de fusión de autores, ya que me bloquea y afecta a los bibliotecarios, pero tengo la sensación de que este problema hidden puede ser la causa de otro mensaje de error faltante también.

@hornc @jdlrobson Es muy probable que !important esté relacionado; vea el hilo a partir de https://github.com/internetarchive/openlibrary/pull/2223#issuecomment -513393435

Perdón por el dolor (de nuevo). El! Important se agregó en 0f9030c1047d5a337fc292a09085d7c353c85424.

El problema de no usar! Important, es si tiene

<div class="hidden button">foo</div>

y una regla de igual especificidad:

.button { display: inline-block; }

el botón no está realmente oculto contra las expectativas.

He estado tratando de movernos más en una dirección BEM para que estas reglas de especificidad se vuelvan más molestas.

El siguiente grep arroja 6 resultados:

removeClass('hidden');

y 4 para:

addClass('hidden');

En este caso reemplazando:

class="hidden"

con

style="display: none;"

trabajaría.

Otras cosas que podríamos probar:

.button[style] { display: block;}

(se supone que el atributo de estilo se elimina en una piel, lo que puede no ser el caso.

@cdrini Sé que tienes opiniones sobre esto, así que, ¿qué piensas?

@jdlrobson No estoy en desacuerdo con la lógica, no estoy de acuerdo con la ejecución: P display: none parece una buena solución (no la cosa style ). No me gusta cómo jugamos a whack-a-mole con errores en producción. Deberíamos 1) asegurarnos de que todas las clases hidden se cambien a display: none (ya que ese era el significado implícito antes de la confirmación hace 6 meses; esto debería hacerse manualmente), o 2) elimine !important y haga (1) más tarde. No me gusta que estemos en este estado intermedio en el que hemos cambiado el significado de la clase hidden sin verificar qué dependía de ello.

Sí, me equivoqué con la ejecución hace 6 meses :( 321d120 parece la solución aquí entonces, siempre que se pueda probar y funcione.

Con suerte, el golpe de un topo se apagará. Me encantaría no hacer eso, pero sin saber de manera confiable qué plantillas son abandonware y cuáles aún están activas, y el hecho de que el JS está lleno de plantillas y JS, la tarea es un poco abrumadora y desmoralizante (he gastado 30 minutos tratando de verificar los flujos de trabajo sin hacer ningún progreso y ahora me siento triste), así que creo que este es el mejor enfoque por el momento. Es fácil y rápido de solucionar una vez que se identifica el problema y, como factor que rompe estas cosas, etiquétame cuando las veas.

Se han agregado dos ejemplos más de combinaciones sugeridas por Wikidata. Puedo confirmar que el problema cosmético del mensaje de error oculto se solucionó y que el mensaje de error de fusión se muestra correctamente al usuario, pero los datos subyacentes y / o los problemas de fusión aún persisten.

Aunque se muestra el error "Arg. Eso no funcionó", faltan detalles (importantes) del error. En el caso de DS Margoliouth, señalan el registro exacto con el que no está contento:

{'message': 'expected /type/author, found /type/redirect', 'at': {'property': 'authors', 'key': '/books/OL20457133M'}, 'value': '/authors/OL5989450A', 'error': 'bad_data'}

Dado que básicamente ignoramos a los autores de la edición (y probablemente no nos importe si es un autor conflictivo / incorrecto siempre que no sea una redirección), hacer que esto provoque un error en la fusión de un autor me parece un poco tonto.

Deberíamos:

• corrija silenciosamente el error y actualice el registro con el objetivo de redireccionamiento, o
• ignorar a los autores de la edición por completo

Como nota al margen, cuando el mensaje de error dice "Lo hemos anotado", suena como si estuviera registrado en algún lugar donde alguien lo notará y lo arreglará. ¿Se registra? ¿Alguien revisa el registro?

Otro caso de falla: https://openlibrary.org/authors/merge?key=OL134502A&key=OL4675154A&key=OL6002146A

El error para la fusión de @ Camillo-Pellizzari fue:

{'message': 'expected /type/author, found /type/delete', 'at': {'property': 'authors', 'key': '/books/OL20496191M'}, 'value': '/authors/OL6036269A', 'error': 'bad_data'}

El registro de autor fue eliminado por CleanupBot de @hornc en 2017 porque no se usó en ninguna obra, pero aún se usó en este registro de edición. Ahora, debido a que no hay forma de editar los autores de la edición, esto no se puede limpiar sin la ayuda de un programador.

Otro caso: https://openlibrary.org/authors/merge?key=OL17370A&key=OL2677210A

Ese ejemplo tiene un solo trabajo atribuido incorrectamente al OL2677210A Carl Jung: "The Workbook" es un directorio de arte comercial de 3 volúmenes, de los cuales "Portfolio" es el volumen 2. Es bueno que el autor haya cometido un error, aunque cómo sucedió es ( demasiado) oscuro.

No se pueden combinar estos:
https://openlibrary.org/authors/OL134502A/Gaius
https://openlibrary.org/authors/OL4675154A/Gaius

@seabelis
¡Ay! Eso es 59 registros de trabajo y dos registros de autor para un trabajo de varios volúmenes con varias ediciones, comentarios y traducciones. Realmente necesitamos una wiki sobre la mejor manera de estructurar tales cosas, pero esa es una discusión separada. Mientras tanto, he cambiado manualmente todos los registros de trabajo de este último para vincular el registro del autor anterior.

Gracias por hacer eso. Un usuario envió esto, así que ni siquiera me había dado cuenta de las obras.

He fusionado los dos registros de autor de Gaius, pero creo que hay un tercero que también debería fusionarse, pero tiene un error en la fusión: https://openlibrary.org/authors/OL6002146A/Gaius

Incluso después de mover todos los trabajos de OL6002146A a OL134502A, https://openlibrary.org/authors/OL134502A/Gaius?merge=true&duplicates=OL6002146A siguen teniendo errores y no se crea la redirección. Extraño....

No puede fusionar https://openlibrary.org/authors/OL735423A/Michel_Jean_Sedaine con https://openlibrary.org/authors/OL6011794A/Sedaine

No es posible fusionar https://openlibrary.org/authors/merge?key=OL4789371A&key=OL6011897A

Nuevamente: no se puede fusionar https://openlibrary.org/authors/merge?key=OL357738A&key=OL5999368A

Nuevamente: no se puede fusionar https://openlibrary.org/authors/merge?key=OL4277168A&key=OL6039003A

Nuevamente: no se puede fusionar https://openlibrary.org/authors/merge?key=OL2557977A&key=OL5998002A

Nuevamente: no se puede fusionar https://openlibrary.org/authors/merge?key=OL133119A&key=OL6011208A

Nuevamente: no se puede fusionar https://openlibrary.org/authors/merge?key=OL1271659A&key=OL5996409A

Mmmm, parece que todos los registros de autor del problema fueron creados por Import Bot el 27 de octubre de 2008. Otras rarezas que podrían ser pistas: incluyen un campo "id =" obsoleto que se elimina mediante cualquier edición directa de ese registro de autor, pero aún así no se pueden fusionar, así que ese no es el problema. El espacio final después del nombre del autor puede ser un factor, o el campo "nombre personal =" que se ve en algunos casos.

Suspiro, esa lista se está haciendo larga :( Gracias @ Camillo-Pellizzari; agregue a la lista.

Esto también falla: https://openlibrary.org/authors/merge?key=OL80534A&key=OL2693344A

Nuevamente: https://openlibrary.org/authors/merge?key=OL17370A&key=OL2677210A

+: https://openlibrary.org/authors/merge?key=OL125439A&key=OL2628479A

Agregado: +1:

Tenga en cuenta que esto probablemente se solucionará en https://github.com/internetarchive/openlibrary/issues/2553

Nuevamente: https://openlibrary.org/authors/merge?key=OL981833A&key=OL6003522A

@ Camillo-Pellizzari
Esto huele como un legado más de nuestros diacríticos destrozados. Me las arreglé para fusionar la mayoría de los registros de autor redundantes con Émile Egger en https://openlibrary.org/authors/OL4557532A/ pero el último registro en https://openlibrary.org/authors/OL6003522A es terco.

Nuevamente: https://openlibrary.org/authors/merge?key=OL4743941A&key=OL4016098A

Otro caso: https://openlibrary.org/authors/merge?key=OL412435A&key=OL5239874A

@ Camillo-Pellizzari
¡¡¡¡Una pista!!!!
Moví las 16 obras de Mayhew al registro de autor principal manualmente, pero persiste un registro de edición huérfana, quizás en caché. Los autores aún no se fusionarán. Esa edición tiene la ruta de pseudotrabajo mal formada https://openlibrary.org/works/OL20459197M con el antiguo autor identificado en el registro de edición, en conflicto con el autor correcto que se muestra en el registro de trabajo https://openlibrary.org/works/OL2788965W .
No hay forma de saber cuál de estas rarezas es la causa del error de fusión, pero si un administrador puede modificarlo, podría ser instructivo:

{"publishers": ["Chatto & Windus"], "clasifications": {}, "subtitle": "ilustraciones del humor, patetismo y peculiaridades de la vida londinense", "title": "personajes londinenses", "notas ":" 1e uitg. (1874) met de aanduiding \ "Por Henry Mayhew y otros escritores \" (Vgl. Toole-Stott, no. 491.). "," Identificadores ": {}," ocaid ":" londoncharacter00gilbgoog "," cubre ": [9182853]," creado ": {" tipo ":" / tipo / fecha y hora "," valor ":" 2008-10-27T03: 19: 48.641147 "}," idiomas ": [{" key ":" / languages ​​/ eng "}]," last_modified ": {" type ":" / type / datetime "," value ":" 2019-12-11T23: 49: 48.914594 "}," latest_revision ": 8 , "clave": "/ libros / OL20459197M", "autores": [{"clave": "/ autores / OL5239874A" }, {"clave": "/ autores / OL1331553A"}], "fecha de publicación": "1881 "," publish_places ": [" London "]," works ": [{" key ":" / works / OL2788965W "}]," type ": {" key ":" / type / edition "}," oclc_numbers ": [" 67342886 "]," revisión ": 8}

Otro caso: https://openlibrary.org/authors/merge?key=OL2629727A&key=OL68455A

Investigaré este cuando tenga tiempo de escribir un código para hacerlo automáticamente: https://openlibrary.org/authors/OL4280920A/Federico_Garc%C3%ADa_Lorca?merge=true&duplicates=OL6887222A , OL4122786A, OL3973784A, OL6250916A, OL6404110A , OL3210186A, OL7313848A, OL7306164A, OL7327570A, OL7386673A, OL7392312A, OL7416035A, OL7687411A

• https://openlibrary.org/authors/merge?key=OL6090558A&key=OL6002080A

@seabelis Encontró otro https://openlibrary.org/authors/merge?key=OL4586796A&key=OL3206959A

Todas las ediciones enumeran dos autores, OL2629754A y OL3206959A, el primero de los cuales es una redirección .

Por supuesto, los autores de la edición no se pueden editar, por lo que esto no se puede solucionar. Pensé que podría hackearlo editando el YAML https://openlibrary.org/books/OL13263866M.yml?m=edit pero no tuve tanta suerte - Permiso denegado.

Pude eliminar a los autores de la edición vinculada. https://openlibrary.org/books/OL13263866M/Relato_de_un_n%C3%A1ufrago?_compare=Compare&b=6&a=5&m=diff

Creo recordar de otra conversación que no se prefiere eliminar a los autores de las ediciones. Pensé que podría borrar los autores de la edición y luego volver a aplicar el autor válido, pero esto arroja un error,
AttributeError: 'str' object has no attribute 'olid'

Creo recordar de otra conversación que no se prefiere eliminar a los autores de las ediciones.

Esa no es mi opinión. Como no se pueden editar y no se sincronizan automáticamente, creo que son más problemáticos de los que valen la pena.

Pude eliminar a los autores de la edición vinculada. https://openlibrary.org/books/OL13263866M/Relato_de_un_n%C3%A1ufrago?_compare=Compare&b=6&a=5&m=diff

¿Pudiste hacer eso a través de la interfaz de usuario web o usaste una de las API?

@tfmorris openlibrary-client a través del cuaderno colaborativo @cdrini me ayudó a configurar. Reemplacé los autores de la edición con un objeto vacío; es la misma forma en que eliminé contribuyentes anteriormente cuando la interfaz de usuario no cooperaba. No estoy seguro de que sea la mejor forma, pero me permitió editar el trabajo sin el error anterior.

Otro para agregar a la lista. https://openlibrary.org/authors/merge?key=OL4435020A&key=OL7214197A&key=OL7622813A

Revisé y resolví todos los problemas de datos mencionados anteriormente y realicé las fusiones (algunas funcionaron sin más cambios, deben haberse resuelto en otro lugar).

Los errores exactos para cada combinación son visibles en el resultado HTTP 400 de merge.json que se puede ver en una consola de herramientas de desarrollo del navegador, por ejemplo:

{'message': 'expected /type/author, found /type/redirect', 'at': {'property': 'authors', 'key': '/books/OL13263870M'}, 'value': '/authors/OL2629754A', 'error': 'bad_data'}

Estos mensajes solían aparecer en la página de resultados de la combinación para al menos señalar la edición del problema. Ahora no lo hacen.

Gracias, @hornc .