Перейти к основному содержимому

Каталоги API, маркетплейсы и списки наборов

Три типа из этой главы встречаются редко. По выгрузке реестра dataportals-registry (выпуск 1.27.0 от 15 октября 2026 года) это 115 каталогов API, 56 маркетплейсов и 107 списков наборов: вместе меньше 1% из 43,6 тысячи каталогов. Их легко не заметить в общей статистике и легко перепутать с «настоящим» порталом.

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

Главный вывод главы: все три типа хорошо работают как дополнение к каталогу данных и плохо — вместо него. Каталог API без карточек наборов прячет, какие данные стоят за интерфейсами. Маркетплейс с закрытыми описаниями прячет сам факт, что данные существуют. Список без лицензий и дат быстро становится тупиком. Лекарство во всех трёх случаях одно: открытое описание по общему стандарту рядом с основной витриной.

Каталог APIМаркетплейсСписок наборов
Что получает свою страницупрограммный интерфейстовар: файл, подписка, доступ к таблицессылка на файл или чужой каталог
Каталогов в реестре11556107
Главный владелеццентральные органы власти, 45%компании, 70%никто не преобладает
Своя разработка74%98%89%
Программный доступ к самому каталогу51%21%14%
Ограниченный доступ хотя бы к части данных14%91%1%
Стандарт описанияOpenAPI, AsyncAPI, сервис данных DCATобщего нет; ODRL и Dataspace Protocol в пространствах данныхчаще никакого; schema.org, Data Package

Строка «программный доступ» говорит о самом каталоге: можно ли программой получить список интерфейсов, товаров или ссылок. У каталога API она не про интерфейсы, которые он перечисляет.

Каталоги API​

Что это. Портал для разработчиков: список программных интерфейсов органа власти, транспортной компании или банка с документацией, примерами запросов, а часто и с выдачей ключей и тестовой консолью. Это не то же самое, что API самого портала открытых данных из главы об API и массовой выгрузке. Там API — дверь в каталог. Здесь интерфейс и есть то, что каталог описывает.

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

Кто создаёт​

Почти половину каталогов API ведут центральные органы власти (45%), ещё 23% — регионы, по 10–11% — компании и муниципалитеты. Больше всего записей у США (24), Финляндии (8), Великобритании (6), Швеции и Норвегии (по 5).

Около трети каталогов API в реестре — 35 из 115 — порталы разработчиков транспорта: метро и автобусных компаний США (MBTA, BART, WMATA, CTA), скандинавских операторов (Entur, Trafiklab, Digitraffic), Лондона, Новой Зеландии, Тайваня. Причина практическая: приложению с расписанием нужны данные о задержках в реальном времени, и транспортная компания выдаёт для этого ключ. Расписания при этом обычно отдают файлом GTFS, а движение машин — потоком GTFS Realtime.

Какие бывают​

  • Национальный каталог государственных API. api.gov.uk в Великобритании, API Setu в Индии, каталог gov.br/conecta в Бразилии, api.gov.au в Австралии, портал разработчиков Сингапура, каталоги Италии, Литвы, Японии, реестр API Нидерландов. Их часто делают отдельно от портала открытых данных: доступ к API почти всегда требует ключа, тестовой консоли и документации, а аудитория — разработчики, а не аналитики.
  • Портал разработчика одной организации. Центральные банки (Риксбанк, Банк Финляндии, Банк Негара Малайзия), статистические службы (Stats NZ, польский GUS), метеослужбы (британский Met Office, индийский IMD), транспорт.
  • Раздел API в портале открытых данных. Во Франции отдельный каталог api.gouv.fr влили в data.gouv.fr: первые карточки переехали 20 ноября 2024 года, в 2025 году старый сайт стали выводить из работы, а теперь его адрес ведёт в раздел сервисов данных портала. 12 октября 2026 года там 1265 интерфейсов: 1119 открытых, 37 с регистрацией и 109 с ограниченным доступом. У 1162 есть ссылка на машиночитаемое описание, у 1038 — на наборы, которые интерфейс отдаёт. Так же устроен каталог API Норвегии в общем национальном каталоге: 1071 сервис данных рядом с наборами. Финский каталог интерфейсов Suomi.fi сделан на CKAN.
  • Реестр интерфейсов государственных систем. Эстонские RIHA и X-tee, лаосский GDX. Это учёт того, какие системы чем обмениваются, в основном для самих ведомств. Публике из него видно описание, но не доступ.
  • Общественные сборники. APIs.guru собирает описания OpenAPI публичных интерфейсов в открытый репозиторий: 12 октября 2026 года — 2529 API и 3992 описания. Рядом publicapis.dev, коммерческие Postman Public API Network и RapidAPI Hub. Немецкий bund.dev — проект волонтёров, которые находят недокументированные государственные API Германии и пишут для них документацию за государство.
  • Реестры серверов MCP. Официальный реестр MCP работает с 8 сентября 2025 года в предварительном режиме. Задача та же — найти интерфейс, — только читает такой каталог не программист, а программа-ассистент. Подробнее о MCP у каталогов данных — в главе о трендах.

