@#382 y #367 se relacionan

El hilo de discusión relacionado está en http://www.mail-archive.com/[email protected]/msg00965.html

@mekarpeles ¿Te importaría comentar?

@LeadSongDog ¡ gracias por la etiqueta! Intentaré responder a esto tan pronto como termine de terminar una mejora de ImportBot (que con suerte traerá ~ 100k elementos legibles a Open Library). Probablemente este fin de semana. También envíe cc a @hornc en caso de que quiera opinar.

Gracias de nuevo @LeadSongDog. Están pasando muchas cosas en este hilo.

En respuesta a la lista de correo:
1) @bfalling y yo estamos presionando para unificar un poco las páginas de Trabajo y Edición. La estructura de URL aparecerá igual, pero según la experiencia del usuario, siempre estará en una página de trabajo con la capacidad de cambiar qué edición (y sus datos) está seleccionada/activa.
2) Creo que mantener los títulos de los trabajos en inglés es una idea práctica. ¿Algún pensamiento en contra? @hornc , @tfmorris , @dvanduzer?
3) Soy partidario de mantener los títulos de las ediciones en su idioma o codificación nativos

(editar: ¿Cuál es la funcionalidad oculta de "biblioteca" que a veces tiene el enlace a la traducción original?)

No creo que pueda haber una regla única para las traducciones. Lo más parecido a una respuesta "correcta" es probablemente la versión que se publicó primero. La literatura de la antigüedad es una importante excepción a esta regla. La mayoría de las traducciones alternativas de Homero, Platón o La Biblia incluyen suficiente erudición original como para que no quieras agruparlas todas en una sola obra.

Estrictamente hablando, no es necesario almacenar ninguna información de título en una Obra, porque una Obra ya es una chapuza. Siempre habrá una edición canónica, ya sea que estemos hablando de Cien Años de Soledad de García Márquez, o que estemos hablando de la cuarta (y más reciente) edición de Introducción al Cálculo. Tener un objeto de trabajo es una conveniencia para desarrollar la interfaz de usuario. (No tiene sentido tratar de captar la metafísica de si la tapa dura o la de bolsillo, o la copia de galera o la máquina de escribir del autor, o qué fragmentos de papiro contienen la esencia de la obra.) Otra forma de decirlo es que una Obra no no hace otra cosa que llevarnos de "una página" a "una página": cosificar un libro o un libro electrónico en un Libro.

Esto se vuelve más complicado porque no siempre está claro cuándo las relaciones como "traducción de" y "revisión de" son conmutativas y transitivas. Cosas como "audiolibro de" y "transcripción de" tienen relaciones unidireccionales aún más complicadas.

Entonces, para 2), es ciertamente práctico mantener la conveniencia de almacenar un título canónico bajo Work por ahora. Una lista de deseos para el futuro podría ser mostrar siempre el título según la configuración regional del usuario e incluir siempre el título en el idioma original, cuando sea diferente a la configuración regional del usuario.

Ciertamente, las obras derivadas a menudo son sustancialmente mejores que las originales, pero "autor" es, creo, claramente para el original. Los traductores, editores y otros colaboradores realmente no deberían confundirse. Supongo que identificar la primera edición publicada es una regla simple que podría automatizarse fácilmente. Observo que para las entradas que no están en inglés, PubMed almacena tanto el título en inglés (y otros metadatos) como el título vernáculo en el idioma original. Es un enfoque robusto aunque sujeto a variaciones en la anglicanización.

Intentando condensar mi comprensión de las discusiones sobre cómo se deben manejar las traducciones:

1. Las ediciones traducidas deben ser ediciones de la obra original.
2. Cualquier registro de trabajo traducido debe fusionarse con el trabajo original (es decir, convertirse en una redirección y todas las ediciones deben trasladarse al trabajo original)

Por lo tanto, el campo translation_of no es necesario. Solo un conjunto traducido correctamente(modo bibliotecario), e idealmente el rol de traductor.

Aquí hay un ejemplo que configuré que muestra Traductor en Colaboradores, y que la edición está escrita en inglés, traducida del griego antiguo. https://openlibrary.org/books/OL18836004M/La_Ilíada

En cuanto a que los títulos de las obras estén en inglés, creo que está bien por defecto, y estoy contento con, por ejemplo, que las obras clásicas en griego y latín usen los títulos comunes en inglés. De hecho, diría que los títulos en inglés serían más útiles en general que cualquier intento de un título griego original en alfabeto griego. Sin embargo, no creo que nadie deba necesariamente cambiar el título de una obra original en francés, ruso, tailandés o árabe a inglés como una cuestión de política. Creo que la regla debería ser que el título de una obra sea cualquier título comúnmente reconocido internacionalmente para esa obra. Si hay varios candidatos, ¿quizás necesitemos una sección de "Nombres alternativos" para los autores?

