Принципы выбора набора функций
Список функций каталога собирают из задач, а не из рекламы платформы и не из чужого технического задания. У каждой функции в итоговом списке пять пометок: чья задача за ней стоит, насколько она обязательна, почему, как её проверить на живом сайте и когда к решению вернуться. Такой список можно положить в техническое задание и по нему сравнивать платформы.
Маршрутная карта даёт первый ориентир за несколько минут, карта возможностей — что вообще бывает и что типично для вашего типа каталога. Эта глава — способ применить обе карты к своему случаю.
Коротко:
- Начните с того, что уже есть. Часть задач закрывают существующие сайты, сервисы и чужие каталоги. Новый каталог часто нужен, чтобы упорядочить уже опубликованное, а не чтобы публиковать с нуля.
- У каждой функции есть источник: задача владельца, задача пользователя или внешнее обязательство. Функция без источника — кандидат на вычёркивание, даже если она есть «у всех».
- Минимум обязателен всем, остальное включают тип каталога и конкретные обязательства.
- «Обязательно» проверяют вопросом: какая задача не выполнится в день запуска без этой функции и кто это заметит. Нет ответа — значит «желательно».
- У функции есть цена, и она зависит от того, где функция живёт: в ядре платформы, в расширении, в своей доработке или за пределами портала.
- Отказ записывают так же, как выбор, вместе с событием, после которого к нему вернутся.
Возможность, функция, требование
В книге три близких слова, и их стоит различать.
- Возможность — то, что каталоги вообще умеют: отдать описания в DCAT, выдать DOI, закрыть файл при открытом описании. Возможностям посвящена часть «Возможности каталогов».
- Функция — возможность, которую вы выбрали для своего каталога, потому что за ней стоит чья-то задача.
- Требование — функция, записанная в техническое задание (документ, по которому подрядчик делает или настраивает систему), вместе с уровнем обязательности, обоснованием и способом проверки.
Глава превращает задачи в функции, а функции — в требования. Международный стандарт инженерии требований ISO/IEC/IEEE 29148:2018 перечисляет свойства хорошего требования. Для каталога важнее всего четыре:
- необходимое — за ним стоит чья-то потребность, и её можно назвать;
- говорит «что», а не «как» — «национальный портал забирает наши описания в профиле DCAT-AP» — требование, «поставить ckanext-dcat» — уже решение, его принимают на следующем шаге;
- единичное — одна функция в одном пункте: «удобный современный поиск с API и картой» — это три пункта, а не один;
- проверяемое — можно показать, выполнено оно или нет.
Шаг 1. Опишите, что уже есть
До списка функций составьте опись: какие данные организация уже публикует и где. Раздел «Документы» на сайте, таблицы во вложениях к новостям, API информационных систем, картографический сервер, страницы в чужих каталогах, выгрузки, которые отправляют по запросу. По каждому пункту запишите, кто этим пользуется и что сломается, если это перенести.
Опись даёт две вещи. Во-первых, часть задач уже решена: слои живут в картографическом сервере, научные данные лежат в Zenodo, статистика отдаётся через API. Каталогу остаётся их описать и связать, а не повторить. Во-вторых, видно, что нельзя ломать: адреса, на которые ссылаются, и программы, которые забирают файлы по расписанию.
Пример — Казахстан. В феврале 2023 года национальный портал открытых данных data.egov.kz выдавал данные только после входа по индивидуальному идентификационному номеру через государственную службу идентификации, то есть открытым по сути не был. При этом общедоступных машиночитаемых данных у органов власти было больше, чем на портале: открытый API статистической системы «Талдау» без авторизации, программный интерфейс сайта правительства gov.kz, картографические сервисы геологической службы на ArcGIS. В такой ситуации главная работа портала — систематизировать уже опубликованное, и функции у него другие: описывать и собирать чужие сервисы, а не принимать файлы вручную. В апреле 2023 года обязательную регистрацию на портале отменили, но стали отдавать не больше 100 записей за раз — об этом в главе об антипаттернах. Документация API «Талдау» в октябре 2026 года открыта.
Если опись показывает, что задачи уже закрыты, свой каталог может оказаться не нужен. Когда так бывает — в главе «Когда портал не нужен».
Шаг 2. Соберите задачи
У функции три возможных источника:
- задача владельца: отчитаться по закону, выполнить условия гранта, продать сервис, перестать отвечать на одни и те же письма;
- задача того, кто данными пользуется: скачать таблицу, сослаться в статье, забрать описания программой, построить приложение;
- внешнее обязательство: национальный портал собирает описания в DCAT, журнал требует DOI, инфраструктура пространственных данных требует каталог слоёв.
Где брать задачи:
- Письма и обращения с просьбой дать данные. Каждая просьба — задача пользователя, повторяющаяся — кандидат в обязательные.
- Статистика существующего сайта: что скачивают и что ищут, но не находят. Запросы в поиске, которые ничего не вернули, — готовый список пробелов.
- Разговоры с настоящими пользователями каждой группы: аналитиками, исследователями, разработчиками. Разговоры можно заканчивать, когда ответы начинают повторяться. Чего ждут разные группы — в главе «Зачем создают каталоги и кто ими пользуется».
- Перечень обязательств: закон и подзаконные акты, требования вышестоящего портала к профилю описаний, условия грантов, отраслевые инфраструктуры вроде INSPIRE или обмена SDMX. Каждое обязательство записывают со ссылкой на документ.
- Задачи редакции: кто будет заводить описания, сколько их, как часто обновлять, откуда брать. Эту группу забывают чаще всего, а от неё зависят роли, массовая загрузка описаний и сбор из учётных систем.
Отдельно запишите задачи программ: вышестоящего портала, поисковиков данных, сборщиков, ИИ-агентов. Писем они не пишут, поэтому их задачи формулируют за них. Обычно это и есть минимум из следующего шага.
Задачу записывают по форме «кто — что делает — зачем». «Аналитик министерства каждый месяц сравнивает качество воздуха по районам» — задача. «Нужен современный портал» — нет: непонятно, кто и что на нём будет делать.
Шаг 3. Переведите задачу в функцию
Одна задача обычно даёт несколько функций, и не всегда тех, что приходят в голову первыми.
| Задача | Какие функции из неё следуют | Что часто просят вместо |
|---|---|---|
| Журналист раз в год скачивает исполнение бюджета и сравнивает с прошлым годом | файл CSV или XLSX, лицензия, дата обновления, прошлые годы по постоянным адресам | предпросмотр с графиками |
| Национальный портал собирает описания региона | выгрузка в профиле DCAT-AP по постоянному адресу, лицензия у каждого набора | таблица наборов, которую раз в квартал отправляют почтой |
| Разработчик приложения показывает ежечасные замеры воздуха | файл или API с постоянным адресом, обновление по расписанию, описание полей | «современный API» без описания, что он отдаёт |
| Аспирант ссылается на данные в диссертации | постоянный адрес набора и файла; DOI и версии — только если данные меняются, а сослаться нужно на конкретное состояние | DOI на каждый набор |
| Грант обязывает положить данные к статье | DOI, версия, строка цитирования — часто в общем научном репозитории | свой репозиторий в каждой лаборатории |
| Поисковик данных находит набор | разметка schema.org, карта сайта, описания без регистрации | продвижение портала в соцсетях |
| Двадцать отделов публикуют сами | организации, роли, проверка перед публикацией | одна учётная запись на всех |
| Ведомство отчитывается о числе наборов | это не задача пользователя, функции из неё не выводят | дробление одного ряда на сотни наборов ради счётчика |
Если вместо задачи приходит готовое решение — «поставить CKAN», «сделать как у соседей», «нужен API», — спросите, какую задачу оно решает. За словом «API» могут стоять три разные функции с разной ценой: файл со всеми описаниями для вышестоящего портала, выборка строк таблицы для разработчика, поиск по каталогу для программы. Как они устроены — в главе «API и массовая выгрузка».
Шаг 4. Сначала то, без чего каталог невидим
Минимум одинаковый для всех, от национального портала до страницы исследовательской группы:
- постоянный адрес набора и файла;
- лицензия у каждого набора, а не только у сайта;
- дата обновления и контакт ответственного;
- выгрузка всех описаний одним файлом или запросом (небольшому сайту хватит одного файла
data.json); - разметка schema.org и карта сайта;
- описания читаются без регистрации и капчи.
Эти функции обязательны без отдельного обоснования, причины записаны в карте возможностей. Поиск с фильтрами, предпросмотр и статистика идут после минимума. Красивый сайт без выгрузки описаний не попадает ни в национальный портал, ни в поисковик данных.
Минимум не требует портала: статический сайт или Git-репозиторий закрывает его целиком.
Шаг 5. Расставьте уровни
| Уровень | Тест | Пример обоснования |
|---|---|---|
| Обязательно | без функции конкретная задача не выполняется в день запуска, и понятно, кто это заметит. Внешнее обязательство всегда даёт «обязательно» — со ссылкой на документ | «Национальный портал забирает DCAT-AP, иначе наши наборы не попадут в общую витрину» |
| Желательно | задача выполняется и без функции, но хуже, дольше или дороже | «Предпросмотр таблицы уменьшит письма „что в файле“, но файл и так скачивается» |
| Не нужно | задачи нет, или её закрывает кто-то другой | «DOI не нужен: данные оперативные, на конкретную версию не ссылаются» |
Пометка «не нужно» не значит «никогда». К ней пишут условие пересмотра: «DOI не нужен, пока данные оперативные; вернуться, если начнём выпускать проверенный годовой архив для исследователей». Без условия отказ через год придётся объяснять заново, а с ним видно, когда объяснение устарело.
Если обязательных функций больше половины списка, пройдите тест заново: скорее всего, часть записана «на всякий случай». По такому списку платформы не сравнить — все окажутся «почти подходящими», а цена проекта вырастет за счёт функций, которыми никто не пользуется.
Шаг 6. Оцените цену функции
Одна и та же функция стоит по-разному в зависимости от того, где она живёт.
| Где функция | Цена запуска | Цена сопровождения | Главный риск |
|---|---|---|---|
| В ядре платформы | настройка | обновляется вместе с платформой | функцию меняют или убирают в новой версии, но об этом пишут в примечаниях к выпуску |
| В расширении | установка и настройка | проверка при каждом обновлении ядра | расширение отстаёт от ядра или его бросают |
| В облачном сервисе | включить в настройках или купить тариф | абонентская плата | функция зависит от тарифа и решений поставщика |
| Своя доработка | работа разработчика | всё сопровождение на вас | автор уходит, функция остаётся без хозяина |
| За пределами портала | договор или правила работы | следить, чтобы связь не порвалась | чужой сервис меняет условия или закрывается |
Разница видна на живых каталогах. По реестру dataportals-registry (выпуск 1.27.0 от 15 октября 2026 года) описания в DCAT отдают 239 из 245 порталов на Socrata, где эта функция в ядре, 633 из 1906 порталов на CKAN, где её добавляет расширение ckanext-dcat, и 24 из 1144 самописных порталов открытых данных. Функция из ядра есть почти у всех установок, из расширения — у трети, из своей разработки — у 2%.
Расширение, без которого обязательная функция не работает, проверяют до выбора: кто его ведёт, на каких версиях ядра идут тесты, когда был последний выпуск. Методика — в главе «Экосистемы расширений». Пример риска: документация ckanext-doi называет только CKAN 2.9 и 2.10, а на 2.11 и 2.12 расширение не тестировалось. Если DOI обязателен, это довод искать платформу, где он в ядре.
Цену запуска и цену сопровождения оценивают отдельно. Облачный сервис запускается за недели, но платить за него придётся каждый год; свою доработку пишут один раз, а сопровождают всё время жизни каталога. Подробнее — в главе «Скорость развёртывания и сопровождение».
Функцию не обязательно делать в своём каталоге
Часть функций выгоднее отдать тому, кто их уже умеет. Тогда в списке функция остаётся, а в графе «где живёт» стоит чужой сервис.
| Функция | Кто может закрыть вместо вас | Что остаётся вам |
|---|---|---|
| DOI и версии | Zenodo, университетский репозиторий, репозиторий консорциума | ссылка из карточки набора на DOI и правило, что считать новой версией |
| Поиск для жителей всей страны | национальный или региональный портал, который собирает ваши описания | выгрузка описаний в его профиле |
| Слои карты и картографические сервисы | картографический сервер или региональный геопортал | карточка набора, которая ведёт на сервис |
| История изменений небольших наборов | Git-репозиторий на GitHub или GitLab | выпуски с метками и файл CITATION.cff |
| Хранение больших файлов | облачное хранилище или общий хаб данных | постоянный адрес файла, а не временная ссылка |
Цена такого решения — зависимость от чужих правил: лимитов Zenodo, расписания сбора у регионального портала, тарифов облачного хранилища. Её записывают в карточку решения так же, как цену расширения. Если чужие сервисы закрывают всё, кроме минимума, свой портал, возможно, не нужен — варианты разобраны в части «Публикация без портала».
Шаг 7. Не закрывайте себе следующий шаг
Спросите, что понадобится через три-пять лет, и проверьте, какое свойство платформы сохраняет к этому дорогу:
- больше публикаторов — организации и роли в ядре, а не одна учётная запись на всех;
- второй язык — многоязычные поля описания, а не только перевод интерфейса;
- сбор муниципальных каталогов — сбор по DCAT или API в ядре или в живом расширении;
- DOI для научных приложений — связь с научным репозиторием или с DataCite;
- смена платформы — полная выгрузка описаний и файлов и адреса, которые можно перенаправить. Об этом раздел «Сколько стоит уйти».
Отказ от функции сегодня допустим. Недопустим выбор платформы, с которой к этой функции потом нельзя подойти. Облачный сервис даст свои поля в шаблоне, но не свою программу вокруг них: проверку по внешнему справочнику, выгрузку в профиль, которого нет у поставщика, новый тип записи. CKAN обрастёт и этим, но ценой расширений.
Что получается на выходе
Таблица, а не абзац «хотим современный портал». Пример ниже условный, но собран из типичных задач.
Природоохранное ведомство региона публикует ежечасные замеры станций качества воздуха, разрешения на выбросы и границы охраняемых территорий. Слои уже есть на региональном геопортале. Национальный портал собирает описания в профиле DCAT-AP. Данные готовят три отдела, публикует пока один сотрудник.
| Функция | Откуда потребность | Уровень | Почему так | Как проверим | Когда пересмотреть |
|---|---|---|---|---|---|
| Постоянный адрес набора и файла | ссылки из докладов, новостей и приложений | обязательно | минимум | адрес не меняется после переименования набора и правки описания | — |
| Лицензия у набора | все пользователи | обязательно | без неё данные нельзя законно использовать | у двадцати случайных наборов лицензия есть и в карточке, и в выгрузке | — |
| Выгрузка DCAT-AP | национальный портал | обязательно | иначе наборы ведомства не попадут в общую витрину | файл выгрузки проходит валидатор профиля, национальный портал забрал описания | национальный портал сменит профиль |
| Замеры воздуха файлом и API с обновлением каждый час | разработчики приложений о качестве воздуха | обязательно | без этого приложения разбирают страницы чужих сайтов и ошибаются | данные по адресу не старше двух часов, описание полей опубликовано | — |
| Слои охраняемых территорий у себя | уже на региональном геопортале | не нужно | слои живут в картографическом сервере, копия разойдётся с оригиналом | карточка набора ведёт на сервис WFS и на страницу геопортала | геопортал перестанет обновлять слои или закроется |
| Роли для трёх отделов | задача редакции | желательно | на старте публикует один сотрудник по заявкам отделов | — | отделы начнут публиковать сами |
| Предпросмотр таблиц | письма «что в файле» | желательно | файл и так скачивается, словарь полей отвечает на те же вопросы | — | письма не убавятся после публикации словаря полей |
| DOI | никто не ссылается на версию | не нужно | замеры оперативные, на конкретное состояние не ссылаются | — | ведомство начнёт выпускать проверенный годовой архив для исследователей |
| Сбор муниципальных каталогов | — | не нужно | это работа регионального портала открытых данных, а не ведомства | — | регион поручит ведомству собирать экологические данные муниципалитетов |
Дальше эта таблица превращается в выбор платформы: следующая глава добавляет к ней колонки «ядро, расширение, доработка, невозможно» для каждой платформы из короткого списка. Отказ от DOI из этой таблицы оформлен карточкой решения. Остальные развилки — платформа, расширение, своя разработка — оформляют так же. Четыре полные цепочки от задачи до платформы — в разобранных примерах.
Как проверить свой список
- У каждой функции записан источник: чья задача или какой документ.
- Минимум отмечен обязательным целиком.
- В списке нет решений вместо задач: названий платформ, «как у соседей», «современный».
- Каждое требование — одна функция, а не три в одной строке.
- У каждой обязательной функции есть способ проверки на живом сайте.
- Обязательных функций меньше половины списка, или про каждую понятно, почему без неё нельзя.
- Отказы записаны с причиной и условием пересмотра.
- Отмечено, какие функции закрывает не ваш каталог, и кто именно.
- В списке есть задачи программ и редакции, а не только людей на сайте.
Те же пункты, разложенные по разделам технического задания, — в чек-листе требований.
Типичные ошибки
- Список из брошюры платформы. Брошюра перечисляет то, что у платформы есть, а не то, что нужно вам. Сравнение по такому списку выигрывает платформа, чья брошюра.
- Список из чужого задания. Национальному порталу нужны сбор чужих каталогов и роли для сотни ведомств, городу с тридцатью наборами — нет. Скопированное задание переносит чужие задачи и чужую цену.
- Функции под отчёт. Число наборов и просмотров — показатель владельца, а не задача пользователя. Когда под него подбирают функции, получается дробление данных и витрина без выгрузки.
- Забытая редакция. Портал выбрали по витрине, а заводить пятьсот описаний вручную некому. Нужны массовая загрузка описаний или сбор из учётной системы, и это функция, а не мелочь внедрения.
- «API» без содержимого. Требование «должен быть API» выполняет любой интерфейс, даже бесполезный. Пишут, что и кому он отдаёт: все описания, строки таблицы, результаты поиска.
- Отказ без условия. «DOI не нужен» без условия пересмотра через год выглядит как недосмотр, а не как решение.
Источники
- Карта возможностей — минимум, функции по типам каталогов, внешние причины обязательности.
- Зачем создают каталоги и кто ими пользуется — группы пользователей и их ожидания.
- Чек-лист требований
- ISO/IEC/IEEE 29148:2018 — Systems and software engineering — Life cycle processes — Requirements engineering: свойства хорошего требования (необходимое, единичное, проверяемое и другие), требование описывает «что», а не «как».
- Доли каталогов с DCAT по платформам — выгрузка реестра dataportals-registry, выпуск 1.27.0 от 15 октября 2026 года. Запросы — в приложении «Как работать с реестром».
- Совместимость ckanext-doi — глава «CKAN: ядро и расширения».
- И. Бегтин, портал открытых данных Казахстана и общедоступные API органов власти, Telegram, 19.02.2023; отмена регистрации и лимит записей на data.egov.kz, Telegram, 26.04.2023; документация API «Талдау», проверено 12 октября 2026 года.