Стандарти відкритих даних місцевого самоврядування¶

Стандарти відкритих даних місцевого самоврядування – це майданчик для спільної розробки, тестування та впровадження рекомендацій для оприлюднення відкритих даних місцевого самоврядування. Він поєднує спільноту розробників, службовців, представників громадських організацій, активістів. Головною метою майданчика є підвищити рівень (пере)використання відкритих даних органів місцевого самоврядування в електронних сервісах, матеріалах медіа, дослідженнях, аналізі політик та інформуванні рішень.

Що для цього необхідно:

вивчення кращих практик обміну даними, їх популяризація серед розробників програмного забезпечення та розпорядників даних;

пристосування та удосконалення вже готових рішень (основних словників, моделей, стандартів даних) для наборів відкритих даних місцевого самоврядування;

створення легких для вивчення та використання розпорядниками рекомендацій щодо оприлюднення наборів даних;

розробка програмного забезпечення, яке допомагає розпорядникам легко взаємодіяти з даними та ділитись ними.

Цей ресурс розроблений ГО «Агенція журналістики даних» Texty.org.ua) в рамках проекту «Прозорість та підзвітність в державному управлінні та послугах» за сприяння Державного агентства з питань електронного урядування України. Реалізація проекту в Україні здійснюється за підтримки USAID/UK aid. Запрошуємо всіх бажаючих долучитись до обговорення та напрацювання рекомендацій. Якщо ви маєте пропозиції, зауваження, коментарі чи бачення, то звертайтесь до координаторів проекту.

Вміст документу ліцензовано на умовах Ліцензії Creative Commons Зазначення Авторства 4.0 Міжнародна.

Вступ¶

Примітка

Обговорення цього розділу в Google Документі або на GitHub Issues.

В спільноті фахівців та активістів впровадження стандартів, удосконалення можливостей обміну та перевикористання відкритих даних (семантичної інтероперабельності) стоять гостро на порядку денному. Як і де оприлюднювати дані? В яких форматах? З якою структурою та метаданими? Деякі відповіді на ці питання дає Постанова КМУ №835 «Про затвердження Положення про набори даних, які підлягають оприлюдненню у формі відкритих даних». Однак, нещодавній моніторинг засвідчив, що підвищення якості відкритих даних потребує детальнішого унормування. Процедура премодерації наборів, впроваджена на новій версії data.gov.ua, бореться, скоріше, з наслідками низької культури роботи з даними, аніж з її передумовами. Вирішити ці проблеми, посилити (пере)використання даних можна втіливши наступні завдання:

вивчення кращих практик обміну даними, їх популяризація серед розробників програмного забезпечення та розпорядників даних;

пристосування та удосконалення вже готових рішень (основних словників, моделей, стандартів даних) для наборів відкритих даних місцевого самоврядування;

створення легких для вивчення та використання розпорядниками рекомендацій щодо оприлюднення наборів даних;

розробка програмного забезпечення, яке допомагає розпорядникам легко взаємодіяти з даними та ділитись ними.

Коротко про структуру майданчика. У розділі «Цикл життя стандарту: від підготовки до впровадження та перегляду» описана розробка рекомендацій (стандартів) з точки зору організації роботи, залучення зацікавлених сторін, впровадження напрацьованих документів. Розділ «Розробникам» декларує принципи розробки структур таблиць, містить пропозиції прив’язки моделей даних наборів до основних словників. У розділі «Як оприлюднити таблицю та її структуру у формі відкритих даних» розглянуті рекомендації для розпорядників щодо роботи з таблицями та їх структурами. Розділ «Стандарти наборів відкритих даних» містить посилання на вже розроблені рекомендації оприлюднення наборів даних.

Цикл життя стандарту: від підготовки до впровадження та перегляду¶

Примітка

Обговорення цього розділу в Google Документі або на GitHub Issues.

Для життєздатності та ефективності стандарту в процесі розробки та впровадження варто керуватись наступними принципами:

реалістичність - врахування технічних та організаційних можливостей розпорядників, баланс між можливостями розпорядників та потребами користувачів;

розвиток (перспективність) - періодичний перегляд і вдосконалення стандарту;

відкритість та прозорість - забезпечення відкритості та прозорості процесу розробки, поширення стандарту під відкритою ліцензією;

залучення - залучення до розробки всіх зацікавлених сторін, постійна комунікація з ними;

інтероперабельність - врахування взаємодії з іншими даними та інформаційними системами;

доступність - простота для розуміння, впровадження та використання стандарту.

Формати роботи. Розробляти стандарти можуть як розпорядники відкритих даних, залучаючи до роботи користувачів, так і навпаки. Залучення обох сторін допоможе розробити реалістичний стандарт, що враховує можливості розпорядників та потреби користувачів. Роботу можна організувати у наступних форматах:

робоча група, що створена органом місцевого самоврядування;

неформальна робоча група, що створена представниками громадського сектору;

неформальна група в межах структурних підрозділів органів місцевого самоврядування.

Склад робочої групи. Для сталості результатів з розробки стандартів варто, щоб до робочої групи входили

представники структурного підрозділу, який є розпорядником даних;

представники структурного підрозділу, що відповідає за інформаційно-комп’ютерне забезпечення та/або оприлюднення відкритих даних;

користувачі даних (розробники, аналітики, журналісти, підприємці, активісти, науковці та інші).

