@#382 и #367 связаны

Соответствующая ветка обсуждения находится по адресу http://www.mail-archive.com/[email protected]/msg00965.html.

@mekarpeles Хотите прокомментировать?

@LeadSongDog спасибо за тег! Я постараюсь ответить на это, как только закончу улучшение ImportBot (которое, надеюсь, добавит около 100 000 читаемых элементов в Open Library). Скорее всего в эти выходные. cc'ing @hornc также на случай, если он захочет взвесить.

Еще раз спасибо @LeadSongDog. В этой теме много чего происходит.

В ответ на список рассылки:
1) @bfalling и я стремимся к некоторому объединению страниц Work и Edition. Структура URL-адреса будет такой же, но, по опыту пользователя, они всегда будут на рабочей странице с возможностью изменить выбранное/активное издание (и его данные).
2) Я думаю, что сохранение названий работ на английском языке — это практическая идея. Есть мысли против? @hornc , @tfmorris , @dvanduzer?
3) Я неравнодушен к сохранению названий Edition на их родном языке/в кодировке.

(редактировать: что такое скрытая «библиотекарская» функциональность, которая иногда имеет ссылку на исходный перевод?)

Я не думаю, что может быть универсальное правило для переводов. Ближе всего к «правильному» ответу, вероятно, та версия, которая была опубликована первой. Литература древности является важным исключением из этого правила. Большинство альтернативных переводов Гомера, Платона или Библии содержат достаточно оригинальной учености, поэтому вам не захочется объединять их все в одну работу.

Строго говоря, в Работе нет необходимости хранить какую -либо информацию о названии, потому что Работа уже является кладжем. Всегда будет каноническое издание, говорим ли мы о Cien Años de Soledad Гарсиа Маркеса или говорим о четвертом (и самом последнем) издании Intro to Calculus. Наличие объекта Work удобно для разработки пользовательского интерфейса. (Нет смысла пытаться уловить метафизику того, в твердой или мягкой обложке, в гранке или на пишущей машинке автора, или в том, какие фрагменты папируса содержат суть произведения.) Другой способ выразить это состоит в том, что Произведение не не делать ничего, кроме как перевести нас со «страницы» на «одну страницу» — материализовать книгу или электронную книгу в Книгу.

Это становится более сложным, потому что не всегда ясно, когда такие отношения, как «перевод» и «пересмотр», являются коммутативными и транзитивными. Такие вещи, как «аудиокнига» и «транскрипция», имеют еще более сложные односторонние отношения.

Итак, для 2), безусловно, целесообразно пока сохранить удобство хранения канонического названия в разделе «Работа». Список пожеланий на будущее может заключаться в том, чтобы всегда отображать заголовок на основе языкового стандарта пользователя и всегда включать заголовок на исходном языке, если он отличается от языкового стандарта пользователя.

Безусловно, производные работы часто существенно лучше оригинала, но "автор", я думаю, явно за оригинал. Переводчиков, редакторов и других участников действительно не следует смешивать. Я полагаю, что идентификация первого опубликованного издания — это простое правило, которое можно легко автоматизировать. Я отмечаю, что для записей не на английском языке PubMed хранит как английское название (и другие метаданные), так и название на языке оригинала. Это надежный подход, хотя и подверженный вариациям в англизировании.

Попытка сжать мое понимание дискуссий о том, как следует обрабатывать переводы:

1. Переведенные издания должны быть изданиями оригинальной работы.
2. Любая переведенная рабочая запись должна быть объединена с оригинальной работой (т. е. превращена в перенаправление и все редакции перемещены в исходную работу).

Следовательно, поле translation_of не нужно? Просто правильно установленное translation_from(Режим библиотекаря) и, в идеале, роль переводчика.

Вот пример, который я настроил, показывающий Translator в разделе Contributors, и что издание написано на английском языке, переведено с древнегреческого. https://openlibrary.org/books/OL18836004M/The_Iliad

Что касается названий работ на английском языке, я думаю, что это нормально по умолчанию, и я доволен, скажем, классическими греческими и латинскими работами, использующими распространенные английские названия. На самом деле я бы сказал, что английские заголовки были бы более полезны, чем любая попытка оригинального греческого названия в греческом алфавите. Тем не менее, я не думаю, что кто-то обязательно должен менять оригинальное название работы на французском, русском, тайском или арабском языке на английское из соображений политики. Я думаю, правило должно заключаться в том, что название работы — это общепризнанное название этой работы во всем мире. Если кандидатов несколько, может быть, нужен раздел "Альтернативные названия" как для авторов?

