Обсуждение:Культурное наследие России/Викиданные

Снова о Викиданных...

Во время последней вики-встречи в Петрозаводске Красным был высказан запрос о необходимости/желательности какого-либо механизма интернационализации списков культурного наследия. В самом деле, представление описаний объектов списков хотя бы даже на английском языке способствовало бы существенному расширению охвата аудитории участников конкурсов ВЛП. И вот тут я в очередной раз вспомнил наше с Женей, Сашей и Алексеем обсуждение двухлетней давности о хранилище Викиданных, поскольку именно оно является наиболее логичным контейнером для хранения мультиязычных данных об объектах. Описанные ранее проблемы никуда не делись: отслеживать 150К объектов по-прежнему сложно, гарантировать целостностность и непротиворечивость изменений данных по-прежнему затруднительно. Но всё же возможность получить мультиязычность "задёшево" весьма заманчива. Правда, поковырявшись несколько дней с этой проблемой, я оценил это "задёшево" не таким уж и дешёвым...

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

Не всё гладко в моём модуле - голову ещё ломать и ломать. Скорее всего на основе Викиданных не удастся создать точно такую же карточку объекта культурного наследия, поэтому я не стал в своём модуле один-в-один копировать интерфейс настоящего шаблона {{monument}} (чтобы спрятать изменения в структуре карточки под видом изменения интерфейса). Тем не менее, если сообществу кажется идея более тесной интеграции с Викиданными перспективной, можно возобновить обсуждение дорожной карты перехода на это хранилище. --Алексей С. (обсуждение) 01:39, 14 февраля 2020 (MSK)

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

Что же касается повышения числа участников, я не думаю, что интернационализация даст значительный эффект, поскольку количество путешествующих по России иностранцев невелико, а их географический охват очень узок. На мой взгляд, гораздо существеннее тотальная простановка координат, которая существенно упростит интерфейс для российских участников, позволив им искать объекты на карте вместо того, чтобы рыться в длинных списках. Кроме того, очень важно добавлять недостающие объекты по крупным городам. Обе задачи идеально подходят для представителей многочисленных новосозданных юзер-групп, если, конечно, у тех есть интерес к занятию краеведением. --Alexander (обсуждение) 10:51, 14 февраля 2020 (MSK)

А вот давайте тут я поясню немного. Во-первых, существование в карточке англоязычного названия объекта позволит автоматически добавлять к загруженным через конкурсные таблицы изображениям ещё и англоязычную подпись, что для изображений на складе вообще must have. Во вторых затеял это я изначально для помощи грузинским коллегам с их таблицами (они прям таблицы с минимумом параметров на грузинском языке). Отработав мультиязычность у нас, мы сможем выдать им готовые технические решения для создания внятных двух- или трёхъязычных списков ОКН, что в силу большого турпотока в страну позволит нехило так расширить список участников конкурса. Да и наши ОКН вполне могут фотографироваться туристами, не стоит сбрасывать их со счетов. Красный (обсуждение) 11:58, 15 февраля 2020 (MSK)

Здесь совершенно неясна задача. Если грузинским коллегам нужен многоязычный интерфейс для загрузки фотографий ОКН, то есть уже упомянутый Monumental, и мы тут вообще ни при чём. Если же коллег интересует возможность редактирования списков с заполнением полей на разных языках, то это вопрос существенного расширения listing editor, что совсем не просто и, на мой взгляд, требует усилий, не сопоставимых с волонтёрской работой (иными словами, за такую работу нужно платить).

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

Наконец, по поводу англоязычных описаний для Викисклада я сильно разочарую: при передаче параметров через адресную строку интерфейс Upload Wizard не даёт возможности отдельно передать описания на русском и на английском языках. Даже если англоязычные описания будут доступны, вам придётся сначала добиться изменений в Upload Wizard, чтобы это нормально работало. --Alexander (обсуждение) 01:20, 16 февраля 2020 (MSK)

Дык займитесь расстановкой координат, раз это для вас так важно. А то иногда у меня подозрение, что кроме меня этим никто не занимается. По Upload wizard если кто-то внятно опишет суть проблемы (я вот не программист ни грамма) я могу транслировать это "наверх" в околофондовые каналы связи — там точно найдут кого к этому припахать. Красный (обсуждение) 08:49, 16 февраля 2020 (MSK)

Дык займитесь расстановкой координат, раз это для вас так важно.

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

А с «околофондовыми каналами связи» мы сами как-нибудь разберёмся, если потребуется. --Alexander (обсуждение) 10:18, 16 февраля 2020 (MSK)

Импорт в Викиданные

А давайте сделаем импорт в Викиданные! Вне зависимости от исхода обсуждения и развития идеи это может быть полезным. Только вот вопрос в том, как сопоставить наши поля со свойствами Викиданных... --Алексей С. (обсуждение) 12:30, 14 февраля 2020 (MSK)

У нас есть скрипт, используемый в картах, который может помочь в экспорте данных. Например, запросить данные ОКН в JSON можно так:

https://tools.wmflabs.org/ru_monuments/monmap/api.php?query=get-page-data&page=Культурное_наследие_России/Алтайский_край/Барнаул&items=monuments&fields=name,knid,address

А получить список страниц в JSON можно следующим образом:

https://tools.wmflabs.org/ru_monuments/monmap/api.php?query=list-pages&prefix=Культурное_наследие_России

https://tools.wmflabs.org/ru_monuments/monmap/api.php?query=list-pages&prefix=Природные_памятники_России

Если надо будет немного дободрить - могу заняться. Работает не быстро, есть идея как оптимизировать.

Реализовать одностороннюю синхронизацию из Викигида в Викиданные не должно быть сложно, в отличии от двухсторонней. То есть скорее всего придется принять, что источник "правды" у нас будет один, а второй источник будет всегда read-only. --AlexeyBaturin (обсуждение) 19:52, 14 февраля 2020 (MSK)

Спасибо. Двухсторонняя синхронизация, на мой взгляд, не нужна. Оригиналы списков должны оставаться тут и нигде больше. --Alexander (обсуждение) 01:00, 15 февраля 2020 (MSK)

Я предлагаю пойти простым путём и считать, что мы не импортируем что-то в Викиданные, а экспортируем туда вспомогательную и уменьшенную копию нашей базы. Тогда указанных ниже полей совершенно достаточно, к ним нужно добавить только type (можно тем способом, который ты предложил). От документов в Викиданных никакой практической пользы, поэтому не надо их пока трогать. Ссылки на sobory или temples.ru там тоже без надобности и могут, к тому же, породить какой-нибудь шум на тему того, что sobory — неавторитетный источник.

А вот существенно, видимо, указывать P1435 = Q8346700 (heritage designation = cultural heritage site in Russia), поскольку Monumental, как я понимаю, реагирует на него.

Было бы отлично, если ты смог этим заняться в расчёте на то, чтобы потом хотя бы вручную время от времени делать синхронизацию. Кроме того, надо поинтересоваться у Ярослава техническими аспектами: нужен ли для такой заливки статус бота, и нужно ли где-то указывать наши списки как первоисточник. --Alexander (обсуждение) 01:00, 15 февраля 2020 (MSK)

Да, нужен статус бота. Если мы хотим использовать полную таблицу ниже, понадобятся ещё несколько ковых свойств (properties), причём, в отличие от ботов, с созданием свойств (там тоже нужно обсуждение) у меня опыт не очень большой.--Ymblanter (обсуждение) 01:09, 15 февраля 2020 (MSK)

Именно поэтому с созданием новых свойств я предлагаю не заморачиваться. --Alexander (обсуждение) 10:02, 15 февраля 2020 (MSK)

Всё-таки свойство по категории охраны создавать придётся, если мы хотим достаточный функционал экспортированной базы в данных. Иначе толку особого нет. Красный (обсуждение) 11:51, 15 февраля 2020 (MSK)

Я попробую всё же экспортировать свойства по-максимуму: ещё немного поломаю голову над тем, что в таблице ниже указано жёлтым. Вот кстати насчёт документов, думаю, что их экспорт и учёт будет проще, чем всё остальное. Я тут наткнулся, что в Викиданных вполне себе размещают описания каких-то НПА, например: d:Q27910222, d:Q56872341, d:Q58329400, d:Q66382939, d:Q66567165, d:Q78796709. Не вижу причин, почему бы не экспортировать информацию об используемых нами документах - их всего 1857 шт. Хорошо бы конечно, чтобы наши документы лежали в Викитеке, тогда в Викиданных можно было бы указывать интервики-ссылку...

Вот пример сущностей для наших документов: d:Q85207342, d:Q85217216, d:Q85216768 --Алексей С. (обсуждение) 22:56, 15 февраля 2020 (MSK)

По-моему, нужно учитывать тот факт, что сам по себе экспорт в Викиданные с точки зрения пользователя не даёт ровным счётом ничего: полезный эффект наступает только от тех приложений, которые Викиданные используют. Так что рациональнее сделать экспорт по минимуму с возможностью последующей синхронизации, после чего понять, какой доработки потребуют нужные нам приложения. Это касается, в том числе, упомянутой выше категории охраны, которой в Monumental просто нет. --Alexander (обсуждение) 01:03, 16 февраля 2020 (MSK)

Сейчас в БД Викигида 168548 записей. Из них лишь у 6770 задано поле wdid. Из этих ОКН с заданными wdid есть 208 с повторяющимися wdid (всего 6648 уникальных wdid). И из них 1833 сущностей имеют проблемы в утверждениях (нет либо "heritage designation", либо "kulturnoe-nasledie.ru ID"), что требует ручной проверки.

Список сущностей Викиданных с "проблемами" обновлён на User:Avsolov/duplicate-wdid.

То есть автоматический экспорт сейчас возможен не более, чем для 4815 ОКН (3% от базы). Итого, у нас проблема даже не в том, какие свойства экспортировать, а куда - большинству ОКН не назначена сущность Викиданных,... даже несмотря на то, что некоторое время назад по нашей базе прошёлся скрипт, вычленяющий из ссылок на Викисклад и Википедию идентификаторы сущностей Викиданных.

Встаёт дилемма: либо создать скопом 160К+ сущноностей Викиданных, а потом со временем находить и объединять дублирующиеся сущности; либо для каждого ОКН сначала искать, вдруг что в Викиданных уже есть, а если нет - добавлять в автоматизированном режиме (например, добавить к скрипту-карточке на toolforge кнопку "Создать сущность/экспортировать в Викиданные"). --Алексей С. (обсуждение) 11:46, 19 февраля 2020 (MSK)

По 1833 проблемным объектам: мне кажется, что поля MISSING можно заполнить автоматически, вручную нужно разбирать только те, что MISMATCH, а их вроде бы не очень много.

По второму вопросу: мне кажется, мы не сможем сделать всё идеально, так что не надо стесняться создавать 160 тыс. элементов Викиданных. Можно также договориться, что до какого-то срока (допустим, 30 июня) мы проходим по спискам крупных городов и проверяем по Википедии, нет ли там объектов, которые можно связать с Викиданными, а заодно выясняем некоторые другие вопросы: особенно навигацию и отображение всех объектов на одной карте, чем мне всё равно заниматься придётся. И потом делаем-таки экспорт, закрывая глаза на возможные недочёты. --Alexander (обсуждение) 12:04, 19 февраля 2020 (MSK)

