Профессор Albert Sanchez-Graells в заметке Let’s get real about AI’s potential to end corruption in procurement [1] пишет о применении ИИ для выявления коррупции при госзакупках, ссылается на его же статью Procurement Corruption and Artificial Intelligence: Between the Potential of Enabling Data Architectures and the Constraints of Due Process Requirements [2] и обозначает ограничения у алгоритмов ИИ, в первую очередь ограничениях в данных, их качестве, доступности ретроспективных данных и их оцифровке и юридических сложностях.

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

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

Лично я практически прекратил расследования на базе госконтрактов, но не от того что нарушений или подозрений стало меньше, а от того что это журналистская деятельность, а уже выросла плеяда дата-журналистов научившихся работать с официальными источниками данных. Хотя, конечно, мало что от расследовательской журналистики в России сейчас остаётся.

Но есть важные особенности. Алгоритмические системы определения нарушений хорошо работают при грамотно спроектированной и работающей системе закупок, а российская система по 44-ФЗ и частично по 223-ФЗ не про качество работы, а про модель гарантированного наличия нарушений у госзаказчиков. Когда сама система выстроена так что, вне зависимости, честные ли госзаказчик и поставщик или коррумпированные, и так и так совершают одни и те же нарушения, то система анализа от формальных нарушений начинает давать сбои.

Об этом я могу говорить и писать ещё долго, в последние годы тема госфинансов меня интересует скорее с точки зрения сбора данных. И в качестве небольшой рекламы я добавлю что мы поддерживаем общественный проект Госрасходы (clearspending.ru) с данным госконтрактов, наша команда создавала и продолжает поддерживать проект Счетной палаты Госрасходы (spending.gov.ru), вернее я покинул СП, а команда продолжает его развивать.

А также у нас есть коммерческий проект APICrafter.ru где можно подключиться к данным системы госзакупок России через API и с коммерческой поддержкой. Это уже не только данные о госконтрактах, но также данные по поставщикам, заказчикам, планам закупок, закупкам, отчетам и всем остальным сведениям.

А в каталоге DataCrafter (data.apicrafter.ru) в том числе есть архивные данные контрактов, сведения из региональных систем закупок и сопутствующие данные.

Ссылки:
[1] https://www.open-contracting.org/2022/01/20/lets-get-real-about-ais-potential-to-end-corruption-in-procurement/
[2] https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3952665

#opendata #procurement #ai

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

Такие каталоги API есть во многих странах, кроме Франции и портала api.gouv.fr который я ранее упоминал, они также есть:
- В Индии API Setu apisetu.gov.in [1] - 1343 точки подключения всех уровней власти
- В Бразилии Catálogo de APIs Governamentais www.gov.br/conecta/catalogo [2] - более 40 точек подключения
- В США API Data api.data.gov [3] - сотни API по единому ключу
- В Великобритании api.gov.uk [4] более 70 API на едином портале
- В Австралии api.gov.au [5] доступно 16 API

И так далее. Это список именно национальных каталогов API, а ещё много отдельных API для доступа к конкретным данным.
Предоставление API это взаимодействие властей с цифровым бизнесом, например, перепись США доступна через API и многие сервисы обогащения данных в США используют его для получения данных в реальном времени.

Ссылки:
[1] https://apisetu.gov.in/
[2] https://www.gov.br/conecta/catalogo/
[3] https://api.data.gov/
[4] https://www.api.gov.uk
[5] https://api.gov.au

#opendata #openapi #api #government

В России обсуждали кейс директора XSolla уволившего кучу людей по итогам автоматизированного анализа, а в США и Европе во всю обсуждают риски появления ИИ боссов (AI Bosses) на примере Amazon'а и других компаний. Когда за твоим рабочим процессом следит ИИ и "всё докладывает кому надо". В Tribune статья именно об этом [1] и в России такие кейсы тоже есть.

