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

У учёного со стажем в сети накапливается множество разрозненных следов: профили в eLibrary, ORCID, Scopus, Web of Science и Google Scholar, страница на сайте организации, аккаунт в научной социальной сети. Каждый по-своему верен, а связаны они между собой лишь частично. Для человека это неудобство; для машины, которая пытается понять, о ком идёт речь, это источник ошибок: два профиля с похожим именем могут принадлежать одному человеку, а могут двум однофамильцам, и сопоставление по соавторам и местам работы не всегда это различает. Машины всё равно пытаются справиться с этой задачей, и разумно облегчить им работу.

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

Таким системам нужен не ещё один профиль, а узел, который связывает существующие записи в одно утверждение: «это один и тот же человек, вот его идентификаторы, вот его работы, вот источники». Для людей таким узлом служит личный сайт, а для машин есть Wikidata, по-русски Викиданные: открытая база структурированных данных, родственная Википедии, но устроенная иначе. В ней нет статей, есть записи из утверждений вида «свойство → значение → источник», которые одинаково доступны и человеку, и программе.

Сразу скажу, что в этой истории подтверждено, а что нет. Подтверждено, что ИИ-агенты обращаются к Wikidata в больших объёмах: об этом публично сообщил Фонд Викимедиа, подробности ниже, в разделе «Что это даёт и чего ждать не стоит». Не подтверждено, что запись об учёном меняет ответы ассистентов или попадает в справочную карточку поисковой системы: ни Google, ни Яндекс не называют Wikidata среди источников своих карточек, а публичных измерений такого эффекта найти не удалось. Поэтому статья не обещает отдачи. Она объясняет, как завести запись, которую можно проверить и в любой момент исправить, и чего от неё разумно ждать. Вывод скажу заранее: запись стоит заводить как порядок в данных о себе, если есть что связывать, и не стоит как средство продвижения.

Статья написана для учёных со стажем: с защищённой диссертацией, публикациями в каталогах и заведёнными профилями. Аспиранту с первыми статьями запись пока рано, ниже объяснено почему. Примером служит моя запись, и главное об этом примере нужно сказать сразу: заполняла её не я, а близкий мне человек со своего аккаунта и с раскрытием конфликта интересов, поэтому я описываю, как запись устроена и что в ней сделано, а не рассказываю о собственных правках. Цель статьи: пройти путь от первого утверждения до связки с диссертацией и сказать прямо то, о чём в инструкциях обычно молчат, а именно что запись о вас будут править другие и к этому надо быть готовым.

Содержание

• Кому и когда запись уместна
• Устройство записи
• Первая запись за пять шагов
• Как создавалась моя запись
• Идентификаторы: пятнадцать мостов к другим профилям
• Запись о работе: диссертация как отдельный объект
• Что это даёт и чего ждать не стоит
• Запись будут править другие
• Как проверить запись
• Этика: только проверяемое и ничего лишнего
• Чек-лист: запись готова, когда
• Вопросы и ответы

Кому и когда запись уместна

Начну с ограничения, потому что без него статья превратилась бы в инструкцию по самопродвижению. Wikidata допускает запись о персоне, если та является ясно идентифицируемой сущностью, описанной в серьёзных, общедоступных и проверяемых источниках. Для учёного это опубликованные работы в каталогах и базах, идентификаторы в реестрах, страница в организации. Критерии Wikidata заметно мягче критериев Википедии, о чём я писала в статье о профилях: энциклопедия требует известности, база данных требует проверяемости. Критерии сейчас обсуждаются сообществом и могут измениться, поэтому перед созданием записи стоит открыть страницу Wikidata:Notability: на 10 октября 2026 года действовало три критерия, и достаточно выполнить любой один.

Защиты правила не требуют, поэтому дальше мой совет, а не их условие. Сначала появляются диссертация, публикации, профиль в eLibrary и ORCID, страница в организации; затем, когда есть что связывать и на что ссылаться, запись становится уместной. Поэтому статья адресована учёным со стажем: у аспиранта с первыми статьями связывать пока мало, и время разумнее потратить на сами публикации и профили. Запись, у которой в источниках только личный сайт, выглядит слабо и может быть оспорена; запись, у которой каждое утверждение подкреплено внешним реестром, живёт спокойно.

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

Устройство записи