Хорошо. Я попробую ещё сделать выборки из Викиданных на предмет того, вдруг там есть сущности, помеченные тем или иным образом как ОКН, а у нас они к объектам не привязаны. --Алексей С. (обсуждение) 12:18, 19 февраля 2020 (MSK)

Ещё один способ — вытащить из Википедии все включения Шаблон:Культурное_наследие_РФ и Шаблон:Культурное_наследие_народов_РФ и посмотреть, какие из них у нас не указаны.

Хотя я сейчас подумал, что более серьёзная проблема возникнет потом: когда люди будут создавать в Википедии новые статьи и заводить под них новые карточки Викиданных, не ведая, что эти карточки уже есть. --Alexander (обсуждение) 12:38, 19 февраля 2020 (MSK)

Ну, ничего особенно серьёзного тут нет, если мы научимся такие случаи отслеживать - два элемента Викиданных объединить недолго.--Ymblanter (обсуждение) 14:20, 19 февраля 2020 (MSK)

Вытащил из Википедии те статьи с шаблоном, которые не попали к нам в базу данных: User:Avsolov/heritage-links (1689 шт). --Алексей С. (обсуждение) 01:15, 23 февраля 2020 (MSK)

Спасибо. Можно ли обработать автоматически те их них, где в Википедии уже указан knid или knid-new? С разборкой остальных готов помочь. --Alexander (обсуждение) 10:58, 23 февраля 2020 (MSK)

А я не поняла, что значит "не попали к нам в БД". Вроде, кое что с этой страницы у нас есть и к нему указаны ссылки на Википедию и Викиданные. Тот же дом Пашкова (7710449000), да и много чего другого (я смотрела только Москву). Я что-то не так понимаю? --Ludvig14 (обсуждение) 11:35, 23 февраля 2020 (MSK)

Татьяна, спасибо, что обратили внимание. Конкретно в этом случае ситуация такая. В карточке Викигида дана ссылка "Пашков дом", которая является редиректом на настоящую статью в Википедии "Дом Пашкова". Естественно, редиректы я забыл учесть. Хотя возможно было бы лучше, если бы в карточке была ссылка на настоящую статью, а не на редирект.

Вопрос Александра вполне закономерен, я уже думаю над ним. Только вот как бы мне не проворонить такие моменты типа этих редиректов... --Алексей С. (обсуждение) 14:56, 23 февраля 2020 (MSK)

Обновил User:Avsolov/heritage-links с учётом редиректов. Наткнулся на такой случай: пара вики-страниц, ссылающихся на один и тот же ОКН (w:Геликон-опера и w:Усадьба Шаховских-Глебовых-Стрешневых). Пока непонято, насколько часто такая ситуация будет встречаться. В упомянутом случае, скорее всего, в одной из статей надо номер убирать, но это правка Википедии... --Алексей С. (обсуждение) 00:36, 3 мая 2020 (MSK)

Думаю, что будет встречаться. Искоренить их из Википедии вряд ли удастся, так что я бы, наверное, и не пытался. Скорее исключал из списка статьи Википедии, привязанные к номерам knid, которые уже имеют связь с Викиданными. --Alexander (обсуждение) 00:46, 3 мая 2020 (MSK)

Параметр шаблона {{monument}}	Описание	Подходящее свойство Викиданных
wdid	карточка объекта в Викиданных	id
name	название	label
type	тип памятника (architecture/history/archeology/monument)	Сейчас я тип определяю по instance of: если есть значение historic site, значит — памятник истории; если есть значение archaeological site, значит — памятник археологии; если есть значение monument, значит — памятник монументального исскуства; в противном случае — памятник архитектуры.
protection	категория охраны (Ф — федеральная, Р — региональная, М — местная, В — выявленный объект)	?
dismissed	код документа о снятии с охраны (в формате dDDMMYYYY)	?
lat	географическая координата (широта)	coordinate location
long	географическая координата (долгота)
precise	точность определения координат (precise=yes — координаты точны, в остальных случаях приблизительны)	Можно брать precision у d:Property:P625
knid	код объекта	kulturnoe-nasledie.ru ID
complex	код комплекса, в который входит объект (только для элементов комплекса)	Тут вероятно для главного элемента комплекса надо в heritage designation ставить cultural heritage ensemble, а у элементов определять свойство part of.
knid-new	номер объекта в новом государственном реестре	EGROKN ID
munid	код города/посёлка/села/деревни в Викиданных	По свойству located in the administrative territorial entity можно определить регион, район и АТО. Обозначение мелких деревень и посёлков можно вынести в location.
region	ISO-код региона
district	название района
municipality	название города/посёлка/села/деревни
address	точный адрес (улица, номер дома)	Может быть directions?
block	квартал	?
year	год постройки	inception
author	автор объекта (архитектор, скульптор, инженер и т.д.)	architect, structural engineer, designed by, creator, ... ? Тут будет проблема, какое свойство выбрать.
style	архитектурный стиль (возможные значения: конструктивизм, авангард, модерн)	architectural style
description	описание в вольной форме	?
status	статус (status=destroyed — если памятник утрачен, разрушен и т.п.)	Свойство dissolved, abolished or demolished сразу задаёт дату утраты, которая у нас где-то в описании в произвольной форме.
image	изображение (имя файла на Commons)	image
wiki	название статьи в Википедии	sitelinks[ruwiki], sitelinks[enwiki],...
commonscat	имя категории на Commons	sitelinks[commonswiki]
link	внешняя ссылка	?
linkextra	дополнительная внешняя ссылка	?
sobory	идентификатор объекта в народном каталоге православной архитектуры sobory.ru	?
temples	идентификатор объекта в проекте «Храмы России» temples.ru	?
document	код документа о постановке на охрану (в формате dDDMMYYYY, где DDMMYYYY — стоящая на документе дата)	В указанных выше примерах для документов я не придумал ничего лучше, чем указать ссылки (references) у свойства heritage designation. Но там вероятно предусмотрены URL-ы без названий. По-хорошему надо заводить все документы как отдельные сущности Викиданных.
document2	код документа о постановке на охрану (в формате dDDMMYYYY), если необходимо

CHEΓ

Как заметил Александр, в этом году планируется реализовать проект интеграции WLM в мобильное приложение Commons. Поскольку информацию об объектах приложение будет брать с Викиданных, актуальной становится задача создания сущностей Викиданных, соответствующих объектам культурного наследия. В настоящий момент из 185 тыс. ОКН сущность Викиданных приписана примерно 9 тыс. объектов.

Чтобы изучить вопрос, можно ли сформулировать какие-то критерии для автоматического экспорта ОКН в Викиданные, я занялся разработкой утилиты Cultural Heritage Export Gadget — CHEΓ. Утилита создана в помощь постоянным редакторам списков культурного наследия. Для выбранного объекта она параллельно показывает информацию из карточки Викигида и из сущности Викиданных. Утилита позволяет экспортировать из Викиданных следующие атрибуты:

• Наименование объекта на русском языке (поле name) — метка сущности.
• Изображение (поле image) — утверждение для свойства Property:P18 (image).
• Идентификатор объекта (поле knid) — утверждение для свойства Property:P1483 (kulturnoe-nasledie.ru ID).

Также номер заносится в свойство Property:P2186 (WLM ID). Для крымских объектов номер заносится с квалификатором of Russia, а если есть поле uid, то оно заносится как второе утверждение с квалификатором of Ukraine.

• Если объект является частью комплекса (поле complex) — утверждение для свойства Property:P361 (part of).
• Номер из госреестра (ЕГРОКН) (поле knid-new) — утверждение для свойства Property:P5381 (EGROKN ID).
• Тип объекта (поле type) — утверждение для свойства Property:P31 (instance of): для памятника градостроительства и архитектуры — Q2319498 (landmark), для памятника истории — Q1081138 (historic site), для памятника монументального искусства — Q4989906 (monument), для памятника археологии — Q839954 (archeological site), для исторического поселения (settlement) — Q3920245 (historical city in Russia).
• Генерируется утверждение для свойства Property:P1435 (heritage designation) со значением Q8346700 (cultural heritage site in Russia), которому задаются ссылки на основе сведений о постановке объекта на государственную охрану.

Уточнение. Если задано свойство protection, то heritage designation примет: Q105835774 — для выявленного, Q23668083 — для федерального, Q105835744 — для регионального, Q105835766 — для местного ОКН. Для объектов "с признаками" (номер на xx4...) — Q105835782. А вот если protection не указано, то Q8346700.

Уточнение-2. Если задано свойство dismissed (снят с охраны), то к свойству P1435 применяется квалификатор end time (P582), значение которого угадывается из даты, обозначающей документ (dXXYYZZZZ или docXXYYZZZZ). Если дату угадать не удаётся, значением квалификатора будет "unknown value".

• Населённый пункт (поле munid) — утверждение для свойства Property:P131 (located in ATE).
• Неструктурированный адрес (поле address) транслируется в утверждение для свойства Property:P2795 (directions).
• Координаты (поля lat и long) — утверрждение для свойства Property:P625 (coordinate location).
• Страница Русской Википедии (поле wiki) — связанная с данной сущностью ссылка ruwiki.
• Категория Викисклада (поле commonscat) — связанная с данной сущностью ссылка commonswiki.
• ID на sobory.ru (если есть) — утверждение для свойства Property:P8316 (sobory ID).
• ID на temples.ru (если есть) — утверждение для свойства Property:P9343 (temples ID).
• Факт утраты (status=destroyed) — утверждение для свойства Property:P576 (dissolved, abolished or demolished date) со значением "unknown value".
• Год создания/возникновения (если удаётся вычленить из поля year) — утверждение для свойства Property:P571 (inception).

Если для для сущности не задано утверждение Property:P17 (country), то при изменении knid, egrokn, heritage designation, municipality, address или координат будет также создано утверждение Property:P17 со значение Russia и квалификатором start time 18.03.2014 (для ОКН на 82xxx и 92xxx) или 25.12.1991 (для остальных ОКН).

• Создаётся утверждение для свойства Property:P2817 (appears in the heritage monument list) со ссылкой на элемент Викиданных соответствующей страницы списков в Викигиде.

Ведётся работа над функцией создания новой сущности на основе сведений из Викигида.

При выполнении изменений запрашивается централизованная авторизация проектов Wikimedia через протокол OAuth.

--Алексей С. (обсуждение) 21:24, 6 марта 2021 (MSK)

Реализовано создание новой сущности. Новый wdid автоматически заносится на страницу списков. Хотя параллельный просмотр свойств сразу становится доступен, CHEΓ будет показывать возможно необновлённые данные, поскольку берёт их из базы данных, а не со страницы списка КН. Обновление БД происходит раз в сутки в 1:22 UTC. --Алексей С. (обсуждение) 22:49, 8 марта 2021 (MSK)

Поймалось подобие ошибки. Для объекта 0300916000 я вздумала заменить изображение через СНЕГ. Получила сообщение "Неоднозначность — утверждение для P18 уже есть: заменить? добавить? исправить?". Разумеется, я могу сделать замену руками на ВД, но пока оставляю в качестве примера. --Ludvig14 (обсуждение) 23:47, 13 марта 2021 (MSK)

