Openlibrary: Попытка объединить некоторых авторов не удалась

Есть много книг с нотной записью от AMZ 2008 года, для которых isbn кажется тупиком в OCLC, или даже авторство неправильно приписывается издателю amz. Для некоторых из них BWB может найти обложку от isbn, но, похоже, у нее такие же дерьмовые метаданные. Нам нужно либо расширить сеть в других базах данных, либо просто как-то изолировать их и верить, что настоящие книги появятся снова.
См. Несколько примеров у автора Исагани Интано.

Автор задачи
https://openlibrary.org/authors/OL4357202A/Ludwig_Van_Beethoven
который не сольется в мастер OL127077A

Отслеживание вероятного проблемного элемента:
OL11122403M
https://openlibrary.org/books/OL11122403M/Piano_Literature_of_the_17th_18th_and_19th_Centuries_Books_6B

Через пользовательский интерфейс это даже не похоже на элемент LVB, поскольку данные пользовательского интерфейса автора поступают из работы https://openlibrary.org/works/OL15097322W/Piano_Literature_of_the_17th_18th_and_19th_Centuries_Books_6B

Однако, если вы посмотрите на пустую плитку обложки издания, то увидите расширенный список авторов, взятый из метаданных издания: https://openlibrary.org/books/OL11122403M.json, где показан список авторов ...

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 - это перенаправление ... на Моцарта https://openlibrary.org/authors/OL5017833A/Wolfgang_Amadeus_Mozart

Итак, здесь есть пара проблем:

1. Авторы слияния проглатывают ошибки без какого-либо указания на то, в чем или где проблема.
2. Пользовательский интерфейс страницы издания скрывает авторов, указанных в метаданных издания, которые иногда могут отличаться от работы.

и, возможно, 3., что усложняет отладку: # 183

и 4. Почему авторы слияния вообще нарушают это? Почему нельзя просто обновить авторов затронутых элементов и продолжить работу?

ОТВЕТ: Я думаю, это относится к № 1445, где данные некоторых элементов могут находиться в состоянии, когда их авторы являются перенаправленными, но повторное сохранение вызывает ошибку. <<< похоже, это основная причина ряда проблем с перенаправлением.

предыдущий PR, который пытался справиться с подобной проблемой: # 2186 Мне нужно выяснить, нужно ли это исправление применить в другом месте, или в исправлении есть пробел. В любом случае чего-то не хватает.

страница просмотра авторов поглощает прогресс слияния авторов и ошибки, и я думаю, что эта проблема возникает на других страницах, которые раньше имели сообщение об ошибке flash msg.

Отлаживая это, я вижу, что есть сообщение div
https://github.com/internetarchive/openlibrary/blob/17cd1728e21a8dafd3dffcebc93dee9a534c37ec/openlibrary/templates/type/author/view.html#L92 -L118

который имеет стиль class.hidden: display: none !important; в page-user.css

Существуют сценарии, которые пытаются .fadeIn() скрыть вложенные блоки. Я _ думаю_ !important предотвращает затухание, но когда я удаляю его, они становятся постоянно видимыми.

@jdlrobson , есть идеи или советы? Я заинтересован в том, чтобы это работало, чтобы привести в порядок эту функцию слияния авторов, поскольку она блокирует меня и влияет на библиотекарей, но я чувствую, что эта проблема hidden может быть причиной другого отсутствующего сообщения об ошибке.

@hornc @jdlrobson !important очень вероятно связано; см. ветку, начинающуюся с https://github.com/internetarchive/openlibrary/pull/2223#issuecomment -513393435

Простите за боль (снова). ! Important был добавлен в 0f9030c1047d5a337fc292a09085d7c353c85424.

Проблема с неиспользованием! Important в том, что у вас

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

и правило равной специфичности:

.button { display: inline-block; }

кнопка фактически не спрятана вопреки ожиданиям.

Я пытался побудить нас больше двигаться в направлении БЭМ, чтобы эти правила специфичности стали еще более неприятными.

Следующий grep дает 6 результатов:

removeClass('hidden');

и 4 для:

addClass('hidden');

В этом случае замена:

class="hidden"

с участием

style="display: none;"

должно сработать.

Еще мы могли попробовать:

.button[style] { display: block;}

(предполагается, что атрибут стиля удален на скрытии, что может быть не так.

@cdrini Я знаю, что ты самоуверен по этому поводу, так что ты думаешь?

@jdlrobson Я не не согласен с логикой, я не согласен с исполнением: P display: none кажется мне хорошим решением (не style ). Мне не нравится, как мы играем с ошибками в продакшн. Мы должны либо 1) убедиться, что все классы hidden изменены на display: none (поскольку это предполагалось до фиксации 6 месяцев назад; это нужно было бы сделать вручную), либо 2) удалите !important и выполните (1) позже. Мне не нравится, что мы находимся в промежуточном состоянии, когда мы изменили значение класса hidden не проверив, что от него зависит.