Стандарты​

OpenAPI описывает обычный интерфейс «запрос — ответ»: какие адреса, какие параметры, что придёт в ответ. По описанию инструменты сами строят страницу документации, тестовую консоль и клиентские библиотеки. Последняя версия — 3.2.0 от 19 сентября 2025 года. AsyncAPI делает то же для потоков событий: подписка на сообщения о задержках, показания датчиков. Версия 3.1.0 вышла 31 января 2026 года.

Сервис данных в DCAT. С версии DCAT 2 (2020) у словаря каталогов есть отдельная сущность для интерфейса: адрес, ссылка на описание вроде OpenAPI и список наборов, которые сервис отдаёт. Это мост между каталогом API и каталогом данных: одна запись говорит «набор такой-то можно получить вот этим интерфейсом». На этом мосту построены разделы API во французском и норвежском национальных каталогах.

Адрес для программ. RFC 9727 (июнь 2025 года) задаёт стандартный адрес /.well-known/api-catalog. По нему программа получает список интерфейсов сайта в формате linkset, не зная заранее, где лежит портал разработчика. Стандарт новый. 12 октября 2026 года ни один из одиннадцати проверенных национальных и крупных каталогов — британский, австралийский, нидерландский, итальянский, сингапурский, норвежский, французский, api.data.gov, Digitraffic, Entur, bund.dev — по этому адресу список не отдавал. Где код ответа был 200, приходила обычная страница сайта.

Отраслевые стандарты. В транспорте это GTFS и GTFS Realtime. В «умных городах» встречается NGSI-LD — интерфейс для данных датчиков в реальном времени, на нём работает индийская IUDX. У многих стран есть свои правила проектирования государственных API; пример — API Design Rules Нидерландов.

Платформы​

Три четверти каталогов API — свои разработки. Из готовых решений чаще всего встречается портал разработчика при шлюзе API. Шлюз — программа, которая стоит перед интерфейсами организации: проверяет ключи, считает запросы, ограничивает нагрузку. Портал разработчика у него входит в комплект, поэтому каталог появляется почти «бесплатно».

  • Azure API Management — 22 каталога в реестре, от Банка Финляндии и Fingrid до портала API Нью-Йорка и транспорта Вашингтона.
  • WSO2 API Manager (свободный, Apache 2.0) — Met Office, латвийская VDAA. Gravitee — портал Французской Полинезии.
  • Статический сайт из файлов. api.gov.uk собирается из одной таблицы CSV в открытом репозитории GitHub. APIs.guru — тоже репозиторий описаний OpenAPI, из которого генерируется сайт.
  • Платформы каталогов данных. У udata, на которой работает data.gouv.fr, сервисы данных — отдельная сущность в ядре: в карточке есть поля для описания OpenAPI, лимитов, доступности, адреса заявки на доступ и связанных наборов. У CKAN отдельной сущности нет: расширение ckanext-dcat позволяет записать сервис доступа внутри ресурса набора и выгрузить его в DCAT.