Как говорится все ждали большого брата от гос-ва, а на деле первыми внедряют их работодатели. Чем более оцифруема твоя работа, тем более вероятно что у тебя будет AI Boss.

Ссылки:
[1] https://tribunemag.co.uk/2022/01/amazon-algorithm-human-resource-management-tech-worker-surveillance

#ai #aiethics

Стартап Canvas [1] делает возможность превращать работу с данными из технической в визуальную задачу, сделав удобный интерфейс по визуализации и работы с данными в СУБД через веб интерфейс.

Сейчас поддерживают Redshift и Snowflake как облачные СУБД и Postgres.

Работа с таблицами очень напоминает Google Spreadsheets или Airtable, но, при этом, визуально сформированные таблицы можно увидеть и в виде SQL запросов.

Сами данные они не хранят, только дают интерфейс над ними.

Берут по $100 в месяц за редактора данных в месяц.

Подняли инвестиций в $4.2M и думаю что у них хорошая перспектива быть купленными одним из крупных облачных провайдеров, потому что выглядит как очень хорошее дополнение к облачным СУБД.

Ссылки:
[1] https://canvasapp.com

#startups #dataviz #spreadsheets

Metadata Guardian [1] [2] свежая утилита для Python, делающая практически то же что и наш движок по идентификации полей и даже теми же самыми способами, только с акцентом на PII (Personally Identifiable Information). Поставляется в виде утилиты командной строки, поддерживает Snowflake, AWS, GCP, MySQL и файлы Avro, Arrow, ORC и Parquet.

Все правила оформлены прям как и у меня в виде YAML файлов [3] с регулярными выражениями. Правила также разделяются на те которые применяются к названиям колонок и те которые применяются

В общем это хорошая утилита, разница между ней и тем что делаю я тоже есть:
1. Правил нашем классификаторе кратно больше. В metadata guardian их около 20, в нашем боте их уже более 150.
2. В нашем классификаторе правила и идентификаторы разделены. Много разных правил могут указывать на один и тот же идентификатор. Например, отдельное правило для почтовых индексов и их написания на английском языке и общее для всех, такое как "postindex" или "postcode" и отдельно для написания на русском "почтовый_индекс" или "pochtoviy_indeks". Это позволяет разделять правила по контексту языка.
3. Это особенность нашего движка, контекстное и языковое разделение правил. Можно задать фильтр и подгрузить любые правила, а не только преднастроенные.
4. В Metadata Guardian используют регулярные выражения, у нас вместо них три типа правил: прямое сравнение, внешние функции и конечные автоматы на PyParsing через которые также можно запускать регулярные выражения.
5. У нас в движке предусмотрена доп. валидация данных после определения. Для этого можно указать внешнюю функцию.
6. Пока наш движок работает с базовым объектом как словарь для Python (python dict), а в качестве входного потока принимает СУБД MongoDB, JSON lines и CSV. А Metadata Guardian нацелен на базы и форматы для облачного применения и для data science.

Причины отличий в том что MG создан для идентификации PII, а наш Data Classifier для задач более общих и, более того, как основа для оценки качества данных и их обогащений. Напомню что наш движок можно потестить вот тут @DataClassifierBot как телеграм бот и скоро будет API.

Тем не менее на Metadata Guardian стоит посмотреть и попробовать, потому что направление движения правильное. К тому же он хоть и меньше может, но более production ready и стыкуется с СУБД.

Ссылки:
[1] https://medium.com/@florian.valeye/metadata-guardian-protect-your-data-by-searching-its-metadata-fe479c24f1b1
[2] https://github.com/fvaleye/metadata-guardian
[3] https://github.com/fvaleye/metadata-guardian/blob/main/python/metadata_guardian/rules/pii_rules.yaml

#metadata #data #datatools #privacy #opensource

Для тех кто ищет больших данных и побольше, Academic Torrents [1] раздает 83ТБ открытых данных, в основном для научного применения - в data science и не только. Например, там есть свежий слепок Wikidata в 109ГБ и множество климатических датасетов, датасетов по распознаванию изображений и многого другого.

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