Я предлагаю удалить/игнорировать поле translation_of и постараться правильно заполнить поля is_translation .

Если кто-то хочет временно заполнить translation_of рабочими OLID, чтобы помочь с выполнением слияний, это может на самом деле работать так же, как использование поля произвольного текста, и быть полезным. Хотя может быть проще делать слияния, как только мы создадим рабочий интерфейс слияния.

Я не согласен с тем, что работа — это просто кладж пользовательского интерфейса. У него куча полезных свойств. Я бы не хотел, чтобы OpenLibrary скатилась по скользкой дорожке, думая, что работа невозможна.

Я не думаю, что только английский язык подходит для рабочих названий. Они должны быть локализованы. Работы имеют разные общепринятые названия на разных языках, и OpenLibrary должна учитывать это. Каждое локализованное название должно быть помечено своим языком, а затем код рендеринга может выбрать подходящие запасные варианты для каждого пользователя, например, английский, затем французский, затем остальные романские языки, а затем все, что у вас есть.

Я не понимаю разницы между translation_of и translated_from . Для меня они звучат как синонимы (или одно свойство Work, а другое свойство Edition?).

Издания на всех языках, связанные с одним и тем же произведением, — правильный путь.

Freebase фактически использовала отдельный объект для сбора информации о переводе. В дополнение к ссылке Work-Edition был также путь Work-Translation-Edition, где объект «Перевод» содержал исходный язык, целевой язык, переводчик и дату перевода. Вы можете сделать некоторые выводы из пар «Работа/Издание», но люди часто говорят о переводе как о чем-то конкретном, и он часто публикуется в нескольких изданиях. Я не говорю, что это обязательно правильный путь, но выбрасываю его как еще одну альтернативу моделированию.

С прагматичной точки зрения обработки данных я полагал, что нормализация заголовков в NFC/NFKC в первую очередь облегчит последующие сравнения и обработку. http://unicode.org/reports/tr15/#Norm_Forms

Извините, терминология не очень понятна, но
translation_of — оригинальное название произведения.
translation_from — код языка

translation_of: Илиада
translated_from : grc (древнегреческий (до 1453 г.))

После продолжительной критики Шарля Перро стало очевидно, что редактирование «перевода» и «оригинального языка» — совершенно напрасная работа. Что должно происходить в хорошо продуманной системе, так это то, что редактор выбирает одну из работ одного и того же автора. В этом примере у нас есть сотни изданий и десятки переводов, но мало оригинальных работ. Если несколько рабочих записей отражают одну работу, в списке должны быть указаны либо наиболее изданные, либо впервые опубликованные (игнорируя недатированные записи).
Кроме того, это также продемонстрировало необходимость лучшего обращения с собраниями произведений: издания будут выбирать разные подмножества или даже собирать рассказы разных авторов в сборники. Некоторые или избранные могут быть первыми публикациями, как, например, сказки мадам д'Обри, которые в некоторых изданиях объединены с его Contes des fées.

@mekarpeles
Мне кажется, что это и
https://github.com/internetarchive/openlibrary/blob/7195f181742af7389843f275eefb2e675055b727/openlibrary/templates/books/edit/edition.html#L229-242
скорее всего, следует применить подход, аналогичный тому, который применялся в
https://github.com/internetarchive/openlibrary/blob/7195f181742af7389843f275eefb2e675055b727/openlibrary/templates/books/edit/edition.html#L169 -188

Заглавие, другие заглавия и перевод — все это способы обозначения одного произведения.

@cdrini Это была твоя последняя работа, не так ли? Хочешь взять и этот бит тоже?

Возможно, решение этой проблемы состоит в том, чтобы заставить это вести себя как поле «Издание какой работы»: разрешить ввод _либо_ идентификатора работы, либо народного названия работы, а затем найти название, связанное с идентификатором работы. Он должен хранить, индексировать и отображать как идентификатор, так и название на местном языке.
--Пересмотр: или просто удалите поле и используйте работу по назначению--

@seabelis У вас есть что добавить к тому, что уже было сказано?

Кроме того, @hornc , вы готовы быть уполномоченным по этому вопросу? Обратите внимание: быть правопреемником не обязательно означает, что вы несете ответственность за выполнение работы, а просто отвечаете за сбор/предоставление информации для решения проблемы. Из Вики.

Назначенный владелец не обязательно является лицом, которое решит проблему (в этот момент даже не обязательно устанавливается, будет ли и когда проблема будет устранена вообще), а скорее это лицо, которое будет делать столько же или сколько меньше, чем необходимо для решения проблемы (задавать вопросы, запрашивать информацию, устанавливать и обновлять приоритет, проверять, не является ли это дубликатом и т. д.).