ВозможностьПортал шлюза APIСтатический сайт из файловudataCKAN
Страница интерфейса с документациейядрогенератор сайтаядро, ссылка на описание OpenAPIнет; ссылка из ресурса
Выдача ключей и учёт лимитовядронетнет; есть поля «лимиты» и «как получить доступ»нет
Связь интерфейса с набораминетвручнуюядрорасширение ckanext-dcat: сервис доступа у ресурса
Видимость для поисковиковслабая, см. «Где ломается»хорошаяхорошаяхорошая

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

Примеры​

  • Раздел API на data.gouv.fr — национальный каталог API внутри портала открытых данных, с типом доступа и связанными наборами в каждой карточке.
  • api.gov.uk — каталог API британского государственного сектора, собранный из таблицы в открытом репозитории.
  • API Setu — индийский каталог интерфейсов всех уровней власти.
  • Digitraffic и Trafiklab — транспортные данные Финляндии и Швеции: интерфейсы реального времени и файлы расписаний.
  • APIs.guru — открытый сборник описаний OpenAPI.
  • bund.dev — документация к недокументированным государственным API Германии, сделанная волонтёрами.

Где ломается​

Описание отстаёт от интерфейса. В документации одно поле, в ответе другое. Масштаб видно по APIs.guru: 12 октября 2026 года из 3992 собранных описаний 688 не проходили проверку формата, а 166 были недоступны по исходному адресу.

Каталог стареет. В британском каталоге 233 записи, и у 70 из них последнее обновление — 2020 год. Лицензия на данные указана у 36 (12 октября 2026 года). Каталог, который собрали один раз, перестаёт отражать живые интерфейсы так же, как заброшенный портал перестаёт отражать данные.

Описан интерфейс, но не доступ. Каталог перечисляет API, для которых нужен ключ, но не говорит, как его получить, кому дают и сколько ждать. В апреле 2024 года индийская IUDX описывала 189 наборов из 47 городов, в основном потоки реального времени, и ни один не был открыт: по сути это портал разработчика для партнёров, а не каталог открытых данных.

Поисковик не видит каталог. Портал разработчика при шлюзе часто собирает страницу скриптом в браузере. 12 октября 2026 года в HTML страницы со списком API у Банка Финляндии на Azure API Management не было ни одного названия интерфейса — только меню и кнопка входа. Такой каталог не находят ни поисковики, ни веб-архив. Карта сайта отмечена в реестре лишь у 26 каталогов API из 115.

Счёт интерфейсов раздувают. Из 1265 «API» на data.gouv.fr около 800 — автоматические интерфейсы к отдельным наборам с региональных порталов на платформе Data Fair, по одному на каждую таблицу. Это не ошибка: такой интерфейс полезен. Но число API в каталоге, как и число наборов, говорит об устройстве, а не о том, сколько у государства сервисов для разработчиков.

API есть, а каталога нет. Частый случай — интерфейсы существуют, но нигде не перечислены и не описаны. Они ломаются при каждом обновлении сайта, и их не сохраняет веб-архив. В России нет национального каталога государственных API: межведомственный обмен идёт через закрытые системы, а публичные интерфейсы госсайтов в 2021 году собирала «Инфокультура» — больше сотни. Московский apistore.mos.ru в 2021 году содержал 15 прототипов API и не обновлялся с 2019 года; в октябре 2026 года он не открывается из-за рубежа. В Германии ту же работу делают волонтёры bund.dev, во Франции — государство.

Интерфейс вместо выгрузки. Если данные можно получить только запросами по одной записи, тому, кому нужна вся база, приходится выкачивать её неделями и упираться в лимиты. Интерфейс — хорошее дополнение к массовой выгрузке, а не замена; подробнее — в разделе «Массовая выгрузка — не роскошь».

Как проверить каталог API​

  1. Найдите машиночитаемое описание. Есть ли у интерфейса файл OpenAPI, и совпадает ли он с настоящим ответом на пробный запрос?
  2. Найдите порядок доступа. Сказано ли, нужен ли ключ, кто его выдаёт, какие лимиты и какая лицензия у данных?
  3. Найдите набор. Есть ли у данных, которые отдаёт интерфейс, карточка в каталоге данных со ссылкой на интерфейс?
  4. Посмотрите как программа. Видны ли названия интерфейсов в HTML страницы и есть ли список по адресу RFC 9727?