Ссылки:
[1] https://academictorrents.com

#opendata #datascience #openacces

О данных, веб-сайтах и том как с ними работают. Я рассказывал что веду архивацию госсайтов, в том числе самописными инструментами, которые архивируют данные из открытых API которые веб-краулеры не поддерживают. Такая утилита есть APIBackuper для сфокусированной архивации и ещё для 5 популярных CMS у которых такое общедоступное API есть по умолчанию. Некоторые владельцы сайтов это API по умолчанию сразу отключают, но у большинства оно доступно и через него можно скачивать весь тот же контент что есть на сайте, только быстрее, удобнее и автоматически.

Но бывают и вопиющие случаи. Не буду называть конкретный орган власти/госорганизацию, но у них на веб-сайт предусмотрена подписка на рассылки СМИ. Подписка реализована встроенными средствами CMS и, барабанная дробь, открытые интерфейсы этой CMS отдают данные о всех подписчиках. К счастью, их там не так много, чуть более 200 человек и данные там хоть и персональные, но не самые чувствительные, только email+ФИО+факт подписки, но картина показательная о том как организована работа с данными в госорганах.

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

Таких случаев много, много случаев публикации чувствительных данных, просто доступа к данным и тд. Госзаказчики чаще всего просто не знают на каких инструментах создана их инфраструктура и поэтому так много недокументированных API у госсайтов и государственных информационных систем. Это вопрос не только культуры работы с данными, но и обычной технологической культуры и полнейшее отсутствие централизованного аудита и мониторинга государственного технологического сектора.

#tech #government #governmentit #privacy #leaks

Нужно ли создание в России api.gov.ru ?
anonymous poll

Конечно! Пусть Минцифра его создаст, наконец – 85
👍👍👍👍👍👍👍 73%

Нужно, но на госорганы надежды нет, скорее как частный проект – 17
👍 15%

Мне лень отвечать, я просто хочу посмотреть ответы других – 5
▫️ 4%

Не нужно, пусть госорганы сами задокументируют API к своим системами и на этих системах разместят документацию – 4
▫️ 3%

Никому не нужно, некому пользоваться – 3
▫️ 3%

Что? Где? Что такое API? Ничего не понимаю – 3
▫️ 3%

👥 117 people voted so far.

Кстати по итогам моего прошлого опроса/голосования о том о чём я пишу, большинство проголосовавших, как оказалось, заинтересовано в материалах про приватности. Постараюсь добавлять об этом больше публикаций. Хотя мои лично самые любимые темы - это технологии работы с данными и доступность/открытых данных. А вот, как ни странно, международные практики мало кому интересны. Может быть, правда, это искажение инструмента голосования где нельзя проголосовать за несколько вариантов.

#votes #polls

Про формат Parquet я многократно писал и давал ссылки, а вот сравнение от Databricks его же с CSV [1]. Если кратко то CSV проигрывает Parquet по всем статьям, сравнение проводилось в экосистеме Amazon AWS:
- экономия при хранении данных на 87%
- в 34 раза быстрее отрабатываются запросы
- на 99% меньше данных надо сканировать
- финансовая экономия до 99.7%

Недостаток Parquet'а для человекочитаемости компенсируется появлением инструментов для GUI и командной строки которые эту проблему снимают. Она, вообще не так значима как кажется.

Лично я считаю что статистику, многие другие данные с временными рядами и иные большие наборы данных которые сразу берут в работу аналитики, можно и нужно публиковать сразу в Parquet. Это даёт не только экономию в хранении, но и сильно облегчает работу аналитиков. Тем более что многие инструменты вроде Power BI и Tableau их его поддерживают.

Ссылки:
[1] https://databricks.com/glossary/what-is-parquet

#fileformats #data #parquet