До робочої групи також можуть бути залучені сторонні фахівці, консультанти, експерти.

Організація роботи та комунікація. Яким би не був формат робочої групи, рекомендовано щоб вона включала не більше 10 осіб. Важливо визначити координатора(-ку), спосіб прийняття рішень, онлайн та офлайн канали для зовнішньої та внутрішньої комунікації. Результати зустрічей та обговорень бажано документувати. Робочі групи можуть працювати над стандартами як для наборів передбачених у Положенні затвердженому Постановою КМУ №835, так і для наборів щодо яких є запит громадськості, бізнесу, науковців або які хоче оприлюднити місцева влада. Розробка стандарту також може відбуватись у форматі хакатону. З порадами щодо того, як його провести, можна ознайомитись за посиланням.

Етапи розробки. Розробка та впровадження стандарту включає шість основних етапів: підготовка, дослідження, розробка, тестування, впровадження, відслідковування та перегляд.

Етап 1. Підготовка¶

Тривалість: від одного до кількох тижнів

Учасники: розпорядники, зацікавлені сторони

Форми роботи: онлайн та офлайн-зустрічі, обговорення, мозковий штурм, опитування, консультації з розпорядниками та зацікавленими сторонами, розробка нормативних документів

Результат: створено робочу група, уноромовано її діяльність, визначено набір даних щодо якого буде розроблений стандарт

На підготовчому етапі визначається набір даних для якого необхідно розробити стандарт, відбувається планування роботи, налагоджуються організаційні процеси та комунікація. Необхідно створити робочу групу, що буде відповідати за розробку стандарту, та регламентувати її діяльність. Якщо ініціатором робочої групи є орган місцевого самоврядування, доцільно розробити та прийняти відповідний нормативний документ, наприклад, положення. В ньому можна визначити склад групи, яким чином відбуватиметься робота, а також питання впровадження стандарту. Якщо ініціатором є громадськість, то не завадить теж впровадити регламент роботи неформальної групи, продумати кампанію адвокації впровадження стандарту та канали комунікації з розпорядниками.

Далі відбуваються обговорення в рамках робочої групи, консультації з розпорядниками й зацікавленими сторонами щодо необхідності та очікувань від впровадження стандарту. Зокрема, можна розглянути наступні питання:

Які дані мають бути відкритими? Який їх зміст та структура?

Що є підставою для відкриття, наприклад, вимоги Постанови КМУ №835 або запит громадськості?

Чому потрібно стандартизувати дані?

Хто є розпорядником даних?

Хто є зацікавленими сторонами в оприлюднені та стандартизації даних?

Хто є користувачами даних?

Які можливості для оприлюднення даних мають розпорядники?

Які потреби щодо використання даних мають користувачі?

Яких позитивних результатів можна досягти впровадженням стандарту, наприклад, розробка додатку, використання даних для формування бюджетних запитів тощо?

За результатами розгляду цих питань робоча група має спланувати подальшу діяльність. Для цього потрібно визначити основні заходи (за приклад можна взяти етапи розробки стандарту) та відповідальних осіб за їх реалізацію. Відповідальні особи повинні володіти знаннями та навичками для виконання поставлених завдань.

Етап 2. Дослідження¶

Тривалість: один тиждень

Учасники: відповідальні особи, визначені робочою групою

Форми роботи: кабінетне дослідження (desk-research), консультації з розпорядниками, експертами, офлайн та онлайн обговорення

Результат: виявлені проблеми й неузгодженості в оприлюднених наборах даних; досліджено те, як розпорядники працюють з даними, які потреби мають користувачі; сформоване бачення змісту і стратегія розробки стандарту (створення нового чи адаптація наявного).

Як множаться стандарти. Джерело зображення: xkcd

Роботу над стандартом необхідно розпочинати з дослідження того, чи вже не розроблений подібний стандарт в Україні або за її межами. Для цього можна переглянути довідник стандартів, скористатись пошуковими сервісами або проконсультуватись з експертами у галузі відкритих даних. Якщо такі напрацювання вже існують, то варто ознайомитись з досвідом їх використання та спробувати адаптувати. Якщо ж розробленого стандарту немає, то для початку потрібно провести невелике дослідження, що включає три підетапи:

Дослідження оприлюднених наборів;

Дослідження роботи розпорядників;

Дослідження потреб користувачів.

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

Дослідження оприлюднених наборів. Дослідження наборів дасть змогу зрозуміти, які саме дані й яким чином оприлюднюють різні розпорядники. Для цього можна завантажити різні версії набору з порталів відкритих даних й проаналізувати їх спільні та відмінні риси. Зокрема, варто розглянути наступні питання:

Паспорти наборів. Які існують варіанти назв, описів, ключових слів?

Тип даних та формати. Який тип даних набору та формати оприлюднення, відповідно до пункту 9 Положення затвердженого Постановою КМУ №835?

Структура набору. Якщо дані структуровані в таблицю, то які колонки використовуються? Якщо дані мають ієрархічну структуру, то які об’єкти є батьківськими, а які дочірніми?

Інтероперабельність. Чи є можливість поєднувати дані набору з іншими даними? Якщо так, то яким чином вона забезпечена? Чи доступний набір у форматах зв’язаних даних?

Оновлення. З якою періодичністю оновлюється набір даних?

