Методические рекомендации по публикации открытых данных государственными органами, органами местного самоуправления и подведомственными им организациями (версия 4.0)

(утв. протоколом президиума Правительственной комиссии по цифровому развитию, использованию информационных технологий для улучшения качества жизни и условий ведения предпринимательской деятельности от 12.12.2024 № 49пр)

Основные понятия и глоссарий

Виджет (widget) — это небольшой графический элемент, вставляемый на страницу сайта для отображения какой-либо периодически обновляемой информации.

Метаданные, метаинформация (Meta) — структурированные данные, представляющие собой характеристики описываемых сущностей для целей их идентификации, поиска, оценки, управления этими сущностями.

Набор открытых данных (ОД), набор данных (Dataset) — систематизированная совокупность однотипных машиночитаемых данных, представленных в форме открытых данных, состоящая из отдельных элементов, характеризующихся набором атрибутов, и позволяющая автоматизированным системам без участия человека идентифицировать, интерпретировать и обрабатывать такие элементы.

Открытые данные (Opendata) — информация, размещенная в сети «Интернет» в виде систематизированных данных, организованных в формате, обеспечивающем ее автоматическую обработку без предварительного изменения человеком, в целях неоднократного, свободного и бесплатного использования.

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

Портал открытых данных Российской Федерации (далее — Портал ОД) — комплексная государственная информационная система, которая реализует функцию предоставления неограниченному кругу лиц доступа к реестру наборов ОД органов государственной власти Российской Федерации, органов местного самоуправления и организаций, действующих на территории Российской Федерации, а также иные функции, обеспечивающие реализацию политики Российской Федерации в области публикации открытых данных.

Реестр наборов ОД (Reestr) — систематизированный перечень наборов ОД, позволяющий в автоматическом режиме осуществлять навигацию по наборам открытых данных и получать ключевые параметры этих наборов, включая гиперссылки, необходимые для доступа к наборам открытых данных.

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

Формат данных (Format) — структура данных (спецификация) файла, предназначенная для представления данных и пригодная для машинной обработки.

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

JSON — текстовый формат обмена данными, основанный на JavaScript и обычно используемый именно с этим языком. JSON легко читается и обрабатывается.

RDF — модель, разработанная консорциумом W3C для представления данных, в особенности — метаданных. RDF представляет сведения о ресурсах в пригодном виде.

XML — язык разметки, рекомендованный Консорциумом Всемирной паутины (W3C). Спецификация XML описывает XML-документы и частично описывает поведение XML-процессоров (программ, читающих XML-документы и обеспечивающих доступ к их содержимому).

1 Общие положения

1.1. Методические рекомендации по публикации открытых данных государственными органами, органами местного самоуправления и подведомственными им организациями (далее соответственно — Методические рекомендации, органы публичной власти и подведомственные им организации) предназначены для ответственных сотрудников органов публичной власти и подведомственных им организаций при подготовке указанными сотрудниками наборов ОД и их последующей публикации в информационно-телекоммуникационной сети «Интернет» (далее — сеть Интернет), включая сопровождение наборов ОД после публикации.

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

1.3. Набор ОД представляет собой файл в машиночитаемом формате, предлагаемом в соответствии с Методическими рекомендациями, содержащий информацию о деятельности органов публичной власти и подведомственных им организаций. Наборы ОД представляют собой структурированную информацию, представленную в открытом формате и доступны для свободного использования, анализа и распространения. Вместе с набором ОД в соответствии с разделом 2 Методических рекомендаций подготавливается файл со структурой набора ОД и паспорт набора ОД.

1.4. Для подготовки наборов ОД используется общедоступная информация о деятельности органов публичной власти и подведомственных им организаций, которая была отнесена к таковой в соответствии с законодательством Российской Федерации и соответствующими решениями органов публичной власти и подведомственных им организаций. Включение в наборы ОД информации ограниченного доступа не допускается.

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

• Федеральным законом от 27 июля 2006 г. № 149-ФЗ «Об информации, информационных технологиях и о защите информации»;
• Федеральным законом от 9 февраля 2009 г. № 8-ФЗ «Об обеспечении доступа к информации о деятельности государственных органов и органов местного самоуправления»;
• Постановлением Правительства Российской Федерации от 24 ноября 2009 г. № 953 «Об обеспечении доступа к информации о деятельности Правительства Российской Федерации и федеральных органов исполнительной власти»;
• Постановлением Правительства Российской Федерации от 10 июля 2013 г. № 583 «Об обеспечении доступа к общедоступной информации о деятельности государственных органов и органов местного самоуправления в информационно-телекоммуникационной сети „Интернет“ в форме открытых данных»;
• Распоряжением Правительства Российской Федерации от 10 июля 2013 г. № 1187-р (О Перечнях информации о деятельности государственных органов, органов местного самоуправления, размещаемой в сети «Интернет» в форме открытых данных);
• Приказом Минэкономразвития России от 23 апреля 2024 г. № 247 «Об утверждении методических указаний по отнесению информации к общедоступной информации, размещаемой государственными органами и органами местного самоуправления на их официальных сайтах в информационно-телекоммуникационной сети „Интернет“ в форме открытых данных» (далее — Приказ Минэкономразвития России № 247).
• иными нормативными правовыми актами, в соответствии с которыми информация о деятельности органов публичной власти и подведомственных им организаций признается общедоступной информацией и подлежащей размещению в сети «Интернет» в форме открытых данных.

