Обсуждение Wikivoyage:Википроект:Перенос списков КН в Викиданные

Общие вопросы

Таблицы википроекта - это просто мой набросок для обсуждения. Тут могут быть ошибки и неточности. Сразу видно, что у нас есть два вида проблем и задач. Сложные вопросы - например, тип и категория охраны (я бы назвал это главнейшим и самым сложным). Вопросы попроще - какой объект использовать или нужно ли нам новое свойство для хранения параметра нашего шаблона. Для обсуждения любого вопроса, по моему мнению, надо создавать на этой СО новую тему. Зеленым цветом в таблице отмечены свойства, по которым у сообщества уже выработался стойкий консенсус. :-) --Voll (обсуждение) 13:50, 20 февраля 2016 (MSK)

Мы говорим о переносе списков, переносе памятников, или и о том, и о том? Если списков, то, в принципе, мы же с Вами два года назад создали неплохие образцы, например, тут всё в порядке, надо просто по этому образцу сделать и всё остальное (обращая внимание на то, что по России у нас иногда города регионального подчинения в списках объединены с районами, и в таких случаях надо проставлять несколько параметров в P131. Что касается самих объектв, мы возвращаемся к вопросу о том, что являетсй объектами - часть из них мы просто руками добавили в списки, так как не смогли найти соотвтетствующие документы. По Украине и Латвии (и по Белоруссии, если возьмётесь - я могу помочь) таких проблем не должно быть. --Ymblanter (обсуждение) 14:11, 20 февраля 2016 (MSK)

И о том, и о том. Про образец - создам новую тему - там есть вопросы. По объектам - не вижу проблем, вся разница будет в наличии или отсутствии свойства код Русского Викигида / kulturnoe-nasledie.ru (P1483). Списки Белорусии - посмотрю. --Voll (обсуждение) 14:59, 20 февраля 2016 (MSK)

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

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

По загрузке в Викиданные самих объектов: есть две проблемы. Одну сформулировал Ярослав, но мне она кажется не очень серьёзной. Мы можем начать с объектов заведомо официальных, благо они легко отличимы по номерам, и уже это работа на многие месяцы. Вторая проблема состоит в том, что некоторые объекты имеют карточки Викиданных, но эти карточки не привязаны к спискам. Это характерно также для других упомянутых здесь стран: например, интерфейс украинских списков позволяет привязывать статьи только из украинской Википедии, а бывают объекты, о которых есть русские статьи, но нет украинских. --Alexander (обсуждение) 14:42, 20 февраля 2016 (MSK)

Конечно элементы для списков будут созданы раньше - там легче все сделать и они нужны при создании элементов объектов. По первой проблеме ответил выше. Что касается второй проблемы, то для нее невозможно придумать алгоритм и нам придется все делать руками. Но есть и хорошая новость - в Викиданных все делать легче. Даже если мы создадим массу дублей для памятников наследия, найдутся люди которые создадут запросы, помогающие нам найти эти дубли. А вот пока они находятся только здесь - нам никто не поможет. По моему мнению, именно в последний год в Викиданных стали серьезно улучшать связность и проверяемость. Но это тема отдельного разговора. --Voll (обсуждение) 15:36, 20 февраля 2016 (MSK)

Давай тогда с элементов списков и начнём? Там ещё будет очаровательная деятельность по привязке категорий Commons, что придётся частично делать вручную. --Alexander (обсуждение) 16:29, 20 февраля 2016 (MSK)

Списки наследия в Викиданных - связывание с регионом

Сейчас в Викиданных используются 2 варианта

• просто административно-территориальная единица (P131) = Гатчина (Q7436) - именно этот вариант сейчас у нас
• в этом списке перечисляются (P360) = объект культурного наследия России (Q8346700) и к нему квалификатор административно-территориальная единица (P131) = Гатчина (Q7436)

Используются они там примерно поровну: первый - 2900 раз, второй - 2200 раз. Второй вариант выглядит правильнее (так как список не объект, он не может находиться в регионе, а вот объекты из списка - могут), но, скорее всего, обслуживать его будет труднее. Будем искать правду в форуме Викиданных? --Voll (обсуждение) 21:31, 20 февраля 2016 (MSK)

В принципе, можно оба использовать, они не взаимоисключающие.--Ymblanter (обсуждение) 21:51, 20 февраля 2016 (MSK)

В общем, можно использовать оба варианта, потом, если P131 не пригодится, удалим его из элементов - это очень просто будет сделать. --Voll (обсуждение) 00:01, 24 февраля 2016 (MSK)

Списки наследия в Викиданных - часть чего?

Для значений свойства является частью (P361) существуют (используются) такие варианты:

• список памятников культурного наследия Ленинградской области (Q18135062) - здесь мы пытаемся выстроить дерево до регионов, которые подвязываются к регистру памятников
• Единый государственный реестр объектов культурного наследия (Q7382189) - здесь любой список сразу связан с регистром памятников
• еще можно списки связывать не с регистром, а с корневой страницей наших списков и тогда все списки могут содержать объекты, не входящие в регистр.

Тут тоже надо выбрать правильный вариант. --Voll (обсуждение) 21:42, 20 февраля 2016 (MSK)

Я, естественно, за связь с реестром верхнего образца.--Ymblanter (обсуждение) 21:45, 20 февраля 2016 (MSK)

Я правильно понимаю, что ты выбрал вариант с деревом? --Voll (обсуждение) 23:59, 23 февраля 2016 (MSK)

Завтра посмотрю, сегодня что-то не могу понять.--Ymblanter (обсуждение) 00:11, 24 февраля 2016 (MSK)

Я не очень внятно написал. Дерево - это когда в элементе списка КН Гатчины в свойстве P361 указан элемент списка КН Ленинградской области, а в элементе списка КН Ленинградской области (как региона верхнего уровня) в свойстве P361 указан элемент Единый государственный реестр объектов культурного наследия (Q7382189).

А второй вариант это когда и в элементе списка КН Гатчины, и в элементе списка КН Ленинградской области в свойстве P361 стоит одно и то же - Единый государственный реестр объектов культурного наследия (Q7382189). --Voll (обсуждение) 13:46, 24 февраля 2016 (MSK)

Я за первый вариант. --Alexander (обсуждение) 13:49, 24 февраля 2016 (MSK)

Да, правильно (за список по Ленинградской области, то есть за вариант с деревом).--Ymblanter (обсуждение) 01:06, 26 февраля 2016 (MSK)

Нам ещё вот такое предложили: [1]--Ymblanter (обсуждение) 20:34, 22 февраля 2016 (MSK)

Это мзменение как раз и есть второй вариант из предыдущей темы. И в результате в элементе есть и первый вариант (чистый P131), и второй вариант (P360 + P131/как_квалификатор). --Voll (обсуждение) 23:59, 23 февраля 2016 (MSK)

Итого - по спискам вопросов больше нет. Я еще перетру со своим коллегой, заодно подумаем как лучше создавать элементы для вас. --Voll (обсуждение) 18:39, 26 февраля 2016 (MSK)

А теперь о памятниках

Все последующие обсуждения уже будут касаться собственно оформлению памятников в Викиданных - т.е. раговор пойдет о нужных нам свойствах и связыванию их с данными в списках. --Voll (обсуждение) 15:31, 10 апреля 2016 (MSK)

Совсем выбрасывать какие-то поля очень не хочется - так как для меня будет идеально, если я смогу из ВД сгенерировать точно такой же список, каким он был изначально - это позволит заменить сегодняшний список памятников на генерируемый список. --Voll (обсуждение) 18:41, 10 апреля 2016 (MSK)

Не позволит, потому что кто-то где-то должен список редактировать, а редактирование российских списков будет продолжаться вечно. Таким образом, речь идёт только о создании (пока не очень понятно кем) копии списков из Викигида при помощи Викиданных. --Alexander (обсуждение) 18:51, 10 апреля 2016 (MSK)

И то, и другое сейчас обсуждать рано - давайте дождемся какого-нибудь результата в латвийских списках. Но, когда настанет то время прекрасное и у меня (или у кого-то другого) всё получится, лучше конечно в Викиданных иметь как можно больше информации из текущих списков, так что прошу подумать как импортировать каждое поле шаблона, а не просто говорить: "давайте их туда не импортировать". И, кстати, ваши ответы и идеи здесь очень помогают мне в латвийском разделе - так как там мне советоваться по полям шаблонов не с кем. --Voll (обсуждение) 19:36, 10 апреля 2016 (MSK)

Идентификатор списка в Викиданных

Сперва я запланировал, что указание того, в каком списке встречается памятник, будет сделано через свойство является частью (P361). Технически тут нет проблемы, но есть чисто политический вопрос - может быть стоит создать специальное свойство для нашего проекта: "является частью списка памятников культурного наследия"? Во-первых, это красиво ;-), во-вторых это позволит отделить два случая - памятник является частью списка памятников и памятник является частью комплекса памятников. Что думаете по этому поводу? --Voll (обсуждение) 15:40, 10 апреля 2016 (MSK)