# RFC 9727: список интерфейсов сайта в формате linkset
curl -s -H "Accept: application/linkset+json" "https://example.org/.well-known/api-catalog"
# data.gouv.fr: сколько интерфейсов открыто; access_type=restricted — сколько закрыто
curl -s "https://www.data.gouv.fr/api/1/dataservices/?page_size=1&access_type=open"
# Норвегия: сервисы данных в национальном каталоге
curl -s -X POST -H "Content-Type: application/json" -d '{}' \
  "https://search.api.fellesdatakatalog.digdir.no/search/data-services"
# британский каталог API — одна таблица
curl -s "https://raw.githubusercontent.com/alphagov/api-catalogue/main/data/catalogue.csv"
# APIs.guru: сколько описаний собрано, сколько недоступно и невалидно
curl -s "https://api.apis.guru/v2/metrics.json"

Когда нужен​

Каталог API нужен, когда у организации много интерфейсов и разработчику нужен один вход: где взять ключ, где документация, что изменилось. Одному API ведомства хватит страницы документации с описанием OpenAPI. Если за интерфейсом стоит набор данных, набор стоит описать и в обычном каталоге — со ссылкой на API как на способ получения. Тогда его найдёт и аналитик, который не ищет «API», и сборщик вроде data.europa.eu, который читает DCAT.

Маркетплейсы данных​

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

Кто создаёт​

70% маркетплейсов в реестре — у компаний, 21% — у центральных органов власти. Доступ хотя бы к части данных ограничен у 91%, программный доступ к самой площадке отмечен у 21%. По странам первые — Южная Корея (16), США (12) и Китай (6), ещё 10 площадок работают на весь мир.

Цифры по странам показывают, что маркетплейс данных во многих странах — государственный проект, а не только бизнес:

  • Южная Корея. Большая часть корейских записей — отраслевые платформы больших данных, которые Министерство науки и ИКТ запустило в 2019 году: десять платформ — финансы, окружающая среда, культура, транспорт, онкология, торговля, связь, малый бизнес, региональная экономика, лес. В 2020 году к ним добавили ещё шесть, в том числе пожарную безопасность и морское рыболовство. Все они собраны в общую карту данных: к концу 2021 года там было 6842 вида данных. Платформы смешивают бесплатные и платные данные.
  • Китай. Государственные биржи данных: первая открылась в Гуйяне в 2015 году, Шанхайская биржа — 25 ноября 2021 года, с 20 продуктами в первый день. По обзору августа 2025 года действовали 49 таких площадок с 3944 поставщиками данных, а ещё 24 были ликвидированы или не открывались.
  • Япония. JDEX и KYOTO DATA MARKETPLACE.
  • США. Облачные площадки (AWS, Snowflake, Databricks, Google, Microsoft) и биржи, которые продают собственные рыночные данные: CME DataMine, Cboe DataShop, Nasdaq Data Link. Так же поступают корейская KRX и гонконгская HKEX.
  • Данные для ИИ. Defined.ai, Nexdata, Centific продают наборы для обучения моделей: записи речи, размеченные изображения, тексты.
  • Пространства данных Европы. Каталог Pontus-X в экосистеме Gaia-X, каталог Language Data Space, нидерландский DMI. О пространствах данных — ниже и в главе о трендах.

Какие бывают​