Прежде чем создавать запись, полезно понять её анатомию. У записи есть номер из буквы Q и цифр: у моей это Q140355257. Есть метки, то есть имя на разных языках, и короткое описание в одну строку, например «российский социолог, доктор социологических наук». Есть утверждения: каждое состоит из свойства, обозначенного буквой P и номером, и значения. Свойство «род занятий» имеет номер P106, и одним из его значений служит запись «социолог»; свойство «работодатель» имеет номер P108, и его значение отсылает к записи об академии. Значения, как видно, тоже являются записями базы, и так образуется граф: запись человека связана с записью организации, а та, как правило, с записью города.

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

Именно идентификаторы делают запись узлом. Запись с пятнадцатью идентификаторами сообщает машине: профиль ORCID с таким номером, автор Scopus с таким номером и аккаунт GitHub с таким именем принадлежат одному человеку. Такую сводку по всем системам сразу ни один из этих профилей не даёт.

Первая запись за пять шагов

Прежде чем перейти к примеру моей записи, короткий маршрут по интерфейсу. Названия кнопок и свойств даны так, как их показывает русский интерфейс Wikidata в октябре 2026 года.

1. Проверить, нет ли уже записи о вас. Откройте wikidata.org и наберите своё имя в строке «Искать в Wikidata» вверху страницы: сначала по-русски, затем латиницей, как оно пишется в ваших англоязычных статьях. Если у вас есть ORCID, введите в ту же строку запрос по его номеру и нажмите Enter. Для моей записи он выглядит так: haswbstatement:P496=0000-0002-0778-7171, а вы подставьте свой номер. Такой запрос находит запись, в которой указан именно этот ORCID. Если запись нашлась, её дополняют, а вторую не создают.
2. Создать запись. В меню слева «Создать новый элемент»: язык, метка (имя), описание в одну строку, кнопка «Создать». Метку и описание на втором языке добавляют уже на странице записи.
3. Добавить первое утверждение. «добавить утверждение» → свойство «это частный случай понятия» (P31, по смыслу «является экземпляром») → значение «человек» (Q5) → «опубликовать». Остальные утверждения вносятся так же; значение выбирают из подсказок, а не вводят текстом.
4. Прикрепить источник. Под утверждением «добавить источник» → свойство «URL-ссылка на источник» (P854) и адрес страницы; в том же источнике «добавить» → «дата проверки» (P813) и дата, когда вы страницу открыли → «опубликовать».
5. Проверить результат. Обновить страницу записи: у утверждений о должности, степени и наградах есть источники, ссылки идентификаторов открывают ваши профили, а поиск по ORCID находит одну запись.

Пример целиком, для места работы: свойство «работодатель» (P108) → значение: запись вашего вуза, выбранная из подсказок → источник: «URL-ссылка на источник» со страницей сотрудника на сайте вуза и «дата проверки».

Как создавалась моя запись

Запись обо мне создана 25 июня 2026 года, и создал её, как уже сказано, близкий мне человек со своего аккаунта. На странице участника он прямо указал, что правит записи о близком человеке и делает это безвозмездно, то есть раскрыл конфликт интересов. Правила проекта разрешают редактировать запись о себе и о тех, кого вы знаете. Аккаунт в Wikidata заводится за минуту. Для правок он необязателен, потому что система допускает и правки без входа, но только с аккаунтом правки подписаны вашим именем и можно включить наблюдение за записью.

Путь выглядел так. Сначала проверили, что записи ещё нет: поиск по имени, кириллицей и латиницей, обязателен, потому что у учёных с давними публикациями запись могла быть создана автоматически из библиотечных каталогов, и тогда её нужно дополнять, а не дублировать. В моём случае записи не было. Затем создана запись с метками и описанием: на русском «Инна Газиева», на английском «Inna Gazieva», по строке описания на каждом языке; полное имя с отчеством внесено отдельным свойством, потому что в русскоязычных источниках автор фигурирует именно так. Первым утверждением стоит «это частный случай понятия» (P31) со значением «человек»: без него запись не считается записью о персоне. Далее внесены пол, гражданство, языки, род занятий, место работы, место учёбы, области деятельности и учёная степень. Где значением может быть другая запись, она выбрана из существующих записей базы, а не введена текстом, так что для места работы указана запись академии. Области деятельности обозначены тремя записями: социология, ювенология, государственное управление.

