В блоге 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.iss.one/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.iss.one/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

В рубрике интересных инструментов по работе с данными Mercury [1], утилита по преобразованию тетрадок с Python в веб приложения и возможностью запуска их с определёнными параметрами.

Выглядит любопытно и есть живое демо [2], может быть полезно для разного рода способов публикации, например, студенческих работ или работ на хакатонах/конкурсах.

А может и другие применения есть.

Ссылки:
[1] https://github.com/mljar/mercury
[2] https://mercury-demo-1.herokuapp.com/

#datatools #notebooks #python #opensource

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

Собственно основные продукты по визуализации данных с открытым кодом готовые к быстрому корпоративному применению - это Metabase и Superset. Изменения в них весьма интересны.

Ссылки:
[1] https://www.metabase.com/blog/Metabase-0.42/index.html

# datatools #cloud #bi #metabase #opensource

Написал в рассылку о судьбе NoSQL в современном стеке данных [1]. Могу сказать что сейчас NoSQL и современные инструменты - это плохо сочетающиеся комбинации, как минимум в ряде задач. Это создает как проблемы, так и коммерческие возможности

Ссылки:
[1] https://begtin.substack.com/p/23

#datatools #mailing #nosql #mongodb

Минцифры анонсировали поддержку раскрытия исходного кода и открытую государственную лицензию для открытого кода публикуемого от лица Российской Федерации и выставили проект НПА на обсуждение [1]

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

В любом случае это тот документ который стоит прочитать и содержательно прокомментировать на regulation как минимум. Лично у меня есть вопросы к содержанию открытой лицензии, я о своих сомнениях и комментариях позже ещё напишу.

Ссылки:
[1] https://regulation.gov.ru/p/124850

#opensource #sourcecode #digital

Если университет проводит хакатоны на данных и не может опубликовать ни одного набора данных в открытом доступе, то это, конечно, то грош цена таким хакатонам. (c)

Кстати, в Испании 12 университетов публикуют свои данные на национальном портале открытых данных data.gob.es [1], а Университет Сарагосы опубликовал уже 341 набор данных.

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

Ссылки:
[1] https://datos.gob.es/es/catalogo?administration_level=U

#opendata #data

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

Вот, в Санкт-Петербурге есть портал бюджетных инициатив граждан [1]. В целом неплохой, современно выглядящий и с примерно 29 тысячами опубликованных инициатив. Когда я в целях архивации региональных сайтов бюджетов пытался его заархивировать то столкнулся с тем что у него нет веб-страниц в нормальном понимании. Вместо этого даннные отдаются через API по вполне легко находимой ссылке /api/v2/budget/initiatives [2] в коде страницы, в HTML коде сайта видно что что API передаётся параметр offset для перехода к следующей порции данных и limit для ограничений числа получаемых данных. В результате все инициативы можно выкачать простым перебором. Запросы к API возвращают в JSON формате общее число объектов в поле total_count и список объектов в поле objects в каждом ответе.

Особенность в том что это типовая задача. Не только на этом сайте и не только в этом API данные публикуются именно таким образом. В принципе вариации мышления и логики разработчиков очень невелики, всего 5-6 базовых сценария. Поэтому когда-то давно, 2 года назад я сделал ручную утилиту apibackuper [3] которую считаю личным вкладом в дело цифровой архивации;)

Утилита создана чтобы автоматизировать именно выгрузку данны из API, так чтобы всё можно было описать простыми параметрами в конфигурационном файле и запустить выгрузку. Не открою большого секрета в том что по объёму около 75% данных в Датакрафере [4] скачано именно с помощью apibackuper, фактически над этой утилитой просто возведена надстройка по автогенерации из API в процессе обнаружения данных.

В отличие от HTML парсеров утилита умеет проходить по всем страницам API, выгружать индивидуальные объекты при необходимости и складывать файлы в локальное хранилище или в S3 совместимое, а также экспортировать данные в JSONL формат. Для простоты все промежуточные файлы хранятся в ZIP контейнере и экспортируются по запросу. Всё описыается в .cfg файле

Пример который я озвучивал выше, с инициативами на портале инициативного бюджетирования СПб один из самых простых. Я специально его выложил онлайн как открытый код [4] хотя именно кода там мало, собственно .cfg файл необходимый для выполнения команд и набор этих команд прост.
- apibackuper estimage - оценить длительность и число запросов по выгрузке данных
- apibackuper run - запустить выгрузку данных
- apibackuper export data.jsonl - экспортировать данные в формат jsonl в файл data.jsonl
- apibackuper getfiles - выгрузить все изображения по ссылкам images.image.url

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

Ссылки:
[1] https://tvoybudget.spb.ru
[2] https://tvoybudget.spb.ru/api/v2/budget/initiatives
[3] https://github.com/ruarxive/apibackuper
[4] https://data.apicrafter.ru
[5] https://github.com/ruarxive/apibackuper-example-spbbudget
[6] https://github.com/ruarxive/apibackuper-example-spbbudget/blob/main/apibackuper.cfg

#opendata #datatools #opensource

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

Вот к примеру на Amazon началось давление по поводу того что через него закупают некоторые пищевые консерванты которые потом используют для суицидов [1], теперь компания использует алгоритмы для идентификации таких продуктов и предлагает тем кто их покупает воспользоваться альтернативами.

Можно ли говорить о том что это самоцензура и саморегулирование? В каких случае это допустимо и в каких нет?