Как только проблема помечена как «Состояние: Работа в процессе», владельцем становится лицо, выполняющее работу, или руководящее/координирующее группу, выполняющую работу.

Я добавил ярлыки в зависимости от контекста: дайте мне знать, что вы думаете

Я ожидаю, что это может быть автоматически заполнено из работы. Возможно, в работе нужно языковое поле, иначе нужно заполнять исходный язык для каждого издания, что, по идее, должно быть ненужным. Потенциально это может привести к беспорядку для изданий с несколькими работами, поскольку у нас нет надежной стратегии для управления ими.

original_language на работе было бы полезным дополнением, если у нас его еще нет. Это может неявно кодировать информацию, для которой @hornc предложил translated_from .

@LeadSongDog (или кто-то еще), не могли бы вы кратко изложить текущее предложение? У меня возникли проблемы с пониманием желаемого изменения после всего обсуждения.

Возможно, решение этой проблемы состоит в том, чтобы заставить это вести себя как поле «Издание какой работы»: разрешить ввод либо идентификатора работы, либо народного названия работы, а затем найти название, связанное с идентификатором работы. Он должен хранить, индексировать и отображать как идентификатор, так и название на местном языке.

За исключением того факта, что он не отображает название, именно так функционирует поле «Что это за произведение?»; значит эта проблема решена?

@cdrini Мое резюме темы (кто-нибудь еще может редактировать этот комментарий, если я что-то пропустил).

предварительный

Когда я набрал это, я понял, что эту проблему, возможно, нужно разбить на несколько проблем или сделать Epic

Оригинальный выпуск

Многие переводы являются их собственными произведениями, тогда как на самом деле они должны быть изданиями оригинального произведения, с которого они переведены.

В настоящее время существует поле translation_of , которое принимает произвольный текст названия произведения, и поле translation_form , которое принимает код языка (например, grc для древнегреческого языка (до 1453 г.)).

@LeadSongDog предложил заставить translation_of принимать olid Works, чтобы заставить переводы ассоциироваться с произведением.

Последующие выпуски

1. Иногда перевод считается «каноническим произведением» или несколько разных переводов считаются «каноническим произведением» в разных регионах. Т.е. очень немногие посетители захотят читать «Одиссею» в ее древнегреческом оригинале.

2. Иногда роман меняет название при публикации в другой стране. Пример: первый роман о Гарри Поттере называется « Гарри Поттер и философский камень» в Великобритании, а в США — « Гарри Поттер и философский камень» . Это перевод?

3. Иногда сами переводы будут иметь несколько изданий. Эй!

Предлагаемые решения

• Объединить все переведенные работы в оригинальную работу
  
  
  
  • Затем заставьте translation_of требовать work_olid/в пользовательском интерфейсе редактирования отображать работы из произвольного текста и позволять пользователю выбирать соответствующую работу.
  
  
• Названия работ должны быть локализованы. Таким образом, поиск «Communauté de l'Anneau» должен привести к локализованной версии страницы произведений «Братство Кольца».
• Все работы должны иметь поля original_language
• Внедрить новую связь Work-Translation-Object, аналогичную реализации Freebase.

Иногда роман меняет название при публикации в другой стране. Пример: первый роман о Гарри Поттере называется «Гарри Поттер и философский камень» в Великобритании, а в США — «Гарри Поттер и философский камень». Это перевод?

Нет, не перевод. Просто маркетинговое решение.

После того, как издания будут правильно связаны с оригинальной работой, запись «translation_of» будет казаться избыточной. Многие записи об издании в настоящее время не связаны ни с одной рабочей записью или с неправильной, так что в промежутке времени имеющиеся данные имеют ценность. Тем не менее, я считаю, что мое предыдущее предложение было необдуманным. Комментарий @seabelis имеет смысл: если мы его вообще показываем, он _должен_ автоматически заполняться из рабочей записи, но зачем нам повторять одно и то же дважды?

Должны ли мы закрыть это, поскольку это не будет исправлено? Я согласен, что сохранение трудовой книжки дважды кажется излишним.