У Бэна Стэнсила, основателя и руководителя аналитиками в стартапе Mode, замечательная заметка в его рассылке, с рефлексией о том как компании сейчас потребляют данные и как это возможно в будущем [1]. Основной посыл заметки в том что "фронтэнд разваливается" и приводит в пример десятки разных способов донесения данных через дашборды, тетрадки, сервисы визуализации, разные виды, формы и ориентации BI продукты и так далее. Идея в том что можно ли сделать открытый продукт к которому разные формы потребления данных можно было бы добавлять плагинами? По аналогии с Wordpress'ом и другими аналогичными экосистемными продуктами.

Идея интересная, созвучная многим, включая меня. Хотя я пока и не чувствую что разваливается именно фронтэнд и конечное потребление данных, скорее современный стек данных превращается в набор для сборки, а для кого-то и в паззл где своими силами ты делаешь только то что не можешь собрать из кубиков. Или делаешь то что хочешь продать/продавать. Отсюда и растущий запрос не просто на дата-инженеров, а на платформенных дата-инженеров, а может уже пора ввести понятие data-constructor ?

Когда я сейчас проектирую стартап и продукт по анализу и/или/или не обработки данных, я, как и многие, не мыслю категориями разработать его с нуля. Я смотрю на open source и облачные продукты и понимаю что: вот тут для ELT можно взять вот это, вот тут для BI вот это, вот тут для хранилища вот это, вот тут для сбора данных в реальном времени вот это, для пользовательского интерфейса вот это и так далее.

А рассылка Бэна весьма популярна в среде аналитиков и дата инженеров, всячески его рекомендую.

Ссылки:
[1] https://benn.substack.com/p/business-in-the-back-party-in-the-front

#data #thoughts #reading #dataengineering #bi

Я много раз писал про такое явление как executable papers [1] [2] [3] о том как меняется создание научных статей в сторону написания тетрадок с кодом интегрированных или сопровождающих научный текст.

К этому хочу дополнить ещё один похожий и важный проект Executable books (исполняемые книги). Создание интерактивных книг/справочников/руководств по общему стандарту и с сохранением структуры именно книги. Довольно большое сообщество в Github - Executable book [4] вот уже несколько лет как создаёт Jupyter Book [5], специальный движок позволяющий писать руководства используя тетрадки Jupyter Notebook и предоставляя возможность создавать контент пригодный к публикации и с экспортом в HTML, PDF и другие форматы.

У авторов собрана большая галерея примеров [6], больше всего примеров с описанием open source пакетов по работе с данными. Авторы же даже создали своё расширение для языка Markdown под названием MyST - Markedly Structured Text для более удобного написания технической документации [7].

Executable books и их продукты происходят из научной среды, с командой из 3-х университетов и большим сообществом и поддержкой Alfred P.Sloan Foundation.

На мой взгляд у них есть явно недооценённый коммерческий потенциал. Удобных онлайн сервисов по написанию технической документации и руководств не так много. Есть Readme.io, Gitbook и ещё несколько, со своими достоинствами и недостатками, но не почти не включают часть связанную с "исполнимостью текста".


Ссылки:
[1] https://t.me/begtin/2147
[2] https://t.me/begtin/2607
[3] https://t.me/begtin/3386
[4] https://github.com/executablebooks
[5] https://jupyterbook.org
[6] https://executablebooks.org/en/latest/gallery.html
[7] https://myst-parser.readthedocs.io

#executablebooks #executablepapers #opensource #data #datadocumentations #datatools

В блоге SeattleDataGuy (консультант по дата платформам Ben Rogojan) две публикации про The Baseline Data Stack [1] [2] о том что нет универсального стека ьтехнологий для данных и есть много разных вариантов сборки. Можно сделать полностью на открытом коде, можно на основе ведущих продуктов и можно сделать только на базе облачных продуктов.
Реальность, как правило, где-то посередине, достаточно вспомнить Gitlab у которых смешаны open source Airbyte и dbt, коммерческий Fivetran, хранилище в Snowflake и собственноручно написанный Meltano, уже выделенный в отдельную компанию/стартап/продукт.