Дослідження роботи розпорядників. Дослідження роботи розпорядників дозволяє вивчити детальніше потік, обмін даними, обладнання, програмне забезпечення та нормативно-правову базу, що використовується для оприлюднення набору. Для цього необхідно опитати одного або декількох розпорядників. Якщо робоча група складається виключно з представників громадськості, необхідно налагодити комунікацію з органами місцевого самоврядування або їх підрозділами, які володіють даними. Наприклад, під час дослідження можна розглянути наступні питання:

Потік та обмін даними. Яким чином дані збираються, обробляються, використовуються, зберігаються, мігрують з одних інформаційних систем в інші, архівуються? Які процеси автоматизовані, які ні?

Обладнання та програмне забезпечення. Яке обладнання та програмне забезпечення використовується при роботі з даними? Яка ліцензія потрібна для його використання? Яка кваліфікація потрібна для роботи з ним?

Нормативно-правова база та організація. На основі якої нормативно-правової бази відбувається ведення, збір, захист та оприлюднення даних набору. Чи є відповідальна особа або структурний підрозділ? Чи існує потреба додатковому регулюванні?

Дослідження потреб користувачів. Наявні та потенційні користувачі даних можуть дати цінні пропозиції щодо розробки стандарту. Для цього необхідно вивчити їх потреби та перешкоди, з якими вони зустрічаються, використовуючи набір. Під час спілкування з користувачами важливо обговорити наступні питання:

Які набори використовуються або яких є потреба?

Які є вимоги до змісту даних?

З якою метою використовуються або будуть використовуватися дані (наприклад, аналіз, розробка сервісів та інше)?

Як часто потрібно оновлювати набір даних?

Якою є бажана структура (схема) та формат набору?

Чи має набір поєднуватися з іншими даними? Якщо так то, з якими? Яким чином краще забезпечити цю можливість (наприклад, уніфікувати назви колонок, включити додаткові ідентифікатори та інше)?

Етап 3. Розробка¶

Тривалість: від двох тижнів

Учасники: члени робочої групи, запрошені експерти

Форми роботи: онлайн та офлайн зустрічі, обговорення, воркшопи, хакатони, документування стандарту

Результат: розроблений проект стандарту

На основі результатів дослідження робоча група може розпочинати розробку стандарту. Це передбачає три підетапи:

Розробка нормативної бази та рекомендацій для організації роботи розпорядників;

Оформлення паспорту (метаданих);

Розробка структури та визначення форматів.

За їх результатами формуються основні розділи стандарту.

Нормативна база та організація роботи розпорядників. Найперше необхідно напрацювати рекомендації щодо нормативної-правової бази та організації роботи розпорядників. Для цього стануть в пригоді матеріали дослідження. Варто розглянути наступні питання:

розпорядники даних та відповідальні особи;

нормативно-правові акти, що необхідні для оприлюднення та стандартизації набору;

джерело, потік й обмін даними (data provenance) згідно результатів дослідження;

вимоги до обладнання, програмного забезпечення та компетенцій відповідальних осіб для оприлюднення даних згідно зі стандартом;

пов’язані набори даних, довідники та інша документація;

якість та валідація даних;

оновлення та версійність;

політика щодо персональних даних у цьому наборі;

ліцензія;

інші рекомендації щодо організації оприлюднення даних.

Робоча група може сформувати запит на прийняття нормативно-правових актів необхідних для оприлюднення набору. Для цього потрібно напрацювати проекти й подати їх на затвердження. Проекти можна додати в стандарт окремим додатками.

Оформлення паспорту (метаданих) набору. Складність роботи з паспортом (метаданими) полягає у тому, що його структура відрізняються на різних порталах відкритих даних. Метадані набору, що складені для одного порталу, можуть виявитися лише частково придатним для іншого. Зважаючи на це, доречно скористатися одним з наступних підходів:

Прописати лише найбільш важливі метадані, особливо ті щодо яких можуть виникнути розбіжності та помилки. Наприклад, це можуть бути назва набору даних, його опис, ключові слова, частота оновлення, формат ресурсів, ліцензія та інші. Результати потрібно занести до таблиці з наступною структурою: (1) назва поля; (2) приклад заповнення.

Скористатися словниками Dublin Core Metadata Initiative (DCMI) або Data Catalog Vocabulary (DCAT). Вони надають погоджену структуру метаданих, що підтримується порталами відкритих даних. У цьому випадку, в таблиці потрібно вказати клас, властивість та значення метаданих.

Другу стратегію варто використати у випадку, коли учасники робочої групи мають навички роботи з основними словниками. Також потрібно зважити на рівень підготовки розпорядників, які можуть бути необізнані зі стандартами DCAT та DCMI. У цьому разі, у стандарті потрібно дати пояснення.

Розробка структури та визначення форматів. При розробці структури та визначенні форматів даних загальним орієнтиром є потреби користувачів та спроможність розпорядників. Однак, вибір конкретної технології необхідно зробити зважаючи на наступне:

вимоги пункту 9 Положення затвердженого Постановою КМУ №835 щодо типів даних та форматів файлів;

міжнародні стандарти, зокрема, 5-ти зіркові відкриті дані;

модель даних;

спосіб, у який набір буде оприлюднений, наприклад, файлами чи через API;

забезпечення семантичної інтероперабельності.

Примітка

Пункт 9 Положення затвердженого Постановою КМУ №835 визначає відповідність між типами даних та форматами.