Я за отдельное свойство, если, конечно, его удастся создать. --Alexander (обсуждение) 16:22, 10 апреля 2016 (MSK)

Я не против, но надо бы сначала посмотреть, как это сделано у других. Например, по нидерландам все и списки, и памятники давно лежат в Викиданных.--Ymblanter (обсуждение) 18:12, 10 апреля 2016 (MSK)

Я пока не готов писать всеобъемлющий запрос, но несколько выбранных в ВД голландских списков Амстердама не имеют обратных ссылок на себя - т.е. памятники на них не ссылаются. Т.е. напрашивается вывод, что Нидерланды не реализовали такой функционал, и в ВД памятники и списки друг про друга не знают. При этом является частью (P361) активно используется, но только для комплексов (для более чем 14000 памятников из 65000). --Voll (обсуждение) 19:11, 10 апреля 2016 (MSK)

Написал запрос. Только лишь 5 голландских памятников (и все они из этого списка - "Lijst van rijksmonumenten in Roermond (plaats)") имеют является частью (P361) указывающий не на элемент комплекса, а на список памятников. --08:59, 17 апреля 2016 (MSK)

Подводим итог - мы за отдельное свойство. --Voll (обсуждение) 08:59, 17 апреля 2016 (MSK)

Год постройки

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