1.6. Подготовка наборов ОД осуществляется с использованием информации о деятельности органов публичной власти и подведомственных им организаций, в отношении которой установлена ее общественная потребность. Установление общественной потребности в информации о деятельности органов публичной власти и подведомственных им организаций осуществляется в порядке, определенном Методическими указаниями по отнесению информации к общедоступной информации, размещаемой государственными органами и органами местного самоуправления на их официальных сайтах в информационно-телекоммуникационной сети «Интернет» в форме открытых данных, утвержденных Приказом Минэкономразвития России от 23 апреля 2024 г. № 247.

1.7 Основные характеристики открытых данных:

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

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

• в специальном разделе для публикации наборов ОД официальных сайтов в сети Интернет (далее — официальные сайты);
• на Портале ОД Российской Федерации.
• на порталах открытых данных, а также в государственных и муниципальных информационных системах, в информационных системах органов публичной власти и подведомственных им организаций (иные ресурсы для публикации наборов ОД).

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

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

1.9. Органы публичной власти и подведомственные им организации определяют ответственных сотрудников за подготовку и публикацию наборов ОД в сети Интернет (далее — ответственные сотрудники).

Информация об ответственных сотрудниках является общедоступной и подлежит ежегодной актуализации органами публичной власти и подведомственными им организациями.

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

Информация об ответственном сотруднике для каждого набора ОД включается в паспорт набора ОД (заполняется для каждого набора ОД перед его публикацией в сети Интернет).

1.10 Доступ к наборам ОД предоставляется неограниченному кругу лиц.

Ответственные сотрудники в отношении каждого публикуемого в сети Интернет набора ОД определяют целесообразность идентификации пользователей, которые получат доступ к наборам ОД. Идентификация пользователей наборов ОД может осуществляться в целях проведения статистического учета востребованности наборов ОД. Для идентификации пользователей наборов ОД рекомендуется использовать функционал Федеральной государственной информационной системы «Единая система идентификации аутентификации в инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг в электронной форме» (ЕСИА).

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

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

В реестры наборов ОД включается информация о всех наборах ОД, опубликованных в сети «Интернет» органами публичной власти и подведомственными им организациями.

1.13. Сведения, включенные в реестры наборов ОД, должны передаваться в сводный реестр наборов ОД, который ведется оператором Портала ОД.

2. Подготовка наборов ОД

2.1 Подготовка набора ОД включает в себя подготовку:

2.1.1. файла с набором ОД в машиночитаемом формате, содержащего общедоступную информацию о деятельности органа публичной власти или подведомственной им организации;

2.1.2. файла со структурой набора ОД;

2.1.3. паспорта набора ОД.

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

2.3. Файлы с наборами ОД могут быть подготовлены в одном из машиночитаемых форматов из раздела 3.1 Методических рекомендаций.

2.4. Выбор машиночитаемого формата файла осуществляется ответственными сотрудниками самостоятельно.

2.4.1. Подготовка наборов ОД в машиночитаемом формате XML описана в разделе 3.1.1 Методических рекомендаций.

2.4.2. Подготовка наборов ОД в машиночитаемом формате CSV описана в разделе 3.1.2 Методических рекомендаций.

2.4.3. Подготовка наборов ОД в машиночитаемом формате JSON описана в разделе 3.1.3 Методических рекомендаций.

2.5. Подготовка наборов ОД в машиночитаемом формате RDFa описана в разделе 3.1.4 Методических рекомендаций.

2.6. Паспорт ОД — совокупность сведений о наборе ОД. Паспорт набора ОД имеет требования, установленные в разделе 3 Методических рекомендаций.

2.7. Публикация набора ОД может быть осуществлена на Портале ОД ручным, автоматическим или автоматизированным способами (согласно разделу 6.3 Методических рекомендаций).

3 Требования к набору, паспорту, структуре

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

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

1. востребованность соответствующих наборов ОД потенциальными потребителями информации, оцениваемую в соответствии с методикой мониторинга и оценки востребованности открытых данных;