Угумс, я просто не знал, что в подобном случае делать, и придумал такое сообщение на некоторые свойства. Для P18 можно ведь несколько картинок задавать. Вот какое в этом случае действие выполнить: добавление ещё одной картинки или замена существующей? Такое же сообщение я предусмотрел для P361. --Алексей С. (обсуждение) 01:24, 14 марта 2021 (MSK)

Ну, я-то хотела заменить картинку. Но СНЕГ ведь и не ждал от меня ответа на вопрос, он просто поинтересовался, чего мне надобно. --Ludvig14 (обсуждение) 01:54, 14 марта 2021 (MSK)

Я придумал такую логику: Если у P18 уже есть несколько картинок, то сменить картинку не предлагается, будет написано: "Всего ХХ фото" (пример: [1]). А вот если картинка была одна, то CHEΓ будет её заменять. Алексей С. (обсуждение) 21:53, 14 марта 2021 (MSK)

Да, так выглядит разумно, спасибо. -- Ludvig14 (обсуждение) 22:41, 14 марта 2021 (MSK)

Культурное наследие России в Викиданных

Эта тема посвящена частичному или полному копированию нашей базы ОКН в Викиданные с последующей синхронизацией. Предыдущий разговор на ту же тему здесь. Скажу сразу, что в контексте этого разговора мы не обсуждаем:

• перенос списков ОКН в Викиданные
• действия с малыми группами объектов (10-100-1000), которые можно совершить вручную

Речь идёт исключительно об автоматическом алгоритме, допускающем последующую синхронизацию. --Alexander (обсуждение) 14:34, 7 марта 2021 (MSK)

Какие объекты копировать?

Тут может быть несколько вариантов:

• Все объекты с координатами
• Все объекты с документами о постановке на охрану
• Все объекты вообще

Первый вариант кажется привлекательным, потому что только объекты с координатами будут отображаться в Monumental или в (запланированном к созданию) мобильном приложении Commons. При этом кажется, что если не переносить лишнего, то не будет захламления Викиданных трудно локализуемыми объектами, памятниками археологии и там далее.

С другой стороны, нужно иметь в виду, что Викиданные — это не только источник информации для конкретного мобильного приложения, но и общая база всего, используемая самыми разными людьми в самых разных целях: например, для статистических исследований. Рано или поздно мы окажемся в ситуации, когда всё, чего нет в Викиданных, попросту не существует. Допустим, некто захочет сделать статистику распределения ОКН по российским регионам в сравнении с польскими. В нынешней ситуации, когда в Викиданных есть только ОКН со статьями в Википедии, наш потенциальный исследователь решит, что в России просто очень мало ОКН. Если скопировать только объекты с координатами, получится очень неоднородное распределение по регионам. Поэтому я за то, чтобы копировать всё. В Викиданных почти 100 миллионов "карточек". Подавляющее их большинство ничуть не более информативны, чем наши памятники археологии. --Alexander (обсуждение) 14:34, 7 марта 2021 (MSK)

• Я бы начал с координат и вообще копировал не очень большими порциями: это позволит оперативно отслеживать возникающие проблемы. Критерий по документам мне не очень нравится. На практике это поле заполняется довольно сложно, а реальной пользы от него не очень много. AndyVolykhov (обсуждение) 14:49, 7 марта 2021 (MSK)

А что делать с комплексами? Мой вчерашний пример - Торговые ряды в Галиче, где обозначено шесть корпусов. Надо ли создавать "сущности" для каждого корпуса или достаточно одной для головного элемента комплекса? При этом координаты стоят для каждого корпуса, но я не люблю ставить координаты заглавного комплекса, потому что при охоте на местности эта точка только мешает. -- Ludvig14 (обсуждение) 15:03, 7 марта 2021 (MSK)

Да, конечно, нужен отдельный элемент Викиданных под каждый элемент комплекса. Сколько ОКН, столько и элементов Викиданных. --Alexander (обсуждение) 15:15, 7 марта 2021 (MSK)

• Копировать всё подрад, на мой взгляд, опасно, так как у нас есть дублирования (и мы даже не знаем, сколько). В большинстве случаев простановка координат и означает хоть какую-то проверку элемента. --Ymblanter (обсуждение) 16:05, 7 марта 2021 (MSK)

Честно говоря, я не вижу тут какой-то опасности: ну будут дубли, и пусть себе будут. По мере обнаружения в списках вычистим их также из Викиданных. --Alexander (обсуждение) 17:01, 7 марта 2021 (MSK)

• Есть ещё такая известная проблема - само здание и находящеся в нём учреждение, вообще говоря, суть две разные вещи, и под них иногда создают два элемента Викиданных. Примеров под рукой у меня нет (условно говоря, должна быть, например, больница и здание больницы), может, у Тани что-то есть. Нас это, в принципе, не должно особенно беспокоить, но есть любители создавать статью про, скажем, университет или больницу, и ставить туда шаблон культурного наследия. Это хорошо бы отслеживать, там, где надо дублировать, дублировать, где не надо - игнорировать.--Ymblanter (обсуждение) 16:22, 7 марта 2021 (MSK)

  Проблема не в двух элементах викиданных, потому что учреждение и здание, в котором расположено учреждение - это действительно две разные сущности, требующие двух разных статей, и если обе статьи есть, то элементов ВД действительно два, но по-хорошему шаблон ОКН должен стоять только в статье о здании и ссылка у нас в списках должна быть на статью о здании (примеров, если надо, у меня полно - w:Александринский театр в СПб как первый пришедший в голову, - но и так понятно, о чем речь). А вот более насущных проблем в этом случае может быть две: 1) если здание ставится под охрану как памятник истории, а не архитектуры ("больница, где работал хирург Иванов", "школа, где учился герой Петров"), и тогда шаблон ОКН, в принципе, вполне оправданно стоит в статье о школе или больнице как об учреждении, элемент ВД там тоже один, и отдельную статью о здании писать нет смысла; 2) статья о здании как о памятнике архитектуры очень нужна, но ее пока нет, поэтому шаблон ставится в статью про учреждение, обычно где-то в районе абзаца, где хоть что-то говорится о здании. Это как бы от безысходности делается, а не потому что "есть любители", хотя они тоже, конечно, есть. В общем, все это требует отдельной сверки и доработки. -- Екатерина Борисова (обсуждение) 21:20, 7 марта 2021 (MSK)

Лёша, я уже забыл: ты не делал подборки элементов Викиданных с одинаковым номером ОКН? --Alexander (обсуждение) 17:01, 7 марта 2021 (MSK)

Непротиворечивостью сведений в Викиданных я ещё не начинал заниматься — есть только страница User:Avsolov/duplicate-wdid, но туда я такие данные ещё не выносил. --Алексей С. (обсуждение) 22:16, 7 марта 2021 (MSK)

Оказывается, Викиданные это делают сами по себе: d:Wikidata:Database_reports/Constraint_violations/P1483#Unique_value. Алексей С. (обсуждение) 00:56, 4 апреля 2021 (MSK)

Насколько "подробно" копировать?

Как обсуждалось выше, почти каждому полю нашего шаблона {{monument}} можно, при желании, сопоставить что-нибудь в Викиданных. Но начать лучше с самого необходимого:

• название
• координаты
• расположение (район, нас. пункт, адрес)
• номера (10-значный, 15-значный)
• фотография
• категория Викисклада

Это позволит представить нашу базу ОКН в Викиданных и начать использовать те приложения, которые работают на их основе. Крупная задача будет решена, потом можно постепенно двигаться дальше. --Alexander (обсуждение) 14:34, 7 марта 2021 (MSK)

• Дата создания, если она чёткая? Адрес, если его можно с чем-то сопоставить? AndyVolykhov (обсуждение) 14:46, 7 марта 2021 (MSK)

Придётся придумывать критерий, какая дата чёткая, какая нет. Такая дата: "сер. XIX в." — чёткая или нет? По мне — она худо-бедно формализуется. А вот дату: "XVIII в., 1714 г., 1764 г., 1863-1874 гг., 1959 г. (воссоздание)," — формализовать, я думаю, будет сложно.

За формализацию адресов я бы не взялся. Сейчас я пока способен выдать лишь неструктурированное P2795 (directions). Потому что найти в адресе улицу, потом найти в Викиданных сущность, соответствующую улице, а если её нет... --Алексей С. (обсуждение) 15:48, 7 марта 2021 (MSK)

+1. Даты — сложная штука, и не нужно за неё пока браться. --Alexander (обсуждение) 15:49, 7 марта 2021 (MSK)

Ну а как-то полуавтоматически? Если известно, что улица Ленина в каком-то НП создана, можно будет потом к ней попривязывать как-то упрощённо или только вручную в каждом элементе? А в чём разница directions и адреса? Они кажутся дублирующими. AndyVolykhov (обсуждение) 15:58, 7 марта 2021 (MSK)

Адрес можно по-разному указывать. Есть свойство P6375 (street address) — но это почтовый адрес с индексом, хотя по типу это "Monolingual text", так что в принципе в него можно произвольные вещи напихать. Есть P669 (located on street) — указание улицы, но для него надо, чтоб сама улица была в Викиданные заведена как сущность. Я выбрал свойство P2795 (directions), для которого вроде нет строгих указаний по формату. Возможно есть ещё какие-то варианты указания адреса? --Алексей С. (обсуждение) 22:25, 7 марта 2021 (MSK)

P6375 - самое то. ShinePhantom (обсуждение) 10:38, 14 марта 2021 (MSK)

P6375 может быть и пригодно для ОКН в городах, но есть такие "адреса": "в сквере у церкви" или "на перекрёстке транзитных дорог", — которые иначе как "directions" язык не поворачивается назвать. --Алексей С. (обсуждение) 17:37, 14 марта 2021 (MSK)

Я попробовал в CHEΓ сделать так: Если начало свойства year можно интерпретировать как трёх-четырёхзначное число, то предлагается синхронизация по свойству P571 (inception), если нет — извиняйте, работайте ручками... Алексей С. (обсуждение) 22:59, 14 марта 2021 (MSK)

У многих ОКН может не быть никаких вики-ссылок (ни на Википедию, ни на Викисклад). Чтобы обеспечить связность сущностей, предлагаю ещё добавлять свойство d:Property:P2354 (has list) с обозначением страницы-списка, например: d:Q105836081. --Алексей С. (обсуждение) 21:25, 9 марта 2021 (MSK)

Согласен. --Alexander (обсуждение) 21:47, 9 марта 2021 (MSK)

Что-то я невнимательно про это свойство прочитал. Похоже, оно не подходит. --Алексей С. (обсуждение) 22:49, 9 марта 2021 (MSK)

А в чём проблема? Например, я сейчас добавил к Q16715672, и всё получилось. --Alexander (обсуждение) 01:33, 10 марта 2021 (MSK)