Да, я испортил исполнение 6 месяцев назад :( 321d120 выглядит как исправление здесь, при условии, что его можно протестировать и работает.

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

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

Несмотря на то, что отображается ошибка «Arg. That not work», (важные) сведения об ошибке отсутствуют. В деле DS Margoliouth они указывают точную запись, которая его не устраивает:

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

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

Мы должны либо:

• молча исправить ошибку и обновить запись с помощью цели перенаправления, или
• вообще игнорировать авторов изданий

В качестве побочного примечания, когда в сообщении об ошибке говорится: «Мы записали это», это звучит так, как будто оно зарегистрировано в каком-то месте, где кто-то заметит и исправит это. Это регистрируется? Кто-нибудь просматривает журнал?

Еще один случай сбоя: https://openlibrary.org/authors/merge?key=OL134502A&key=OL4675154A&key=OL6002146A

Ошибка слияния @ Camillo-Pellizzari:

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

Запись об авторе была удалена CleanupBot @hornc еще в 2017 году, потому что она не использовалась ни в каких работах, но все же использовалась в записи этого издания. Теперь, поскольку нет возможности редактировать авторов редакций, это не может быть исправлено без помощи программиста.

Другой случай: https://openlibrary.org/authors/merge?key=OL17370A&key=OL2677210A

В этом примере есть единственная работа, неправильно отнесенная к OL2677210A Карла Юнга: «Рабочая тетрадь» - это трехтомный коммерческий каталог произведений искусства, из которых «Портфолио» - это том 2. Хорошо, что автор слияния допустил ошибку, хотя как это произошло ( тоже) непонятно.

Невозможно объединить эти:
https://openlibrary.org/authors/OL134502A/Gaius
https://openlibrary.org/authors/OL4675154A/Gaius

@seabelis
Ой! Это 59 трудовых книжек и две авторских записи на одно многотомное произведение с различными редакциями, комментариями и переводами. Нам действительно нужна вики о том, как лучше всего структурировать такие вещи, но это отдельная тема. Тем временем я вручную изменил все рабочие записи из последнего, чтобы вместо этого связать запись первого автора.

Спасибо за это. Пользователь отправил это, так что я даже не заметил этого в работах.

Я объединил две записи автора Гая, но есть и третья, которую, я думаю, тоже нужно объединить, но при слиянии возникает ошибка: https://openlibrary.org/authors/OL6002146A/Gaius

Даже после перемещения всех работ из OL6002146A в OL134502A, https://openlibrary.org/authors/OL134502A/Gaius?merge=true&duplicates=OL6002146A по- прежнему возникают ошибки, и перенаправление не создается. Странно ....

Невозможно объединить https://openlibrary.org/authors/OL735423A/Michel_Jean_Sedaine с https://openlibrary.org/authors/OL6011794A/Sedaine

Невозможно объединить https://openlibrary.org/authors/merge?key=OL4789371A&key=OL6011897A

Опять же: невозможно слить https://openlibrary.org/authors/merge?key=OL357738A&key=OL5999368A

Опять же: невозможно слить https://openlibrary.org/authors/merge?key=OL4277168A&key=OL6039003A

Опять же: невозможно слить https://openlibrary.org/authors/merge?key=OL2557977A&key=OL5998002A

Опять же: невозможно объединить https://openlibrary.org/authors/merge?key=OL133119A&key=OL6011208A

Опять же: невозможно слить https://openlibrary.org/authors/merge?key=OL1271659A&key=OL5996409A

Хм, кажется, все записи об авторах проблемы были созданы Import Bot 27 октября 2008 г. Другие странности, которые могут быть подсказками: они включают устаревшее поле «id =», которое удаляется любым прямым редактированием этой записи автора, но все же не могут быть объединены, так что проблема не в этом. Конечный пробел после имени автора может быть фактором или поле "личное имя =", которое можно увидеть в некоторых случаях.

Вздох, этот список становится все длиннее :( Спасибо @ Camillo-Pellizzari; добавьте в список.

Это также не удается: https://openlibrary.org/authors/merge?key=OL80534A&key=OL2693344A

Опять же: https://openlibrary.org/authors/merge?key=OL17370A&key=OL2677210A

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

Добавлено: +1:

Обратите внимание, что это, скорее всего, будет исправлено https://github.com/internetarchive/openlibrary/issues/2553.

Опять же: https://openlibrary.org/authors/merge?key=OL981833A&key=OL6003522A

@ Камилло-Пеллиццари
Это пахнет просто очередным наследием наших искаженных диакритических знаков. Мне удалось объединить большинство повторяющихся записей об авторах с Эмилем Эггером на https://openlibrary.org/authors/OL4557532A/, но последняя запись на https://openlibrary.org/authors/OL6003522A упряма.

Опять же: https://openlibrary.org/authors/merge?key=OL4743941A&key=OL4016098A

Другой случай: https://openlibrary.org/authors/merge?key=OL412435A&key=OL5239874A

@ Камилло-Пеллиццари
Ключ!!!!
Я вручную переместил 16 работ Мэйхью в основную запись об авторе, но одна запись о сиротском издании сохраняется, возможно, в кэше. Авторы все равно не сольются. Это одно издание имеет неверный псевдоработический путь https://openlibrary.org/works/OL20459197M со старым автором, указанным в записи об издании, что противоречит правильному автору, указанному в трудовой записи https://openlibrary.org/works/OL2788965W .
Невозможно узнать, какая из этих странностей является причиной сбоя слияния, но если администратор может настроить ее, это может быть поучительно:

{"publishers": ["Chatto & Windus"], "classifications": {}, "subtitle": "иллюстрации юмора, пафоса и особенностей лондонской жизни", "title": "лондонские персонажи", "примечания ":" 1e uitg. (1874 г.) встретился с ведущим \ "Генри Мэйхью и другими писателями \" (Vgl. Toole-Stott, № 491.). "," Identifiers ": {}," ocaid ":" londoncharacter00gilbgoog "," охватывает ": [9182853]," created ": {" type ":" / type / datetime "," value ":" 2008-10-27T03: 19: 48.641147 "}," languages ​​": [{" key ":" / languages ​​/ eng "}]," last_modified ": {" type ":" / type / datetime "," value ":" 2019-12-11T23: 49: 48.914594 "}," latest_revision ": 8 , "ключ": "/ books / OL20459197M", "авторы": [{"ключ": "/ авторы / OL5239874A" }, {"ключ": "/ авторы / OL1331553A"}], "publish_date": "1881 "," publish_places ": [" London "]," works ": [{" key ":" / works / OL2788965W "}]," type ": {" key ":" / type / edition "}," oclc_numbers ": [" 67342886 "]," редакция ": 8}

Другой случай: https://openlibrary.org/authors/merge?key=OL2629727A&key=OL68455A

Я исследую это, когда у меня будет время написать код, который сделает это автоматически: https://openlibrary.org/authors/OL4280920A/Federico_Garc%C3%ADa_Lorca?merge=true&duplicates=OL6887222A , OL4122786A, OL3973784A, OL62404110A. , OL3210186A, OL7313848A, OL7306164A, OL7327570A, OL7386673A, OL7392312A, OL7416035A, OL7687411A

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

@seabelis Нашел еще один https://openlibrary.org/authors/merge?key=OL4586796A&key=OL3206959A

Во всех изданиях указаны два автора, OL2629754A и OL3206959A, первый из которых является перенаправленным .

Конечно, авторов редакции нельзя редактировать, так что это не исправить. Я думал, что смогу взломать его, отредактировав YAML https://openlibrary.org/books/OL13263866M.yml?m=edit, но не тут-то было - Permission Denied.

Мне удалось удалить авторов из связанного издания. https://openlibrary.org/books/OL13263866M/Relato_de_un_n%C3%A1ufrago?_compare=Compare&b=6&a=5&m=diff

Думаю, из другого разговора я припоминаю, что удалять авторов из изданий не рекомендуется. Я думал, что могу просто удалить авторов из издания, а затем повторно применить действительного автора, но это вызывает ошибку,
AttributeError: 'str' object has no attribute 'olid'

Думаю, из другого разговора я припоминаю, что удалять авторов из изданий не рекомендуется.

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

Мне удалось удалить авторов из связанного издания. https://openlibrary.org/books/OL13263866M/Relato_de_un_n%C3%A1ufrago?_compare=Compare&b=6&a=5&m=diff

Удалось ли вам сделать это через веб-интерфейс или вы использовали один из API?

@tfmorris openlibrary-client через совместный блокнот @cdrini помог мне настроить. Я заменил авторов издания пустым объектом; точно так же я удалял участников раньше, когда пользовательский интерфейс не работал. Я не уверен, что это лучший способ, но он позволил мне отредактировать работу без предыдущей ошибки.

Еще один добавить в список. https://openlibrary.org/authors/merge?key=OL4435020A&key=OL7214197A&key=OL7622813A

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

Точные ошибки для каждого слияния видны в результате HTTP 400 merge.json который можно увидеть в консоли инструментов разработчика браузера, например:

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

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

Спасибо, @hornc .