2. степень готовности наборов ОД, характеризующуюся наличием необходимых данных в электронном виде, а также готовностью организационных, технических, технологических и иных средств, необходимых для опубликования наборов ОД в порядке и формате, определяемых Методическими рекомендациями;

3. затраты на публикацию (финансовые, временные, трудовые), необходимые для опубликования наборов ОД и поддержания их в актуальном состоянии.

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

При формировании как реестра наборов ОД, так и самих наборов ОД, следует учитывать:

1. публикации подлежит общедоступная информация;

2. для каждого набора данных должно быть определено должностное лицо, ответственное по вопросам публикации открытых данных;

3. для каждого набора данных должна быть установлена периодичность обновления с учетом потребностей потребителей открытых данных.

Содержание файла с набором ОД, файла со структурой набора ОД и паспорт набора ОД должны соответствовать минимальными требованиям (в зависимости от формата файла, в котором они были сделаны), установленными в разделе 3 Методических рекомендаций.

Атрибутивный состав паспорта набора ОД должен включать:

• Идентификационный номер (ID набора ОД)
• Наименование набора ОД
• Описание набора ОД
• Владелец набора ОД
• Ответственное лицо
• Телефон ответственного лица
• Адрес электронной почты ответственного лица
• Гиперссылка (URL) на открытые данные
• Формат набора ОД
• Описание структуры набора ОД
• Дата первой публикации набора ОД
• Дата последнего внесения изменений
• Содержание последнего изменения
• Дата актуальности набора данных
• Ключевые слова, соответствующие содержанию набора данных
• Гиперссылки (URL) на версии ОД
• Гиперссылки (URL) на версии структуры набора

Сформированный реестр ОД утверждается государственным органом или органом местного самоуправления и подлежит публикации на официальном сайте органа в сети Интернет.

Атрибутивный состав информации в реестрах наборов ОД, утвержденных государственным органом или органом местного самоуправления, должен включать:

• наименование органа публичной власти и подведомственной им организации;
• категорию владельца набора ОД (государственный орган, подведомственная организация государственного органа, муниципальный орган, подведомственная организация муниципального органа);
• статус набора ОД (действующий, переведен в архив);
• наименование органа публичной власти (указывается для подведомственных организаций);
• порядковые номера наборов ОД, опубликованных в сети Интернет;
• ID набора ОД;
• указание на принадлежность наборов ОД к определенным категориям открытых данных;
• наименования наборов ОД;
• дату первичной публикации наборов ОД;
• источник первичной публикации наборов ОД (официальный сайт, Портал ОД, иной ресурс для публикации наборов ОД (указывается официальное наименование источника));
• ссылку на первоисточник опубликования наборов ОД;
• периодичность актуализации для наборов ОД;
• дата последней актуализации набора ОД;
• статус размещения наборов ОД на Портале ОД (да, нет);
• ссылку на наборы ОД, размещенные на Портале ОД;
• ФИО, должность, структурное подразделение, контактный телефон и адрес электронной почты ответственного сотрудника за подготовку и размещение наборов ОД в сети Интернет;
• количество скачиваний наборов ОД;

3.1 Форматы и их особенности

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

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

• XML;
• CSV;
• JSON;
• RDFa;

3.1.1 XML формат

XML (eXtensible Markup Language — расширяемый язык разметки) — язык разметки, который используется для хранения и передачи данных. Его основное назначение — структурирование информации в текстовом виде, чтобы она была легко читаемой как человеком, так и машиной. XML позволяет описывать данные через набор тегов (могут быть заданы разработчиком), которые могут быть вложены друг в друга и могут содержать атрибуты, что делает структуру данных гибкой и расширяемой. Это универсальный формат, поддерживаемый множеством программ и библиотек, что делает его удобным для обмена данными между разными системами.

В отличие от языков программирования, XML не может выполнять вычислительные операции сам по себе. Вместо этого для управления структурированными данными используется любой язык программирования или программное обеспечение.

Формат XML часто используется для передачи данных по API, причем является единственно возможным форматом данных в SOAP API.

Текстовый документ с расширением .xml может быть открыт с помощью следующих инструментов:

• Microsoft Excel;
• Microsoft Word;
• блокнота Windows;
• любого интернет-браузера;
• редакторов XML (например, XML Editor).

3.1.1.1 Признаки для выбора формата

Формат XML хорошо подходит для структурированных данных, если важна иерархическая структура и метаданные.

1. Сложные иерархические данные — если данные имеют несколько уровней вложенности (например, данные о компаниях, содержащие информацию о филиалах, сотрудниках, их ролях и т.д.).

2. Метаданные и схемы — если данные включают много метаданных, таких как описания, единицы измерения, ссылки на источники и другие атрибуты. В формате XML легко определяются схемы (XSD), которые обеспечат строгость и валидацию данных, что важно для гарантии их качества.

