Когда портал не нужен

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

Пустая установка обещает каталог, сопровождать который некому. Описания устаревают. Если регистрация открыта, она собирает спам — так бывает у порталов на CKAN, подробнее в главе о доступе и ролях. После окончания договора на хостинг пропадают адреса. Страница с десятком наборов такого обещания не даёт.

Что в этой главе называется порталом

Каталог — любое место, где набор можно найти, понять и получить. Им бывает и статический сайт. Портал в этой главе — своё приложение: база описаний, поиск, учётные записи, роли и сервер, который кто-то обновляет годами. Список наборов — страница или файл со ссылками, без карточек и поиска. Для десятка наборов список нормален. Тупиком он становится, когда у строки нет лицензии, даты и постоянного адреса.

Как каталог собран из частей — в главе об устройстве каталога. Как довести список до находимой публикации — в главе о списках наборов.

Пять вопросов до установки

Ответы записывают до выбора платформы. Платформа, которая закрывает функции, бесполезна, если её некому сопровождать. Сравнение способов создания — в главе «Свои силы, свободное ПО или облачный сервис».

1. Кто должен увидеть данные. Вышестоящий каталог, поисковик, читатель статьи, коллеги внутри организации. От адресата зависит файл описаний: DCAT-AP, DCAT-US, schema.org или DataCite.
2. Сколько наборов и как часто они меняются. Десятки наборов и правки несколько раз в год закрывает страница или репозиторий. Сотни наборов, которые каждый день приходят из учётной системы, требуют загрузки в портал или скрипта, который сам обновляет файлы. Скрипт — по-прежнему публикация без портала.
3. Сколько организаций публикует и как они правят. Одна группа обходится правами на репозиторий и проверкой изменений перед слиянием. Портал нужен, когда публикаторов много и они не работают с Git, либо когда поток заявок на закрытый файл при открытом описании уже не разобрать почтой и ручным одобрением на общем хабе.
4. Кто обновляет сервер через три года. Если ответ «автор страницы» или «никто», портал ставить рано. Ставка или договор на сопровождение делают портал возможным, но первые три вопроса не отменяют.
5. Что именно обязан забрать верхний каталог. Обычно это один файл описаний в нужном профиле. API поиска нужен людям и программам, когда наборов уже сотни. Сборщику хватает файла.

Ответ	Куда публиковать
Одна группа, десятки наборов, верхний каталог принимает чужие организации	в этот каталог, своей витрины нет
Свой сайт уже есть, верхний каталог забирает файл	файл описаний на этом сайте
Нужны история правок и совместная работа	Git-репозиторий и страница из тех же файлов
На данные будут ссылаться в статье, своего репозитория нет	общий репозиторий с DOI, например Zenodo
Файл большой	облачное хранилище или хаб, описание — на своей странице
Много публикаторов вне Git, поток заявок на закрытые файлы, сбор чужих каталогов	свой портал или типовой портал, который уже раздают органам власти

Последняя строка не значит «ставить CKAN завтра». Типовой портал, который регион или поставщик уже ведёт для муниципалитетов, закрывает роли без вашей установки. Разбор для города — в примере муниципалитета.

Куда публиковать

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

Способ	Когда его хватает	Чего не будет	Подробнее
Чужой каталог	наборов мало, каталог уже принимает ваши наборы	своего домена и своих полей	способ создания
Раздел своего сайта	сайт есть, наборов немного	формы «добавить набор» и ролей для внешних публикаторов	ниже, на примере файла data.json
Статический сайт	десятки наборов, есть человек, который правит файлы	поиска по API и сбора чужих каталогов по расписанию, пока его не напишете отдельно	статические сайты
Git-репозиторий	важны история и совместная правка	больших файлов в самом Git и находимости без страницы	Git-репозитории
Облако и общий хаб	файл большой, нужен DOI или аудитория уже на площадке	гарантии, что правила площадки сохранятся	хранилища и хабы

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

Файл на своём сайте вместо портала

data.gov не хранит файлы ведомств. Ведомство публикует каталог метаданных — обычно data.json по профилю DCAT-US — по постоянному адресу на своём сайте. Сборщик забирает этот файл по расписанию, и записи появляются в общем каталоге. В инструкции GSA источник — публичный файл, тип источника «документ», частота от ежедневной до ежемесячной. По правилам сборщика источник забирают не реже раза в месяц.

13 октября 2026 года список источников сбора показывал 793 записи. 135 из них имеют тип «документ»: сборщик забирает один файл. У 117 адрес ведёт на data.json. Ещё 577 принадлежат Бюро переписи: это папки географических описаний, нарезанные по типам границ, а не отдельные ведомства. Для небольшого ведомства вывод прямой: ему достаточно одного файла.