Под одним словом «маркетплейс» живут четыре разные модели.

  • Государственные и отраслевые площадки. Крайняя точка шкалы — data.europa.eu: общественная инфраструктура без платы и без сделок, то есть не маркетплейс, а то, с чем его сравнивают. Шанхайская биржа данных проводит платные сделки между компаниями. Catena-X в автопроме совмещает некоммерческое управление с платными услугами подключения. Британский Rail Data Marketplace, открытый в ноябре 2023 года, ведёт Rail Delivery Group: за первый год там появилось больше 140 продуктов, 1200 организаций и 4000 соглашений об обмене, а в октябре 2026 года — 269 продуктов, бесплатных и платных. Площадка не столько продаёт, сколько ведёт соглашения об использовании: при запуске организаторы обещали, что бесплатных данных будет большинство. Государство или отрасль здесь ещё и продвигает площадку, и может быть регулятором. Поэтому на ней появляются данные, которых нет больше нигде.
  • Данные внутри профессионального продукта. Bloomberg и LSEG продают не наборы, а связку из данных, идентификаторов, лицензий и рабочего места трейдера. Это скорее способ встроить данные в продукт, чем отдельный рынок.
  • Площадки облачных провайдеров. AWS, Snowflake, Google, Databricks. Они различаются тем, берут ли оплату сами и как доставляют данные. Общая логика одна: площадка увеличивает потребление основной облачной платформы.
  • Витрины поставщиков. Datarade (на главной странице в октябре 2026 года — больше 2000 поставщиков) помогает найти поставщика и передать ему запрос, а договор, оплата и доставка остаются между сторонами. Это каталог с привлечением покупателей, а не биржа.

Стандарты​

Описание товара. Общего стандарта нет, каждая площадка ведёт свою карточку. Ближе всего к общему языку описание дата-продукта: владелец, условия, способы доставки, тарифы. Шаблоны вроде ODPS разобраны в главе «Единицы публикации и форматы».

Условия использования. Там, где доступ договаривают между организациями, условия описывают машиночитаемо: ODRL — язык W3C для правил вида «можно использовать для исследований, нельзя передавать третьим лицам».

Протокол пространства данных. Dataspace Protocol (версия 2025-1, утверждена Eclipse Foundation 23 июля 2025 года) соединяет эти части. Участник публикует каталог своих наборов в DCAT, к каждому прикладывает условия в ODRL, а дальше протокол описывает переговоры о договоре и передачу данных. Свободная реализация — коннектор Eclipse Dataspace Components, на нём построен обмен в Catena-X. Важная деталь: описание набора здесь — обычный DCAT. Значит, его можно показать и снаружи, даже если сами данные закрыты.

Доставка без скачивания. Облачные площадки часто не отдают файл, а открывают покупателю доступ к таблице прямо в хранилище поставщика. AWS Data Exchange знает пять видов поставки: файлы, интерфейсы, доступ к таблицам Redshift, прямой доступ к хранилищу S3 и права в Lake Formation. Databricks Marketplace работает на открытом протоколе Delta Sharing, который 10 июня 2026 года превратился в OpenSharing и перешёл в Linux Foundation.

Платформы​

В реестре 55 маркетплейсов из 56 — собственные разработки, и это честная картина: тиражируемого ПО маркетплейсов почти нет. Облачные площадки — часть облака, у бирж данных свои системы. Открытые платформы каталогов — CKAN, Dataverse, InvenioRDM — оплату не принимают. Для пространств данных есть свободный коннектор EDC, но это канал обмена между участниками, а не витрина с оплатой.

Граница с порталами открытых данных размывается. 30 сентября 2025 года OpenDataSoft переименовалась в Huwise и стала продавать ту же платформу как маркетплейс дата-продуктов, в том числе для обмена внутри организации.

Почему площадки редко взлетают​

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

Работающие площадки обычно держит главный владелец данных или тот, у кого уже есть покупатели. Биржи продают собственные котировки. Rail Data Marketplace ведёт отраслевая организация железных дорог. Облачные площадки продают туда, где покупатель уже хранит данные. Независимой витрине чужих данных приходится годами тратиться на продвижение.

Примеры​

  • Rail Data Marketplace — отраслевая площадка железных дорог Великобритании: бесплатные и платные продукты, соглашения об использовании ведёт сама площадка.
  • AWS Data Exchange, Snowflake Marketplace, Databricks Marketplace — облачные площадки с доставкой в хранилище покупателя.
  • Nasdaq Data Link — финансовые и альтернативные данные биржи и сторонних поставщиков.
  • Datarade — витрина поставщиков.
  • JDEX и KYOTO DATA MARKETPLACE — японские площадки.
  • Catena-X — пространство данных автопрома на Dataspace Protocol.

Где ломается​

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