Точно также я хочу предложить создать новое свойство для указания года постройки памятника. Да у нас уже есть дата возникновения (P571), но его недостаточно для наших данных. Вот один из ярких примеров даты создания одного памятника: 1207 - 1209 г.г., XIII - нач. XVI века, кон. XIX века. В дата возникновения (P571) это не уложишь. Поэтому предлагаю созадть новое свойство для нашей задачи. Рабочее название пока такое: inception period; период создания; період створення; izveides laikposms. Напрашивается что-то более грамотное, но ничего в голову не приходит. --Voll (обсуждение) 16:38, 10 апреля 2016 (MSK)

А разве P571 запрещает множественные даты? --Alexander (обсуждение) 17:42, 10 апреля 2016 (MSK)

Да, запрещает. Это первое что не позволяет использовать свойство дата возникновения (P571)

Второе - я очень хочу при переносе поменьше выполнять сложной работы (а это очень сложно предусмотреть все варианты дат).

Кстати, твой вопрос дает понять, что в поле шаблона у нас не только дата первоначального создания памятника, но и даты его переделок. Может про переделки как-то упомянуть в названии свойства - что-то вроде "дата создания и переделок"? --Voll (обсуждение) 18:11, 10 апреля 2016 (MSK)

Да, в российских списках всегда указываются и дата создания, и даты значительных переделок. Раз Ярослав говорит, что голландские списки уже в Викиданных, советую для начала посмотреть, как сделано там. В принципе, у нас (как и в официальных источниках) поле year= представляет собой ту ещё кашу. --Alexander (обсуждение) 18:56, 10 апреля 2016 (MSK)