Оно вроде по смыслу не подходит. Если ставить "has list" к "Церкви Покрова Пресвятой Богородицы", то получается что это ссылка на список церквей Покрова Пресвятой Богородицы. Как будто бы авторы этого свойства вкладывали в него именно такой смысл. А указание списка у сущностей—элементов списка как будто бы в Викиданных не практикуется. --Алексей С. (обсуждение) 11:50, 10 марта 2021 (MSK)

Это же не общая церковь Покрова, а вполне конкретная. Одним из её признаков является расположение в определённом районе, к которому мы даём список ОКН. Вот прямо в описании свойства есть пример Basshunter — has list — list of artists related to Basshunter. Я понимаю, что чаще это свойство используется как "вертикальное", то есть общее понятие (президент Франции) и список более частных, связанных с ним объектов (конкретные президенты Франции). Но я не вижу какого-то запрета и на "горизонтальное" использование: от объекта к списку ему подобных. --Alexander (обсуждение) 13:24, 10 марта 2021 (MSK)

Ну запрета сейчас нет, но в будущем, с развитием ВД, это может привести к какой-нибудь внезапной ерунде. Лучше всё же использовать элементы строго по назначению. А если ставить по дефолту ссылку на красную категорию по номеру объекта на ВС? Или нельзя? AndyVolykhov (обсуждение) 15:22, 10 марта 2021 (MSK)

На форуме Викиданных мне предложили запихнуть обозначение списка в ссылки свойства P1435. Собственно, именно так я сначала и собирался делать, меня останавливало только то, что не у всех страниц списков есть элемент Викиданных. --Алексей С. (обсуждение) 12:47, 11 марта 2021 (MSK)

Как быть с повторяющимися элементами Викиданных?

Во-первых, сами по себе они не являются большой проблемой. Повторяются, ну и пусть себе повторяются. Во-вторых, их можно разыскивать через:

• одинаковые номера ОКН
• одинаковые статьи Википедии / категории Викисклада

Идеального порядка при таком количестве объектов всё равно не будет, и я не вижу, чем этот беспорядок страшнее беспорядка в категориях Викисклада.

Если новый элемент появляется при создании статьи в Википедии, то возможны два варианта:

• автор статьи в курсе, что пишет про ОКН и приходит в нашу базу за номером, где видит уже имеющийся элемент Викиданных и подцепляет статью к нему
• автор статьи не в курсе, что пишет про ОКН, и потому создаёт новый элемент Викиданных, в котором не проставляет P1435 и номера ОКН. Этот новый элемент не будет виден Monumental и другим приложениям и никому, в общем, не помешает. Рано или поздно мы его найдём и исправим.

--Alexander (обсуждение) 14:34, 7 марта 2021 (MSK)

Синхронизация конкретных свойств

Здесь я бы начал с того, что изменения в нашей базе отслеживаются опытными участниками, а изменения в Викиданных если и отслеживаются, то теми, кто вряд ли в курсе российских ОКН. Поэтому информация в наших списках в среднем точнее, даже если по каким-то отдельным элементам мы видим обратное. Я думаю, что информация в Викиданных точна лишь там, где она взята из русской Википедии, и этот вопрос можно проверить при первичном экспорте. В дальнейшем можно спокойно перезаписывать почти все поля на основе актуальной информации в наших списках. --Alexander (обсуждение) 14:34, 7 марта 2021 (MSK)

При экспортировании свойств СНЕГ-ом я добавляю ссылку (reference) на Викигид. При синхронизации это наверное можно как-то использовать. Однако у label и wiki-ссылок нет такого атрибута — ссылка. --Алексей С. (обсуждение) 16:01, 7 марта 2021 (MSK)

Это плохое решение, хотя на первое время и сойдёт при отсутствии вариантов лучше. После заполнения у Викиданных могут добавляться дополнительные значения из других источников, и затирать их очень плохо. Относительно хороших вариантов несколько: 1) синхронизировать в обе стороны, но это не очень просто, 2) привязываться к источнику виду «импортировано из Викигида» и исправлять только эти значения, что тоже не просто, 3) синхронизировать из списков в Викиданные только то, что было изменено (потенциально можно что-нибудь затереть). Кроме этого, возможны варианты полуавтоматического подтверждения изменений, но это потенциально ещё сложнее. — putnik 15:55, 9 марта 2021 (MSK)

Название объекта

Лёша отмечал, что в Викиданных оно бывает удачнее. Это вполне естественно: у нас официальные названия из реестров ОКН, порой не самые благозвучные. Возможное решение: не синхронизировать названия там, где к элементу Викиданных подцеплена статья Википедии. --Alexander (обсуждение) 14:34, 7 марта 2021 (MSK)

• Ну а если некто исправит в ВД «Жилой дом» на «Дом купца Иванова», а потом бот это будет затирать? Кажется, что проставленное в ВД название (напрямую или из ВП или Коммонса) не стоит заменять нашим примерно никогда. Разве что при вандализме, но это надо вручную отслеживать. AndyVolykhov (обсуждение) 14:44, 7 марта 2021 (MSK)

А если кто-то исправит в наших списках, то это никогда не появится в Викиданных. Списки первичны, поэтому да, бот будет затирать. Так лучше, чем наоборот, поскольку над списками идёт систематическая работа, а над Викиданными нет. --Alexander (обсуждение) 15:18, 7 марта 2021 (MSK)

Здесь поддержу Александра: работа в Викиданных идёт крайне спорадически и ведут её те, кому тема интересна. Так как все они по этой теме уже есть здесь, не вижу смысла распылять силы. Фактически нам надо просто сделать группу свойств для привязки к уже существующим элементам ВД, дабы они отразили, скажем так, уникальные для нашего проекта параметры (сходу на ум приходит только номер в нашей базе и, вероятно, отдельно нужно будет сделать свойством название в ней). Дальше при наличии этих свойств можно будет создавать элементы ВД, которых ещё нет, наполняя их данными из списков, тем паче что большая часть параметров оттуда уже существует в виде свойств. Красный (обсуждение) 15:42, 7 марта 2021 (MSK)

Мне кажется, что нужно проверять: если разночтение появилось благодаря правке в ВГ, то да, исправлять в ВД, а если благодаря ВД — пока ничего не делать, проверять вручную. Так же можно, наверное, настроить бота? Ну и вообще хотелось бы понимания: мы в нашем списке хотим нормальные названия или только официальные? AndyVolykhov (обсуждение) 15:47, 7 марта 2021 (MSK)

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

Названия в наших списках уже многие годы и довольно массово изменяются по сравнению с официальными. Тут ничего нового. --Alexander (обсуждение) 15:56, 7 марта 2021 (MSK)

То есть нормально ли в случае обнаруженных расхождений (вручную, помимо правок бота) будет просто вносить в ВГ более точное название и ничего дальше не делать? AndyVolykhov (обсуждение) 16:01, 7 марта 2021 (MSK)

Да, будет нормально. --Alexander (обсуждение) 17:05, 7 марта 2021 (MSK)

Бывает ещё атрибут P1448 (official name) — можно его задействовать. А всё-таки Викиданновская метка "Дом жилой в Урюпинске" будет лучше метки "Дом жилой" на основе списков Викигида. --Алексей С. (обсуждение) 16:04, 7 марта 2021 (MSK)

это оптимальный вариант - есть официальное бюрократическое название - вот его и запихнуть в свойство. ShinePhantom (обсуждение) 10:40, 14 марта 2021 (MSK)

В списках Викигида не всегда придерживаются официального бюрократического названия. Екатерина, например, очень любит переводить с канцелярита на русский литературный. Так что название в Викигиде может не подходить под принцип свойства P1448. Мне кажется название из Викигида надо брать только при создании сущности, возможно добавив к нему в скобочках населённый пункт: name (municipality). А при последующих синхронизациях уже не трогать — пусть название живёт своей жизнью... Алексей С. (обсуждение) 22:54, 14 марта 2021 (MSK)

Это известная проблема. Бот должен составить список элементов Викиданных, где название отличается от нашего, а мы потом его вручную проверим. Будет бот названия исправлять или нет - вопрос вторичный.--Ymblanter (обсуждение) 16:12, 7 марта 2021 (MSK)

У меня плохой опыт сопоставления ботом случайных строк текста: будет очень много несовпадений из-за разного порядка слов и ещё какой-нибудь ерунды, не требующей человеческого внимания. Попробовать можно, но я боюсь, что получится огромный список, который трудно будет разобрать. Вариант с исправлением/неисправлением названий в зависимости от наличия статьи Википедии мне кажется самым простым в реализации, как минимум на первом этапе. --Alexander (обсуждение) 17:05, 7 марта 2021 (MSK)

И всё же: не стоит ли чуток позаботиться об уникальности названий сущностей? Вроде как вручную Викиданные не дают сохранять имя сущности, если оно совпадает с уже существующим. Но в CHEΓ вроде получилось создать три штуки "Дом жилой (Сортавала)"... Алексей С. (обсуждение) 16:33, 20 марта 2021 (MSK)

Нет, там не должна совпадать комбинация названия и описания. --Ymblanter (обсуждение) 17:46, 20 марта 2021 (MSK)

Координаты

Перед первичным экспортом было бы хорошо сопоставить координаты в Викиданных и в наших списках. Различия более 100 м проверить вручную. --Alexander (обсуждение) 14:34, 7 марта 2021 (MSK)

• Да, тоже думал, что проверку нужно начинать только свыше какого-то расстояния. AndyVolykhov (обсуждение) 14:45, 7 марта 2021 (MSK)

Обнаружил много объектов, у которых в Викиданных координаты стоят, а в Викигиде нет: Avsolov/duplicate-wdid (последняя колонка WV_MISSING) --Алексей С. (обсуждение) 16:12, 12 марта 2021 (MSK)

Там попадаются утраченные. Стоит тратить на них силы? --Ludvig14 (обсуждение) 02:13, 13 марта 2021 (MSK)

Расположение

Для районов у нас всегда указаны коды элементов Викиданных (districtid). Населённые пункты подцеплены далеко не все, но лишь потому, что их просто нет в Викиданных. Здесь всё, по-моему, просто:

• если munid известен, указываем его в P131
• если неизвестен, добавляем название населённого пункта в P2795 текстом

Когда в будущем кто-то добавит munid в наши списки, система учтёт это при синхронизации.

Есть другой проблемный момент: менявшиеся административные единицы. Например, районы vs. городские округа в Московской области. Я думаю, что здесь лучше всего обновить параметры districtid там, где мы про это вспомним, после чего для уже имеющихся элементов Викиданных сравнить наш districtid с тем, что указано в P131. Всё равно будет немалый разнобой, но станет яснее, какую стратегию дальше выбрать. --Alexander (обсуждение) 14:34, 7 марта 2021 (MSK)

На самом деле населенных пунктов в Викиданных гораздо больше, чем есть статей в руВики и я изредка добавляю фотографии, привезенные из экспедиций, в разные мелкие деревушки. Искать их приходится перебором всех деревень, входящих в конкретное административное/муниципальное образование. И, кажется, не было ни одного случая, когда я не смогла бы обнаружить нужный населенный пункт в Викиданных. Так что, похоже, большинство населенных пунктов в Викиданных есть и нам хорошо бы достать их автоматически. -- Ludvig14 (обсуждение) 14:55, 7 марта 2021 (MSK)

