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

Полнота и детальность метаданных

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

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

Что это​

Три свойства описания часто смешивают.

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

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

Достоверность — правда ли то, что записано в поле. Период «1900–2099» у таблицы за один год, описание, которое повторяет название, территория «вся страна» у данных одного района. Формально поле заполнено, по существу — нет.

Платформа может быть подробной и при этом пустой: двадцать обязательных полей, в которых стоит прочерк. И наоборот: короткая схема, заполненная честно, полезнее длинной анкеты. Крайний случай — каталог вычислительной химии ioChem-BD на DSpace: у его наборов название часто просто числовой код, например «000112758». Химик, который знает, что ищет, такой набор откроет по ссылке из статьи. Поиск по каталогу и поисковики данных его не найдут.

Зачем нужна​

Чтобы найти. Поиск и фильтры работают только по заполненным полям. Набор без периода не попадёт в фильтр «2020–2024», набор без темы — в раздел «Транспорт». Поисковики данных строже: Google принимает разметку набора, только если у неё есть название и описание длиной от 50 до 5000 символов.

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

Чтобы понять, что внутри. Колонка sum_2 без словаря полей открыта формально и закрыта по смыслу. В 2021 году Росводресурсы открыли систему «Водные данные» с паспортами наборов, API и электронной подписью файлов. Описания структуры полей в паспортах не было, а в одном поле реестра водопользователей вместе лежали название владельца, адрес и ИНН. Данные есть, документации к ним нет.

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

Чтобы сборщик не гадал. Агрегатор, который собирает описания со многих каталогов, при бедном описании набора вынужден подставлять свойства самого каталога: если весь каталог посвящён здравоохранению, его наборы получают тему «здоровье». Так поисковик Dateno ищет слои с серверов ArcGIS и GeoServer, у которых своего описания почти нет. Это лучше, чем ничего, но точность такого поиска — точность догадки.

Четыре уровня описания​

Минимум, без которого набор нельзя использовать:

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

Этого хватает, чтобы найти набор и понять, можно ли его брать.

Рекомендуемый уровень добавляет то, без чего набор трудно отфильтровать и трудно обновлять:

  • охват по времени и территории;
  • как часто обновляется;
  • тема из общего справочника;
  • формат и размер файла;
  • язык.

Предметный уровень нужен там, где без него данные нельзя интерпретировать:

  • статистика — методика, единица измерения, разрывы ряда;
  • геоданные — система координат, масштаб, тип объекта;
  • наука — авторы с ORCID, финансирование, связь со статьёй;
  • микроданные — выборка, вопросник, уровни доступа.

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

Чем отличаются даты данных от дат карточки, разобрано в главе «Анатомия каталога». Коротко: если платформа их не различает, дата «обновлено» говорит о правке описания, а не о свежести данных.

Что требуют стандарты и чего не требуют​

Обязательные поля стандарта — это минимум для обмена между программами, а не минимум пользы. Самое неожиданное в таблице ниже — где оказалась лицензия.

СтандартОбязательноВажное, но не обязательное
DCAT-AP 3.0.1, профиль порталов ЕСу набора — название и описание; у способа получения — адрес доступау набора 7 рекомендуемых свойств: контакт, способ получения, территория, ключевые слова, издатель, период, тема. Ещё 27 необязательных, среди них дата выпуска, дата изменения и частота обновления. Лицензия — рекомендуемое свойство способа получения, а не набора
Схема DataCite, по ней регистрируют DOIидентификатор, автор, название, издатель, год публикации, тип ресурсаописание, тема, даты, территория — рекомендуемые; лицензия, язык, формат, размер, версия, финансирование — необязательные
schema.org/Dataset по требованиям Googleназвание, описание от 50 до 5000 символовлицензия, автор, период, территория, измеряемые переменные, идентификатор — рекомендуемые

Из этого следуют два вывода.

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

Второй: в DCAT-AP лицензия живёт у файла. Платформа, построенная по профилю, хранит её там же, и проверка «есть ли лицензия у набора» на ней даст неверный ответ. Пример — в разделе о проверке живого портала.