К самым важным утверждениям прикреплены источники: к месту работы страница образовательной программы академии, где я указана её руководителем, к степени страница академии с объявлением о защите диссертации, к наградам страницы, где о них сообщается. Сначала и к месту работы стояло объявление о защите, но место работы на самой этой странице не названо, поэтому источник заменили: он должен подтверждать именно тот факт, к которому прикреплён. У части второстепенных утверждений, например у областей деятельности и места учёбы, источника пока нет, и это следующий шаг. Подбор источников самый трудоёмкий шаг, и без него запись остаётся набором заявлений. Последний шаг: официальный сайт указан свойством P856, и круг замыкается, потому что в разметке сайта, в свою очередь, указана ссылка на запись Wikidata (свойство sameAs), и связь видна с обеих сторон.

Идентификаторы: пятнадцать мостов к другим профилям

Ради идентификаторов запись во многом и создаётся. На момент публикации в ней пятнадцать внешних идентификаторов и ссылка на официальный сайт; за каждым идентификатором стоит отдельное свойство: ORCID, Scopus, Web of Science, Google Scholar, eLibrary, Semantic Scholar, OpenAlex, SSRN, ResearchGate, GitHub, ИСТИНА, Литрес, LinkedIn, ВКонтакте и Kudos. Для большинства научных систем свойство в базе уже существует; найти его проще всего, открыв запись любого известного учёного и посмотрев, как оформлен нужный идентификатор.

Три практических замечания. Во-первых, набор свойств растёт: например, свойство для профиля в Kudos (Kudos author ID) появилось в базе в сентябре 2026 года, и в октябре его добавили в запись, а для Znanium, OpenAIRE и Leader-ID на 10 октября 2026 года свойств в базе не оказалось. Связи, для которых свойства нет, остаются только в разметке сайта («то же самое, что»), и это нормально. Во-вторых, значение вводится в том виде, какой ожидает свойство: у одних это число, у других имя пользователя, у третьих полный адрес; форма подсказывает, а после сохранения ссылка должна открываться. В-третьих, идентификаторы стоит вносить по мере появления профилей, а не откладывать: пять из пятнадцати были добавлены в июле, когда появились соответствующие профили, а Kudos — в октябре. Вносились они по одному через форму и заняли около трёх минут; если строк десять и больше, быстрее внести список через инструмент QuickStatements, а образец файла с пояснениями лежит в репозитории-шаблоне research-repository-template. Перед запуском списка каждую строку нужно проверить глазами, потому что он вносится без подтверждений.

Порядок здесь обратный привычному: не Wikidata порождает профили, а профили, заведённые по статье о профилях, дают материал для записи. Пустая запись с одним ORCID полезна мало; запись, где каждая связь проверена, становится тем самым узлом.

Запись о работе: диссертация как отдельный объект

Записи заслуживает не только персона, но и её работа. У моей диссертации есть собственная запись, Q140609231: тип «диссертация», название, автор со ссылкой на мою запись, язык, дата, число страниц, организация, где работа защищена, и два свойства, которые связывают запись с открытой публикацией, то есть DOI архива Zenodo и адрес полного текста в репозитории. DOI в записи один — общий, действующий для всех версий. Сначала их было два, общий и версионный, и Wikidata отмечала пару значком «!»: у этого свойства ожидается одно значение, а два допустимы, только когда их различают уточнениями (квалификаторами). Устойчивого уточнения «общий / версионный» в Wikidata нет, поэтому версионный DOI убран: общий всегда ведёт на актуальную версию. Это решение о том, как хранить DOI в Wikidata, а не правило цитирования: в списке литературы допустимы оба, и сам Zenodo по умолчанию предлагает DOI конкретной версии. О том, как текст диссертации попадает в репозиторий и получает DOI, я писала в статьях о диссертации в открытом репозитории и о Zenodo и DOI; здесь важно, что Wikidata умеет это зафиксировать.

Связь работает в обе стороны. В записи о работе автор указан ссылкой на мою запись; в моей записи стоит свойство «известная работа», и среди его значений диссертация и монографии. Так появляется цепочка: человек → известная работа → DOI → полный текст, и каждое звено проверяемо. Для записи о работе правилам достаточно надёжного описания, например в каталоге библиотеки или в базе DOI; открытый текст не обязателен, хотя с ним запись полезнее: читатель сразу попадает к тексту. Заводить запись на каждые тезисы не нужно: критерий тот же, что и для персоны, есть ли что проверить и на что сослаться.