А вот да. По-моему, в паре разделов их залили вообще все (чеченский и ещё какой-то), так что если НП невозможно найти в в ВД, скорее всего, его просто не существует в настоящее время, и надо искать существующий. Правда, могут быть ОКН и вне существующих НП. AndyVolykhov (обсуждение) 15:05, 7 марта 2021 (MSK)

Я не вижу никаких способов сделать это автоматически. И не вижу, зачем на данном этапе оно вообще нужно. В предложенной мной схеме munid отдельных населённых пунктов всегда можно доработать потом. --Alexander (обсуждение) 15:23, 7 марта 2021 (MSK)

Про "зачем": если вдруг в ВД проставлены координаты населенного пункта (шансов немного, но есть), а ОКН не имеет координат, это будет дополнительная информация о его местоположении. Что касается автоматизации, то, на мой дилетантский взгляд, нужно делать перебор всех НП по району и сравнивать русскоязычные названия (в ВД обычно прописаны только они). Совпадут, наверное, не все, но что-то выловится. -- Ludvig14 (обсуждение) 15:43, 7 марта 2021 (MSK)

Хорошо, но какое это имеет отношение к обсуждаемой теме? Если сказать, что мы не будем ничего экспортировать в Викиданные до тех пор, пока не заполним для всех населённых пунктов munid, это поставит задачу принципиально более трудоёмкую, требующую отдельно разбираться с каждой административной единицей, и отложит экспорт на неопределённый срок. Если же это независимая задача, то давайте и обсуждать её независимо. Экспорт в Викиданные, на мой взгляд, важнее. --Alexander (обсуждение) 15:59, 7 марта 2021 (MSK)

Да, на Викиданных в целом уже есть все существующие ныне населённые пункты, но не без багов (что-то дублируется, несколько районов неожиданно отсутствует). Если я редактирую список района, обычно проставляю там munid (выгружаю список из викиданных и ВПР-ом в экселе подтягиваю). Не всегда это делаю только в Центральной России, потому что там в районах бывает по 500 деревень, из которых по 3-4 с названиями типа Зайцево, и нужно еще угадать, что это одна из них, а не еще какое-нибудь урочище. Это в целом к тому, что автоматически подтянуть можно, просто придётся потом ещё просматривать вручную. --Bok (обсуждение) 10:47, 8 марта 2021 (MSK)

А много у нас таких случаев, когда wdid населённого пункта не проставлен? Я вчера прошёлся по нескольким районам Саратовской и Сахалинской областей, нашёл два случая из нескольких сот.--Ymblanter (обсуждение) 17:22, 10 марта 2021 (MSK)

На выгрузке из базы от 5 марта: всего 185408 ОКН, непустое munid у 135795 ОКН (т.е. у примерно 50000 объектов munid не указан). --Алексей С. (обсуждение) 18:13, 10 марта 2021 (MSK)

Правильный ответ знают только ботоводы, но я сталкиваюсь с таким достаточно регулярно. Например, здесь примерно для четверти страницы данных нет. -- Ludvig14 (обсуждение) 17:29, 10 марта 2021 (MSK)

Саратовскую и Сахалинскую области как раз я выкладывал или редактировал практически целиком, там в целом должны быть проставлены. Есть регионы, где в сельской местности проставлено очень мало - например, Владимирская область или Краснодарский край. А так в целом да, надо считать. --Bok (обсуждение) 17:49, 10 марта 2021 (MSK)

Я так понял, что в P131 мы хотим видеть не населённый пункт, как сейчас в большинстве карточек, а муниципальное образование? А населённый пункт перенести в P276 (location)? Алексей С. (обсуждение) 19:40, 14 марта 2021 (MSK)

В самих Викиданных ведутся затяжные споры на счёт этого свойства. Теоретики хотят там видеть административные единицы, чтобы была корректная структура. Практики наоборот хотят, чтобы было как в Википедии, даже если это формально будет некорректно. Как же в итоге лучше — чёрт знает. — putnik 20:02, 14 марта 2021 (MSK)

Предлагаю пока ориентироваться на Р131. Так проще. Если кому-то будет нужно, он сможет, помучавшись, перенести населённые пункты в Р276, определив для каждого из них правильное значение Р131. --Alexander (обсуждение) 20:05, 14 марта 2021 (MSK)

На стадии экспорта можно такое реализовать. Дополнительная проверка munid на наличие subclass of "municipal formation in Russia" и при отсутствии — небольшой поиск уже по P131 у него самого — потребуют не очень много строк кода. Алексей С. (обсуждение) 20:39, 14 марта 2021 (MSK)

Нам мой взгляд при таком подходе есть проблема, что данные между списками и Викиданными будут неочевидным образом расходиться. Ну, или же после такого экспорта нужно будет обновить данные в списках. — putnik 21:07, 14 марта 2021 (MSK)

Номера объектов

Нам подсказывают, что есть ещё такое свойство как P2186 (Wiki Loves Monuments ID). Не хотим ли мы перейти на него, отказавшись от P1483 как устаревшего? --Alexander (обсуждение) 22:35, 16 марта 2021 (MSK)

P1483 генерирует ссылку на карточку ОКН (ru_monuments.toolforge.org/wikivoyage.php). У P2186 такого нет (там сейчас, кстати, в ограничениях не прописана Russia как разрешённая страна для использования этого идентификатора). Алексей С. (обсуждение) 22:42, 16 марта 2021 (MSK)

Судя по странице обсуждения, разрешённые страны там кто-то прописал от балды, поэтому Россию ничто не мешает добавить. Ссылка на карточку ОКН — да, полезна. Может быть, в итоге надо будет использовать оба свойства. --Alexander (обсуждение) 23:20, 16 марта 2021 (MSK)

Если надо, я могу добавить Россию в это свойство.--Ymblanter (обсуждение) 23:23, 16 марта 2021 (MSK)

Ещё может быть конфликт в Крымских ОКН по номерам, там P2186 используется для украинского номера (например, d:Q25443399, d:Q4173050).

Если отказываться от P1483, то надо будет предупредить википедистов — у них это свойство используется в шаблонах {{Культурное наследие...}} Алексей С. (обсуждение) 23:57, 16 марта 2021 (MSK)

Собственно, нам никто не мешает проставлять оба свойства сразу, там, где это не вызовет проблем.--Ymblanter (обсуждение) 00:13, 17 марта 2021 (MSK)

Если никого не смущает наличие нескольких свойств с одним и тем же значением, то это может быть решением. Алексей С. (обсуждение) 00:26, 17 марта 2021 (MSK)

Не вижу, почему это кого-то должно смущать. В самом худшем случае вынесут одно из свойств на удаление и ботом всё переставят, но мне даже и такое развитие событий кажется совершенно невероятным.--Ymblanter (обсуждение) 00:31, 17 марта 2021 (MSK)

Ну, учитывая, сколько у нас объектов на 3 и 4 (и сколько ещё будет; возможно, когда-нибудь придётся и дальше дробить сущности и усложнять номенклатуру добавляемых объектов), переход на отдельное свойство выглядит не самой плохой идеей. AndyVolykhov (обсуждение) 23:51, 16 марта 2021 (MSK)

У нас сложился консенсус, что такое свойство мы добавляем в сущности Викиданных или пока ещё думаем? Алексей С. (обсуждение) 21:27, 2 апреля 2021 (MSK)

Давай добавлять его параллельно с P1483. Хуже от этого не будет. --Alexander (обсуждение) 21:45, 2 апреля 2021 (MSK)

Ок. Я добавил Russia в список допустимых стран для этого свойства.

У меня остались ещё три непонятки с этим свойством:

1. У него стоит "distinct values constraint" — я так понимаю, оно не допускает совпадающих номеров. Не может у нас возникнуть случайного совпадения номеров с другими странами? (пинг @Ymblanter:)

   Я, честно говоря, не знаю, никогда и нигде таких длинных номеров не видел, но, если нет, наверное, квалификатор можно добавить?--Ymblanter (обсуждение) 22:22, 2 апреля 2021 (MSK)

2. Что будет делать Commons:Mobile app/WLM на основе этого свойства? Надо ли будет ещё потом ту метаинформацию, которую добавит мобильное приложение в загруженные через него фотки, конвертировать в наш шаблон {{Cultural Heritage Russia}}?
3. Что делать с несколькими крымскими объектами, у которых в него уже записан украинский номер?

Алексей С. (обсуждение) 21:59, 2 апреля 2021 (MSK)

Как будет работать мобильное приложение, мы точно не знаем, но я писал разработчикам, что шаблон {{Cultural Heritage Russia}} нужно бы добавлять сразу.

По поводу номеров, совпадающих с другими странами: там вроде был какой-то разговор на странице обсуждения свойства. По идее, надо добавлять для каждой страны свой префикс, но это можно сделать и позже. --Alexander (обсуждение) 22:20, 2 апреля 2021 (MSK)

Подготовительная работа

Вот что я пока для себя отметил:

• разобрать элементы Викиданных с проблемами в свойствах P1435, P1483, P5381: список
• разобрать ошибочные значения в поле munid (тут хорошо бы сделать список)
• разобрать различающиеся координаты (тоже было бы хорошо сделать список)
• обновить districtid для менявшихся в последнее время административных единиц; после этого сравнить с P131 (тоже хорошо бы сделать список)

Большая, но, мне кажется, посильная задача. Есть ещё что-то? --Alexander (обсуждение) 14:34, 7 марта 2021 (MSK)

• Одобрить бота на Викиданных.--Ymblanter (обсуждение) 16:14, 7 марта 2021 (MSK)

Ярослав, можно ведь разбить наши задачи на небольшие группы (скажем, по 10000 операций) и выполнять их через quickstatements? Для работы с quickstatements ведь не нужны права бота. Я попробовал так экспортировать координаты для небольшой группы тех сущностей, у которых их ещё вообще не было: batch#50948. --Алексей С. (обсуждение) 23:05, 12 марта 2021 (MSK)

Но для синхронизации всё равно ведь понадобится бот? --Alexander (обсуждение) 23:08, 12 марта 2021 (MSK)

Не обязательно. У quickstatements есть несколько точек входа, в том числе, неинтерактивных. То есть можно периодически на toolforge генерить задачу для quickstatements и отправлять её от имени какого-нибудь пользователя (например, недавно созданного мной AVSBot или ещё одного специально завести). Единственное, что меня смущает, это нестабильность работы quickstatements. Я наверное буду по мелочам его сейчас пробовать, чтобы оценить "масштаб трагедии", но всё же предполагаю, что это некритично. --Алексей С. (обсуждение) 23:19, 12 марта 2021 (MSK)

Нет, для quickstatements флаг бота не нужен, если мы можем всё сделать, то так имеет смысл.--Ymblanter (обсуждение) 23:09, 12 марта 2021 (MSK)

Создал заявку на добавление свойства для temples.ru, чтобы можно было сразу и его переносить: d:Wikidata:Property proposal/temples.ru ID. — putnik 19:56, 14 марта 2021 (MSK)

Свободное обсуждение