Голландцы не переносили год в ВД. У них в ВД всего 200 годов на 65000 памятников, т.е. они сделаны вручную. Либо их испугало то же самое, что и нас, либо они заливали не из списков, а из БД конкурса, где год не используется. --Voll (обсуждение) 19:19, 10 апреля 2016 (MSK)

Подводим предварительный итог - никто не против отдельного свойства для этого поля шаблона. --Voll (обсуждение) 09:12, 17 апреля 2016 (MSK)

Место

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

К тому же ситуация с этим полем шаблона/свойством очень похожа на предыдущий топик (почему я их и разместил рядом). Тоже уже есть местонахождение (P276), но его не хватает для занесения таких мест как "от села Петровки 3 километра по левому берегу Оки", "в 10 километрах от села рядом с водопадом на речке Смуглянке".

Поэтому я хочу предложить создать новое свойство для указания как можно найти место, где находится памятник или любой другой объект. Рабочее название пока такое: locality; место; місце; vieta. По-моему мнению название неплохое, но всегда рад обсуждению и открыт предложениям. --Voll (обсуждение) 16:53, 10 апреля 2016 (MSK)

Я не вижу, чем это принципиально отличается от адреса. Если есть нормальный адрес, то уточнений типа "в 250 м от колодца" в списках не бывает. Если же адреса в привычном смысле нет, то расположение объекта и в официальных документах задаётся как "в 3 км от села по левому берегу Оки" — см. все памятники археологии. То есть новое свойство создать можно, но мы на него не рассчитывали, а кроме того надо не перестараться с созданием новых свойств, иначе это будет очередной Викисклад: сотни ветвей категорий, о которых никто не знает, как они устроены и зачем нужны. --Alexander (обсуждение) 17:39, 10 апреля 2016 (MSK)

Ещё, кстати, есть координаты.--Ymblanter (обсуждение) 18:13, 10 апреля 2016 (MSK)

Нашел у себя 580 памятников у которых в официальном списке есть и адрес, и место. Конечно, по большей части, это просто уточнения по поводу организаций которые находятся в здании (так как часто название сооружения это не отражает): Латвийская госуд. филармония, Кинотеатр "Рига", Лимбажский музей, Военный порт и т.п. Есть микрорайоны (ха, значит и кварталы подойдут). Также встречаются такие места, как "зал на втором этаже", "в вестибюле" и т.п. Так что, как видите, очень полезное во всех смыслах свойство. --Voll (обсуждение) 18:36, 10 апреля 2016 (MSK)

Самая прямая аналогия — поле directions= в шаблоне listing. Да, во многих ситуациях эти уточнения могут быть полезны. --Alexander (обсуждение) 18:53, 10 апреля 2016 (MSK)

Подводим предварительный итог - никто не против этого отдельного свойства. К тому же оно будет полезно для опсания кварталов и в Викигиде. --Voll (обсуждение) 09:10, 17 апреля 2016 (MSK)

Квартал

Не уверен, что с ним делать. Это точно не административно-территориальная единица (P131). Этот параметр очень похож на предложенное мной ранее "место" - как раз номер квартала (пока у нас кварталы указаны только для Краснодара и Волжского и там только номера) помогает найти место, где расположено здание. Т.е. что-то вроде "квартал №15". Подходящая идея? --Voll (обсуждение) 17:08, 10 апреля 2016 (MSK)

Я не против такого варианта, хотя думаю, что в первом приближении этими кварталами можно пренебречь. Их действительно мало. --Alexander (обсуждение) 17:40, 10 апреля 2016 (MSK)

Как я уже написал выше, латвийские списки активно используют поле шаблона "место" для микрорайонов в Риге. Так что это хороший вариант. Совсем выбрасывать какие-то поля очень не хочется - так как для меня будет идеально, если я смогу из ВД сгенерировать точно такой же список, каким он был изначально - это позволит заменить сегодняшний список памятников на генерируемый список. --Voll (обсуждение) 18:41, 10 апреля 2016 (MSK)