Фрагмент таблиці з пункту 9 Постанови КМУ №835¶

Тип даних Формат даних

Текстові дані TXT, RTF, ODT, DOC(X), PDF (з текстовим змістом, нескановане зображення), (X)HTML

Структуровані дані RDF, XML, JSON, CSV, XLS(X), ODS, YAML

Архів даних ZIP, 7z, Gzip, Bzip2

Геопросторові дані GeoTIFF, SHP, DMF, MID/MIF, DXF, ХML, GeoJSON, GPX, LOC, ARINC, AIXM

Стандарт 5-ти зіркові відкриті дані дає оцінку якості даних на основі можливостей роботи з ними.

Дані, які можна перевикористати, відповідають стандарту двох зірок та вище, машиночитані - трьох та вище. Якщо набір містить ресурси лише у машиночитаних форматах (CSV, XML, JSON), доцільно продублювати їх у людиночитаних електронних таблицях (ODS, XLS, XLSX).

Таким чином, для розробки структури та визначення форматів можна використати один з наступних підходів:

Якщо набір представлений таблицею можна використати рекомендації для розробки структур таблиць. Цей варіант найкраще підійде для робочих груп, що працюють над простими та ефективними рішеннями для найширшого кола розпорядників та користувачів.

Якщо набір представлений декількома таблицями, має ієрархічно структуровані дані (формати XML, JSON) або буде доступний через API, доцільно створити модель даних. Для її розробки можна використати уніфіковану мову моделювання, моделі сутність-зв’язок або опис структури бази даних SQL. Таку модель можна додати до стандарту у графічному або табличному вигляді.

Якщо набір буде доступний у форматах зв’язаних даних (linked data), для розробки його схеми можна використати методологію розробки моделей даних та створення співставлень за допомогою основних словників з Підручника з основних словників для електронного врядування.

Залежно від формату структуру (схему) набору потрібно представити відповідно до наступних вимог:

CSV: Metadata Vocabulary for Tabular Data (W3C), Table Schema (Frictionless Data), CSV Schema Language

XML: XML Schema 1.1

JSON: JSON Schema

RDF: RDF Schema 1.1

Етап 4. Випробування¶

Тривалість: від декількох тижнів до декількох місяців

Учасники: розпорядники, користувачі, інші зацікавлені сторони

Форми роботи: робота з даними, оприлюднення, тестування, консультації з розпорядниками та користувачами

Результат: проведено тестування, підготовлено фінальну версію стандарту

Проект стандарту необхідно випробувати перед впровадженням. Розпорядники мають пройти повний цикл: від підготовки до оприлюднення та оновлення набору даних. Після цього важливо отримати коментарі користувачів щодо якості даних, та розпорядників - щодо дотримання вимог стандарту. Цей процес може відбуватись, як в межах діяльності робочої групи, так і з залученням ширшого кола зацікавлених сторін. Наприклад, можна провести публічні або онлайн обговорення. При цьому важливо чітко скоординувати випробування та комунікацію. Отримані побажання та зауваження мають бути розглянуті на засіданні робочої групи і враховані у фінальній версії стандарту. За потреби, необхідно повернутись до певного етапу розробки й виправити недоліки.

Також на етапі випробування варто дослідити яка методична, технічна, організаційна чи інша підтримка потрібна розпорядникам. Обговоривши це в робочій групі, варто запропонувати рішення. Наприклад, якщо є потреба підвищення кваліфікації, можна передбачити навчання, розробку інструкцій, тощо.

Етап 5. Впровадження¶

Тривалість: 2-4 тижні

Учасники: розпорядники

Форми роботи: розробка нормативних документів, робота з даними, оприлюднення

Результат: стандарт впроваджено та унормовано

Після випробування вдосконалений стандарт можна представити у вигляді нормативного документу (наприклад, правил, інструкцій, рекомендацій, роз’яснень, тощо). Це зобов’яже розпорядників дотримуватись встановлених вимог при оприлюдненні та оновленні датасету. Нормативний документ затверджується наказом або рішенням виконавчого органу. Залежно від політики відкритих даних, він може мати різну структуру та охоплювати один або декілька наборів. У випадку, якщо стандарт розроблений громадськістю необхідно провести адвокаційну кампанію щодо його впровадження.

Важливо, щоб робоча група просувала стандарт і оприлюднений набір, як серед користувачів, так розпорядників. Для цього необхідно поширити напрацьовані матеріали, ділитися отриманим досвідом, проводити консультації та роз’яснення. Після впровадження стандарту робоча група не завершує діяльність. Потрібно змінити формат роботи, зокрема, визначити особу, що відповідатиме за підтримку стандарту, спланувати моніторинг та перегляд.

Етап 6. Моніторинг, перегляд та покращення¶

Тривалість: постійно після впровадження

Учасники: розпорядники, користувачі, члени робочої групи, зовнішні експерти

Форми роботи: онлайн та офлайн опитування, обговорення, моніторинг, консультації

Результат: стандарт відповідає актуальним вимогам і потребам

Необхідно регулярно моніторити дотримання вимог стандарту під час оприлюднення наборів даних. Важливо отримувати зворотній зв’язок від розпорядників та користувачів. Стандарт потрібно періодично переглядати, наприклад, раз на рік або на декілька років. Це дозволить виправити помилки та підтримати актуальність.

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