Что это даёт и чего ждать не стоит

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

Первое: ИИ-агенты обращаются к Wikidata в больших объёмах. 5 октября 2026 года Фонд Викимедиа в заметке Selena Deckelmann, директора Фонда по продуктам и технологиям, сообщил, что обнаружил на своих площадках активность агентов, которых он называет «rogue» (самовольными) и считает управляемыми OpenAI. Они выполнили миллионы автоматических запросов к открытым интерфейсам, обошли миллионы страниц, главным образом в Wikidata и на Викискладе, и отправили сотни тысяч запросов к сервису запросов Wikidata (Wikidata Query Service); Фонд допускает, что этот трафик способствовал частичному сбою сервиса в мае 2026 года. Для чего агентам понадобились эти данные, в заметке не сказано, и о конкретных записях речи нет. Вывод поэтому узкий: ИИ-агенты Wikidata читают, но что именно они с ней делают, документ не говорит.

Второе: Wikidata использовалась как материал для языковой модели. В 2021 году исследователи Google Research Siamak Shakeri и Oshin Agarwal описали проект KELM: английскую Wikidata (около 45 млн утверждений) превратили в 18 млн предложений обычного текста и добавили их в корпус, из которого извлекает сведения модель REALM; прежде он состоял только из текстов Википедии. Авторы сообщают о повышении точности на двух открытых наборах вопросов и ответов. Это исследовательская работа, о применении такого корпуса в продуктах Google публикация не сообщает.

Третье: Wikidata готовят для разработчиков ИИ как отдельный продукт. 1 октября 2025 года Wikimedia Deutschland вместе с Jina AI и DataStax запустила Wikidata Embedding Project, открытую векторную базу, которая позволяет искать по Wikidata по смыслу, а не по точному совпадению слов. В описании проекта сказано, что структурированные данные помогают справиться с ограничениями чисто языковых моделей: ложной информацией, устареванием, недостатком сведений о слабо представленных темах. Это инфраструктура, предложенная разработчикам; кто из крупных ассистентов ею пользуется, на странице проекта не сказано.

Теперь о том, что подтвердить не удалось. Начну со справочной карточки в поисковой системе. Google не раскрывает, откуда берёт сведения для карточек: в его справке сказано лишь, что информация приходит из различных источников в интернете, от партнёров по данным и от подтверждённых лиц, а Wikidata не названа. Яндекс в описании объектного ответа упоминает Википедию как источник сведений о музыкантах, а Викиданные не называет. У меня карточку заметили 13 июля 2026 года, через 18 дней после создания записи, и по запросу латиницей она показывала род занятий «социолог» и место учёбы, совпадающие с записью Wikidata. Это совпадение, а не доказательство. На 10 октября 2026 года карточка показывается не на каждый запрос: по запросу «Инна Газиева социолог» она есть, и в блоке «Сведения» стоит образование «Нижегородский институт управления», как в записи, а по запросам «Инна Газиева» и «Инна Александровна Газиева» без уточнения карточки нет. Подпись, фотографию и адрес сайта в карточке исправляли отдельно: после подтверждения права представлять человека Google принимает такие правки прямо в карточке; это отдельная процедура Google, и в её справке Wikidata не упоминается.

Что касается ИИ-ассистентов, вклад записи в точность их ответов не измерен, и устойчивого эффекта я показать не могу; публичных измерений такого эффекта найти тоже не удалось. В начале октября 2026 года Алиса AI, отвечая на вопрос о моём научном руководителе Т. Г. Калачёвой, назвала среди пяти источников запись о ней в Wikidata. Повторная проверка 10 октября в режиме инкогнито этого не подтвердила: ни Алиса, ни ассистент Kimi запись Wikidata среди источников не назвали, а «Обзор от ИИ» в Google по запросам с моим именем ссылался на мой сайт, SSRN и ResearchGate. Выводов два: ассистент может сослаться на такую запись, но набор источников у ассистентов меняется, и рассчитывать на постоянный эффект нельзя. Проверять сведения, которые дают ассистенты, необходимо в любом случае.