Если значение действительно неизвестно, честнее сказать об этом, чем выдумать. В схеме DataCite для этого есть стандартные коды: :unkn — неизвестно, :none — значения нет, :null — пусто намеренно. Цена такой честности видна в примере из документации DataCite: ссылка на набор, где неизвестно почти всё, выглядит как :unkn (2020). :none. :null. Зато её никто не примет за полноценную.

Варианты реализации​

Платформы позволяют настроить схему описания пятью способами. От способа зависит, кто может поменять поля и сколько это стоит при обновлении.

Готовая схема. Поля заданы платформой, поменять их нельзя или можно только правкой кода. Так устроены лёгкие каталоги вроде JKAN и статический сайт: схему пишет автор шаблона, проверки полей нет. У ArcGIS Online и сайтов ArcGIS Hub своих полей нет, но администратор выбирает для организации один стиль описания из готовых стандартов: ISO 19139, ISO 19115-3, INSPIRE, FGDC, североамериканский профиль ISO 19115 или Dublin Core+. У организаций, созданных после июля 2025 года, по умолчанию стоит Dublin Core+, у более старых — ISO 19139.

Схема из файла. Администратор описывает поля в файле, платформа строит по нему форму и проверку.

  • В CKAN это делает расширение ckanext-scheming. Схема пишется в JSON или YAML и задаёт поля набора, ресурса, организации и группы: обязательность, список допустимых значений, готовые заготовки полей, функции проверки. С CKAN 2.12 можно не требовать обязательные поля у черновика, пока его не опубликовали.
  • В DKAN схема набора — файл JSON Schema, по умолчанию построенный на DCAT-US. Свой файл кладут вместо стандартного, и всё, что попадает в каталог, проверяется по нему. Документация предупреждает: менять схему, когда в каталоге уже есть наборы, нужно осторожно, несовместимая правка ломает проверку старых записей.
  • В DSpace поля берутся из реестра схем метаданных (по умолчанию Dublin Core), а формы ввода описаны в файле submission-forms.xml. Поле можно показывать только для определённого типа записи, например только для набора данных. После правки форм сервер перезапускают.

Блоки и профили. Платформа поставляет готовые наборы полей под отрасли, их включают и дополняют своими.

  • В Dataverse семь поддерживаемых блоков: цитирование, геоданные, социальные и гуманитарные науки, астрономия, науки о жизни, журналы, 3D-объекты. Есть и экспериментальные: CodeMeta для программ, вычислительные процессы, архивные сведения, метки Local Contexts для знаний коренных народов. Администратор коллекции сам решает, какие поля в ней обязательны. Свой блок описывают в файле TSV и загружают через API. Документация отдельно напоминает: новые поля нужно добавить и в схему поискового индекса Solr, иначе по ним не будет поиска.
  • В GeoNetwork 4.4 в ядре схемы ISO 19139, ISO 19115-3, Dublin Core и ISO 19110 — каталог объектов, то есть словарь полей для геоданных. Национальные профили ставятся плагинами схем: швейцарский, канадский HNAP, нидерландские, итальянский RNDT, британский GEMINI, а также DCAT-AP.
  • InvenioRDM хранит описание по схеме DataCite. Обязательны тип ресурса, название, дата публикации и авторы. Готовые дополнительные поля — сведения о журнале, издании, диссертации, конференции и CodeMeta для программ. Свои поля задают в настройках сайта и раскладывают по разделам формы.

Шаблоны в облачном сервисе. Свои поля заводит администратор в веб-интерфейсе, без программиста.

  • У Huwise (бывший OpenDataSoft) базовый шаблон «Standard» не меняется и не удаляется. Рядом подключаются шаблоны для совместимости — DCAT, INSPIRE — и свои: администратор создаёт поля с типом, допустимыми значениями и правилами и включает перевод по каждому полю. Отдельные служебные шаблоны видны только в административной части.
  • У Socrata (Tyler Data & Insights) свои поля собираются в наборы полей. У каждого поля своя обязательность — без обязательного поля набор не опубликовать — и видимость: всем или только сотрудникам. К полю можно приписать проверку на языке запросов SoQL, в том числе зависящую от других полей, а инструмент аудита показывает, какие наборы правилам не соответствуют. В файл data.json для data.gov попадают только поля с заранее известными именами из набора «Common Core».