Площадку не видно из-за рубежа. 12 октября 2026 года корейские платформы больших данных, их общая карта данных и китайские биржи из-за рубежа не открывались. Для внутреннего рынка это может быть приемлемо, но для иностранного покупателя, агрегатора и веб-архива таких площадок нет.

«Маркетплейс» как вывеска. Корейские платформы и Rail Data Marketplace во многом раздают данные бесплатно, а Huwise называет маркетплейсом платформу порталов открытых данных. Название не говорит, продают ли там что-нибудь. Тип определяют по тому, что получает пользователь: файл без условий — портал открытых данных; договор на каждую выдачу — маркетплейс.

Площадки закрываются. Из китайских бирж данных к августу 2025 года 24 были ликвидированы или не работали. data.world начинался как открытый облачный каталог, а 13 июля 2026 года закрыл открытое сообщество — история разобрана в главе об облачных хранилищах и хабах.

После подписки ничего не остаётся. При поставке «без скачивания» доступ к таблице исчезает в день окончания подписки. У файлов, которые покупатель успел выгрузить, судьбу решает договор: в AWS Data Exchange выгруженные файлы остаются у подписчика, но договор поставщика может требовать их удалить. Это стоит прочитать до покупки, а не после.

Как проверить маркетплейс​

  1. Откройте карточку без входа. Видны ли описание, состав полей, период, частота обновления, образец данных?
  2. Найдите условия. Записаны ли условия использования в карточке, а не только в договоре, который покажут после оплаты?
  3. Узнайте способ доставки. Файл, интерфейс или доступ к таблице в облаке — и сможете ли вы перенести данные к себе?
  4. Спросите, что останется. Что можно хранить после окончания подписки, и можно ли ссылаться на данные в публикациях?

Когда нужен​

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

Списки наборов​

Что это. Страница, таблица или репозиторий со ссылками на файлы или на чужие каталоги. У списка нет поиска, фильтров и карточек: строка списка — ссылка и одна фраза описания. В реестре 107 таких списков, программный доступ — примерно у 14%.

Кто создаёт​

Здесь нет главного владельца: 20% списков у компаний, 19% у центральных органов власти, 14% у муниципалитетов, 13% у сообществ, 12% у университетов. 89% — свои разработки, 16 лежат на GitHub или GitLab. Первые по странам — США (20) и международные проекты (12). Пять записей отнесены к Сейшельским островам: это криптобиржи, зарегистрированные там, которые выкладывают историю торгов.

Какие бывают​

  • Тематическая подборка сообщества. awesome-public-datasets на GitHub — около 79 тысяч звёзд в октябре 2026 года. Рядом списки по странам: awesome-nigeria-datasets, open-data-turkey. Последний в 2023 году оставался самым полным перечнем порталов Турции: национального портала там нет, а городские порталы и ГИС разбросаны.
  • Страница «Открытые данные» на сайте ведомства или города. Кардифф, Галле, Арнсберг, Лодзь, Эр-Рияд, налоговая служба Саудовской Аравии. Файлы лежат на страницах обычной CMS — TYPO3, Drupal, SharePoint, — без отдельного портала.
  • Страница выгрузки одного издателя. Поездки такси Нью-Йорка — по файлу Parquet на месяц и словари полей. Дампы Википедии, выгрузки OpenStreetMap по регионам, файлы расписаний транспорта. 13 записей из 107 — история торгов криптобирж. Например, data.binance.vision — листинг облачного хранилища, где рядом с каждым архивом лежит файл контрольной суммы.
  • Список, собранный из файлов описаний. Registry of Open Data on AWS — сайт, который генерируется из 1238 файлов YAML в репозитории GitHub (12 октября 2026 года). В каждом файле одни и те же поля: название, описание, лицензия, частота обновления, контакт, адрес хранилища. Сам awesome-public-datasets устроен так же: README собирается автоматически из файлов YAML в соседнем репозитории apd-core.
  • Личные указатели на GitHub Pages. Каталоги клинических данных, геоданных Индии, открытых данных Гонконга, которые ведёт один человек. Полезны как стартовая точка, но у них нет владельца, который ответит за полноту.

