Разобранные примеры
Четыре карточки ниже доводят задачу до названной платформы. С какой строки начать — в главе «Типовые сценарии». Каждая записана семью разделами из главы «Как обосновать решение»: контекст, варианты, критерии, решение, почему, последствия, когда пересмотреть. Это образцы записи. Для другого города или службы разделы заполняют заново: чужая карточка тащит за собой чужое обязательство и чужую плату.
Числа жителей и наборов в примерах условные. Факты о платформах взяты из карточек и сверки октября 2026 года.
Коротко:
- В карточке одна развилка. Соседний отказ, который уже просили, назван отдельно, чтобы его не внедрили молча.
- В разделе «почему» каждый отвергнутый вариант проигрывает по названному критерию.
- Плата стоит рядом с выбором.
- «Когда пересмотреть» — событие, которое организация заметит. Новое решение — новая карточка.
| Пример | Развилка | К чему приходят |
|---|---|---|
| Муниципалитет | свой портал, чужой каталог или статический сайт | публиковать на региональном портале |
| Регион | какая платформа соберёт города и отдаст страну | CKAN, ckanext-dcat и ckanext-harvest |
| Университет | репозиторий данных или портал открытых данных | Dataverse рядом с уже стоящим DSpace |
| Статистическая служба | один сайт или два каталога | показатели и микроданные на разных платформах |
Как из задач получается список функций и короткий список платформ — в главах о функциях и о платформе.
Муниципалитет: не заводить свой портал
Контекст. Город на 40 тысяч жителей. Около тридцати наборов: бюджет, маршруты, адреса школ. Обновляют их два раза в год. Информатик администрации один, порталы он не сопровождал. Регион уже принимает наборы муниципалитетов и забирает описания в профиле DCAT-AP. Карта города лежит на региональном геопортале. Свой геопортал никто не просил.
Варианты. Свой CKAN. Облачный портал, Huwise или Socrata. Публикация наборов организацией на региональном портале, в том числе в типовом разделе, который регион уже ведёт для городов. Статический каталог на сайте города: JKAN или страницы с файлом описаний.
Критерии. Регион забирает описания без переписывания карточек, и файл совпадает с его профилем. Один человек без опыта порталов обновляет наборы два раза в год и через три года. Плата соразмерна тридцати наборам. Если критерии спорят, важнее первый: наборы должны дойти до региона.
Решение. Публиковать наборы организацией на региональном портале. Если регион не заводит чужие организации, город выкладывает статический каталог с файлом описаний в том профиле, который регион собирает.
Почему. Свой CKAN проигрывает по второму критерию. Выгрузка DCAT у него не в ядре, а в расширении ckanext-dcat, и обновление — это ядро плюс расширения. При одном человеке без опыта портал останется без обновлений через год-два. Облачный сервис проигрывает по третьему критерию. Страницу набора, лицензию, файл и выгрузку для региона он закроет, но эти функции уже есть на региональном портале. Подписка и будущий перенос адресов добавляют плату там, где своей установки нет. Чужой договор в карточку не переносят: сумму берут из предложения на эти тридцать наборов, как разобрано в главе о способе создания. Статический каталог остаётся запасным ходом, если регион не заводит чужие организации. У JKAN файл data.json объявляет схему DCAT-US 1.1, шаблон заполняет короткий список полей. Регион из этой карточки ждёт DCAT-AP, поэтому шаблон переделывают под его профиль до публикации. opendata.scot показывает другой случай: статический каталог собрали, когда государственного портала ещё не было. У города из этой карточки верхний портал уже есть.
Последствия. Город зависит от полей и расписания регионального портала. Отдельного домена с витриной не будет. Лицензию и постоянный адрес набор получает там же: регион их за город не выдумает. Карты остаются на геопортале. Если на набор нужно сослаться с городского сайта, страница ведёт на карточку региона, а не заводит вторую копию.
Когда пересмотреть. Наборов стало больше двухсот, появилась ставка на сопровождение портала, или регион перестал принимать муниципальные данные. Тогда открывают новую карточку. По этой записи CKAN молча не ставят.
Регион: собрать муниципалитеты и отдать страну
Контекст. Регион публикует свои открытые данные и обязан отдавать описания национальному порталу. Профиль — DCAT-AP плюс несколько своих обязательных полей. Одновременно регион собирает наборы муниципалитетов. Подрядчик есть, своей команды разработки нет. Часть городов уже ведёт каталог, часть будет публиковать прямо сюда, как в примере муниципалитета.
Варианты. CKAN с ckanext-dcat и ckanext-harvest. Piveau. Huwise. Socrata. Свой портал. Не собирать города и оставить их сами по себе.
Критерии. Файл выгрузки проходит валидатор профиля, который ждёт национальный портал, включая свои поля, и при смене профиля его чинит не единственный поставщик. Город без каталога публикует набор с файлом на региональном портале, город с каталогом отдаёт файл описаний, регион забирает его по расписанию. Подрядчик обновляет платформу на стенде. Если критерии спорят, совпадение с профилем страны важнее витрины и скорости запуска.
Решение. CKAN: ядро, ckanext-dcat и ckanext-harvest. Город без своего каталога публикует наборы организацией на региональном портале. Город со своим каталогом отдаёт файл описаний, регион его забирает. Свои поля национального профиля задаёт ckanext-scheming, в выгрузку их кладёт профиль ckanext-dcat. На scheming в тот же день пишут отдельную карточку расширения: что ставят, кто сопровождает, что делать, если расширение замолчит. Если страна принимает общий DCAT-AP без своих полей, scheming не ставят.
Почему. Socrata проигрывает по первому критерию, до разговора о цене. Сбор у неё есть: Catalog Connector забирает data.json и публичный ArcGIS Server. Штатный файл выгрузки — DCAT-US, а страна ждёт DCAT-AP.
Huwise проигрывает по тому же критерию. Сбор у неё тоже в самом сервисе: сборщики CKAN, Socrata, ArcGIS, data.json и других порталов Huwise, сбор из CSW включают по запросу в поддержку. Свои поля задаются шаблонами и попадают в выгрузку DCAT, только если поставщик предусмотрел соответствие. Подрядчик видит национальный профиль на пилоте у поставщика и сам его в репозитории не правит.
Piveau проигрывает по первому критерию в части своих полей. Собирать DCAT и публиковать наборы он умеет: на нём работает data.europa.eu, а форма ввода на октябрь 2026 года документирует спецификации DCAT-AP и DCAT-AP.de. Профиля этой страны в списке нет. Его добавляют отдельно, и дальше его сопровождает подрядчик. У CKAN общий профиль DCAT-AP 3 уже есть в ckanext-dcat, свои поля задаёт ckanext-scheming, в выгрузку их кладёт профиль того же расширения. Автоматические тесты идут на CKAN 2.10, 2.11 и 2.12.
Свой портал проигрывает по первому критерию тоже. Среди самописных порталов открытых данных выгрузку DCAT реестр нашёл у 24 из 1144. Сайт откроют люди. Национальный портал описания не заберёт.
Ход «оставить города сами по себе» проигрывает по второму критерию: страна муниципальные наборы не получит.
Сбор и выгрузка в этой сборке — два расширения, и они делают разную работу. Файл DCAT наружу и разбор чужого DCAT даёт ckanext-dcat. ckanext-harvest даёт очередь, расписание и экран ошибок. Последний выпуск harvest, 1.6.2, старше CKAN 2.12, но тесты основной ветки включают 2.12. В карточке записывают адрес репозитория, который ставят, и проверку сбора на стенде той версии ядра, которую выбрали. Подробности — в главе про CKAN.
Последствия. Подрядчик при каждом обновлении CKAN проверяет ckanext-dcat, ckanext-harvest и, если он стоит, ckanext-scheming. Ошибки сбора смотрит человек. В карточке копии стоит ссылка на страницу набора у города, иначе один набор считается и у города, и у региона, и у страны. В ядре CKAN ни выгрузки, ни сбора нет: это штатная сборка. Та же связка уже стоит на живом портале: у data.gov.gr на CKAN 2.11.3 в сверке 13 октября 2026 года среди плагинов были scheming, dcat и harvest.
Когда пересмотреть. Национальный портал сменит профиль, или ckanext-dcat либо ckanext-harvest перестанут проверяться на новой версии CKAN. Тогда ищут замену расширения или остаются на последней версии ядра, которая ещё получает исправления безопасности. Как выбрать из этих ходов — в главе об обосновании. Если страна обяжет регионы работать на одной государственной платформе, свою сборку закрывают по плану переноса адресов.
Университет: репозиторий данных, а не «ещё один CKAN»
Контекст. Университет уже ведёт репозиторий публикаций на DSpace. Гранты требуют выкладывать данные к статьям с DOI, версией и строкой цитирования, которую можно выгрузить в BibTeX. Публикуют научные группы, библиотека готова модерировать. Отдельной группы под новое приложение нет: систему ведёт та же библиотека. Открытых данных администрации немного, им место на странице университета или на портале органа власти. Федерация DCAT-AP государственного портала на первом шаге не обязательна.
Варианты. Доработать стоящий DSpace. Поставить рядом Dataverse. Поставить рядом InvenioRDM. Не ставить ничего и отправлять авторов в Zenodo. Поставить CKAN и добавить расширение ckanext-doi.
Критерии. DOI, версии, строка цитирования и выгрузка BibTeX есть в ядре той версии, которую поставят. Библиотека модерирует запись, файл можно закрыть при открытом описании. У университета свой префикс DOI. Уже стоящий репозиторий публикаций этой карточкой не заменяют, и сопровождает новую систему библиотека, без отдельной команды. Если критерии спорят, цитирование в ядре важнее желания обойтись одной программой.
Решение. Dataverse рядом с DSpace. Общая точка входа — на сайте библиотеки. В описании набора данных стоит DOI статьи, в описании статьи — DOI набора. Группам с единичными наборами по-прежнему можно пользоваться Zenodo.
Почему. CKAN проигрывает по первому критерию. DOI у него — расширение ckanext-doi, на CKAN 2.11 и 2.12 оно не тестировалось. Версий набора в ядре нет. OAI-PMH, которым научные агрегаторы забирают описания, в ядре тоже нет.
DSpace проигрывает по тому же критерию, хотя DOI в ядре включается настройкой. До версии 10.1 включительно готовой ссылки и выгрузки в BibTeX и RIS нет: в ядре только метатеги для Google Scholar, кнопку «Cite» переносят из DSpace-CRIS. В DSpace 10 появился тип записи «набор данных», но в репозиториях на DSpace наборы остаются малой долей записей, а фильтр по типу в поиске по умолчанию выключен. Дорабатывать публикационный репозиторий до репозитория данных библиотека сможет, когда выгрузка цитирования появится в ядре. До этого дня данные идут в отдельную систему.
Zenodo проигрывает по третьему критерию. DOI, версии и цитирование там есть, установка не нужна, на одну запись можно положить до 50 ГБ и 100 файлов. Префикс DOI общий, модерацию групп библиотека не ведёт.
InvenioRDM закрывает DOI, версии и BibTeX в ядре. Карточка платформы отдаёт его организации, которая готова сопровождать Python-приложение. У этой библиотеки такой готовности нет, поэтому в коротком списке он не остаётся. Университету с отдельной командой и с обязанностью самому отдавать DCAT он подходит: выгрузка DCAT у InvenioRDM в ядре, у Dataverse её нет. В этой карточке федерация государственного портала не обязательна, и выгрузка DCAT решение не перевешивает.
Последствия. Две системы у библиотеки. Связь «статья — данные» держат идентификаторами в описаниях. Общего поиска по ним эта карточка не обещает. Нужен договор с DataCite, если его ещё нет. Самостоятельный член платит 2000 евро в год и инфраструктурный сбор от 200 до 700 евро, участник консорциума — только сбор. Университеты обычно получают префикс через библиотечный консорциум. Пока префикса нет, группы пользуются Zenodo. Боевые DOI с тестовой учётной записи не выпускают: ошибку в рабочей системе трудно исправить, DOI не удаляются.
Когда пересмотреть. Сопровождать две системы некому — свой Dataverse закрывают и договариваются о Zenodo или общем репозитории консорциума. Вышла версия DSpace, в которой строка цитирования и BibTeX есть в ядре наравне с Dataverse, — открывают новую карточку о слиянии. Появилась обязанность самому отдавать описания в DCAT-AP — карточку открывают заново и снова смотрят InvenioRDM.
Статистическая служба: показатели и микроданные — разные каталоги
Контекст. Национальная статистическая служба ведёт две полки, которые часто пытаются закрыть одним сайтом. Первая — показатели с разрезами по времени и территории и обмен с международными организациями по SDMX. Вторая — обезличенные файлы обследований: описание открыто, файл по заявке, описание в духе DDI.
Варианты. Один самописный сайт «вся статистика». Два каталога: платформа показателей и NADA для микроданных. Только платформа показателей, а микроданные рассылать почтой.
Критерии. Программа получает срез показателя по году и территории, международный партнёр забирает SDMX. У обследования открытое описание, уровни доступа и описание в DDI. Служба не пишет оба контура сама. Проигрыш любого из первых двух критериев значит, что каталог к работе не готов.
Решение. Два каталога. Микроданные — на NADA. Платформу показателей выбирает следующая карточка. На сайте службы обе точки входа стоят рядом, и подписи прямо говорят, чем полка показателя отличается от полки обследования. Показатели внутри NADA не включают. С выпуска 5.6 платформа умеет их описывать, но возможность ещё не делает каталог гибридом: в библиотеке микроданных Всемирного банка все 7 145 записей — обследования, а показатели банк публикует на другой платформе.
Почему. Самописный сайт проигрывает по третьему критерию и обычно по первому. Среди каталогов показателей самописных 44%, это 1505 витрин по выгрузке реестра dataportals-registry (выпуск 1.27.0 от 15 октября 2026 года). Программный доступ есть у 37% каталогов этого типа. У самописных витрин API отмечен у 8%. SDMX и уровни доступа в таком сайте придётся написать и не бросить. Почта вместо каталога проигрывает по второму критерию: исследование нельзя найти и на него нельзя сослаться, пока его нет в каталоге. NADA закрывает уровни доступа и DDI в ядре. Dataverse ближе университетскому архиву: DOI и OAI-PMH у него в ядре, а семи типов доступа нет.
Последствия. Два сопровождения и два адреса. Пользователь путается, если подписи на сайте не различают полки. Живой образец такой раскладки — мексиканский INEGI: показатели, микроданные на NADA, геопортал и открытые данные стоят рядом и записаны разными каталогами. NADA ставят на домен службы и закладывают сопровождение в бюджет, не только установку. Из 59 неработающих каталогов микроданных 47 — брошенные установки NADA после проектов поддержки. В NADA нет OAI-PMH. DOI она не регистрирует: поле для уже выпущенного DOI есть, выпуск — отдельная задача. Если службе нужен обмен с архивами вроде CESSDA или свой префикс DOI, это следующая карточка, а не повод переехать на Dataverse молча. Nesstar для нового каталога не рассматривают: с версии 4.0 в 2015 году его объявили устаревшим, к 2022 году сняли.
Когда пересмотреть. NADA перестанут выпускать — преемника ищут заранее, не ждут, пока сайт останется без обновлений. На октябрь 2026 года этого события нет: выпуск 5.7.1 вышел 4 октября. Обмен с архивами социальных данных станет обязанностью — открывают карточку про OAI-PMH и DOI.
Какая платформа показателей
Контекст. Предыдущая карточка уже развела показатели и микроданные. Эта выбирает только полку показателей. Обмен по SDMX обязателен. Своей большой команды разработки нет, бюджет на консультантов ограничен.
Варианты. Только PxWeb. Только .Stat Suite. PxWeb для витрины и отдельно .Stat Suite или SDMX-RI как точка обмена.
Критерии. Есть API и выборка по разрезам. Международный партнёр получает SDMX со структурами и справочниками. Служба тянет сопровождение того, что поставила. Если знакомый интерфейс обмен не закрывает, обмен важнее интерфейса.
Решение. Если консультанты по SDMX есть и обмен — главная обязанность, показатели ставят на .Stat Suite: служба SDMX у неё в ядре, внутри используется SDMX-RI. Если команда уже умеет PxWeb, а обмен нужен рядом, витрину ставят на PxWeb. Новые установки — сразу на PxWebApi 2. Точку SDMX добавляют отдельным продуктом, .Stat Suite или SDMX-RI. Два статистических продукта здесь обычная схема: витрина для людей и служба для обмена.
Почему. Один PxWeb проигрывает по второму критерию. Полноценной службы SDMX у него нет: старый API отдаёт файл SDMX-ML 2.0, в PxWebApi 2 формата SDMX нет. Разбор — в главе о каталогах показателей. Одна .Stat Suite закрывает API и SDMX и проигрывает по третьему критерию, если консультантов нет: без них её ставят редко. Самописную витрину поверх этой пары не делают. Порталы ЕЦБ и Статистики Канады стоят поверх API и массовой выгрузки. У службы из этой карточки такой команды нет.
Последствия. При выборе «PxWeb плюс точка обмена» сопровождают два статистических продукта, не считая NADA. Переход на PxWebApi 2 меняет адреса запросов. Старые ссылки переводит конвертер, старый API держат, пока пользователи не переехали, и заранее называют срок отключения. У .Stat Suite обозреватель данных и служба SDMX — разные модули, обновляют оба.
Когда пересмотреть. Международный обмен уйдёт с SDMX на другой обязательный протокол. Команда, которая умела только PxWeb, получит консультантов по SDMX и решит снять отдельную точку обмена — это новая карточка.
Что общего у примеров
Отказ записан так же явно, как выбор. Плата названа. Пересмотр привязан к событию.
| Пример | Что отвергли и по какому критерию | Чем платят | Когда открыть карточку заново |
|---|---|---|---|
| Город | свой CKAN — некому обновлять; облако — те же функции уже есть у региона | зависимость от полей и расписания региона; витрина на своём домене не появляется | больше двухсот наборов, ставка на сопровождение, регион перестал принимать данные |
| Регион | Socrata — файл DCAT-US; Huwise и Piveau — свой профиль страны сопровождает поставщик или подрядчик; свой сайт — выгрузка DCAT редка | расширения, которые проверяют при обновлении, и человек на ошибки сбора | смена профиля, расширение не проверяется на новой версии ядра, страна обязала сидеть на одной платформе |
| Университет | CKAN и один только DSpace — нет цитирования в ядре; Zenodo — нет своего префикса | две системы и договор с DataCite | некому вести две системы; у DSpace появилась выгрузка цитирования; понадобился свой DCAT-AP |
| Статслужба | один самописный сайт — API и SDMX придётся писать самим; почта — обследования не найти | два адреса у показателей и микроданных, а при PxWeb — ещё точка обмена SDMX | NADA перестанут выпускать; обмен уйдёт с SDMX |
Чужая строка этой таблицы другому владельцу не подходит. Региону нужна сборка, которую городу сопровождать некому. Университетский Dataverse не становится порталом открытых данных администрации. NADA с выпуска 5.6 не заменяет каталог показателей.
Источники
- Как обосновать решение, принципы выбора функций, от функций к платформе, свои силы, свободное ПО или облачный сервис — шаблон карточки, матрица региона и почему чужой договор в карточку не переносят.
- CKAN: ядро и расширения — ckanext-dcat, ckanext-harvest 1.6.2 и тесты на CKAN 2.12, ckanext-scheming, ckanext-doi; сверка расширений 11 октября 2026 года. Живой список плагинов data.gov.gr — 13 октября 2026 года, в главе о карточках платформ.
- Экспорт метаданных — файл
data.jsonу JKAN объявляет схему DCAT-US 1.1 и заполняет короткий список полей; штатный файл Socrata — DCAT-US; у ckanext-dcat по умолчанию профиль DCAT-AP 3. - Сборщики Huwise, проверено 14 октября 2026 года; Catalog Connector у Socrata.
- Форма ввода Piveau — заявленная поддержка DCAT-AP и DCAT-AP.de, проверено 14 октября 2026 года. Сбор как основная работа ядра — в главе о федерации.
- Научные репозитории — DOI, версии и цитирование Dataverse, InvenioRDM и DSpace 10.1; лимиты Zenodo. Взносы DataCite — в главе об идентификаторах.
- Каталоги показателей — 1505 самописных витрин, API у 37% каталогов типа и у 8% самописных, PxWeb и SDMX. Каталоги микроданных — NADA 5.7.1 от 4 октября 2026 года, 47 из 59 неработающих каталогов, снятие Nesstar. Сравнение типов и гибриды — INEGI и 7 145 обследований библиотеки Всемирного банка.
- opendata.scot — статический каталог, пока не было государственного портала; разбор — в главе о публикации без портала.
- Доли DCAT у самописных порталов и доли API у каталогов показателей — выгрузка реестра dataportals-registry, выпуск 1.27.0 от 15 октября 2026 года.