Шаблон как часть стандарта. Полный стандарт для публикатора слишком велик: в DDI или ISO 19115 сотни элементов. Удачное решение — у редактора метаданных Всемирного банка, с которым работают каталоги микроданных на NADA. Для каждого типа данных в нём два вида готовых шаблонов, оба неизменяемые: полный, со всеми элементами стандарта, и рекомендуемый, только с главными. Организация копирует шаблон и правит копию: убирает лишнее, меняет подписи, делает поля обязательными. Стандарт и выгрузка остаются общими, а форма у каждого издателя своя. Тот же приём применим на любой платформе: схема одна, а формы для разных публикаторов разные.

Словарь полей​

Словарь полей описывает колонки таблицы: название, понятная подпись, смысл, тип, единица измерения, допустимые значения, обозначение пропуска. Без него таблица открыта формально и непонятна по существу. У набора метеостанции Парнита на data.gov.gr в хранилище таблиц все 57 колонок записаны как текст, включая температуру и давление, и ни у одной нет описания. Карточка целиком разобрана в главе «Анатомия каталога».

Машиночитаемых форм у словаря несколько, и выбирают ту, что принята в отрасли:

ФормаГде применяется
Table Schema из семейства Frictionless, обычно внутри файла datapackage.jsonоткрытые данные, публикация в Git-репозитории, проверка файлов программой
CSV on the Web (CSVW), рекомендация W3C 2015 годатаблицы со связанными данными; Google в бета-режиме читает словарь таблицы в этой форме прямо из разметки страницы
переменные DDIмикроданные: у каждой переменной текст вопроса, коды ответов, частоты
ISO 19110, каталог объектовгеоданные: типы объектов слоя и их атрибуты
поля и наборы записей Croissantнаборы для машинного обучения
структура SDMXпоказатели: разрезы, справочники, атрибуты

Словарь полезен вдвойне, если по нему проверяют сам файл. Тогда «число» в словаре означает, что в колонке действительно числа, а не текст «н/д». Во Франции это устроено на уровне страны: в каталоге schema.data.gouv.fr в октябре 2026 года 106 общих схем, из них 69 в Table Schema. Ресурс набора на data.gouv.fr ссылается на схему, и портал проверяет файл по ней. Общая схема для одной темы — например, для зарядных станций электромобилей — позволяет склеить файлы сотен издателей в одну таблицу. Но даже там ссылку на схему ставят редко: в выборке из тысячи наборов она была у 36.

Связь набора со стандартом в описании DCAT записывают полем dct:conformsTo: оно говорит, какой схеме или отраслевому стандарту соответствует файл. Сами отраслевые стандарты данных — OCDS, GTFS, Darwin Core и другие — разобраны в главе о том, что публикуют.

Когда подробность вредна​

Обязательная схема из пятидесяти полей замедляет публикацию. Поля начинают заполнять формально: копируют описание из соседнего набора, повторяют название в описании, ставят сегодняшнюю дату в «период данных». Хуже всего, когда это делает сама программа: подставляет значение по умолчанию, чтобы форма прошла проверку. Как это выглядит на национальном портале, показано ниже, в проверке data.gov.gr.

Отсюда три правила.

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

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

Когда нужна, а когда нет​

СитуацияЧто сделатьЧем обычно закрывают
Портал открытых данных в ЕС, который собирает национальный порталDCAT-AP и национальный профиль; лицензия у каждого файла; темы и периодичность из словарей ЕСCKAN со scheming и ckanext-dcat, Piveau, Huwise с шаблоном DCAT
Небольшой муниципальный порталминимум и рекомендуемый уровень; свои поля не заводить; словарь полей у таблицготовая схема облачного сервиса или CKAN без scheming
Научный репозиторийDataCite плюс блок дисциплины; авторы с ORCID, связь со статьёйDataverse с отраслевыми блоками, InvenioRDM со своими полями
ГеопорталISO 19139 или ISO 19115-3, профиль страны, каталог объектов у векторных слоёвGeoNetwork с плагином профиля, стиль ISO в ArcGIS
Каталог микроданныхDDI с описанием переменныхNADA с редактором метаданных, Dataverse
Каталог показателейструктура SDMX, методика, единицысм. главу о каталогах показателей
Публикация без порталафайл README, datapackage.json со словарём, разметка schema.org на страницешаблоны этой книги, проверка в CI