• А можно пояснить проблему с P1435 (категория охраны)? Да и с другими двумя? MISSING — это когда в ВД нет категории, а у нас есть? Это вроде бы легко ботом внести. AndyVolykhov (обсуждение) 15:17, 7 марта 2021 (MSK)

P1435 — это не категория охраны, а сам факт того, что объект является культурным наследием. MISSING означает, что это свойство не проставлено. Должно ли оно там быть, лучше проверить вручную. --Alexander (обсуждение) 15:20, 7 марта 2021 (MSK)

А категория охраны где? AndyVolykhov (обсуждение) 16:20, 7 марта 2021 (MSK)

Мне такое свойство не попадалось. По идее, можно не заводить отдельное свойство (поскольку это, говорят, сложно и муторно), а придумать разные варианты сущностей-подклассов cultural heritage (federal cultural heritage, regional cultural heritage, local cultural heritage и т.п.), чтобы присваивать их этому свойству P1435. --Алексей С. (обсуждение) 22:42, 7 марта 2021 (MSK)

Ну, вот я вижу, что голландцы делают так: d:Q17329920 использует P1435, и его значение установлено как Rijksmonument (это аналог нашего памятника федерального значения). Надо просто завести три элемента (не свойства!) Викиданных - памятник федерального значения РФ, памятник местного значения РФ, выявленный памятник (если их ещё нет), ну, или сразу 12 - для каждой категории охраны сделать архитектуру, историю, археологию и монументальное искусство.--Ymblanter (обсуждение) 01:18, 9 марта 2021 (MSK)

Я нашёл d:Q23668083 (federal), сделанное Putnik-ом, и создал ещё d:Q105835744 (regional), d:Q105835766 (local) и d:Q105835774 (выявленный). Для объектов на xx4 сделал d:Q105835782. --Алексей С. (обсуждение) 15:34, 9 марта 2021 (MSK)

Отличное решение. Спасибо! --Alexander (обсуждение) 15:52, 9 марта 2021 (MSK)

Замечательно, спасибо.--Ymblanter (обсуждение) 16:04, 9 марта 2021 (MSK)

А что и как будет происходить, когда выявленный объект включается в реестр и становится местным или региональным? Или когда выявленному оказывают в статусе и он т.о. становится снятым с охраны? Это всё случается довольно часто и много. -- Екатерина Борисова (обсуждение) 01:10, 10 марта 2021 (MSK)

Ну, вероятно, значение свойства P1435 надо будет изменить. Мы же в списках их меняем. Для снятых с охраны/утраченных можно оставлять старый статус, только добавить квалификатор end time (P582). --Алексей С. (обсуждение) 01:24, 10 марта 2021 (MSK)

О, отлично. Всячески одобряю и это решение, и предыдущее. AndyVolykhov (обсуждение) 15:19, 10 марта 2021 (MSK)

Ещё по поводу P1435. "Объекты с признаками..." это — d:Q8346700 или нет? --Алексей С. (обсуждение) 16:06, 7 марта 2021 (MSK)

Им можно ставить более общее Q358, чтобы педанты из русской Википедии потом не придирались. --Alexander (обсуждение) 16:15, 7 марта 2021 (MSK)

У heritage designation есть ограничение "none of constraint", запрещающее ставить Q358 (heritage site). Надо что-то другое... --Алексей С. (обсуждение) 01:09, 9 марта 2021 (MSK)

Недавно в Викиданные массово и весело переехала база культурного наследия Грузии. Сделано, как по мне, было очень топорно, как итог у большого количества объектов появились дубли, которые ещё и трудно толково объединить. Подобные вещи надо отследить, как и решить, как мы будем делать распределение комплексов: пользоваться P527 или, например, сделаем отдельную группу элементов "архитектурно-исторический комплекс" и "часть архитектурно-исторического комплекса" или навроде того. Красный (обсуждение) 15:36, 7 марта 2021 (MSK)

Для элементов комплекса можно использовать P527/P361. --Alexander (обсуждение) 16:54, 7 марта 2021 (MSK)

А что правильно делать в случаях, вроде d:Q1152922? Само здание, как я понимаю, прописано в d:Q14404494. Или лучше не мешать? -- Ludvig14 (обсуждение) 17:22, 12 марта 2021 (MSK)

Я думаю, что здесь нужно выбирать элемент Викиданных с более простым и человеческим названием, то есть "Военная академия им. Фрунзе". --Alexander (обсуждение) 19:20, 12 марта 2021 (MSK)

Или сделать еще один элемент на ВД для здания? Академия, в конце концов, тоже учреждение. Мне еще попались посольства Египта и Сирии, живущие в ОКН. По-хорошему, наверное, надо делать для каждого подобного здания свою сущность. -- Ludvig14 (обсуждение) 19:26, 12 марта 2021 (MSK)

Да, в перспективе лучше конечно разделять здание и учреждение. На примере музеев (d:Q195311 vs. d:Q3719164) я подсмотрел, как делаются свойства Викиданных в этом случае. У здания ставится occupant, а у учреждения ставится headquarters location, где указывается город, с квалификатором location, где уже указывается здание. Я так сделал у d:Q16695744 vs. d:Q84817228. --Алексей С. (обсуждение) 20:43, 12 марта 2021 (MSK)

я театрам создавал отдельные сущности организации и зданию. И нарушений меньше и в зданиях раньше и иные организации были, а у театров и иные адреса. ShinePhantom (обсуждение) 10:36, 14 марта 2021 (MSK)

А вот сходная ситуация с Большим театром, где все сделано правильно: здание (d:Q55657993) указано в нашем списке, а сам театр (d:Q138908) попал в список неиспользованных сущностей. Что надо сделать, чтобы последний в списке сущностей не фигурировал? Убрать heritage designation или что-то более сложное? -- Ludvig14 (обсуждение) 18:54, 12 марта 2021 (MSK)

Неиспользованные — это те, у которых есть heritage designation, но в БД у нас они не используются. Да, достаточно убрать heritage designation. --Алексей С. (обсуждение) 19:00, 12 марта 2021 (MSK)

Еще одна непонятная ситуация. В Старожиловском районе Рязанской области объект 6200376000. Название села и церкви пришло из старой базы данных, но Октябрьское в Рязанской области есть только в Пронском районе, где живет Никольская церковь, внесенная в списки. Где ошибка, я не понимаю и пока объект остается в своем первоначальном месте. И, собственно, вопрос - надо ли экспортировать заведомо ошибочный объект в ВД? И если нет, то не стоит ли придумать какой-то способ отмечать такие объекты? Например, можно завести для них указатель или сделать отдельный список. -- Ludvig14 (обсуждение) 22:59, 14 марта 2021 (MSK)

Принципиально ­— такой список для "бота" можно завести. Но сколько мы вручную найдём таких объектов? Десяток? Сил будет потрачено много, а всех ошибочных мы всё равно сейчас не выловим. Надо продумать механизм, как это потом исправлять. Мне видится это так: надо будет ещё просматривать наш список дублей на предмет того, не ссылается ли какая-то сущность на дублирующий knid. Вот как потом быть с освобождёнными номерами на xx3...? Алексей С. (обсуждение) 23:11, 14 марта 2021 (MSK)

А силы мы на это тратить не будем, просто внесем туда то, что случайно выловим в ходе обычной работы. Вчера вот Ярослав поймал памятник в неизвестном населенном пункте. Но у меня еще один вопрос - а в какую черную дыру исчезают памятники из ЕГРОКН? Вот кто-то раньше поставил 15-значные номера, а теперь в реестре памятников их уже нет. Сняли с охраны или еще что? Эдак мы обречены иметь расхождения. --Ludvig14 (обсуждение) 12:14, 18 марта 2021 (MSK)

Вопрос по вероятному алгоритму работы. Допустим бот намеревается создать новую сущность для ОКН, но обнаруживает, что для страницы Википедии (wiki=) или категории Викисклада (commonscat=) сущность уже есть. Такое возможно не только в случае, если мы пропустили уже созданную сущность, но и если одна и та же страница/категория прописана для нескольких ОКН. Понятно, что в логе бота такая ситуация будет отражена, но вот какое поведение тут реализовать: не создавать сущность вообще или создать, но без привязки к странице Википедии/категории Викисклада? Алексей С. (обсуждение) 15:26, 19 марта 2021 (MSK)

Создать без привязки к странице Википедии. А указать категорию Викисклада можно в качестве свойства. --Alexander (обсуждение) 16:42, 19 марта 2021 (MSK)

Бот

Так как тут вряд ли кто-то регулярно пишет ботов, то я подумал, что вероятно мне лучше поковыряться в этом самому. За пару вечером я накидал первую версию, от которой можно отталкиваться. Логика работы бота в целом сделана на основе таблички выше, СНЕГе и этом обсуждении, её можно расширять и в сторону экспорта и в сторону обновления списков. Он умеет создавать вот такие элементы и привязывать их обратно к шаблонам, на основе которых создал (и даже теоретически делать это пачкой за один раз). Добавлять отсутствующие свойства тоже умеет. Имеющиеся свойства пока сознательно не перезаписывает, хочется сделать это аккуратно. Там нужно ещё привести в порядок код и добавить публикацию лога работы в на вики-страницу, чтобы было проще следить за происходящим. Если в целом такой вариант всех устраивает, то я его буду допиливать на основе замечаний. — putnik 09:07, 14 марта 2021 (MSK)

государство = Россия, вероятно можно сразу добавить. И можно сразу с датой начала: 25 декабря 1991 года. Если конечно, памятник не создан позже, что сильно вряд ли возможно (если не Крым) ShinePhantom (обсуждение) 10:30, 14 марта 2021 (MSK)

Да, государство можно добавить. Кстати, как корректно значения для Крыма оформляются? — putnik 17:20, 14 марта 2021 (MSK)

P6375 = "Адыгейск, проспект Ленина, 21/4" (русский) - будет корректно добавить тоже сразу. ShinePhantom (обсуждение) 10:31, 14 марта 2021 (MSK)

Спасибо. Здесь есть несколько человек, активно писавших ботов, в том числе для работы с Викиданными. В данном случае Лёша, я думаю, может сказать, начал ли он уже писать что-то и насколько ему близка логика этого конкретного кода, или хочется видеть другую.

По реализации есть несколько комментариев, касающихся как действий бота, так и подготовки к ним:

• 1. Не был использован параметр munid
• 2. В качестве района нужно было ставить городской округ Адыгейск (Q14506940), а не город Адыгейск (Q102521). Это не ошибка бота, а ошибка districtid в наших списках. Как я писал выше, нужно, видимо, перед массовым экспортом проверять districtid в списках — иначе мы создадим большую путаницу: особенно в тех регионах, где территориальное деление менялось.
• 3. Получившаяся карточка содержит несколько предупреждений. Часть из них уйдёт, если указать страну, но есть ещё ошибки, которые выдаёт P1483: отсутствие координат и отсутствие категории Commons. Я не совсем понимаю, зачем нужны эти ограничения и откуда они взялись. Ярослав, что Вы думаете о том, чтобы их убрать? Нужно ли для этого специальное обсуждение в Викиданных?

--Alexander (обсуждение) 14:20, 14 марта 2021 (MSK)