3. Совместимость и интеграция — если набор данных должен быть интегрирован с другими системами, которые ожидают данные в формате XML (например, веб-сервисы, SOAP).

4. Малый объем данных — для небольших наборов данных, где производительность не является критическим фактором, XML может быть удобен благодаря своей читабельности и доступности для обработки различными инструментами. Однако для больших объемов данных (big data) XML может быть менее эффективным из-за увеличенного размера файла по сравнению с другими форматами, такими как CSV или JSON.

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

В общем случае XML лучше всего подходит для структурированных, иерархически организованных данных, требующих метаданных и строгой валидации. Для простых числовых данных или big data лучше выбирать другие форматы, такие как CSV или JSON, которые обеспечивают большую компактность и производительность.

3.1.1.2 Типовые ошибки при работе с форматом

Существует несколько правил «well formed» XML, то есть его синтаксической корректности:

1. Все XML документы должны иметь один корневой элемент. Отсутствие корневого элемента делает документ недействительным (в данном примере элемент является корневым и содержит данные об учетных записях).

2. У каждого элемента должен быть закрывающий тег. Кроме того, имена тегов не должны содержать пробелов, специальных символов, и должны начинаться с буквы или подчеркивания.

3. Учет регистрозависимости тегов.

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

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

Также дополнительно в качестве одной из ошибок при работе с XML можно выделить несоответствие кодировки — например, в декларации указано UTF-8, а фактически используется другая кодировка.

Для проверки XML на синтаксис возможно использование любого XML Validator.

3.1.1.3 Основные правила при составлении XML вручную

Рассмотрим простой пример XML документа:

1. Строка называется прологом и означает, что используется XML версии 1.0 и кодировка UTF-8. Пролог является первой строкой XML документа.

2. В XML каждый элемент заключен в теги. Тег — некий текст, заключенный в угловые скобки. Текст внутри тега — его название. Существует два типа тегов: открывающий и закрывающий .

3. В каждом XML документе должен быть только один корневой элемент, который включает все другие элементы (иными словами, это тег, с которого документ начинается и которым заканчивается). В приведенном примере корневым элементом является тег .

4. Значение элемента хранится между открывающим и закрывающим тегами. Может быть числом, строкой, или вложенным тегом. В примере Alexander Pushkin элемент указывает на автора книги, здесь это «Alexander Pushkin».

5. У элементов могут быть атрибуты — один или несколько. Они указываются внутри открывающегося тега после названия тега через пробел. В примере элемент book представляет одну книгу в каталоге, у него есть атрибут id, который обозначает уникальный идентификатор книги (в данном случае bk101).

6. Все теги в XML являются регистро-чувствительными. Если тег закрыт как , документ будет оформлен некорректно.

7. В XML контролируется вложенность тегов, поэтому необходимо следить за порядком открывающих и закрывающих тегов.

8. Пробелы и переносы строк внутри текста тегов учитываются как часть данных, на это следует обращать внимание при форматировании.

Пространства имен

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

Согласно спецификации W3C пространство имен XML — это идентифицируемая с помощью ссылки URI ((англ. Uniform Resource Identifier) — унифицированный (единообразный) идентификатор ресурса. URI — последовательность символов, идентифицирующая абстрактный или физический ресурс) коллекция имен, используемых в XML документах для обозначения типов элементов и именования атрибутов.

При задании пространства имен в XML документе необходимо иметь в виду следующее:

1. Элементы и атрибуты связываются с пространством имен с помощью квалифицированных имен;

2. В одном XML документе может быть задано несколько пространств имен;

3. Область действия пространства имен может распространяться:

• на весь документ (когда оно задано в корневом элементе XML документа);
• контейнер (когда оно задано в элементе верхнего уровня контейнера);
• отдельный элемент или атрибут (когда оно задано непосредственно для данного элемента и атрибута).

Для объявления пространства имен в XML документе используется ключевое слово xmlns. Синтаксис объявления имеет следующий формат: xmlns[:prefix]=«uri», где:

• prefix — это квалифицированное имя, посредством которого элементы и атрибуты XML документа связываются с пространством имен;
• uri — это URI, задающий пространство имен, которое будет использоваться в XML документе.

В том случае, если параметр prefix не задан, то объявленное пространство имен будет использоваться как пространство имен по умолчанию.

3.1.1.4 Основные правила составления структуры в формате XSD

1. Основы XSD схемы:

Для определения структуры данных (Data Schema) используется XSD (XML Data Definition). XSD — это стандартный язык, предназначенный для описания структуры XML документов. В XSD определяется, какие элементы и атрибуты могут присутствовать в документе, их типы, допустимые значения, порядок и количество повторений.

2. Определение основного элемента:

Основной элемент схемы задается с использованием тега xs:element. Внутри него указывается имя элемента и тип, который определяет структуру и свойства данного элемента.