Не позволит, потому что кто-то где-то должен список редактировать, а редактирование российских списков будет продолжаться вечно. Таким образом, речь идёт только о создании (пока не очень понятно кем) копии списков из Викигида при помощи Викиданных. Я думаю, что этот неизвестный будущий пользователь без номеров кварталов переживёт, но, как уже говорилось, я не против того, чтобы отправить номер квартала в "уточнение адреса". --Alexander (обсуждение) 18:51, 10 апреля 2016 (MSK)

Подводим итог: заносим значение этого поля в новое свойтво "место" ("уточнение адреса"). --Voll (обсуждение) 09:14, 17 апреля 2016 (MSK)

Точность определения координат

Интересное поле в шаблоне. Не могу придумать как его реализовать без создания нового свойства. В латвийской части мы решили вообще отказаться от его использования. В русской части на 20000 координат "precise=no" встречается всего 80 раз. Вам решать, что с ним делать. Как один из возможных вариантов - опять же использовать свойство место/locality и неточные координаты заменить на неточное описание того, как найти нужное место. --Voll (обсуждение) 17:29, 10 апреля 2016 (MSK)

Зато часто не используется precise=yes, и это означает, что координаты определены неточно. Для начала можно это свойство вообще никуда не переносить. Оно важнее редакторам, нежели читателям. Читатели же, глядя на карту, не видят разницы между точными и неточными координатами. --Alexander (обсуждение) 17:33, 10 апреля 2016 (MSK)

Я считаю, что надо переносить только точные координаты. Несколько дней назад это обсуждалось на форуме Викиданных.--Ymblanter (обсуждение) 18:14, 10 апреля 2016 (MSK)

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

• Предпочтительный ранг = precise=yes
• Нормальный ранг = precise= или отсутствие поля в шаблоне
• Нерекомендуемый ранг = precise=no

Для предпочтительного ранга необходимо будет также создать квалификатор метод определения (P459) = ну, например, "ручная проверка редактором Викигида".

А все координаты которые уже были в элементах или будут добавлены редакторами других разделов получат нормальный ранг, что тоже соответствует нашим требованиям к координатам. --Voll (обсуждение) 08:23, 17 апреля 2016 (MSK)

Внешняя ссылка (link) и Дополнительная внешняя ссылка (linkextra)

Здесь надо выбирать. Есть простое техническое решение - использовать официальный сайт (P856). Там где есть и link, и linkextra - вводить официальный сайт (P856) два раза. Технически просто, но наши ссылки - не официальный сайт.

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

Есть еще вариант последовательного подхода - попробовать слегка причесать наши ссылки. Всего у нас 6000 ссылок, 3 тысячи из них sobory.ru. Создав новое свойство для сайта sobory.ru мы сможем ссылаться на страницу сайта из элемента Викиданных. Потом придется разбираться с остальными 3 тысячами ссылок.

Т.е. тут нет легких путей и нам придется чем-то поступиться или что-то придумать. --Voll (обсуждение) 17:54, 10 апреля 2016 (MSK)

Вот тут предлагаю вообще не заморачиваться и эти параметры просто не трогать. Не будет их пока в Викиданных, и ладно. sobory.ru в той же русской Википедии не любят, поскольку это не авторитетный источник, так что создание под них своего отдельного свойства может рано или поздно вызвать вопросы. --Alexander (обсуждение) 17:59, 10 апреля 2016 (MSK)

Я был не прав. Уже есть свойство для неофициального сайта - описывается по ссылке (P973) и оно используется в Викиданных 113 тысяч раз. Так что нет никакой проблемы вообще. --Voll (обсуждение) 15:11, 11 апреля 2016 (MSK)

Подводим итог - все уже есть, ничего придумывать не надо. --Voll (обсуждение) 09:15, 17 апреля 2016 (MSK)

Автор объекта