Я бы предупреждения игнорировал, нам от них ни тепло, ни холодно, мы и так знаем, есть у нас координаты или нет. Просто так их убрать нельзя, надо обсуждать В принципе, можно открыть обсуждение и попробовать по результатам их убрать, но я не думаю, что это разумная трата времени.--Ymblanter (обсуждение) 14:34, 14 марта 2021 (MSK)

Если импорт ста тысяч элементов с одинаковыми предупреждениями не вызовет чьей-нибудь негативной реакции, то можно, я думаю, игнорировать. --Alexander (обсуждение) 15:17, 14 марта 2021 (MSK)

это нормально для ВД. Проверки на предупреждения вводятся часто сильно позже заполнения, вызывая уйму срабатываний. Не есть хорошо, но не критично, если правильно по сути заполнено. ShinePhantom (обсуждение) 22:39, 14 марта 2021 (MSK)

Спасибо за развёрнутый комментарий.

1. munid как раз используется в качестве значения для P131 (в данном случае это Q102521), а наоборот пока не используется глобальный districtid из кода страницы.

2. Есть ощущение, что исправление исключительно districtid мало поможет как раз потому, что много где он продублирован munid. Нужно как-то менять оба, хотя бы банально заменой по всей странице.

3. Добавил страну и координаты (но их много где не будет). Возможно стоит попробовать перевести часть предупреждений в рекомендации (которые флажком, а не восклицательным знаком), потому что ситуация, когда каких-то полей нет, вполне допустима. — putnik 18:26, 14 марта 2021 (MSK)

К п. 1: да, прошу прощения — мне почему-то показалось, что карточка была создана для бюста в посёлке Гатлукай. Но раз речь шла о братской могиле в Адыгейске, то всё верно: привязка к Q102521 даёт более точную локализацию, чем к Q14506940. --Alexander (обсуждение) 18:44, 14 марта 2021 (MSK)

Безобразие, конечно, что в ВД не разделяют принадлежность к населённому пункту и административной единице. AndyVolykhov (обсуждение) 22:22, 14 марта 2021 (MSK)

Ну вот, я хотел посмаковать, а тут уже всё наготово... --Алексей С. (обсуждение) 18:16, 14 марта 2021 (MSK)

Ну, от прототипа до готового продукта путь не близкий, работы ещё очень много. И её даже куда больше в плане принятия решений, что и как правильнее делать, а не в плане написания кода. Так что если у вас вдруг появится желание всё переписать с нуля, я нисколько не обижусь. — putnik 18:29, 14 марта 2021 (MSK)

Собственно, CHEΓ, как раз и писался для отработки принятия решений, что и как правильнее делать. Я пишу на PHP, к python симпатии не испытываю. При импорте обращаюсь не напрямую к странице Викигида, а беру данные из mysql на toolforge, где они уже распарсены (правда могут быть не совсем свежие). Пользователя с правами бота на Викиданных у меня нет, поэтому я собирался выкрутиться через quickstatements. Алексей С. (обсуждение) 18:42, 14 марта 2021 (MSK)

А зачем бот в этом примере ставит ссылки на две разных версии страницы Культурное наследие России/Адыгея/Адыгейск? Кстати, там номер ЕГРОКН неверный. AndyVolykhov (обсуждение) 22:12, 14 марта 2021 (MSK)

Ну так он из какой версии взял, на ту и ставит. Если все свойства за один раз добавлены, тогда будет только одна версия, а если какие-то раньше, а какие-то позже, то может очень много их быть. В данном случае я некоторые поля позже добавил и между запусками поправил страницу. И я ещё хочу на будущее якорь добавить, чтобы было https://ru.wikivoyage.org/?oldid=423504#0130058000. Мне кажется, что так проще будет с этими ссылками работать. — putnik 22:22, 14 марта 2021 (MSK)

Да, с якорями удобнее, конечно. А якорь в шаблон памятника зашит, его специально ставить не надо? AndyVolykhov (обсуждение) 22:24, 14 марта 2021 (MSK)

Да, якорь шаблоном добавляется. — putnik 22:36, 14 марта 2021 (MSK)

По ЕГРОКН я нашёл только один источник. Хотя там вполне может быть и ошибка. Приложение к оригинальному постановлению не гуглится. — putnik 22:45, 14 марта 2021 (MSK)

Ну, может быть, по каким-то причинам на сайте не отображается, хотя номер официально присвоен. Необычная история, раньше я такого не видел. AndyVolykhov (обсуждение) 23:21, 14 марта 2021 (MSK)

Предложение по функционированию CHEBOT