Розробникам¶

Примітка

Обговорення цього розділу в Google Документі або на GitHub Issues.

Принципи розробки рекомендацій¶

Розробка рекомендацій (стандартів відкритих даних) для розпорядників - це складне завдання. В його основі лежить конфлікт вимог та можливостей. Існуючі стандарти оприлюднення відкритих даних вимагають від розпорядників високих навичок володіння програмним забезпеченням, програмування, розуміння основ семантичної інтероперабельності. У свою чергу, «полегшення» стандартів погіршує можливості перевикористання даних. Одним зі способів вирішення такого конфлікту є розробка програмного забезпечення (сервісів), яке спрощуватиме взаємодію користувачів з даними через UI та полегшуватиме обмін - через API. Іншим рішенням може стати підвищення навичок розпорядників. Однак, обидва варіанти потребують матеріальних та часових ресурсів і не знімають відповідальності за оприлюднення даних.

Для розробки рекомендацій та структур таблиць для наборів даних використані наступні принципи:

для створення структур наборів перевикористовуються та розширюються існуючі основні словники або інші релевантні моделі даних;

розробка відбувається у напрямку від контекстно-нейтральних моделей даних основних словників до контекстно-специфічних моделей даних наборів;

рекомендації мають забезпечити оприлюднення даних у відкритих машиночитаних форматах;

рекомендації орієнтовані на роботу з даними у електронних таблицях (Microsoft Excel, Google Таблиці, LibreOffice Calc);

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

простота використання таблиць розпорядниками є важливішою за нормалізацію структури моделі даних;

виконання вимог рекомендацій має дати користувачам можливість легко приводити дані до нормалізованої структури;

рекомендації забезпечують людиночитаність даних: ідентифікатори/коди дублюються назвами/заголовками;

метадані та структура таблиць описується відповідно до рекомендацій W3C «Model for Tabular Data and Metadata on the Web».

Використання основних словників для розробки структур наборів¶

Примітка

Обговорення цього розділу в Google Таблиці або на GitHub Issues.

Для розробки структур наборів пропонуємо використовувати наступні основні словники та інші моделі даних.

Використання основних словників для розробки структур наборів¶

Назва набору Mодель даних Додатково Коментар

Довідник підприємств, установ (закладів) та організацій розпорядника інформації та підпорядкованих йому організацій ISA2 Core Public Organisation Vocabulary vCard Ontology, Schema.org

Інформація про організаційну структуру розпорядника інформації W3C The Organization Ontology

Нормативи, що затверджуються та підлягають оприлюдненню відповідно до закону розпорядником інформації Dublin Core Metadata Initiative Набір оприлюднюється у формі переліку, що містить посилання на документи у мережі Інтернет.

Переліки національних стандартів, які в разі добровільного застосування є доказом відповідності продукції вимогам технічних регламентів Dublin Core Metadata Initiative

Звіти, в тому числі щодо задоволення запитів на інформацію Dublin Core Metadata Initiative

Інформація про систему обліку, види інформації, яка зберігається розпорядником Data Catalog Vocabulary Dublin Core Metadata Initiative

Реєстр наборів даних, що перебувають у володінні розпорядника інформації Data Catalog Vocabulary Dublin Core Metadata Initiative

Адміністративні дані, що збираються (обробляються) та підлягають оприлюдненню відповідно до вимог закону, розпорядника інформації Необхідно роз’яснення Державного агентства з питань електронного урядування України щодо змісту даних набору.

Нормативно-правові акти, акти індивідуальної дії (крім внутрішньоорганізаційних), прийняті розпорядником інформації, проекти рішень, що підлягають обговоренню, інформація, визначена законодавством про засади регуляторної політики Dublin Core Metadata Initiative Akoma Ntoso, MetaLex, Functional Requirements for Bibliographic Records Набір оприлюднюється у формі переліку, що містить посилання на документи у мережі Інтернет.

Фінансова звітність суб’єктів господарювання державного сектору економіки Відповідно до форми затвердженої Наказом Міністерства фінансів України «Про затвердження Національного положення (стандарту) бухгалтерського обліку 1 «Загальні вимоги до фінансової звітності»» від 07.02.2013 № 73

Переліки регуляторних актів із зазначенням дати набрання чинності, строку проведення базового, повторного та періодичного відстеження їх результативності та інформації про місце їх оприлюднення Dublin Core Metadata Initiative W3C The Organization Ontology, Schema.org, Simple Knowledge Organization System, RDF Schema

Звіти про виконання фінансових планів суб’єктів господарювання державного сектору економіки Відповідно до форми затвердженої Наказом Міністерства економічного розвитку і торгівлі України «Про затвердження Порядку складання, затвердження та контролю виконання фінансового плану суб’єкта господарювання державного сектору економіки» від 02.03.2015 № 205.

Основні положення генеральних планів населених пунктів та детальних планів територій Набір містить просторові дані.

Перелік об’єктів комунальної власності Open Contracting Data Standard (openregistry.assets.bounce)

Перелік об’єктів комунальної власності, що передані в оренду чи інше право користування (з даними про умови передачі об’єктів в оренду) Open Contracting Data Standard (openregistry.assets.bounce)

Перелік незадіяних земельних ділянок і майнових об’єктів (приміщень) комунальної форми власності, які можуть бути передані в користування Open Contracting Data Standard (openregistry.assets.bounce)