Вот пример того как в нашем списке описывается, кто строил и перестраивал памятник: арх. Кваренги Д., 1807 г., арх. Кваренги Д., 1807-1808 гг., арх. Кваренги Д., 1810-е гг., 1860-е гг., 1878 г. (восстановление), 1899-1910-е гг., 1923-1924 гг., арх. Гельфрейх В.Г., арх. Щуко В.А., 1923-1934 гг., арх. Гельфрейх В.Г., садовый маст. Так же написано и на официальном сайте. Тут поможет только новое свойство, что-то вроде "список создателей во времени". --Voll (обсуждение) 17:03, 11 апреля 2016 (MSK)

Я обычно делил подобные списки, ставя авторов и даты отдельно. Таким образом, в обычном случае у нас авторы идут списком без дат и наоборот. При этом, наверное, теряется информация о том, кто когда строил, но она с самого начала не была толком упорядочена: например, из приведённого списка неясно, кто был автором переделок 1860-х гг. и 1878 г. --Alexander (обсуждение) 17:17, 11 апреля 2016 (MSK)

Статус

Тут у нас мешанина:

• destroyed - 732
• Выявленный - 311
• Региональный - 184
• Федеральный - 10
• перестроен - 1

Итак

• "перестроен" можно проигнорировать
• "Региональный" и "Федеральный" относятся к статусу в регистре КН, они будут учтены в другом свойстве
• "Выявленный" - подскажите, этот статус ведь также отражается и в коде объекта?
• "destroyed" - помнится было обсуждение на форуме Викиданных на эту тему, если никто не помнит, я поищу.

Хорошо, с эти полем шаблона разберемся позже. --Voll (обсуждение) 17:59, 11 апреля 2016 (MSK)

Честно говоря, я не знаю, кто и зачем вписывал в поле status= значения "Федеральный", "Региональный" и "Выявленный". Федеральный отмечается единицей на третьей позиции номера, Региональный и Выявленный никак не отмечаются, ну так они и на kulturnoe-nasledie.ru были вперемешку. В нашем случае 0 или 2 на третьей позиции — это объекты не-федерального статуса с kulturnoe-nasledie.ru (могут быть и региональными, и выявленными), а 3 на третьей позиции — это наша самодеятельность на базе региональных реестров (тоже могут быть и региональными, и выявленными, хотя выявленных в этой группе больше). --Alexander (обсуждение) 18:03, 11 апреля 2016 (MSK)

Тип памятника и категория охраны

Стандартное свойство для хранения такой информации - статус наследия (P1435). А у нас, как видите, два параметра шаблона. Кстати, в латвийских списках ситуация такая же. Так что у нас есть 2 варианта:

• вынести тип памятника в отдельное свойство (квалификатор). Это может быть как новое, так и существующее уже свойство. Хороший вариант - что-то вроде квалификатора "относится к".
• использовать только статус наследия (P1435), но при этом для всех возможных вариантов параметров "Тип памятника" и "категория охраны" нужно создать элемент в Викиданных. Например, у латвийских памятников 7 типов и 2 категории - у нас будет 14 элементов. Также мы можем создать элементы/классы для каждого типа и для каждой категории, чтобы получилось развесистое дерево классов. У российских памятников в списках 4 типа памятников, а категорий охраны - пять, так что у нас получится 20 элементов, которые станут значениями для статус наследия (P1435)

В Латвии мы не нашли простого решения для первого варианта, поэтому склоняемся ко второму варианту, а в украинских списках уже давно используется именно объединенный идентификатор типа, т.е. тоже второй вариант. --Voll (обсуждение) 10:45, 13 апреля 2016 (MSK)

Прокомментируйте, пожалуйста, эту тему - она очень важна. --Voll (обсуждение) 09:07, 17 апреля 2016 (MSK)

По России мы сочли, что достоверной информации о категории охраны у нас нет, так что я бы её просто игнорировал. Что же касается типа памятника, в России их четыре - памятники истории, архитектуры, археологии, монументального искусства. Для них можно просто использовать P31.--Ymblanter (обсуждение) 11:08, 17 апреля 2016 (MSK)

Не понял про "достоверной информации о категории охраны у нас нет" - вы же сами создали 5 категорий и обязательно относите памятник в одну из них:

• 0 — местная или региональная (объекты из базы министерства культуры)
• 1 — федеральная (объекты из базы министерства культуры)
• 2 — толком не выяснена (объекты из базы министерства культуры)
• 3 — объект отсутствует в базе Министерства культуры, номер присвоен Викигидом независимо от категории охраны (чаще всего она неизвестна)
• 4 — объект не найден ни в одном из списков, но по нашему мнению относится к памятникам культурного наследия

И главное - у каждого памятника обязательно должен быть статус наследия (P1435)!

Что, касается P31 как типа памятника, то это не очень хороший вариант с двух сторон. Со стороны самого это частный случай понятия (P31) - уже разбирали это, когда создавали статус наследия (P1435) и решили что не надо засорять основной смысл P31 дополнительными значениями. И со стороны проекта переноса - вылавливать это значение будет намного труднее, чем класс из статус наследия (P1435). --Voll (обсуждение) 12:11, 17 апреля 2016 (MSK)

Хорошо, давайте тогда о второму варианту. А зачем надо 20 типов? Нельзя два раза сослаться на Р1435, один раз по типу, один раз по категории охраны?--Ymblanter (обсуждение) 12:23, 17 апреля 2016 (MSK)

Прошерстил как сумел все значения статус наследия (P1435) - несколько значений в элементе может быть, но они относятся к разным регистрам памятников, чтобы кто-то выделял так типы, как ты предложил - не нашел. --Voll (обсуждение) 21:48, 17 апреля 2016 (MSK)

Может зададим этот вопрос "Нельзя два раза сослаться на Р1435, один раз по типу, один раз по категории охраны?" на форуме Викиданных? Попросим помощь зала. ;-) --Voll (обсуждение) 22:16, 17 апреля 2016 (MSK)

Можно, конечно, спросить, но я не вижу, кто нам мешает - в элементе (Q) у любого свойства (P) может быть несколько значений.--Ymblanter (обсуждение) 22:19, 17 апреля 2016 (MSK)

по обсуждению видно, что это никому не интересно. --Voll (обсуждение) 17:50, 25 апреля 2016 (MSK)

Я не знаю точно, какие в Викиданных правила на предмет достоверности информации, но я не уверен, что наша самодеятельность с номерами соответствует тамошним правилам. В любом случае, зачем огород городить, раз "категория охраны" уже зашита в номере объекта? --Alexander (обсуждение) 14:21, 17 апреля 2016 (MSK)

Именно поэтому и стоит огород городить, так как некоторые номера объектов созданы нами. И нам, возможно, покажется правильным переделать наши регистры в будущем и перестроить дерево категорий охраны. Кстати, я видел, что в Викиданых встречаются негосударственные регистры памятников (по-моему испанские), которые дополняют государственные списки. Все это вкупе с выбранной моделью для статус наследия (P1435) дает нам простор для экспериментов и улучшений наших списков. --Voll (обсуждение) 21:48, 17 апреля 2016 (MSK)

Запасные значения типов в любом случае надо иметь. Например, вот ещё 2 типа. --Figure19 (обсуждение) 15:50, 24 апреля 2016 (MSK)

Запасными их, конечно, назвать трудно. ;-) Скажем так - чем больше я на все это смотрю - тем больше понимаю, что дерево классов нам подойдет лучше всего. Однако, можно снова это обсудить после латвийского теста, так как мы будем использовать именно такой вариант. --Voll (обсуждение) 17:50, 25 апреля 2016 (MSK)

Новые свойства

Прошу поддержать создание новых свойств:

• d:Wikidata:Property_proposal/Place#Locality_or_Place,
• d:Wikidata:Property_proposal/Unsorted#Time_period_of_inception_and_reconstruction,
• d:Wikidata:Property_proposal/Unsorted#appears_in_the_list_of_heritage_monuments.

Если у вас есть идеи, как улучшить мои запросы, чтобы они были одобрены - правьте смело. Спасибо заранее. --Voll (обсуждение) 21:00, 23 апреля 2016 (MSK)