Вопрос очень непростой потому что нет какого-то общечеловеческого каталога ценностей определяющих допустимые границы самоограничений для технологических компаний да и бизнеса в принципе. Как правило компании разрабатывают свои принципы самостоятельно, некоторые даже публикуют их в открытом доступе. К примеру, Google на странице "Беспрепятственный доступ к информации" [2], по сути, декларируют свою ценностную модель (частично декларируют на самом деле).

Но в отличие от вопросов научной этики или международных документов по защите прав человека - эти правила не универсальны.

Случай с Amazon - это тоже некая форма цензуры и таких будет только больше.

Ссылки:
[1] https://www.nytimes.com/2022/02/04/technology/amazon-suicide-poison-preservative.html
[2] https://www.google.com/intl/ru/search/howsearchworks/mission/open-web/

#policy #amazon #censorship

Напомню что 4-5 марта мы, Инфокультура и АУРД, организуем в Москве Open Data Day 2022 [1] он пройдет паралеллельно с сотнями других мероприятий по всему миру [2]. ODD начинался по инициативе Open Knowledge Foundation, большая часть мероприятий были простыми митапами и хакатонами, но несколько больших мероприятий были в формате конференций, например, неделя открытых данных в Нью-Йорке.

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

А когда-то мы проводили ODD в формате большой оффлайновой [не]конференции, но пандемия все сильно поменяла и в этом году почти всё будет онлайн с оффлайновым присутствием для спикера и тех кто захочет прийти во ФРИИ и послушать вживую.

Как принять участие/помочь/сделать доброе дело?
1. Сделать репост этого поста и рассказать другим о мероприятии.
2. Ещё есть время предложить спикеров для дискуссий/актуальные темы/проведения мастер классов. Главный критерий - знание предметной области и хорошая подача материала!
3. Подключиться к трансляции в сам День открытых данных, задавать вопросы и комментировать.
4. [При желании] прийти вживую в оффлайн и поговорить на актуальные темы в оффлайне. Чай/кофе/печеньки обеспечим;)

И, конечно, и это важно, что мероприятий в день открытых данных много. В России кроме мероприятия в Москве, анонсировано мероприятие в Кирове и надеюсь оно также будет интересным. Я ещё напишу о нём когда узнаю все подробности от организаторов.

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

ODD в Москве проводится при поддержке членов ассоциации АУРД и наших многолетних партнеров: Фонда Развития Интернет Инициатив, Интерфакса, Департамента медиаи коммуникации Высшей школы экономики и Центра цифровых прав, Роскомсвободы и многих других! Присоединяйтесь к списку партнеров и вступайте к нам в ассоциацию, конечно же;)

Вы также можете поддержать Инфокультуру по мере своих возможностей.

Ссылки:
[1] https://opendataday.ru/msk
[2] https://opendataday.org

#opendataday #odd #деньоткрытыхданных #opendata #events #data

В Италии выяснили что местные автостраховщики делают разные оценки процентной ставки в зависимости от того где Вы родились [1]. Для жителей Рима тариф будет одним, для жителей Неаполя другим. Всё это в статье Algorithmic Audit of Italian Car Insurance: Evidence of Unfairness in Access and Pricing от команды исследователей из 3-х итальянских университетов [2].

Дискриминация по национальности и по месту рождения одна из наиболее жёстких. Большинство из нас не имеет возможности выбрать расу, нацию и, особенно, место рождения.

В статье упоминается что эта практика существовала и раньше, а с применением автоматизированных алгоритмов она лишь стала изощрённее.

Ссылки:
[1] https://algorithmwatch.org/en/discriminating-insurance/
[2] https://www.dei.unipd.it/~silvello/papers/2021_aies2021.pdf

#privacy #ai #ethics

Существует совсем не нулевая вероятность что Google Analytics в Европейском союзе может быть запрещён или ограничен или Google сами перестанут предоставлять этот продукт европейским пользователям. Simpleanalytics [1] сделали обзор с упоминанием регуляторов Австрии и Голландии которые уже сформулировали свои претензии к этому продукту, в части нарушения GDPR.

Но тут важно помнить что Google просто самый большой из таких сервисов. Кто следующий и чем это закончится?


Ссылки:
[1] https://blog.simpleanalytics.com/will-google-analytics-be-banned-in-the-eu

#privacy #eu #google

В Forbes вышла моя колонка [1] по регулировании Метавселенных в России

Вначале я хотел добавить юмора, описать будущее чего-то вроде Росметаконтроля или Федеральной службы виртуального патриотизма или Министерства внутривиртуальных дел, но в какой-то момент юмор засбоил и получился серьёзный текст про усиление госконтроля.

Ссылки:
[1] https://www.forbes.ru/mneniya/455185-metavselennye-pod-kontrolem-pocemu-novye-tehnologii-v-rossii-vosprinimaut-kak-ugrozu

#privacy #vr #ar #metauniverses #reading

В блоге Open Ownership пишут о том что на декабрьской конференции UNDC (Управлении ООН по противодействии коррупции) приняли резолюцию [1] о развитии в сторону раскрытия сведений о конечных владельцах компаний. Обратите внимание что именно о конечных владельцах (beneficial owners), а не учредителям юр. лиц. Сведения об учредителях не везде, но много где доступны за деньги или бесплатно, а вот сведения о конечных владельцах публикуются лишь единицами стран.

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

Ссылки:
[1] https://www.unodc.org/unodc/en/corruption/COSP/session9-resolutions.html#Res.9-7

#opendata #un #anticorruption