Результати радіаційного контролю Розпорядником даних є Державна служба з надзвичайних ситуацій України.

Інформація про використання публічних коштів під час будівництва, ремонту та реконструкції об’єктів дорожньої інфраструктури та хід виконання проектів Open Contracting Data Standard Розглянути можливість отримання даних через API Єдиного веб-порталу використання публічних коштів та Prozorro.

Генеральні плани населених пунктів, історико-архітектурні опорні плани, плани зонування територій та детальні плани територій (за винятком відомостей, які відповідно до законодавства складають інформацію з обмеженим доступом) Набір містить просторові дані.

Дані про місцезнаходження громадського транспорту в режимі реального часу GTFS Realtime Datex II

Звіти про виконання фінансових планів комунальних підприємств Відповідно до форми затвердженої Наказом Міністерства економічного розвитку і торгівлі «Про затвердження Порядку складання, затвердження та контролю виконання фінансового плану суб’єкта господарювання державного сектору економіки» від 02.03.2015 № 205.

Паспорти бюджетних програм місцевого бюджету Відповідно до форми затвердженої Наказом Міністерства фінансів України «Про паспорти бюджетних програм» від 29.12.2002 № 1098.

Звіти про виконання паспортів бюджетних програм місцевого бюджету Відповідно до форми затвердженої Наказом Міністерства фінансів України «Про паспорти бюджетних програм» від 29.12.2002 № 1098.

Титульні списки на проведення капітального та поточного ремонту, будівництва, реконструкції та благоустрою Open Contracting Data Standard

Інформація про рекламні засоби (дані про місце розміщення рекламного засобу, його вид і розміри, найменування розповсюджувача зовнішньої реклами, номер його телефону, дата видачі дозволу та строк його дії, номер і дата укладення договору, якщо місце розміщення рекламного засобу належить до комунальної власності) ISA2 Business, Location, Person Vocabulary, Schema.org Open Contracting Data Standard, Dublin Core Metadata Initiative

Реєстр боргових зобов’язань суб’єктів господарювання комунальної власності територіальної громади (як суб’єктів господарювання перед третіми особами, так і третіх осіб - перед суб’єктами господарювання) Дослідити можливість використання фінансових RDF-словників.

Інформація про інвестиційні договори, додатки, додаткові угоди та інші матеріали до них Dublin Core Metadata Initiative Open Contracting Data Standard Набір оприлюднюється у формі переліку, що містить посилання на документи у мережі Інтернет.

Відомості щодо схем розміщення засобів пересувної торгівлі ISA2 Business, Location, Person Vocabulary, Schema.org Open Contracting Data Standard, Dublin Core Metadata Initiative

Відомості щодо схем розміщення засобів сезонної торгівлі ISA2 Business, Location, Person Vocabulary, Schema.org Open Contracting Data Standard, Dublin Core Metadata Initiative

Відомості щодо ярмарків (строк проведення, місце, кількість місць, вартість місць), організаторів ярмарків, договорів, укладених з організаторами таких ярмарків ISA2 Business, Location, Person Vocabulary, Schema.org Open Contracting Data Standard, Dublin Core Metadata Initiative

Дані про розміщення громадських вбиралень Schema.org

Відомості щодо залучення пайової участі (як у забезпечення розвитку інженерно-транспортної інфраструктури, так і в утримання об’єктів благоустрою) Open Contracting Data Standard

Перелік перевізників, що надають послуги пасажирського автомобільного транспорту, та маршрути перевезення GTFS Static Transit Структура таблиць відповідає фідам agency.txt, routes.txt.

Відомості щодо транспортних засобів, які обслуговують пасажирські автобусні, тролейбусні та трамвайні маршрути перевезення (кількість транспортних засобів на кожному маршруті, марка, модель, державний номер, пасажиромісткість) GTFS Static Transit Необхідно розширити модель GTFS Static Transit.

Розклад руху громадського транспорту GTFS Static Transit Структура таблиць відповідає фідам agency.txt, stops.txt, routes.txt, trips.txt, stop_times.txt. Можливе включення опціональних фідів.

Дані про місце розміщення зупинок міського електро- та автомобільного транспорту GTFS Static Transit Структура таблиці відповідає фіду stops.txt.

Перелік розповсюджувачів реклами, що отримали дозвіл на розміщення зовнішньої реклами Дублювання даних з набором «Інформація про рекламні засоби».

Перелік земельних ділянок, що пропонуються для здійснення забудови Open Contracting Data Standard (openregistry.assets.bounce)

Перелік укладених договорів, укладені договори, інші правочини, додатки, додаткові угоди та інші матеріали до них Open Contracting Data Standard

Актуальні списки власників/орендарів місцевих земельних ділянок Open Contracting Data Standard (openregistry.assets.bounce) Набір оприлюднюється як «Перелік земельних ділянок комунальної власності, що були приватизовані або передані в оренду або інше право користування».

Відомості про лікарські засоби/препарати, придбані за бюджетні кошти, відомості про розподілення таких ліків між закладами охорони здоров’я та їх залишки в кожному з них Schema.org (health-lifesci) Open Contracting Data Standard

Інформація про заповнюваність пасажирських і приміських поїздів Розпорядником даних є ПАТ «Укрзалізниця».