Свою схему полей стоит заводить, когда её требует закон, профиль верхнего портала или отрасль. Её не стоит заводить ради полноты анкеты: каждое поле — это работа публикатора на каждом наборе и работа администратора при каждом обновлении платформы.

Коротко, как выглядит обоснование по шаблону карточки решения:

  • Контекст. Региональный портал на CKAN, национальный профиль требует два поля, которых нет в ядре: категорию набора высокой ценности и правовое основание.
  • Варианты. Писать значения в свободные дополнительные поля (extras); поставить ckanext-scheming; перейти на облачный сервис с шаблонами.
  • Критерии. Проверка значений при вводе, выгрузка в DCAT-AP, стоимость обновлений.
  • Решение. ckanext-scheming со схемой в YAML и ckanext-dcat с профилем страны.
  • Почему. Свободные поля не проверяются и попадают в выгрузку под случайными именами. Переход на облачный сервис ради двух полей дороже, чем одно расширение, которое ведёт сообщество CKAN.
  • Когда пересмотреть. Если профиль страны начнут поставлять готовым расширением или если обязательных своих полей станет больше десятка.

Как это сделано в платформах​

Пометки — ядро, расширение, нет, не проверено, как в сводной таблице. Сверено с документацией платформ 12 октября 2026 года.

ПлатформаСвои поля описанияСловарь полей таблицыЧто важно знать
CKAN 2.12расширение ckanext-scheming: схема в JSON или YAMLядро: словарь у таблиц в хранилище DataStore — подпись, описание, тип колонки; с 2.11 ещё Table Designer — таблица со схемой и проверкой значенийнесколько языков описания — расширение ckanext-fluent; проверка файлов по Table Schema — расширение ckanext-validation, см. ниже
DKANядро: замена файла JSON Schemaне проверенопо умолчанию схема DCAT-US; менять её на живом каталоге рискованно
Huwise (OpenDataSoft)ядро: свои шаблоны полей, служебные шаблоныядро: подпись, описание и один из 12 типов у каждого поля; вкладка «Схема» показывает долю заполнения каждой колонкибазовый шаблон не меняется
Socrataядро: наборы своих полей с обязательностью и проверкой SoQLядро: название, описание и тип колонки, отдаются в /api/views/ID.jsonв data.json уходят только поля набора «Common Core»
ArcGIS Online и Hubнет: один стиль из готовых стандартов на организациюядро: у размещённого слоя описание поля, тип значения, списки допустимых значенийописание слоя и описание элемента в каталоге не синхронизируются
Dataverseядро: отраслевые блоки и свои блоки в TSVядро: у загруженных таблиц (SPSS, Stata, R, Excel, CSV) переменные описываются в DDIновые поля нужно добавить в схему индекса Solr
InvenioRDMядро: свои поля в настройкахнетоснова — схема DataCite
DSpaceядро: реестр схем и submission-forms.xmlнетправка форм требует перезапуска
GeoNetwork 4.4ядро: ISO 19139, ISO 19115-3, Dublin Core; профиль страны — плагин схемыядро: каталог объектов ISO 19110плагин нужен ровно под вашу версию GeoNetwork
NADAне провереноядро: переменные DDI с частотамишаблоны полей — в отдельном редакторе метаданных Всемирного банка
JKAN и статический сайтнет: поля задаёт шаблоннет: словарь кладут файлом рядомпроверку пишет автор сайта

Гибкая схема почти всегда означает сопровождение: кто-то должен решить, какое поле обязательно, и не дать схеме расползтись. Чем глубже свои поля встроены в платформу, тем дороже каждое её обновление.

Расширения и их риски​