Propongo que eliminemos/ignoremos el campo translation_of y nos esforcemos por completar los campos is_translation correctamente.

Si alguien quiere llenar translation_of con OLID de trabajo temporalmente para ayudar a realizar fusiones, eso podría funcionar tal como está usando el campo de texto libre y ser útil. Aunque puede ser más fácil hacer las fusiones, una vez que hagamos la interfaz de fusión de trabajo.

No estoy de acuerdo con que un trabajo sea solo un error de interfaz de usuario. Tiene un montón de propiedades útiles. Odiaría ver a OpenLibrary descender por la pendiente resbaladiza de pensar que las obras son prescindibles.

No creo que solo en inglés sea apropiado para títulos de trabajo. Deben estar localizados. Las obras tienen diferentes nombres comunes en diferentes idiomas y OpenLibrary debería adaptarse a eso. Cada título localizado debe etiquetarse con su idioma y luego el código de representación puede elegir los respaldos apropiados para cada usuario, por ejemplo, inglés, luego francés, luego el resto de los idiomas romances, luego lo que tenga.

No entiendo la distinción entre translation_of y translated_from . Me suenan como sinónimos (¿o es una propiedad de Trabajo y la otra una propiedad de Edición?).

Ediciones en todos los idiomas conectados a la misma Obra es el camino correcto a seguir.

Freebase en realidad usó un objeto separado para capturar información de traducción. Además del vínculo Trabajo-Edición, también había una ruta Trabajo-Traducción-Edición donde el objeto Traducción contenía el idioma de origen, el idioma de destino, el traductor y la fecha de traducción. Puede inferir algo de esto a partir de los pares Obra/Edición, pero la gente a menudo habla de una traducción como algo específico y, a menudo, se publica en varias ediciones. No estoy diciendo que este sea necesariamente el camino correcto a seguir, pero lo estoy lanzando como otra alternativa de modelado.

Desde un punto de vista pragmático de disputa de datos, habría pensado que normalizar los títulos a NFC/NFKC primero haría que las comparaciones y el procesamiento posteriores fueran mucho más fáciles. http://unicode.org/reports/tr15/#Norm_Forms

Lo siento, la terminología no es muy clara, pero
translation_of es el título de una obra original
translation_from es un código de idioma

translation_of: La Ilíada
translated_from : grc (Griego antiguo (hasta 1453))

Después de criticar a Charles Perrault durante bastante tiempo, se hace evidente que la edición de "traducción de" y "idioma original" es un esfuerzo totalmente inútil. Lo que debería ocurrir en un sistema bien concebido es que el editor escoja una de una lista de obras del mismo autor. En este ejemplo tenemos cientos de ediciones y decenas de traducciones, pero pocas obras originales. Cuando varios registros de trabajo reflejen un solo trabajo, la lista debe mostrar la mayoría de las ediciones o la primera publicación (ignorando los registros sin fecha).
Aparte, también ha ejemplificado la necesidad de un mejor tratamiento de las obras recopiladas: las ediciones seleccionarán diferentes subconjuntos o incluso reunirán las historias de varios autores en colecciones. Algunas o seleccionadas pueden ser primeras publicaciones, como los cuentos de Mme d'Aubrey agrupados con sus Contes des fées en algunas ediciones.

@mekarpeles
Me parece que esto y
https://github.com/internetarchive/openlibrary/blob/7195f181742af7389843f275eefb2e675055b727/openlibrary/templates/books/edit/edition.html#L229 -242
probablemente debería adoptar un enfoque similar al de
https://github.com/internetarchive/openlibrary/blob/7195f181742af7389843f275eefb2e675055b727/openlibrary/templates/books/edit/edition.html#L169 -188

El título, otros títulos y la traducción de son formas de indicar una sola obra.

@cdrini Ese último fue trabajo tuyo, ¿no? ¿Te importa tomar esto también?

Tal vez la solución a esto sea hacer que se comporte como el campo "¿De qué obra es esta una edición?": permita la entrada de _ya sea_ el ID de la obra o el título vernáculo de la obra, luego busque el título asociado de la ID de la obra. Debe almacenar, indexar y mostrar tanto la identificación como el título vernáculo.
--Revisión: o simplemente elimine el campo y use el trabajo según lo previsto--

@seabelis ¿Tiene algo que agregar además de lo que ya se ha dicho?

También @hornc , ¿está dispuesto a ser el cesionario de este problema? Tenga en cuenta que ser el cesionario no significa necesariamente que sea responsable de hacer el trabajo, solo responsable de recopilar/proporcionar información para abordar el problema. De Wiki.

El propietario asignado no es necesariamente la persona que solucionará el problema (ni siquiera está necesariamente establecido, en ese momento, si el problema se solucionará o cuándo), sino que es la persona que hará tanto o como poco según sea necesario para manejar el problema (hacer preguntas, solicitar aportes, establecer y actualizar la prioridad, verificar si es un duplicado, etc.).