3. Использование сложных типов (Complex Types):

Сложные типы (xs:complexType) используются для определения элементов, которые могут содержать другие элементы или атрибуты.

Внутри xs:complexType можно использовать xs:sequence, xs:choice или xs:all, чтобы задать порядок или набор возможных подэлементов.

4. Определение простых типов (Simple Types):

Простые типы (xs:simpleType) используются для определения ограничений на значения элементов, например, строки, числа, перечисления возможных значений (xs:enumeration).

5. Аннотации (Annotations):

Аннотации (xs:annotation) используются для добавления описаний и документации к элементам и типам в XSD. Это помогает разработчикам и пользователям схемы лучше понимать ее структуру и назначение.

6. Определение атрибутов:

Атрибуты (xs:attribute) определяются внутри элементов и задают дополнительные свойства, такие как уникальные идентификаторы или другие данные, связанные с элементом.

3.1.1.5 Чек-лист проверки набора в формате XML

1. Общие проверки

Корректность синтаксиса:

• Все открывающие теги имеют соответствующие закрывающие теги.
• Все элементы правильно вложены (не допускается перекрытие тегов).
• Все атрибуты заключены в кавычки (двойные или одинарные).

Использование корневого элемента:

• Документ содержит один корневой элемент, который включает все остальные элементы.

2. Проверка структуры документа

Правильность структуры:

• Структура документа соответствует схеме (XSD)

Проверка обязательных элементов:

• Наличие всех обязательных элементов, которые указаны в схеме.

Порядок элементов:

• Элементы находятся в правильном порядке, если схема требует определенной последовательности (xs:sequence).

3. Валидация данных

Проверка типов данных:

• Значения элементов и атрибутов соответствуют их типам данных, определенным в схеме (например, xs:integer, xs:date, xs:string).

Ограничения значений:

• Данные удовлетворяют ограничениям, определенным в схеме (например, длина строки, диапазон чисел, регулярные выражения).

4. Проверка атрибутов

Наличие обязательных атрибутов:

• Все обязательные атрибуты присутствуют в соответствующих элементах.

Правильность значений атрибутов:

• Значения атрибутов соответствуют требованиям (например, тип данных, допустимые значения).

5. Проверка комментариев

Корректность синтаксиса комментариев:

• Все комментарии корректно закрыты () и не содержат запрещенных символов (-- внутри комментария).

6. Проверка на корректность содержания

Корректность данных:

• Все данные в документе актуальны и корректны (например, даты, числовые значения).

Смысловая проверка:

• Содержимое документа логично и согласовано (например, отсутствие противоречий между связанными элементами).

3.1.2 CSV формат

CSV (от англ. Comma-Separated Values — значения, разделенные запятыми) — текстовый формат хранения данных, использующийся для обмена и преобразования информации различными программами работы с электронными таблицами, также применяется для импорта и экспорта данных.

Стандартный формат файла CSV определяется данными строк и столбцов, где новая строка завершает каждую строку, а каждый столбец внутри строки разделяется запятой.

Файлы данного формата имеют расширение «.csv».

CSV легко читается человеком и может быть отредактирован с помощью любого текстового редактора.

3.1.2.1 Признаки для выбора формата

Формат CSV оптимально использовать для данных, которые представляют собой табличную структуру, и при этом все строки таблицы содержат одинаковое количество полей.

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

Формат не подходит для представления сложных таблиц, в которых имеются многоуровневые шапки, объединение ячеек. Такие данные не могут быть корректно представлены с помощью CSV без потери сведений либо нарушения структуры файла самого CSV.

Также при помощи формата CSV не получится опубликовать вложенные объекты или массивы.

3.1.2.2 Типовые ошибки при работе с форматами

В данном разделе перечислены часто встречающиеся ошибки при создании файла набора.

1. Некорректная кодировка файла

Если файл набора сохранен в кодировке отличной от UTF-8, возможно отображение части данных в нечитаемом виде. Пример такой ошибки показан на рисунке ниже.

Чтобы избавиться от нее, следует изменить кодировку файла на UTF-8. Более подробно об этом описано в пункте 1.2. Методических рекомендаций.

2. Нарушение порядка атрибутов в структуре

Если допущена данная ошибка, то при дальнейшей обработке набора название, описания полей и формат могут быть перепутаны между собой. Чтобы этого не допустить, лучше опираться на эталонный пример структуры.

3. Несоответствие количества описанных полей в структуре и файле набора

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

4. Неправильные заголовки атрибутов в структуре

Для корректного описания и анализа полей данных, атрибуты структуры должны иметь четко заданные залоговой и порядок, а именно:

• field name
• english description
• russian description
• format

Детально создание правильной структуры разобрано в разделе ниже.