Основная мысль в том что под разные задачи - разные решения и это, конечно, так оно и есть. И я также вижу тренд как вначале появляется/давно существует коммерческий продукт, потом кто-то делает open source продукт который воспроизводит ключевые/значимые возможности этого коммерческого продукта и далее _очень быстро_ получают венчурное финансирование на создание облачного продукта на базе этого open source. Раньше такое тоже было, но сейчас всё ускоряется.

Меня, кстати, поражает насколько медленно развиваются Яндекс.Облако и облачные сервисы VK. Фактически если ты работаешь с современным стеком технологий то зарубежные платформы почти безальтернативны. Почти, потому что всегда есть "танцы с бубном", но в целом это так. Вообще в области работы с данными "импортозамещения" очень мало, только замена на open source.


Ссылки:
[1] https://medium.com/coriers/the-baseline-data-stack-going-beyond-the-modern-data-stack-part-1-9791b7d49e85
[2] https://medium.com/coriers/the-baseline-data-stack-the-different-types-of-data-stacks-part-2-c6a826d8f2f1

#data #readings #thoughts

В рубрике полезных наборов данных Unicode Common Locale Data Repository [1] [2], 18 летний проект по систематизации и публикации базы языковых данных включая: переводы названий языков, переводы названий стран, шаблоны для форматирования валют, дат, правила сортировки и ещё много всего.

Большинство из нас с этими данными сталкивается неявно, поскольку CLDR используется в операционных системах и во многих других продуктов где необходимо учитывать местные языковые и иные культурные особенности. Для работы с CLDR есть инструменты для всех наиболее популярных языков программирования, например, для Javscript [3] или Python [4] и многих других.

Традиционно CLDR распространялся в XML формате, но есть и версия в формате JSON [5], одна её сборка в сжатом виде - это около 59МБ, а в распакованном виде около 525MB.

Этот набор данных является скорее большим справочником, в нём нет временных рядов или больших данных для анализа, однако он полезен всем кто занимается "склейкой" данных из разных источников и задачами локализации интерфейсов/инструментов/алгоритмов распознавания шаблонов написания текстов.

Ссылки:
[1] https://ru.wikipedia.org/wiki/Common_Locale_Data_Repository
[2] https://cldr.unicode.org
[3] https://github.com/cldr-tools/cldr-tools
[4] https://github.com/carlospalol/money
[5] https://github.com/unicode-org/cldr-json

#datasets #opendata #dictionaries #data #unicode

Тем временем в РБК статья посвящённая теме нормативной закрытости ведомств [1] со ссылкой на мою заметку про рост числа постановлений и распоряжений Правительства РФ [2].

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

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

В целом у нас накопилась большая аналитическая база по российским НПА. Оно не особо монетизируемо в чистом виде, хотя и есть в DataCrafter'е в разных формах, но много интересных цифр подсчитать можно.

Одно жаль, можно сколь угодно диагностировать болезнь, а вот её лечение в текущей ситуации куда как менее очевидно. Мы все в последнее время превращаемся в "диагностов", без возможности исправления ситуации.

Ссылки:
[1] https://www.rbc.ru/politics/07/02/2022/61fbe8909a794784a2243429
[2] https://t.me/begtin/3511

#russia #npa #laws #legal #statistics

Итого проголосовало 104 человека из которых большинство, 71% за то что нужен api.gov.ru и что хорошо бы Минцифре РФ его создать (наконец) и около 16% за то что только если в рамках частной инициативы.

По моему запрос вполне очевиден.

#opendata #openapi #government

В нашем движке по распознаванию типов данных внутри баз данных, таблиц и файлов теперь 195 правил охватывающих геоданные, данные об организациях, о людях, о медицинских препаратах, финансах, госфинансах, справочниках и классификаторах и так далее. Прежде чем запускать бета-тестирование API, я выложил сам движок как открытый код и он доступен на Github как metacrafter [1].