Una vez que un problema se etiqueta Estado: Trabajo en curso, el propietario es la persona que realiza el trabajo o que dirige/coordina el grupo que realiza el trabajo.

He agregado etiquetas por contexto: hágame saber sus pensamientos

Espero que esto pueda autocompletarse a partir del trabajo. Tal vez el trabajo necesite un campo de idioma, de lo contrario, se debe completar el idioma original para cada edición, lo que, en teoría, debería ser innecesario. Podría resultar complicado para las ediciones de varios trabajos, ya que no tenemos una estrategia sólida para administrarlas.

original_language en el trabajo sería una adición útil si aún no lo tenemos. Esto podría codificar implícitamente la información para la que @hornc propuso translated_from .

@LeadSongDog (o alguien más) ¿le importaría dar un resumen de cuál es la propuesta actual aquí? Tengo problemas para seguir cuál es el cambio deseado después de toda la discusión.

Tal vez la solución a esto sea hacer que se comporte como el campo "¿De qué obra es esta una edición?": permitir la entrada de la identificación de la obra o el título vernáculo de la obra, luego buscar el título asociado de la identificación de la obra. Debe almacenar, indexar y mostrar tanto la identificación como el título vernáculo.

Excepto por el hecho de que no muestra el título, así es como funciona el campo "¿De qué obra es esta una edición?"; ¿Eso significa que este problema está resuelto?

@cdrini Mi resumen del hilo (cualquier otra persona puede editar este comentario si me perdí algo).

Premable

Mientras escribía esto, me di cuenta de que es posible que este problema deba dividirse en varios problemas o convertirse en Epic

Problema original

Muchas traducciones son sus propias obras cuando en realidad deberían ser ediciones de la obra original de la que se traducen.

Actualmente hay un campo translation_of que acepta el texto libre del título de una obra y un campo translation_form que acepta un código de idioma (es decir grc para griego antiguo (hasta 1453)).

@LeadSongDog propuso hacer que translation_of acepte un olid de Obras para obligar a que las traducciones se asocien con una obra.

Números posteriores

1. A veces, la traducción se considera la "obra canónica" o varias traducciones diferentes se consideran la "obra canónica" en diferentes lugares. Es decir, muy pocos clientes querrían leer La Odisea en su griego antiguo original.

2. A veces, una novela cambiará de título cuando se publique en un país diferente. Ejemplo: la primera novela de Harry Potter se titula Harry Potter y la piedra filosofal en el Reino Unido, pero se titula Harry Potter y la piedra filosofal en los EE. UU. ¿Es esto una traducción?

3. A veces, las propias traducciones tendrán varias ediciones. ¡Eek!

Soluciones propuestas

• Combinar todas las obras traducidas en la obra original
  
  
  
  • Posteriormente, haga que translation_of requiera un id_obras/en la interfaz de usuario de edición que muestre obras a partir de texto libre y permita que el usuario elija una obra relevante.
  
  
• Los títulos de las obras deben estar localizados. De modo que la búsqueda de "Communauté de l'Anneau" debería producir una versión localizada de la página de obras de "The Fellowship of the Ring".
• Todos los trabajos deben tener campos original_language
• Introducir una nueva relación Trabajo-Traducción-Objeto similar a la implementación de Freebase

A veces, una novela cambiará de título cuando se publique en un país diferente. Ejemplo: la primera novela de Harry Potter se titula Harry Potter y la piedra filosofal en el Reino Unido, pero se titula Harry Potter y la piedra filosofal en los EE. UU. ¿Es esto una traducción?

No, no es una traducción. Sólo una decisión de marketing.

Una vez que las ediciones están correctamente vinculadas al trabajo original, la entrada "translation_of" parecería ser redundante. Muchos registros de edición están actualmente vinculados a ningún registro de trabajo, o al registro incorrecto, por lo que, mientras tanto, los datos allí tienen valor. Dicho esto, creo que mi sugerencia anterior fue mal considerada. El comentario de @seabelis tiene sentido: si lo mostramos, _debería_ completarse automáticamente a partir del registro de trabajo, pero ¿por qué tendríamos que decir lo mismo dos veces?

¿Deberíamos cerrar esto porque no se arreglará? Estoy de acuerdo en que almacenar el registro de trabajo dos veces parece redundante.

(Hay otros problemas abiertos para crear un flujo de fusión (n.º 805) y para asegurarse de que todas las ediciones tengan un trabajo (n.º 2629))

Si esto finalmente se resuelve indirectamente a través de otro problema, creo que cerrarlo está bien.

Creo que se resolverá indirectamente por los dos problemas anteriores.

@cdrini #805 y #2629 no abordan traducciones que tienen varias ediciones.