Бази даних щодо ремонту доріг: точне зазначення ділянки відремонтованої дороги (від кілометра до кілометра), ширина та довжина дороги, довжина ділянки, товщина дорожнього покриття, матеріали, види робіт, вартість робіт, гарантійний строк, виконавці робіт Open Contracting Data Standard, CoST Infrastructure Data Standard

Схеми планування територій громад та плани зонування територій (для сільських, селищних, міських рад) Набір містить просторові дані.

Інформація про дотримання державних соціальних нормативів у сфері обслуговування закладами (інституціями) культури, підсумки споживання культурних благ і їх доступність для різних категорій населення Необхідно роз’яснення Державного агентства з питань електронного урядування України щодо змісту даних набору.

Огляд стану забезпечення правової охорони і захисту прав інтелектуальної власності з переліком проведених заходів для підвищення обізнаності та поваги до інтелектуальної власності, розвитку культури суспільства у зазначеній сфері Необхідно роз’яснення Державного агентства з питань електронного урядування України щодо змісту даних набору.

Як оприлюднити таблицю та її структуру у формі відкритих даних¶

Примітка

Обговорення цього розділу в Google Документі або на GitHub Issues.

Табличні дані¶

Табличні дані - прості у створенні та ефективні у використанні. Таблиця - це впорядкована сукупність колонок та рядків. Кожен рядок таблиці містить один запис. Кожна колонка - значення, що змінюються від рядка до рядка. Назви колонок розміщуються в шапці. На перетині рядків та колонок знаходяться комірки. З цього визначення випливає, що таблиця не може містити заголовків та об’єднаних комірок. Колір, шрифт, інше форматування тексту та комірок не є даними. Розглянемо приклад пустої таблиці на 4 колонки та 5 рядків.

Колонка 1 Колонка 2 Колонка 3 Колонка 4

Рядок 1

Рядок 2

Рядок 3

Рядок 4

Рядок 5

Наповнимо таблицю даними про обласні центри, що розміщені на річці Дніпро (за даними Вікіпедії). Кожним рядком у таблиці є запис про певне місто, а стовпчиком - його характеристики (назва, кількість населення, площа, густота населення).

Назва міста Населення, осіб Площа, кв. км Густота населення (осіб на кв. км.)

Київ 2937239 848 3463.7

Черкаси 277944 69 4028.2

Дніпро 1000506 415 2410.9

Запоріжжя 743113 331 2245.1

Херсон 291428 145 2009.8

Вести таблиці необхідно у Microsoft Excel, Google Таблицях, LibreOffice Calc, а зберігати - у форматах XLS, XLSX, ODS або CSV. Категорично не рекомендується використовувати Microsoft Word, Google Документи, LibreOffice Writer тощо, та зберігати таблиці у форматах DOC, DOCX, ODT, RTF, PDF, HTML. Детальніше про роботу з таблицями можна дізнатися за посиланнями: Відкриті дані: формати та правила створення (Texty.org.ua, 2017), Організація даних у таблицях (К. Броман, К. Ву, 2018).

Шапка таблиці¶

Для того, щоб таблиці в наборі можна було легко завантажувати до баз даних, створювати на їх основі застосунки або аналізувати, їх шапка має містити лише латинські літери, цифри та нижні підкреслення - _. Перетворимо шапку таблиці відповідно до цих правил.

name population area populationDensity

Київ 2937239 848 3463.7

Черкаси 277944 69 4028.2

Дніпро 1000506 415 2410.9

Запоріжжя 743113 331 2245.1

Херсон 291428 145 2009.8

Як можна побачити, назви колонок стали лаконічними, пробіли були видалені, а для відділення слів одне від одного використаний, так званий, нижнійВерблюжийРегістр (перше слово пишеться з маленької літери, а кожне наступне - з великої). Тепер таблиця стала машиночитаною, однак, частина важливої інформації з шапки втрачена. Наприклад, одиниці виміру кількості населення, площі та густоти. На відміну від електронних таблиць, в CSV файлах неможливо вказати формат даних, які знаходяться в колонках (наприклад, число, текст, відсоткове значення, дата). Для того, щоб уникнути цих недоліків, використовуються структури.

Структура таблиці¶

Структура - це окремий файл, який описує кожну колонку вихідної таблиці. Існує два способи створення структури:

використати форму у вкладці «Словник даних» на data.gov.ua;

підготувати та завантажити окрему таблицю у форматі CSV.

У другому випадку, структура включатиме 4 колонки. У першій колонці (name) зазначаються назви колонок з вихідної таблиці, у другій (title) - короткі заголовки для користувачів, у третій (description) - довільний опис, у четвертій (datatype) - тип даних, де string - це рядок тексту, integer - це ціле число, а decimal - десятковий дріб.

name title description datatype

name Назва міста Назва обласного центру, який розміщений на річці Дніпро. string

population Кількість населення Кількість населення, осіб за даними https://uk.wikipedia.org/. integer

area Площа міста Площа міста, кв. км за даними https://uk.wikipedia.org/. integer

populationDensity Густота населення Густота населення, осіб на кв. км. за даними https://uk.wikipedia.org/. decimal

Структура оприлюднюються, як окремий ресурс набору даних. Наприклад, набір даних «Перелік обласних центрів, що розміщені на річці Дніпро» включатиме ресурси Cities.csv та CitiesStructure.csv. Якщо розпорядники володіють навичками створення JSON-файлів, структуру набору даних можна передставити відповідно до рекомендацій W3C «Model for Tabular Data and Metadata on the Web» або Table Schema від Frictionless Data. Наприклад, CitiesStructure.json.