Свои поля и словарь — та область, где цена расширений видна лучше всего. Методика оценки расширения разобрана в главе об экосистемах расширений, здесь — то, что нашлось при сверке.

  • ckanext-scheming и ckanext-fluent ведёт сообщество CKAN, автоматические тесты идут на CKAN 2.10, 2.11 и 2.12. Это обычная часть взрослого портала на CKAN, а не экзотика. Подробности — в главе про CKAN.
  • ckanext-validation проверяет загруженные таблицы по Table Schema с помощью Frictionless. В основном репозитории Frictionless Data в октябре 2026 года совместимость заявлена только с CKAN 2.9, для 2.10 и 2.11 в таблице совместимости стоит «нет», и тесты идут только на 2.9. Живая ветка — форк правительства Квинсленда qld-gov-au/ckanext-validation: его тесты идут на CKAN 2.10, 2.11 и 2.12. Это типичная судьба расширения: исходный автор отошёл, а работающую версию поддерживает один из пользователей. Перед установкой проверяют не название, а репозиторий и ветку.
  • Плагины схем GeoNetwork привязаны к версии ядра: на каждую линейку GeoNetwork у плагина своя ветка. У одного плагина бывают копии в разных местах, и они расходятся. Британский профиль GEMINI 2.3 ведёт компания Astun Technology, в её репозитории есть ветка для GeoNetwork 4.4. В общем собрании плагинов metadata101 лежит копия, которая не обновлялась с февраля 2023 года и доходит только до 4.2.
  • Свои блоки Dataverse и своя схема DKAN — не расширения, а настройка ядра. Но и их проверяют при каждом обновлении: блок Dataverse требует согласованной схемы индекса, а несовместимая правка схемы DKAN ломает проверку старых записей.

Публикация без портала​

Без портала полнота описания целиком на авторе: никакая форма не потребует лицензию. Зато и детальность ничем не ограничена. Хватает трёх файлов рядом с данными:

  • README.md — что это, за какой период, кто отвечает, как обновляется, лицензия;
  • datapackage.json — список файлов и словарь полей каждой таблицы по Table Schema;
  • разметка schema.org/Dataset на странице набора, если у набора есть свой сайт.

Готовые README, datapackage.json и разметка schema.org лежат в шаблонах книги. Проверку можно поручить программе: команда frictionless validate datapackage.json, запущенная в CI репозитория при каждом изменении, сверит файлы со словарём и не даст выложить таблицу, где в колонке чисел появился текст. Как устроить такой репозиторий, разобрано в главе о Git-репозиториях.

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

Ручная проверка — по-прежнему лучший первый шаг:

  1. Откройте десять случайных наборов из разных организаций, не самые свежие.
  2. Для каждого отметьте, заполнены ли лицензия, издатель, контакт, дата обновления, период и территория.
  3. Сравните описание с названием: не повторяет ли оно его.
  4. Посмотрите, есть ли словарь полей у табличного набора и совпадают ли типы колонок с содержимым.
  5. Проверьте, похожи ли значения на правду: период — на содержимое файла, территория — на издателя.

Пятый шаг важнее остальных. Валидатор профиля и оценка качества метаданных на data.europa.eu (MQA) проверяют, что поле есть, а не что в нём правда. Заглушка проходит обе проверки.

Две проверки на выборке​

На большом портале проверку делают программой. 12 октября 2026 года через API взята тысяча наборов на каждом из двух национальных порталов: десять блоков по сто наборов, равномерно по всему каталогу. Числа — снимок на этот день.

data.gov.gr — национальный портал Греции на CKAN 2.11 со схемой по DCAT-AP, всего около 22,7 тысячи наборов. В выборку попали наборы 118 организаций.

ПолеПохоже на заполненноеЗаполнено по существу
Период97%у 938 наборов из 1000 период «1900-01-01 — 2099-12-31», одинаковый у министерства, государственного архива и десятков муниципалитетов. Его подставила программа, а не издатель
Территория96%у 60% название территории — пустая строка, ещё у 35% — вся Греция
Контакт и издатель24% и 31%22% и 28%: у части записей все поля контакта — пустые строки
Описание94%у 31% описание короче 50 символов, у 22% оно дословно повторяет название
Лицензияу 32% наборов, если искать её у наборау 99% наборов, если искать её у файлов, как велит DCAT-AP
Частота обновления36%у 32% выборки значение «не планируется», настоящая частота — только у 4%