Экспорт осуществляется ежедневно для страниц, у которых изменилась ревизия (проверяется при ежесуточном обновлении "карточек" ОКН).
Для ОКН, у которых задан wdid, выполняется обновление полей сущности.
Если wdid не задан, создаётся новая сущность при выполнении следующих условий: есть координаты, нет dismissed, нет status=destroyed (такой ОКН можно занести в Викиданные через #CHEΓ и впоследствии его сущность будет обновляться).

Для создания новой сущности используется та же процедура, что и в #CHEΓ.

Обновление (далее под карточкой подразумевается запись из базы данных Викигида):

• метка (label) не обновляется;
• P17 (country): если не задано Q159 (Russia), то будет также создано утверждение Property:P17 со значение Russia и квалификатором start time 18.03.2014 (для ОКН на 82xxx и 92xxx) или 25.12.1991 (для остальных ОКН);
• P18 (image): задаётся, только если утверждение отсутствует;
• P1483 (knid): проверяется, что утверждение имеет единственное значение, совдающее с knid карточки, если нет — обновляется;
• P2817 (appears in the heritage monument list): проверяется, что утверждение имеет единственное значение, совпадающее с сущностью страницы-списка, если нет — обновляется;
• P2186 (WLM ID): проверяется, что утверждение имеет значение, совпадающее с knid карточки (для крымских объектов допустимы два значения: knid и uid), если нет — обновляется;
• P361 (part of): если для головного элемента комплекса имеется сущность, проверяется, что одно из утверждений для P361 содержит это значение, если нет — добавляется новое утверждение;
• P5381 (egrokn), P8316 (sobory), P9343 (temples): если для карточки задано knid-new/sobory/temples, проверяется, что утверждение имеет единственное значение, совпадающее с knid-new/sobory/temples карточки, если нет — обновляется;
• P31 (instance of): проверяется, что одно из утверждений для P31 содержит значение, соответствующее типологии карточки (landmark / historic site / monument / archaelogical site / historical city in Russia), если нет — добавляется новое утверждение. Также проверяется, что instance of не содержит "Cultural heritage site in Russia" (это значение предусмотрено для heritage designation), которое при необходимости удаляется;

Только при создании или если сущность содержит единственное значение P31, соответствующее типологии: Если наименование содержит слово «церковь», будет добавлено P31=d:Q16970. Если наименование содержит слово «часовня», будет добавлено P31=d:Q1975485. Если наименование содержит слово «дом» или «здание», будет добавлено P31=d:Q41176.

• P1435 (heritage designation): проверяется, что одно из утверждений для P1435 содержит значение, соответствующее статусу охраны (d:Q105835774 — для выявленного, d:Q23668083 — для федерального, d:Q105835744 — для регионального, d:Q105835766 — для местного ОКН, d:Q105835782 — для объектов "с признаками" или d:Q8346700, если protection в карточке не указано), если нет — обновляется (утверждения для P1435 со значением не из этого списка сохраняются).
• P131 (located in ATE): если в карточке задано munid и оно не совпадает с wdid (т.е. ОКН не является поселением, для поселений P131 не трогается), проверяется, что утверждение имеет единственное значение, совдающее с munid карточки, если нет — обновляется;
• P2795 (directions): если в карточке непустой адрес, проверяется, что осутствуют утверждения для P6375 (street adreess) и P669 (located on street) (при наличии таких утверждение обновление не происходит), проверяется, для утверждения P2795 на языке "ru" отсутствует или отличается значение — в таком случае происходит обновление (добавление утверждения);
• P625 (coordinates): если в карточке заданы непустые координаты (lat, long), проверяется, что утверждение имеет единственное значение, отличающеется от lat, long в карточке не более, чем на 30 м, если нет - обновляется; если у сущности несколько утверждений P625 — обновление не производится;
• P571 (inception): если в карточке задано поле year, в котором можно угадать 4-значное число, и для сущности утверждение P571 отсутствует, оно добавляется (если утверждение для P571 уже имеется, поле пропускается);
• P576 (abolished...): если в карточке задано status=destroyed и для сущности утверждение P576 отсутствует, оно добавляется со значением somevalue (если утверждение для P576 уже имеется, поле пропускается);
• P373 (commons category): если в карточке значение commonscat непустое и утверждение P373 отсутствует, оно создаётся (если утверждение P373 уже есть, оно не изменяется);
• commonswiki: если в карточке значение commonscat непустое, у указанной категории Викисклада отсутствует привязанный элемент Викиданных и у сущности ОКН отсутствует привязка commonswiki, то сущность ОКН привязывается к этой странице катагории Викисклада (если привязка к commonswiki уже есть, она не меняется);
• ruwiki: если в карточке значение wiki непустое, у указанной страници РВП отсутствует привязанный элемент Викиданных и у сущности ОКН отсутствует привязка ruwiki, то сущность ОКН привязывается к этой странице РВП (если привязка к ruwiki уже есть, она не меняется).

Алексей С. (обсуждение) 20:57, 29 марта 2021 (MSK)

Запрос бота: d:Wikidata:Requests_for_permissions/Bot/AVSBot. Алексей С. (обсуждение) 21:07, 29 марта 2021 (MSK)

Мне кажется, всё хорошо.--Ymblanter (обсуждение) 23:52, 29 марта 2021 (MSK)

Я одобрил бота, сделайте, пожалуйста, ему на Викиданных локальную страницу, чтобы претензии по боту шли Вам в Викиданные, а не на мету.--Ymblanter (обсуждение) 22:35, 2 апреля 2021 (MSK)

Сделал. Алексей С. (обсуждение) 22:47, 2 апреля 2021 (MSK)

Не предусмотрено удаление утверждений.

Сейчас попадаются такие случаи: в Викиданных номер ЕГРОКН приписан к комплексу в целом (типа "монастырь"), потому что о нём есть Вики-статья, а в Викигиде естественно комплекс расписан поэлементно и номер ЕГРОКН приписан куда надо (как будто бы). Когда CHEBOT будет создавать сущности элементов комплекса, получится, что он повторно использует номер ЕГРОКН.

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

С другой стороны, касательно ЕГРОКН с нашей стороны ситуация как будто бы надёжно контролируется: у нас есть missing_egrokn, где перечислены ещё неиспользованные номера ЕГРОКН, а на странице duplicate-wdid перечислены несовпадения по номерам ЕГРОКН у Викиданных с Викигидом. Описанная выше ситуация чаще всего наблюдается для тех строк, где в колонке egrokn стоит WV_MISSING. Их не очень много и можно разрулить вручную. Алексей С. (обсуждение) 22:48, 31 марта 2021 (MSK)

Тут я не совсем понял. Из текста выше вроде бы не следует, что, когда у элементов комплекса нет своего ЕГРОКН, бот будет добавлять им ЕГРОКН головного объекта. Я что-то упустил? --Alexander (обсуждение) 00:54, 1 апреля 2021 (MSK)

Пример: [2]. К ОКН 3200546000 (комплекс — Ансамбль Покровского монастыря) привязана сущность Q16663995 (Климовский Покровский монастырь). У сущности указан номер ЕГРОКН 321610499420005 (Покровский собор). И в Викигиде этот номер ЕГРОКН привязан не к комплексу в целом, а к элементу комплекса — 3200546001 (Покровскому собору). Когда бот будет проходить по странице Климовского района, он создаст недостающие сущности Покровского собора и Николаевской церкви. В результате упомянутый номер ЕГРОКН — 321610499420005 — окажется у двух сущностей: у старой сущности комплекса (Q16663995), потому что удаление утверждений не предусмотрено, и у новой сущности Покровского собора.

Как будто бы таких ситуаций немного, но натыкаюсь я на них уже не единожды, и не дважды, и не трижды. Вот и возник вопрос, не надо ли здесь "навернуть" что-то более интеллектуальное. Алексей С. (обсуждение) 01:33, 1 апреля 2021 (MSK)

По-моему, всё хорошо. Спасибо! Единственное сомнение у меня возникло по поводу P571, где иногда бывает более одной четырёхзначной даты: строительство, реконструкция и т.д. Что будет происходить в этом случае? --Alexander (обсуждение) 00:55, 1 апреля 2021 (MSK)

В inception будет записана первая (вероятно самая ранняя) дата Алексей С. (обсуждение) 01:20, 1 апреля 2021 (MSK)

При создании новых сущностей скриптом CHEBOT User:AVSBot будет изменять страницы списков, внося в них wdid новых сущностей, например, так: [3]. Надо ли мне для этой цели получить и использовать права бота в Викигиде? Алексей С. (обсуждение) 23:33, 2 апреля 2021 (MSK)

Да, надо — иначе мы забьём список свежих правок. Игорь, выдашь права бота? --Alexander (обсуждение) 23:47, 2 апреля 2021 (MSK)

Alexander, done. Digr (обсуждение) 15:50, 4 апреля 2021 (MSK)

Значение для P1435

Заданием для quickstatements #53564 Участник:Infovarius добавил к сущностям ОКН дополнительное значение d:Q8346700 для утверждения P1435 (heritage designation), при том что более точный класс с учётом категории охраны в этих утверждениях уже был задан. Обсуждение задания -- d:Wikidata:Edit groups/QSv2/53564‎ Алексей С. (обсуждение) 12:00, 27 апреля 2021 (MSK)

Ярослав, Саша, кому-нибудь удалось добиться от Infovarius пояснений, что он делает?

Появились его собственные версии обозначений категорий охраны ОКН: я нашёл, как минимум d:Q106636485, d:Q106636489, d:Q106636501. В новом задании #53632 он сносит имеющиеся утверждения для P1435 с ссылками на документы, устанавливая свои вот эти значения. Алексей С. (обсуждение) 00:10, 28 апреля 2021 (MSK)

Нет, не удалось. Может, объединить свойства?--Ymblanter (обсуждение) 00:17, 28 апреля 2021 (MSK)

Скорее всего, придётся объединить. Но ведь человек же какую-то цель преследует? Не может же быть, что он не увидел существующие свойства? Может, существующие его чем-то не устраивают? Алексей С. (обсуждение) 00:26, 28 апреля 2021 (MSK)

А он исправил бардак с добавлением давно исчезнувших государств без соответствующего ранга? Или так всё по-прежнему и висит? --Alexander (обсуждение) 00:39, 28 апреля 2021 (MSK)

Я боюсь, что эти ситуации будут возникать постоянно, как и на Викискладе. Рецепт тут, на мой взгляд, один: бот, который как можно чаще обновляет все актуальные поля на основании наших списков. И не колышет. --Alexander (обсуждение) 00:39, 28 апреля 2021 (MSK)

Позвольте объясниться. Начал я с чистки согласно d:Talk:Q8346700. Потом я увидел, что число объектов, имеющих (общий) статус наследия России, меньше, чем число статей в категории и добавил отсутствующие. Признаю, что не заметил малочисленные более точные классы и вообще не заметил эти элементы, т.к. они никак не были связаны с основным. Т.е. я думал, что никаких уточняющих классов и нет (о чём, кстати, написал в Дискорде, где User:Putnik ответил мне, что "Если они там сами не порешают, то я где-нибудь ко вторым майским доберусь"). Поэтому я решил сам уточнить классы и сначала их создал. Конечно, это дубликаты и спасибо Алексею С. за их объединение. Ещё какие-то проблемы (от меня или другие по этому вопросу) остались? Infovarius (обсуждение) 16:58, 29 апреля 2021 (MSK)

@Infovarius, замечу, что процитированная вами фраза была продолжением другой: «Элементы созданы. При заливке из Викигида должны проставиться более точные значения». — putnik 19:49, 29 апреля 2021 (MSK)

@Infovarius, с моей стороны два пожелания. Одно — обсуждать на этой странице любые массовые изменения в Викиданных, связанные с российскими ОКН, а второе — проставить пониженный ранг для старых значений свойства P17. У нас из-за этого по-прежнему не всё работает так, как хотелось бы. Спасибо заранее. --Alexander (обсуждение) 23:56, 29 апреля 2021 (MSK)

Копирую объекты в Wikidada самописным скриптом

со страницы вопросов и комментариев

Я с 2015 года слежу за проектом, мне не хватало удобного интерфейса для просмотра, а теперь я обнаружил что появился https://maps.wikilovesmonuments.org/map - он показывает из wikidata объекты со статусом "культурное наследие"

Я написал скрипт с использованием pywikibot, и начал им не спеша вручную копировать объекты в wikidata c некоторых страниц. Процесс импорта такой:

- Из страницы со списком генерируется файл gpkg с координатами. Я его правлю в QGIS: добавляю координаты там где их нет, раздвигаю комплексы на отдельные здания. Изменёные координаты отправляются в wikivoyage

- Список обьектов со страницы импортируется в БД, я открываю таблицу и вручную подправляю названия/свойства wikidata. По готовым записям создаются объекты wikidata, ссылки на них записываются на страницу wikivoyage.

Это не бот, а ручной скрипт, полностью автоматизировать это сложно.

Описание маппинга списка wikivoyage в свойства Wikidata: https://github.com/trolleway/wikivoyage2wikidata/blob/main/helpers/set_wikidata_names.sql

Пример экспортированного списка: Культурное наследие России/Москва/Центральный округ/От Пятницкой до Озерковской наб.

Копируются свойства:

- Название объекта берётся из адреса. Я решил что так лучше чем строительное название здания

- Название памятника (Усадьба графа такого-то) записывается в алиас

- Частный случай: "Памятник архитектуры" + Здание/Усадьба/Забор/... по списку

- Часть от: ссылка на главный объект в комплексе

- Ссылка на commons: добавляется, если её пропускает утилита wikibase-cli, она проверяет чтобы в wikidata был только 1 объект с уникальной ссылкой

- Адрес, административная единица, страна, координаты. Создаются только объекты с известными координатами, потому что мне нужна карта

- Источники: код kulturnoe-nasledie.ru, код WLM. Добавлять ссылки на разные постановления советов народных депутатов за 1974 год я не осилил. Svetlov Artem (обсуждение) 21:55, 23 февраля 2023 (MSK)

@Svetlov Artem, замечательно! Но посмотрите, пожалуйста, вот эту тему и уточните у Алексея, чтобы ваши усилия не нарушили тот процесс, который он ведёт уже пару лет. -- Alexander (обсуждение) 22:43, 23 февраля 2023 (MSK)

Есть бот, который который умеет экспортировать страницу целиком (и при модификации страницы — обновлять элемнты ВД) — AVSbot/chebot. Он правда работает не для всех страниц, а только для «белых». Я потихонечку добавляю в белый список страницы, когда вижу, что опытные участники над ними поработали и большого количества противоречий (например, таких или таких) на них быть не может.
И он, кстати, делает ссылки на постановления народных депутатов, если они в ВГ есть :) Алексей С. (обсуждение) 23:19, 23 февраля 2023 (MSK)

Свежие изменения в ботохозяйстве

• P131 (located in ATE): если в карточке не задано munid, подставляется P131 из элемента Викиданных страницы списка. Например, если ОКН с незаданным munid находится на странице списка N-ского района, в этот ОКН будет подставлено P131 N-ского района. Раньше в таком случае свойство не задавалось.

• P373 (commons category). Было: "Если в карточке значение commonscat непустое и утверждение P373 отсутствует, оно создаётся (если утверждение P373 уже есть, оно не изменяется)." Стало: "Если при обновлении информации в карточке значение commonscat пустое и в элементе Викиданных утверждение P373 отсутствует, то в элемент Викиданных подставляется утверждение P373 со значением из Module:Monument/commonscat. Если в карточке значение commonscat непустое и утверждение P373 отсутствует или равно ``Cultural heritage monuments in...``, то создаётся/изменяется утверждение P373 со значением commonscat, если оно не противоречит интервики-ссылке commonswiki".

• В отчёте User:Avsolov/duplicate-wdid скорректирована проверка на противоречие координат для элементов Викиданных с несколькими утверждениями P625. Если координаты хотя бы одного из этих утверждений находятся вблизи (<100 м) координат карточки, противоречие не фиксируется.

• В отчёт User:Avsolov/duplicate-wdid добавлен раздел "Несоответствия категорий Викисклада". Туда попадают следующие ситуации: commonscat в карточке не совпадает с P373 элемента Викиданных, а также когда в элементе Викиданных P373 есть, а в карточке commonscat пустое (кроме случаев, когда P373 содержит "Cultural heritage monuments in...").

Алексей С. (обсуждение) 22:55, 14 апреля 2023 (MSK)

Большое спасибо! --Alexander (обсуждение) 19:38, 15 апреля 2023 (MSK)

Включить бота для Омской области

Я заметил, что бот, генерящий и связывающий с объектами списков ОКН элементы викиданных для объектов с точно установленными координатами, работает не по всем регионам. Как бы его включить на давно приведённую в порядок Омскую область? Mib5578 (обсуждение) 09:08, 10 марта 2024 (MSK)

Уточнил название темы. И можно сразу пинговать Лёшу. --Alexander (обсуждение) 12:03, 10 марта 2024 (MSK)

Сделаю в течение нескольких дней.
Я сразу всю область не включаю, чтобы не пропустить ошибки — по две-три страницы за раз. Алексей С. (обсуждение) 15:59, 10 марта 2024 (MSK)

Спасибо! А где можно контролировать наличие возможных ошибок? Mib5578 (обсуждение) 18:53, 10 марта 2024 (MSK)

Журнал тут — https://ru-monuments.toolforge.org/snow/last_chebot_log.txt, но у меня не дошли руки где-то прокомментировать, как его интерпретировать... Алексей С. (обсуждение) 20:15, 10 марта 2024 (MSK)

Ну там, в принципе, на первый взгляд всё понятно, буду посматривать. Mib5578 (обсуждение) 20:30, 10 марта 2024 (MSK)