Отдельно проверен открытый веб-архив Common Crawl, из которого составляют обучающие наборы. Страницы Wikidata в нём встречаются: контрольная запись о Дугласе Адамсе (Q42) найдена в сборах июля и сентября 2026 года, хотя в сборах июня и августа её нет. Моих двух записей, о персоне и о диссертации, нет ни в одном из этих четырёх сборов (проверка 12 октября 2026 года). Отсутствие в архиве служит слабым свидетельством, потому что и контрольная запись есть не в каждом сборе, и у моделей есть другие пути к данным Wikidata; но и подтверждения, что запись попала в открытый корпус, нет.

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

Запись будут править другие

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

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

Что делать на практике. Включите наблюдение за страницей записи (звёздочка «Следить» рядом с вкладкой «История») и время от времени открывайте историю правок: в ней видно, кто и что изменил. Не удаляйте чужие правки, подкреплённые источником, даже если считаете их неверными: правила Wikidata этого не одобряют, а спорное предлагают обсуждать на форуме проекта (Project chat). Сведения о частной жизни, которые вы не хотите видеть публично, можно попросить удалить через доску объявлений администраторов или письмом на .

Как проверить запись

Результат записи нельзя измерить одной цифрой, но три проверки сделать можно. Во-первых, поиск по Wikidata с запросом haswbstatement:P496= и вашим номером ORCID должен находить вашу запись, и только её: так проверяется, что идентификатор внесён верно и дубля с тем же ORCID нет; дубль без ORCID ищут по имени, как в первом пункте чек-листа. Во-вторых, в разметке вашего сайта должна быть ссылка на запись (свойство sameAs), а в записи ссылка на сайт: тогда ссылки согласованы с обеих сторон. В-третьих, через несколько недель спросите у поисковой системы и у ассистента, кто вы и где работаете, и сравните ответ с записью. Расхождение — повод разобраться: причиной может быть устаревший источник, путаница с однофамильцем или выдумка модели; совпадение само по себе ничего не доказывает.

Этика: только проверяемое и ничего лишнего

Здесь необходим отдельный раздел, потому что база, в которую может писать каждый, провоцирует приукрашивание. Каждое утверждение о себе должно быть проверяемым по внешнему источнику, и источник указывается: должность в том виде, в каком она значится на сайте организации, степень в том виде, в каком она значится на странице организации, награда со ссылкой на страницу, где о ней сообщается. Формулировки вроде «крупный специалист», «известный учёный», «эксперт федерального уровня» в базе не имеют места: у них нет свойства, потому что нет способа проверки.

Записи о работах создаются для заметных и проверяемых работ, а не для наращивания видимого списка. Дублировать чужие записи, создавать запись, если она уже есть, и удалять чужие корректные правки нежелательно. Если запись ведёт близкий человек, как в моём случае, об этом стоит сообщить на его странице участника: на мой взгляд, это прозрачность, которая снижает недоверие к записи. Наконец, Wikidata не заменяет ни публикаций, ни профилей, ни сайта: она их связывает, и заводить запись, которой нечего связывать, не стоит.

Чек-лист: запись готова, когда

• Проверяем, что записи ещё нет: поиск по имени кириллицей и латиницей и по номеру ORCID. Сделано, когда: дубля нет или найденная запись взята для дополнения.
• Создаём запись с метками и описанием на русском и английском; первым утверждением ставим «это частный случай понятия» (P31) → «человек». Сделано, когда: запись открывается по своему номеру Q и распознаётся как персона.
• Заполняем основные утверждения из существующих записей базы (род занятий, работодатель, учёба, область деятельности, степень) и к содержательным прикрепляем источник с датой обращения. Сделано, когда: значения-записи выбраны из базы, а не введены текстом, а у должности, степени и наград есть внешняя ссылка.
• Вносим внешние идентификаторы (ORCID, eLibrary, Google Scholar, Scopus, остальные по мере появления профилей) и официальный сайт, а в разметку сайта добавляем ссылку на запись. Сделано, когда: каждая ссылка открывает нужный профиль, а ссылки с сайтом согласованы с обеих сторон.
• Для ключевых работ с DOI или записью в каталоге библиотеки создаём отдельные записи и связываем их с персоной свойствами «автор» и «известная работа». Сделано, когда: цепочка человек → работа → DOI проходится по ссылкам, а где есть открытый текст, то и до него.
• Включаем наблюдение за записью и через несколько недель проверяем её: поиск по ORCID, ответы поисковой системы и ассистента. Сделано, когда: чужих правок без источника нет, а на найденные поставлен источник или отправлена просьба об удалении.

Вопросы и ответы