Живой пример — Избирательная комиссия США (Election Assistance Commission). Её сайт собран на Drupal 10. Каталог данных комиссии — файл eac.gov/data.json. 13 октября 2026 года в нём было 11 записей по схеме DCAT-US 1.1, и сборщик data.gov забирает его раз в неделю как источник eac-data. Этого хватает, чтобы описания попали в национальный каталог.

Сбор забирает и слабое описание. Поля license в записях нет. В поле rights схема DCAT-US 1.1 ждёт короткий текст об условиях доступа, а у части записей стоит логическое значение true, у части поля нет. Часть адресов скачивания ведёт на раздел сайта, а не на файл. Часть записей — отчёты в PDF. Файл вместо портала закрывает задачу сбора. Лицензию, прямую ссылку и отделение набора от отчёта автор проставляет сам.

В Европе тот же приём: data.europa.eu забирает каталог по DCAT-AP, если издатель подал его на сбор. Свой CKAN для этого не требуется. Как устроена цепочка — в главе о федерациях.

Три места сразу

Исследовательский проект Global Jukebox публикует данные о песенных традициях без своего портала. Сайт theglobaljukebox.org показывает записи людям. Таблицы и код лежат в репозиториях организации theglobaljukebox на GitHub. Выпуск набора Cantometrics, на который ссылаются, заархивирован в Zenodo: DOI 10.5281/zenodo.4898406, версия v0.1-alpha от 3 июня 2021 года. 13 октября 2026 года сайт открывался, запись Zenodo тоже.

Сочетание работает, пока у трёх мест одно и то же описание. Здесь оно разошлось уже в том выпуске, который получил DOI. Файл LICENSE.txt в метке v0.1-alpha — лицензия CC BY 4.0. Файл .zenodo.json той же метки указывает CC BY-NC 4.0, и запись Zenodo показывает именно её. Человек, который цитирует DOI, и человек, который скачал репозиторий, получают разные условия. Лицензию выбирают один раз, пишут в том месте, которое считают главным, и в остальные копируют ту же.

Пример: ведомство с двадцатью наборами

Контекст. Небольшое ведомство. Около двадцати наборов: выгрузки раз в квартал и годовые отчёты. Сайт на обычной CMS уже есть, его ведёт один веб-мастер. Национальный каталог забирает файл описаний в известном профиле — DCAT-US или DCAT-AP — и организации внутри себя тоже принимает. Своей команды порталов нет.

Варианты. Свой CKAN. Облачный портал. Организация только на национальном каталоге, файлы остаются на сайте ведомства. Файл data.json на существующем сайте, зарегистрированный для сбора.

Критерии. Попасть в национальный каталог. У каждого набора — лицензия и прямая ссылка на файл. Адрес файла описаний не меняется при правке текста на сайте. Сопровождение укладывается в работу одного веб-мастера. Своя витрина на уже существующем сайте важнее отдельного портала: читатели ищут данные там, где ищут само ведомство.

Решение. Файл описаний на существующем сайте и заявка на сбор. Если национальный каталог внешние файлы не забирает и принимает только организации внутри себя — публиковать туда и портал не ставить.

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

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

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

Как записать такую карточку у себя — в главе «Как обосновать решение».

Когда свой портал всё-таки нужен

• Наборы публикуют много организаций, эти люди не работают с Git, и каждой нужны свои права и проверка перед публикацией.
• Описание открыто, а файл выдают по заявке, и заявок столько, что общий хаб и почта не справляются. Так устроены каталоги микроданных.
• Нужно регулярно забирать чужие каталоги и модерировать копии. Скрипт в репозитории, как у opendata.scot, тянет тысячи описаний, но роли он не даёт.
• Наборы каждый день приходят из учётной системы, и скрипт, который обновляет файлы, поддерживать труднее, чем загрузку в портал.
• Профиль страны требует возможности, которой нет ни у файла, ни у чужого каталога, уже принимающего ваши наборы. Чаще требуют именно файл в нужном профиле.

Для отдельных типов каталога порог другой. Научной группе с одним набором к статье свой репозиторий не нужен. Городу с тридцатью наборами — тоже.

Задача	Где разобрано, когда свой каталог не нужен
Открытые данные органа власти	порталы открытых данных
Карты и слои	геопорталы
Данные к статье	научные репозитории
Показатели	каталоги показателей
Микроданные	каталоги микроданных
Наборы для моделей	ML-каталоги
Справочники	каталоги метаданных