Por ejemplo, La Odisea de Homero tiene múltiples obras en diferentes idiomas. No creo que fusionar todas estas ediciones en un solo trabajo sea la mejor manera de manejar esto.

Creo que la forma más sólida de manejar esta situación es tener un objeto Translated Work que puede tener sus propias ediciones pero debe estar vinculado a un Original Work . Sin embargo, no estoy seguro de cuánto trabajo tomaría implementar esto.

Quizás la solución más fácil es permitir que las ediciones se busquen y filtren a través de una página de Works.

@guyjeangilles Si podemos abrir la puerta a un nuevo objeto en el esquema, debería ser útil para algo más que traducciones. Consideraría una respuesta más general como "based_on", que podría tomar una lista de identificadores de trabajo. De esa manera podría capturar antologías, compendios, obras recopiladas, adaptaciones, etc., no solo traducciones.

@LeadSongDog Si based_on es fácil de implementar, esto también permitiría filtrar los medios asociados de los resultados de búsqueda, como guías complementarias, notas de chispa y conjuntos de cajas. Ejemplo: https://openlibrary.org/search?q=the+hunger+games&mode=everything

Si seguimos estos estándares de catalogación (que he estado tratando de hacer), todas las traducciones pertenecerían a la obra original de una manera que no lo hacen las adaptaciones, los complementos, etc. https://www.isko.org/cyclo/work1.jpg

No estoy seguro de entender completamente lo que se entiende por ediciones de traducciones. El modelo OL Work-Edition realmente no distingue entre expresión y manifestación; todo esto se captura junto como 'edición'. Esto se aplica también a las 'ediciones' en el idioma original.

Dicho esto, veo beneficios en tener algo de separación. Esto es complicado y no solo se trata de la traducción (como se discutió extensamente la semana pasada) o de establecer la preferencia de idioma del usuario para el sitio. Por ejemplo, con frecuencia pondré un enlace al artículo de Wikipedia para un trabajo determinado. Usualmente enlazo al artículo en el idioma original del trabajo. Si el trabajo ha sido traducido a veinte idiomas, hay potencialmente 20 enlaces a Wikipedia solamente. No los agrego porque esto haría una lista muy larga. Tampoco agrego los enlaces a páginas de ediciones individuales porque un artículo de Wikipedia generalmente no es específico de la edición y no quiero agregar esto a varias ediciones. Esto también se aplica a otros tipos de enlaces, por ejemplo, reseñas de libros.

Si hubiera una forma de filtrar por idioma a nivel de trabajo, creo que esto sería útil para el usuario. Entonces, 1) mostrar solo ediciones en un idioma determinado y 2) mostrar contenido de nivel de trabajo en ese idioma. Esto debería ser independiente de cualquier preferencia de idioma del sitio, ya que muchas personas son multilingües y pueden tener su preferencia de contenido del sitio configurada en su idioma nativo pero estar alfabetizados en varios idiomas (aunque se tendría que establecer algún comportamiento predeterminado, tal vez el el usuario puede identificar su propia preferencia, es decir, una configuración para 'filtrar automáticamente las obras en mi configuración de idioma' / 'mostrar obras en su idioma nativo').

Si tener un objeto de trabajo traducido como sugiere @guyjeangilles lograría esto o algo así, estoy totalmente de acuerdo.
Relacionado con # 1808?

@cdrini resaltó esto porque no creo que el n.º 805 ni el n.º 2629 aborden las traducciones con múltiples ediciones. ¿Quizás deberíamos hacer un tema aparte?

Es posible que haya perdido la pista de algo de esto, ya que la discusión se ha hecho bastante larga, pero pensé que la decisión final era desaprobar translation_of y usar la relación de trabajo existente (que es cómo funciona el sistema actual, y hay han habido esfuerzos anteriores a escala para mover las traducciones bajo el trabajo correcto). Esto _deja_ las obras traducidas con varias ediciones sin vincular, lo que pensé que era un gran punto a tener en cuenta, pero parece que este es un problema estándar que también se acepta en otros lugares.

Creo que el sistema actual también puede admitir la separación de las traducciones en sus propias obras (la _Ilíada_ de A. Pope es mi ejemplo donde creo que estaría completamente justificado), pero parece que podríamos terminar con guerras de edición que terminan fusionando obras, y luego intentar separarlos porque es difícil trazar una línea clara en la que todos estén de acuerdo. "Todas las traducciones pertenecen a una sola obra" es más fácil de trabajar.

Ya mezclamos diferentes ediciones de diferentes editoriales bajo una misma obra, esto realmente no es tan diferente. Los problemas prácticos que afectan a los usuarios probablemente se resolverían si tuviéramos una forma decente de filtrar o localizar ediciones por idioma.

¿Se conservarán los datos existentes para obras que no hayan sido consolidadas?

2601 se refiere aquí.