Главные достоинства по сравнению с аналогичными инструментами:
* легко расширяется новыми правилами, правила описываются в файлах в YAML формате
* быстро работает без дополнительных расширений. Вместо регулярных выражений используются конечные автоматы PyParsing
* обычно такие инструменты работают с колоночными данными, а тут наоборот поддержка любых построчных.
* поддерживает MongoDB, любую СУБД через SQL Alchemy, файлы в форматах CSV, JSON, JSON lines, BSON, Parquet
* прицел именно на распознавание идентфикаторов, а не просто идентификацию PII.

Почему открытый код? Потому что он не единственный такой продукт и именно эта его часть с написанием правил может быть полезна многим. А я лично искренне надеюсь что у него будут пользователи которые помогут с его тестированием и доработкой. Главную коммерческую стоимость здесь имеет не код, а знание как устроены данные и сейчас в открытой версии выложено 25 правил, охватывающие базовые виды данных, а также используется 312 правил-шаблонов определения дат и времени.

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

Обратите внимение что в среди правил есть правила идентификации персональной информации (PII). Сейчас нет команды поиска только и именно PII, но это несложно добавить.

Плюс в него же встроен веб-сервер для запуска движка распознавания в серверном варианте, с API.

Для того чтобы правила и выявляемые идентификаторы были систематизированы, в отдельном репозитории metacrafter-registry [2] доступны данные по всем идентифицируемым объектам. По списку идентификаторов [3] в нём можно понять, то какие правила существуют и какие данные идентифицируются. Этот реестр будет расширяться, дополняться и пополняться.

Наше коммерческое API использует этот же движок, включает все 195 правил идентификации объектов и скоро будет доступно для бета-тестирования.

Ссылки:
[1] https://github.com/apicrafter/metacrafter
[2] https://github.com/apicrafter/metacrafter-registry
[3] https://github.com/apicrafter/metacrafter-registry/blob/main/data/entities.yaml

#metadata #data #opensource

Я, кстати, не писал про весьма любопытный стартап Hyperquery который в декабре вошёл в публичную бету [1] и теперь доступен [2]. Авторы продают инструмент сочетающий SQL запросы и тетрадки (notebooks) в стиле Notion. Фактически - это Notion для команд аналитиков и дата саентистов.

Идея SQL тетрадок не новая, есть Franchise [3] в облаке и как открытый код, есть Query.me [4], есть Count [5].

Достоинство Hyperquery именно в Notion подобном интерфейсе, в том что команды привыкшие к такому интерфейсу заценят его удобство.
Интересное сочетание, на мой взгляд имеет хорошую перспективу если к SQL запросам добавят расширяемую коллекцию способов визуализации.

Ссылки:
[1] https://medium.com/df-foundation/introducing-hyperquerys-public-beta-b871252e99e9
[2] https://www.hyperquery.ai
[3] https://franchise.cloud/
[4] https://query.me/
[5] https://count.co/

#startups #datatools #querytools #notebooks

Humanitarian Data Exchange (HDX) опубликовали доклад The State of Open Humanitarian Data 2022 [1] с подробностями и цифрами их проекта Data Grids по сбору структурированных данных по странам где происходят гуманитарные кризисы. В основном это африканские и азиатские страны, а из постсоветских стран там только Украина упомянута.

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

Для тех кто не знает, HDX [3] - это проект каталога данных Управления по координации гуманитарных вопросов ООН. Там собрано более 18 тысяч наборов данных по гуманитарным кризисам. В отличие от многих других порталов данных, в проекте сильный фокус на данные в привязке к странам и территориям, визуализации и систематизации данных.

Год назад их представитель выступал у нас на Дне открытых данных в Москве и интересно рассказывал что они делают.