3.1.2.3 Основные правила при составлении CSV вручную

CSV файл открытых данных может быть создан с помощью различных текстовых редакторов:

• «МойОфис Текст»
• Встроенного текстового редактора «блокнот» в Windows или его аналогов в других операционных системах
• Свободно распространяемого текстового редактора с открытым исходным кодом «Notepad++»
• Иных текстовых редакторов

Также файл набора может быть создан сначала в табличном редакторе (в виде электронной таблицы), а после экспортирован уже в CSV. Для этого можно использовать следующие программные продукты:

• «МойОфис Таблицы»
• Р7-Офис
• Microsoft Excel
• OpenOffice Calc
• Иные табличные редакторы

При таком варианте необходимы дополнительные настройки при экспорте в части кодировки и разделителя.

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

1. Все строки должны содержать одинаковое количество полей

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

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

2. Последнее поле документа не должно завершаться запятой

В ином случае структурированность файла также может быть нарушена, так как будет ожидаться еще одна строка.

3. Ограничения по объему отсутствуют

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

4. Файл должен быть в кодировке UTF-8

Правильная кодировка обеспечивает корректное отображение всех символов. Неверная кодировка файла может привести к отображению вместо текстовых данных символов «неизвестного языка».

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

Если файл уже создан, но его кодировка отлична от UTF-8, то ее необходимо изменить с помощью любого доступного текстового редактора, который обладает соответствующими функциями.

5. Файл должен соответствовать стандарту Separated Values (CSV) Files»