Заглушка периода уходит и в выгрузку DCAT, которую собирает европейский портал: в описании набора стоят dcat:startDate "1900-01-01" и dcat:endDate "2099-12-31", а рядом пустое английское название. Сборщик и оценка качества увидят период заполненным у почти всех наборов страны.

data.gouv.fr — национальный портал Франции на udata, всего около 74,4 тысячи наборов, 78% выборки собраны с других каталогов. У udata в ядре есть своя оценка качества описания: девять равных критериев, от лицензии и периода до доступности файлов. API отдаёт её по каждому набору, на сайте она видна рядом с карточкой. Медиана по выборке — 5 из 9.

  • Лицензия «не указана» у 19% наборов. При этом встроенная оценка засчитала лицензию у 98%: по исходному коду udata критерий выполнен, если поле лицензии вообще заполнено, а «не указана» — тоже значение.
  • Период указан у 23% наборов, частота обновления «неизвестна» у 70%.
  • Территория: уровень детальности (коммуна, департамент) указан у 63%, а сами территории — у 14%.
  • Описание длиннее 100 символов, как требует встроенная оценка, у 73%.

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

Команды​

Для портала на CKAN. Команда берёт 500 наборов и считает долю коротких описаний, описаний, повторяющих название, лицензию у набора и у файлов, и два самых частых значения периода. Имя поля периода зависит от схемы портала: на data.gov.gr это temporal_coverage, на другом портале посмотрите его в ответе package_show.

PORTAL=https://data.gov.gr
curl -s "$PORTAL/api/3/action/package_search?rows=500&start=5000" \
  | jq '.result.results as $r | ($r | length) as $n | {
      datasets: $n,
      short_description: ([$r[] | select((.notes // "") | length < 50)] | length / $n),
      description_is_title: ([$r[] | select((.notes // "" | gsub("^\\s+|\\s+$"; "")) == .title)] | length / $n),
      license_on_dataset: ([$r[] | select((.license_id // "") != "")] | length / $n),
      license_on_files: ([$r[] | select(any(.resources[]; (.license // "") != ""))] | length / $n),
      top_periods: ([$r[] | .temporal_coverage | tostring] | group_by(.) | map({value: .[0], n: length}) | sort_by(-.n) | .[0:2])
    }'

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

Для портала на udata. Команда сравнивает лицензию со встроенной оценкой и считает период и частоту на одной странице выдачи:

curl -s "https://www.data.gouv.fr/api/1/datasets/?page_size=100&page=200" \
  | jq '.data as $d | ($d | length) as $n | {
      datasets: $n,
      license_not_specified: ([$d[] | select(.license == "notspecified")] | length / $n),
      score_counts_license: ([$d[] | select(.quality.license)] | length / $n),
      frequency_unknown: ([$d[] | select(.frequency == "unknown")] | length / $n),
      with_period: ([$d[] | select(.temporal_coverage != null)] | length / $n)
    }'

Запускайте команды несколько раз с разными start или page, чтобы выборка не состояла из одной организации. Для портала на Socrata словарь полей и даты отдаются по адресу /api/views/ID-набора.json: там у каждой колонки название, тип и описание, а дата обновления данных записана отдельно от даты правки описания. Как превратить такие доли в метрики и что с ними делать дальше — в главе о метриках качества.

Что из этого следует​

  • Составьте свой список обязательных полей от пользователя: лицензия, издатель, контакт, дата обновления данных, период. Не ограничивайтесь обязательными полями стандарта.
  • Уберите значения по умолчанию у полей, которые публикатор может не знать. Пустое поле лучше заглушки.
  • Требуйте словарь полей у каждой таблицы и, где можно, проверяйте файл по нему.
  • Свои поля заводите под закон, профиль или отрасль, а не «на всякий случай». Каждое поле стоит работы на каждом наборе и при каждом обновлении платформы.
  • Расширения для схем проверяйте по репозиторию и ветке под свою версию ядра, а не по названию.
  • Считайте полноту по существу: самые частые значения, повторы названия в описании, правдоподобие периода. Встроенным оценкам и валидаторам верьте только в том, что поле есть.

Источники​