Довідник структур¶

Для того, щоб легко й просто створювати структури таблиць рекомендуємо використати Довідник структур. У ньому зібрані найпоширеніші «компоненти» наборів даних, наприклад, описи документів, фізичних та юридичних осіб, контактних даних, адрес, тощо. Назви колонок та правила їх заповнення відповідають міжнародним стандартам (основним словникам). Це допомагає створювати якісні відкриті дані, які легко завантажувати до баз даних, аналізувати, перетворювати у інші формати.

Довідник структур дає лише загальний опис основних характеристик. Тому, його структури можна уточнювати, доповнювати та поєднувати, залежно від потреб власного набору. Наприклад, створимо структуру для переліку тимчасових споруд міста Тростянець. У наборі необхідно зазначити номер споруди, власника, адресу, номер та дату видачі дозволу.

Колонка, що міститиме номери тимчасової споруди матиме назву identifier.

Для того, щоб вказати інформацію про власника (юридичну особу або ФОП) використаємо колонки legalName та legalIdentifier з таблиці LegalEntity.

Таблиця Address дає опис повної адреси: addressCountry, addressRegion, addressLocality, streetAddress.

Номер та дату видачі дозволу можна взяти з таблиці Document: permissionIdentifier, permissionIssued (частина permission додана, щоб колонка identifier не дублювалась).

Таким чином, структура матиме наступний вигляд.

name title description datatype

identifier Номер тимчасової споруди Номер тимчасової споруди, що присвоєний рішенням Виконавчого комітету Тростянецької міської ради. Наприклад, 123-центр. string

legalName Назва власника Назва юридичної особи, яка є власником тимчасової споруди, відповідно до Єдиного державного реєстру юридичних осіб, фізичних осіб-підприємців та громадських формувань (ЄДР). Наприклад, ТОВ «Годівничка». string

legalIdentifier Номер власника у ЄДР Номер юридичної особи, яка є власником тимчасової споруди, в Єдиному державному реєстрі юридичних осіб, фізичних осіб-підприємців та громадських формувань (ЄДР). Наприклад, 01234567. string

addressCountry Країна Назва країни, де розміщена тимчасова споруда. У колонці має бути зазначено Україна. string

addressRegion Область Назва області, де розміщена тимчасова споруда. У колонці має бути зазначено Сумська область. string

addressLocality Населений пункт Назва населеного пункту, де розміщена тимчасова споруда. У колонці має бути зазначено Тростянець string

addressStreetAddress Вулиця та номер будинку Вулиця та номер будинку розміщення тимчасової споруди. Наприклад, вул. Лесі Українки, 18-а. string

permissionIdentifier Номер дозволу Номер дозволу на розміщення тимчасової споруди відповідно до рішення Виконавчого комітету Тростянецької міської ради. Наприклад, 98/45. string

permissionIssued Дата видачі дозволу Дата, якою виданий дозвіл, у форматі ISO 8601 (рррр-мм-дд). Наприклад, 2018-07-06. date

Рекомендації для оприлюднення наборів даних¶

Рекомендації для оприлюднення набору даних «Перелік регуляторних актів»

Рекомендації щодо ведення Реєстру комунального майна та його оприлюднення в формі відкритих даних

Корисні посилання¶

Примітка

Обговорення цього розділу в Google Документі або на GitHub Issues.

Стандарти відкритих даних¶

Akoma Ntoso XML for parliamentary, legislative, judiciary documents (UN DESA)

Beneficial Ownership Data Standard (OpenOwnership)

General Transit Feed Specification (Google)

International open government data specifications (Popolo)

Fiscal Data Package (Open Knowledge International)

Open Contracting Data Standard (Open Contracting Partnership)

Стандарти розкриття інформації CoST (Construction Sector Transparency Initiative)

Популярні RDF словники¶

DCMI Metadata Terms (Dublin Core Metadata Initiative)

Data Catalog Vocabulary (DCAT) (W3C)

Friend of a Friend (FOAF) (Dan Brickley, Libby Miller)

ISA2 Core Core Vocabularies (ISA2)

Schema.org

vCard Ontology - for describing People and Organizations (W3C)

Linked Open Vocabularies (Pierre-Yves Vandenbussche, Bernard Vatant)

Інші корисні посилання¶

Creating and maintaining open standards (Porism)

From Development to Adoption: Lessons from Three Open Standards (OpenNorth)

Open Data Standards Directory (Center for Government Excellence at Johns Hopkins University)

Open Standards for Data (Open Data Institute)

W3C study of practices and tooling for Web data standardisation (W3C)

Standards Lab: an open data standard toolkit (Open Data Services)

Контакти¶

Якщо у Вас є пропозиції, зауваження, коментарі чи бачення щодо стандартів відкритих місцевих даних в Україні, то звертайтесь до координаторів проекту

ГО «Агенція журналістики даних»

Eлектронна пошта: texty.org.ua@gmail.com

Bеб-сайт: http://texty.org.ua/

Богдан Тишкевич (ГО «Агенція журналістики даних»)

Eлектронна пошта: b.tyshkevych@gmail.com

Facebook-профіль: https://www.facebook.com/b.tyshkevych