(Есть и другие проблемы, связанные с созданием потока слияния (#805) и обеспечением работоспособности всех редакций (#2629))

Если это в конечном итоге будет решено косвенно через другую проблему, я думаю, что закрыть ее можно.

Я думаю, что это будет косвенно решено двумя вышеперечисленными проблемами.

@cdrini #805 и #2629 не относятся к переводам, имеющим несколько редакций.

Например, в «Одиссее» Гомера есть несколько произведений на разных языках. Я не думаю, что объединение всех этих изданий в одну работу — лучший способ справиться с этим.

Я думаю, что самый надежный способ справиться с этой ситуацией — это иметь объект Translated Work , который может иметь свои собственные версии, но должен быть связан с Original Work . Я не уверен, сколько работы потребуется, чтобы реализовать это.

Возможно, самое простое решение — разрешить поиск и фильтрацию выпусков на странице Works.

@guyjeangilles Если мы сможем открыть дверь для нового объекта в схеме, это должно быть полезно не только для переводов. Я бы рассмотрел более общий ответ, такой как «основанный на», который может принимать список идентификаторов работы. Таким образом, он мог бы захватывать антологии, сборники, собрания сочинений, адаптации и т. д., а не только переводы.

@LeadSongDog Если based_on легко реализовать, это также позволит отфильтровать связанные мультимедиа из результатов поиска, таких как сопутствующие руководства, искровые заметки и наборы коробок. Пример: https://openlibrary.org/search?q=the+hunger+games&mode=everything

Если мы будем следовать этим стандартам каталогизации (что я и пытался сделать), все переводы будут принадлежать оригинальному произведению в отличие от адаптаций, компаньонов и т. д. https://www.isko.org/cyclo/work1.jpg

Я не уверен, что полностью понимаю, что имеется в виду под изданиями переводов. Модель OL Work-Edition на самом деле не различает выражение и воплощение; все это вместе взято как «издание». Это относится и к «изданиям» на языке оригинала.

Тем не менее, я вижу преимущества в некотором разделении. Это сложно, и дело не только в переводе (как подробно обсуждалось на прошлой неделе) или в настройке языковых предпочтений пользователя для сайта. Например, я часто буду ссылаться на статью в Википедии для данной работы. Я обычно ссылаюсь на статью на языке оригинала. Если работа была переведена на двадцать языков, то только на Википедию потенциально может быть 20 ссылок. Я не добавляю их, потому что это сделало бы очень длинный список. Я также не добавляю ссылки на страницы отдельных изданий, потому что статья в Википедии, как правило, не привязана к конкретному изданию, и я не хочу добавлять ее в несколько изданий. Это относится и к другим типам ссылок, например, к отзывам о книгах.

Если бы был способ фильтрации по языку на рабочем уровне, я думаю, это было бы полезно для пользователя. Итак, 1) отображать только выпуски на заданном языке и 2) отображать контент рабочего уровня на этом языке. Это должно быть независимо от каких-либо языковых предпочтений сайта, так как многие люди говорят на нескольких языках и могут иметь настройки содержимого своего сайта на своем родном языке, но быть грамотными на нескольких языках (хотя необходимо будет установить какое-то поведение по умолчанию — возможно, пользователь может указать свои собственные предпочтения, например, настройку «автоматическая фильтрация работ в соответствии с настройками моего языка» / «показывать работы на их родном языке»).

Если наличие объекта «Переведенная работа», как предлагает @guyjeangilles , позволит достичь этого или чего-то подобного, я полностью за это.
Связано с № 1808?

@cdrini натыкается на это, поскольку я не думаю, что # 805 или # 2629 будут касаться переводов с несколькими изданиями. Может, стоит сделать отдельную тему?

Возможно, я что-то упустил из виду, так как дискуссия затянулась, но я подумал, что окончательное решение состоит в том, чтобы отказаться от поддержки translation_of и использовать существующие рабочие отношения (именно так работает текущая система, и там предпринимались прошлые масштабные попытки перевести переводы под правильную работу). Это _оставляет_ переведенные работы с несколькими изданиями несвязанными, что, как мне кажется, было важным отметить, но похоже, что это стандартная проблема, которая просто принята и в других местах?

Я думаю, что текущая система также может поддерживать разделение переводов на их собственные произведения (мой пример — «Иллиада» А. Поупа, где я думаю, что это было бы полностью оправдано), но, похоже, мы могли бы закончить войнами редактирования, которые заканчиваются объединением произведений, а затем попыткой разделить их, потому что трудно провести четкую грань, с которой все согласны. «Все переводы принадлежат одной работе» легче работать.

Мы уже смешиваем разные издания от разных издательств под одной и той же работой, это на самом деле не так уж и отличается. Практические проблемы, влияющие на пользователей, вероятно, были бы решены, если бы у нас был достойный способ фильтрации или поиска выпусков по языку.

Будут ли сохранены существующие данные для работ, которые не были консолидированы?

2601 относится сюда.