Стандарты​

Чаще никаких. Довести список до машиночитаемого вида помогают:

  • разметка schema.org — DataCatalog для страницы и Dataset для каждой строки;
  • файл datapackage.json рядом с данными — его шаблон есть среди шаблонов книги;
  • сам список в CSV, JSON или YAML в репозитории, из которого генерируется страница, — как у реестра AWS;
  • файлы контрольных сумм рядом с архивами, как у Binance;
  • файл DCAT со списком наборов — так статический сайт становится каталогом, который читают сборщики. Как это делают JKAN и другие генераторы, разобрано в главе о статических сайтах.

Платформы​

Обычная веб-страница на CMS, файл README в Git-репозитории, статический сайт на GitHub Pages, общая таблица или просто листинг облачного хранилища. Когда наборов становится несколько десятков, следующий шаг — не CKAN, а статический каталог: те же файлы, но у каждого набора своя страница с описанием и разметкой.

Примеры​

  • awesome-public-datasets — тематический список открытых наборов с пометками о сломанных ссылках.
  • Registry of Open Data on AWS — список наборов в облачном хранилище, собранный из файлов описаний.
  • TLC Trip Record Data — страница выгрузки, которой пользуются годами: один издатель, понятный ряд файлов, словари полей.
  • Wikimedia Downloads — дампы всех проектов Викимедиа.

Где ломается​

Ссылки умирают. Это главная болезнь списков, и awesome-public-datasets с ней борется: каждой строке присвоен статус, и 12 октября 2026 года 96 записей из 1062 помечены как требующие починки. Выборочная проверка 300 случайных ссылок оттуда в тот же день: 258 открылись, 16 вернули ошибку или не ответили, ещё 26 отказали программе (коды 401, 403, 429). Последние для человека, скорее всего, живы, но робот-сборщик их уже не видит.

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

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

Список держится на одном человеке. Личный указатель на GitHub Pages или страница на сайте города перестают обновляться, как только автор уходит. У страницы «Открытые данные» на сайте ведомства при переделке сайта ломаются все адреса разом.

Как довести список до находимой публикации​

  1. У каждой строки — лицензия, дата обновления, формат и размер. Без этого список нельзя использовать, а только просматривать.
  2. Сам список — данные. Храните его файлом CSV, JSON или YAML в репозитории и генерируйте из него страницу. Тогда список можно скачать, проверить программой и собрать в агрегатор.
  3. Ссылки проверяет робот. Проверку ссылок по расписанию легко включить в репозиторий, например действием lychee в GitHub Actions. Сломанные строки помечайте, как в awesome-public-datasets, а не удаляйте молча.
  4. Разметка и регистрация. Добавьте schema.org на страницу и зарегистрируйте список в каталоге своей страны или темы.

Подробно этот путь разобран в главах «Публикация без портала» и «Как сделать публикацию находимой», сводный список шагов — в чек-листах.

Когда нужен​

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

Чем отличаются от соседей​

ТипСоседГлавное отличие
Каталог APIПортал открытых данныхописывает сервисы, а не наборы; у портала API — способ получить набор, у каталога API интерфейс и есть предмет описания
Каталог APIКаталог метаданныхреестр интерфейсов госсистем описывает, кто чем обменивается; каталог API выдаёт доступ разработчику
МаркетплейсПортал открытых данныхна каждую выдачу — договор и условия; у портала открытых данных выдача без заявок
МаркетплейсПространство данныхпространство — правила и протокол обмена между участниками; маркетплейс — витрина, которая может работать поверх него
МаркетплейсКаталог для машинного обученияпродают обучающие наборы по договору; хабы вроде Hugging Face раздают их по открытым лицензиям
Список наборовПортал открытых данныхнет карточек, поиска и API; строка — ссылка и фраза
Список наборовКаталог каталоговперечисляет наборы, а не порталы; подборки awesome часто смешивают то и другое
Список наборовАгрегатор и поисковик данныхсписок собирают руками, агрегатор — программой из чужих каталогов

Сводная таблица всех типов — в главе «Сравнение типов и гибриды».

Источники​