Не могу не напомнить что у ООН много проектов на данных и очень много открытых данных в повестке, подборку порталов открытых данных их управлений я приводил ранее на канале [4]

Ссылки:
[1] https://data.humdata.org/dataset/2048a947-5714-4220-905b-e662cbcd14c8/resource/56bb190e-fd43-4573-898c-76aaedb7e10a/download/state-of-open-humanitarian-data-2022.pdf
[2] https://data.humdata.org/dashboards/overview-of-data-grids
[3] https://data.humdata.org
[4] https://t.me/begtin/3310

#opendata #un #hdx #unocha

Я рассказывал про то что у очень многих госорганов/госсайтов/информационных систем есть документированные, плоходокументированные и совсем недокументированное API. Все вместе это частично, объект интереса в задачах сбора и извлечения данных, частично вопрос информационной безопасности и, в значительной степени, вопрос технической квалификации.

Я приведу несколько примеров API на порталах органов власти и их информационных систем.

Росрыболовство
Официальный сайт органа власти (fish.gov.ru) создан на бесплатной CMS Wordpess. Сайт установлен без доп. настроек и с настройками по умолчанию, поэтому из сайта доступно техническое API Wordpress'а [1] через которое можно автоматически выгрузить все их новости, веб-страницы и тд. Похоже на неотключенную возможность у CMS.

Автоматизированная система транспортного комплекса (АСУ ТК)
Сайт АСУ ТК (asutk.ru) создан на базе CMS Sharepoint, по умолчанию API к спискам на сайте и к веб-страницам доступно по технической ссылке [2]. Не видно что API используется где-то на сайте, скорее не отключенная возможность CMS.

Портал уполномоченного органа в сфере электронной подписи
Сайт Минцифры России со сведениями о УЦ и УП (e-trust.gosuslugi.ru) предоставляет недокументированное API, например, для получения списка аккредитованных УЦ [3]. Похоже на API сделанное разработчиками для скорости отображения данных на веб-страницах которые подгружают данные через Ajax запросы.

Цифровой мастер-план города Байкальска
Не совсем государственный, скорее государством заказанный сайт (план.байкальск.рф) отображает данные с помощью Graphql API [4]. Похоже это основной принцип работы сайты через отображение данных через запросы к бэкэнду Graphql.

Я привёл 4 примера из нескольких сотен, именно недокументированных API. Как такие API появляются? Почему часто владельцы данных сами о них не знают?

Основные причины таковы:
1. Неотъемлимая часть CMS или веб-фреймворка. CMS вроде Sharepoint'а или Wordpress предоставляют API по умолчанию, позволяющее скачивать весь общедоступный контент автоматизировано. Аналогично делают некоторые компоненты для существующих CMS.
2. Разработчикам так удобнее. Разработчики привыкшие делать внутренние или закрытые веб-приложения часто переносят эти практики для приложений в открытом доступе и отображают данные через Ajax запросы.
3. Внутреннее API не для всех. Значительно реже, API делается для себя/каких-то команд которые работают с данными, но не документируется, не описывается и тд. Часто можно найти в документах техзаданий к госконтрактам.

Есть порталы где API декоративно и запросы автоматически блокируются после 5-10 обращений в минуту. Есть порталы где API - это основной способ предоставлять информацию. В одном только портале электронного бюджета более 100 API к данным.

Ссылки:
[1] https://fish.gov.ru/wp-json/
[2] https://asutk.ru/_api/Web/
[3] https://e-trust.gosuslugi.ru/app/scc/portal/api/v1/portal/ca/list
[4] https://api-dmp-baykalsk.chg.one/v1/graphql

#opendata #openapi #api #government

Полный слепок всех данных из портала Data.gov.ru выложен на Хаб открытых данных [1]. Это архив в 13ГБ, после распаковки 29 ГБ.

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

Ссылки:
[1] https://hubofdata.ru/dataset/datagovru-20220202

#opendata #data #dataports #ruarxive