Подробнее со стандартом можно ознакомиться по ссылке (http://tools.ietf.org/html/rfc4180)

3.1.2.4 Основные правила в составлении структуры

Основные правила формирования файла структуры, следующие:

• Структура набора ОД должна быть представлена отдельным файлом.
• Файл структуры набора ОД также должен быть сохранен в формате UTF-8.
• По горизонтали должны быть перечислены атрибуты полей набора ОД, по вертикали перечислены все поля набора ОД.

Первая строка файла структуры набора ОД всегда должна содержать 4 атрибута. Атрибуты должны располагаться именно в таком порядке, как представлены ниже:

1. Наименование поля набора ОД

• Должен быть установлен обязательный заголовок атрибута: «field name».
• Значением атрибута является наименование поля набора ОД.

2. Английское описание поля набора ОД

• Должен быть установлен обязательный заголовок атрибута: «english description».
• Значением атрибута является подробное описание поля набора ОД на английском языке.

3. Русское описание поля набора ОД

• Должен быть установлен следующий обязательный заголовок атрибута: «russian description».
• Значением атрибута является подробное описание поля набора ОД на русском языке.

4. Формат поля набора ОД

• Должен быть установлен следующий обязательный заголовок атрибута: «format».
• Значением атрибута является формат поля набора ОД на английском языке

С второй строки необходимо описать все поля набора ОД. Пустая строка между атрибутами и описанием не нужна.

Количество строк файла структуры должно быть на одну больше, чем количество полей в файле набора данных. Так, если в файле набора 4 поля, то файл структуры должен содержать 5 строк (первая строка атрибутов + 4 строки описания полей из набора).

3.1.2.5 Чек-лист проверки набора в формате CSV

1. Первая строка в файле отведена под заголовок

2. В файле отсутствуют пустые строки (которые нередко добавляют с целью улучшения его визуального восприятия)

3. Если поле не содержит данных, то оно обозначено просто разделительными запятыми, без пробелов между ними.

4. При записи дробных чисел в формате CSV, разделитель десятичной части является точкой, либо (если необходима именно запятая) экранируется.

5. Любые данные внутри ячейки окружены двойными кавычками. Если же кавычки применяются не ко всему полю

6. При наличии в тексте ячейки двойных кавычек, запятых и символов возврата каретки, содержимое всей ячейки заключено в двойные кавычки (если этого не сделать, то данные невозможно будет корректно обработать).

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

8. Не используется символ «/» для экранирования кавычек, поскольку такое решение некорректно отображается в большинстве программ по созданию и просмотру CSV файлов.

3.1.3 JSON формат

JSON (JavaScript Object Notation, нотация объектов JavaScript) — это текстовый формат обмена данными. Он представлен наборами пар «ключ-значение», причем ключ — это всегда строка, а значение может задаваться одним из следующих типов:

• число;
• строка;
• логическое значение;
• массив;
• объект;
• нулевое значение null.

JSON основан на двух структурах данных:

• Коллекция пар ключ/значение. В разных языках, эта концепция реализована как объект, запись, структура, словарь, хэш, именованный список или ассоциативный массив.
• Упорядоченный список значений. В большинстве языков это реализовано как массив, вектор, список или последовательность. Структура JSON data type разработана на основе синтаксиса объектов JavaScript.

Процесс сериализации превращает объекты в строки JSON с помощью JSON.stringify(), а десериализация возвращает их обратно в объекты через JSON.parse(). Это позволяет легко передавать данные через сеть.

Формат JSON имеет ряд преимуществ:

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

3.1.3.1 Признаки для выбора формата

Основные характеристики для использования формата JSON:

1. Простота чтения и записи. JSON представляет собой текст в удобном для человека формате. Это делает его легким для чтения и создания.

2. Независимость от языка. Может быть использован с любым языком программирования, так как он представляет собой текстовый формат обмена данными.

3. Структурированный формат. JSON поддерживает массивы и объекты, что позволяет создавать сложные структуры данных. Данные могут быть вложенными и организованными в иерархическую структуру.

4. Легкая поддержка. У многих популярных языков программирования в составе есть функции для работы с JSON, а в JavaScript эта нотация встроена прямо в язык.

5. Не занимает много места и является компактным в написании и быстро компилируется.

6. Универсальность в типах данных. JSON можно использовать для хранения массивов, упорядоченных списков и коллекций пар «ключ — значение». Формат подходит для представления сложных структур данных, включая деревья и иерархические структуры.

7. Широкая поддержка в браузерах. Все современные браузеры поддерживают работу с JSON.

8. Самостоятельное документирование. В JSON можно включить метаданные, которые описывают представленные данные, упрощая работу с ними.

3.1.3.2 Типовые ошибки при работе с форматом

Типовые ошибки, которые допускаются в файлах формата JSON:

1. Ошибки синтаксиса. Отсутствие даже одного необходимого символа может привести к неработоспособности всего кода.

2. Неструктурированные данные. Если строка содержит типы данных, которые не соответствуют ожидаемой структуре, это вызовет ошибку в базе. Например, если ожидается массив, а в строке указан тип «объект», или наоборот.

3. Отсутствие запятых между элементами и отсутствие запятых после последнего элемента в массивах и объектах.

4. Отсутствие разделения ключей и значений с помощью двоеточий.

5. Некорректное использование скобок: фигурные {} для объектов и квадратные [] для массивов.

6. Несоблюдение соответствия логических значений: в JSON — это true и false.

Бывает, что файлы JSON содержат специальные символы или возникают проблемы с кодировкой:

try:
  with open('your_filename.json', 'r', encoding='utf-8') as json_file:
    parsed_data = json.load(json_file)
except UnicodeDecodeError as err:
  print(f"Произошла ошибка кодирования: {err}")

Правильная настройка параметров кодировки файла поможет избежать проблем с чтением данных.

3.1.3.3 Основные правила при составлении JSON вручную

Два основных типа структур данных в JSON — это объекты и массивы:

1. В JSON объекты являются беспорядочным набором сочетаний «ключ-значение». Между ключами (названиями) и значениями ставятся двоеточия, а пары разделяются запятой. Открывающая и закрывающая фигурные скобки обозначают начало и конец объекта:

{ «название»: «JSON для начинающих», «автор»: «Иван Петров» }

2. Массивы представляют собой упорядоченный список значений. Значения в массиве разделяются запятой. Массивы начинаются с открывающей квадратной скобки и заканчиваются закрывающей квадратной скобкой:

[ «яблоко», «апельсин», «банан» ]

Эти две структуры могут комбинироваться для создания более сложных иерархий данных в JSON. Например, объекты могут содержать вложенные объекты или массивы, а массивы могут содержать объекты или другие массивы.

Одной из ключевых характеристик JSON является его способность представлять разнообразные типы данных, используя ограниченный набор примитивных базовых типов, таких как строки, числа, логические значения, массивы и вложенные объекты. Эта гибкость делает его идеальным для передачи структурированных данных в приложениях, веб-сервисах и API.

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

{ «structure»: «object», «parameters»: { «fullname»: { «structure»: «unicode» }, «years»: { «structure»: «numeric» } }, «compulsory»: [«fullname», «years»] }

В этом варианте JSON Schema указано, что данные в формате JSON должны быть объектом с необходимыми полями fullname и years, где fullname олицетворяет собой строку, а years — числовое значение.

3.1.3.4 Основные правила составления структуры

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

Массивы в JSON являются упорядоченными списками значений. Они могут содержать любые значения, включая числа, строки, логические значения, массивы или даже другие объекты. Массивы обозначаются с помощью квадратных скобок и элементы внутри массива перечисляются через запятую.

Значения в JSON могут быть различными типами данных, такими как числа, строки или логические значения. Числа записываются без кавычек. Строки должны быть заключены в двойные кавычки. Логические значения представлены, как true или false.

Форматирование JSON регламентируется определенными правилами. Каждый новый уровень вложенности — это отступ, обычно используются пробелы или табуляция.

Отличие JSON от XML и других форматов данных заключается в его простой и легко читаемой структуре. В отличие от XML, JSON не использует закрывающих тегов и имеет более компактный синтаксис. Благодаря этому, JSON стал предпочтительным форматом для передачи данных через сеть, особенно в веб-разработке.

3.1.3.5 Чек-лист проверки набора в формате JSON

1. Правильное тело файла

2. Различные параметры (обязательность, работа параметров)

3. Перестановка мест слагаемых (заголовки, тело файла)

Обратите внимание, что объект в формате JSON имеет несколько важных отличий от объектного литерала:

• Строки используют двойные кавычки. Никаких одинарных кавычек или обратных кавычек в JSON. Так Ivan' становится «Ivan».
• Имена свойств объекта также заключаются в двойные кавычки. Это обязательно. Так age:30 становится «age»:30.
• Важное ограничение: не должно быть циклических ссылок.
• Имена свойств должны быть в двойных кавычках
• Имена ключей должны быть в одинарных кавычках
• Не допускается конструктор «new», только значения
• Отсутствует запятая после непоследнего свойства
• Не должно быть запятой после последнего свойства

3.1.4 RDF формат

RDF (Resource Description Framework) — это стандарт, разработанный W3C для описания данных в сети Интернет. RDF предназначен для моделирования информации о веб-ресурсах (например, веб-страницах, элементах контента) и их взаимосвязях и позволяет структурировать и связывать данные таким образом, чтобы они могли быть поняты и обработаны как людьми, так и машинами.

В основе RDF лежит концепция триплетов (троек), где каждая запись представляет собой утверждение, состоящее из трех частей:

• Субъект (Subject) — то, о чем идет речь (например, конкретный веб-ресурс).
• Предикат (Predicate) — характеристика или свойство субъекта (например, «является автором»).
• Объект (Object) — значение свойства или другой ресурс, связанный с субъектом (например, имя автора).

Таким образом, каждое утверждение в RDF можно прочитать как «Субъект имеет свойство Предикат со значением Объект».

RDFa (Resource Description Framework in Attributes) — это технология, позволяющая внедрять семантические данные RDF в существующие документы HTML, XHTML и XML, добавляя дополнительные атрибуты к стандартным элементам разметки. RDFa используется для предоставления структурированных данных и улучшения обработки контента, чтобы он был понятен как для пользователей, так и для поисковых систем и других автоматизированных агентов.

RDFa позволяет интегрировать триплеты RDF (субъект-предикат-объект) в HTML-документ. Эти триплеты представляют собой основные единицы семантических данных, описывающие отношения между ресурсами, такими как веб-страницы, текстовые блоки, изображения и другие элементы.

3.1.4.1 Признаки выбора для формата

RDFa целесообразно использовать в случаях:

• Публикация контента в вебе: формат подходит для публикации данных, которые уже содержатся на веб-страницах. Это удобный способ добавить дополнительные метаданные к существующему содержимому, не меняя структуры HTML-документа.
• Повышение видимости данных: использование RDFa помогает поисковым системам лучше понимать содержание страниц и делать их более доступными для поиска.
• Интеграция с веб-страницами: RDFa подходит для интеграции метаданных прямо в HTML-контент. Если вы создаете веб-страницы, на которых публикуются данные, и хотите, чтобы эти данные были структурированы и доступны для машинного чтения, RDFa является отличным выбором. Это позволяет использовать существующие HTML-документы для хранения и передачи метаданных, не создавая отдельные файлы.

3.1.4.2 Типовые ошибки при работе с форматом

1. Неправильное использование атрибутов: например, путаница между property и typeof может привести к некорректной интерпретации данных. Атрибут property указывает на свойство объекта, а typeof описывает тип объекта.

2. Отсутствие или неверное указание URI: поскольку RDFa работает с ресурсами, важно корректно указывать URI. Отсутствие уникальных идентификаторов может затруднить объединение и обработку данных.

3. Ошибки в онтологии: использование неподходящих или неверных терминов из онтологии (например, Schema.org) может привести к тому, что данные не будут корректно распознаны сторонними сервисами.

3.1.4.3 Основные правила при составлении RDFa вручную

Основная идея RDFa заключается в использовании атрибутов HTML для встраивания метаданных. Это включает добавление атрибутов about, typeof, property, content, resource и datatype в HTML-теги.

• about — указывает на ресурс, о котором идет речь (например, URL страницы или конкретного объекта).
• property — указывает свойство ресурса, которое описывается (например, название книги).
• content — позволяет определить значение свойства, если оно не совпадает с содержимым тега.
• typeof — указывает тип ресурса (например, «Книга»).
• resource — используется для обозначения ресурсов, на которые ссылаются другие ресурсы.

Пример использования RDFa+HTML:

Проведем более подробный разбор примера:

1.