Чем платите

Способ	Что получаете	Чем платите
Чужой каталог	карточки, сбор и поиск уже работают	чужие поля, чужое расписание, нет своего домена
Раздел сайта	дёшево, адрес в вашем домене	правки вручную; поиск по API не появляется
Статический сайт	почти нечему ломаться, сайт можно забрать файлами	правки через файлы; форму «добавить набор» люди без Git не осилят
Git-репозиторий	история и совместная работа	предел размера: GitHub не принимает файлы больше 100 МиБ и советует держать репозиторий меньше 1 ГБ; без страницы с разметкой набор плохо ищется
Облако и хаб	большие объёмы, DOI, чужая аудитория	правила и лимиты площадки меняются, площадка может закрыться

Цены чужих площадок сравнивают в главе о способе создания. История закрытых хабов — в главе об облачных хранилищах.

Что видно по живым спискам

В реестре dataportals-registry (выпуск 1.27.0 от 15 октября 2026 года) 107 каталогов записаны как списки наборов: страница, репозиторий или листинг хранилища, без карточек. Программный интерфейс есть у 15. Карта сайта — у 12. 95 записаны своей разработкой. Остальные двенадцать — страницы на обычных движках сайтов: Drupal, WordPress, TYPO3, Jekyll, SharePoint и Liferay. Недействующих и снятых — 7.

Малая доля интерфейсов для списка ожидаема. Списку из двадцати ссылок API поиска не нужен. Ломается другое: у строки нет лицензии, адрес страницы меняется при переделке сайта, разметки schema.org нет, и ссылки умирают молча. Как это измерили на тематическом списке и как починить — в главе о списках наборов. Реестр лицензии и разметку schema.org почти не записывает, поэтому эти дыры в его цифрах не видны.

Как проверить своё решение

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

Команды проверки файла и разметки — в главах об экспорте метаданных и о находимости.

Типичные ошибки

Портал «как у всех». Город или ведомство ставит CKAN, потому что так сделал сосед. Через два года ядро не обновлено, наборов столько же, сколько влезло бы на одну страницу. Сначала отвечают на пять вопросов выше.

Ссылка на папку. Общий диск или бак без страницы описания — не публикация. Адрес временный, лицензии нет, через год папку не находят.

Свой формат файла описаний. Чтобы собрать сайты, придумывают таблицу CSV со своими колонками. Сборщик национального каталога её не читает. Файл делают в том профиле, который уже принимает верхний каталог. Как это вышло с методическими рекомендациями в России — в главе об антипаттернах.

Ждать, пока кто-то построит портал. Пока национальный или региональный каталог не принимает наборы, страница и репозиторий уже публикуют данные. Сообщество в Шотландии так собрало opendata.scot, не дожидаясь государственного портала. Подробности — в главе о статических сайтах.

Три копии — три лицензии. Сайт, репозиторий и хаб описывают один набор по-разному. Читатель не знает, какая копия главная. Главной назначают одну и сверяют с ней остальные.

Источники

• GSA, How to get your Open Data on Data.gov — data.gov не хранит файлы, ведомство публикует data.json; Harvester API — источник забирают не реже раза в месяц; список источников сбора — 793 источника, из них 135 с типом «документ», 117 адресов data.json и 577 источников Бюро переписи, проверено 13 октября 2026 года
• eac.gov/data.json — 11 записей, схема DCAT-US 1.1, поле rights и адреса скачивания; сайт комиссии отвечает заголовком Drupal 10. Проверено 13 октября 2026 года. Источник eac-data в списке сбора — еженедельный документ. Поле rights в схеме набора DCAT-US 1.1 — текст до 255 знаков или пустое значение; license — необязательная ссылка
• Global Jukebox: сайт, организация на GitHub, DOI 10.5281/zenodo.4898406 (запись Zenodo, лицензия CC BY-NC 4.0, версия v0.1-alpha от 3 июня 2021 года). В той же метке репозитория LICENSE.txt — CC BY 4.0, а .zenodo.json указывает CC BY-NC 4.0. Проверено 13 октября 2026 года
• Большие файлы на GitHub — предел 100 МиБ на файл и рекомендация держать репозиторий меньше 1 ГБ
• Выгрузка реестра dataportals-registry, выпуск 1.27.0 от 15 октября 2026 года: 107 списков наборов, интерфейс у 15, карта сайта у 12, своя разработка у 95, недействующие и снятые — 7. Запросы 15 октября 2026 года — в приложении
• Как попасть в сбор data.europa.eu