Мне много что есть сказать по поводу отзыва компанией GlobalSign сертификатов у российских доменов и недавнего изменения политики Let's Encrypt в части соблюдения санкций США (теперь соблюдают, если вкратце и не будут больше выдавать их санкционным компаниям).

Последствия этого будут для российских пользователей неприятными и пойдут эти действия скорее в копилку доводов тех кто говорит про суверенный интернет в РФ и как бы все не обернулось попытками усиления внедрения отечественных браузеров, сертификатов НУЦ и так далее. В чем, разумеется, ничего хорошего нет и быть не может, российский цифровой рынок не настолько большой чтобы усиливать собственную изоляцию, и множество продуктов поломается из-за невозможности проверки сертификатов так же как и риски взломов усилятся.

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

Сертификаты для сайтов и других целей в мире выдаются не кем попало, а так называемыми Certificate Authority и крупнейшие вендоры браузеров, операционных систем и устройств проводят их верификацию/аттестацию и включают в списки признаваемых ими. Вот тут можно посмотреть примеры таких списков. Наиболее значимые - это списки Apple, Microsoft, Google для их операционных систем, но, в принципе, все они важны.

Наиболее крупный список Common CA Database ведет Linux Foundation в партнерстве с Microsoft, Mozilla, Cisco и Google. Он включает 10122 сертификата, выпущенных 186 корневыми CA из примерно 60 стран. Эти страны включают, практически все страны ЕС, многие азиатские и даже некоторые африканские страны.

А каких стран там нет? Из значимых там нет России, Беларуси и всех стран Центральной Азии и многих других.

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

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

#opendata #certificates #russia #datasets #data

Для тех кто интересуется разного рода международной таксономией, новая версия internacia-db управляемого справочника по странам и международным блокам в виде открытого репозитория приведенного к формату дата-продукта.

В новом релизе 1.5.0 по совокупности изменений:
- число стран/территорий расширено до 256 и теперь включает записи по непризнанным территориям вроде Приднестровья, Абхазии и тд.
- добавлены новые международные блоки которых теперь 1070, типы международных блоков по прежнему: экономические блоки, международные соглашения, межгосударственные организации и фонды, экономические группы стран (по классификация Всемирного банка и другим) и так далее. Всего более 86 типов международных группировок стран
- добавлена лицензия для данных которая CC-BY и provenance (происхождение) по отдельным полям данных в карточках записей.
- многие карточки включают обновленные метаданные: описания, официальные названия, сведения о странах участниках, статус участия и так далее.

Все данные опубликованы в форматах Parquet, YAML, JSON lines и в виде базы DuckDB.

Для чего нужна эта база?
1. Для обогащения данных при работе с любыми данными имеющими геопривязку к стране или международному блоку
2. Для задач визуализации данных, например, статистики в привязке к странам и международным блокам
3. Для сравнения стран и международных блоков

И тому подобных задач. Этот дата-продукт можно сравнить с pycountry пакетом для Python со справочником стран, но он больше, шире, детальнее и включает данные по международным блокам.


#opendata #dataproducts #data

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

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

Быстрое API на основе файла с данными

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

Очень простая и быстрая команда

undatum api run data.jsonl

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

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

Быстрое документирование дата файлов

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

В самом простом виде выглядит как

undatum ai doc data.csv

выводит на экран итоговый Markdown текст

Более продвинутый

undatum ai doc —blocks general,schema,quality,examples,codebook —format json —language Russian data.csv

Создает документацию в формате JSON с Markdown блоками перечисленными списком и на русском языке.

Загрузка данных в NoSQL/SQL базы данных

Команда ingest изначально делалась для продвинутого импорта данных в MongoDB и Elasticsearch и идея в том чтобы на вход получить файл и строку подключения в базе данных после чего загрузить содержимое в выбранную таблицу/коллекцию/индекс

Пример команды

undatum ingest data.jsonl https://elasticsearch:9200 myindex myindex --dbtype elasticsearch --api-key YOUR_API_KEY --doc-id id

В чем важная особенность undatum от специализированных инструментов которые умеют это же? В поддержке любых сжатых файлов .xz, .gz, .zst, .lz4, .bz2 и так далее. Потому что хранить данные в чистом NDJSON или CSV - это прямо таки очень неэффективно. Особенно когда это много слепков коллекции из MongoDB или индекса Elasticsearch.

#opensource #datatools #data

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

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

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

#data #thoughts

Множество обновлений в internacia-db дата-продукте с метаданными по всем странам и страновым блокам таким как ЕС, СНГ, НАТО, ЕАЭС, структурам ООН и тысячи других.
Я как-то рассказывал что изучение межгосударственных образований - это мое очень давнее и немного странное хобби, у которого есть практическое применение, в случаях когда надо делать разметку по странам и в случаях когда надо иметь возможность делать аналитику по международным блокам - где они пересекаются, как можно их сравнить и так далее.

В последних нескольких релизах добавлено:
- несколько новых международных блоков таких как Pax Silica, WAICO, WANO, ARABSAT, CDRI, BLASMBL
- обновлены метаданные множества блоков, нескольких сотен. Что-то вручную, что-то с помощью LLM. Много добавлений provenance, подтверждений источников сведений.
- добавлен механизм контроля качества карточек блоков и стран и исправлены многие пробелы в карточках, например, отсутствия перечней стран участников и нормализованные названия стран. Механизм правил такой же как и в реестре Dateno, в виде отдельной команды анализа по набору YAML правил и выдачей результата в виде перечня ошибок в структурированном виде.
- и множество мелких изменений, подробности в CHANGELOG файле

Напомню, что результатом является дата продукт и все в итоге собирается в файлы данных в форматах Parquet, JSONL, YAML и базу данных DuckDB. А сам проект является частью поисковика по датасетам Dateno и используется там для разметки датасетов по странам.

#opendata #datasets #data #opensource

Ещё немного рефлексии про разное сугубо технологическое:
1. Размышляю над тем как надо публиковать датасеты в современном мире и склоняюсь к тому что надо разделять более явным образом понятия набор данных (датасет) и дата продукт. Набор данных становится дата продуктом по мере зрелости его документации, наличия владельца и понятной аудитории/пользователей. Поэтому, к примеру, API Всемирного банка дата продукт, а набор данных на типовом портале открытых данных нет. Дата продукты ближе к корпоративному и профессиональному потреблению данных, наборы данных, в первую очередь открытых данных, всё ещё существуют в режиме "будьте довольны что хоть так это доступно, могли бы вообще ничего не публиковать". Когда я проектировал и делал internacia-db то держал в голове модель именно как курируемого дата продукта. Поэтому там и экспорт в разные форматы, и документация по использованию в разных языках разработки и инструментах и так далее. Что я, действительно, хочу сделать так это попытаться привести этот опыт в систематизированный вид, возможно в спецификацию, reusable datasets или reusable data products.
2. Продолжая размышления про ИИ инструменты для разработки, видно как они быстро развиваются, особенно Cursor с его построением архитектурных холстов (canvas) и пока главное отставание китайских моделей скорее инструментальное чем на уровне возможностей LLM. Когда, к примеру, тот же ZCode от z.ai сможет делать подобное то им можно будет пользоваться уже как приоритетным инструментом.
3. Как я уже описывал ранее, у меня сохраняется и углубляется мнение что вся экосистема инструментов открытых данных сильно отстает от технологий работы с данными и это отставание усиливается. Видно как сообщество, и профильные международные НКОшки, и активисты разделяются. Те кто был про технологии уходят в них и отходят от общественного, те кто про технологии был меньше уходят в темы этики ИИ, европейского цифрового суверенитета и всего подобного. У сообщества открытых данных кризис схожий с кризисом сообществ открытого кода. Все производимое общедоступное идет на корм ИИ агентам и для многих это существенный кризис миросознания.
4. А вот для тех кто делает что-то для общественного интереса всё больше возможностей для создания проектов в режиме человека-оркестра (one-man-projects). К примеру я смотрю на проект "Как голосовали депутаты?" про голосование российских депутатов по отобранным автором(-ами) чувствительным законопроектам и понимаю что почти наверняка всё это сделано одним человеком за 2-3 вечера и с помощью одного из ИИ ассистентов. Это стало реально просто, на такие проекты не нужны иностранные гранты какие-либо финансовые ресурсы, я довольно много их уже видел по европейским странам, по выборам в Армении и тд. Всё что для подобных проектов нужно - это: четкое видение результата, базовые технические навыки и, желательно, аналоги на которые можно ориентироваться. И данные, конечно. Поэтому многие общественные проекты могут/могли бы появляться как на дрожжах и не появляются, не потому что нет технической возможности, а по другим, иным причинам.

#opendata #opensource #ai #thoughts #data #dataproducts

Новая версия dataportals-registry реестра всех существующих в мире каталогов открытых данных, используемого внутри поисковика Dateno для понимания того где брать датасеты для индексации.

В новой версии 1.9.0 нет новых каталогов данных, приоритет изменений был на исправлении ошибок и удалении дубликатов:
- было исправлено 240 ошибок негармонизированных справочников, теперь все приведены к унифицированному формату
- было удалено 34 дубликата
- исправлены все текущие критичные и значимые ошибки качества данных
- добавлены новые правила контроля качества данных (все выявленные ими ошибки исправлены)

Итого в реестре сейчас 14 436 каталогов данных включающих порталы открытых данных, порталы геоданных, статистические порталы, порталы микроданных, порталы данных для машинного обучения, поисковые системы по данным и так далее.

Все данные реестра доступны в форматах Parquet, NDJSON и в виде базы DuckDB.

#opendata #datasets #datacatalogs #data

Еще немного рефлексии про работу с референсными данными и применении ИИ ассистентов для создания и сопровождения контролируемых дата продуктов/датасетов. О чем-то из этого я уже писал с чуть другими акцентами, что-то новые мысли:
1. ИИ ассистенты вполне справляются с наполнением управляемых баз данных до определенного размера когда записи хранятся в текстовом виде, оптимально, YAML файлах. По моему опыту ведения уже нескольких таких репозиториев, это вполне работающая модель с оговоркой относительно редких обновлений таких дата продуктов. Для справочных данных такое работает, для часто изменяемых скорее нет чем да.
2. Важная любого создания данных с помощью ИИ агентов - это многоуровневые data quality gates (не могу подобрать адекватного русскоязычного термина). Это не только проверка ответов от LLM через валидатор типа pydantic, но и набор правил для проверки данных перед их сборкой. LLM не последних версий чаще косячат при заполнении текстовых файлов даже по шаблону и наиболее частые косяки массовом редактировании.
3. Как и в работе с исходным кодом важны правила что делать, что не делать, заранее описанная архитектура.
4. Регулярные итерации промптов в стиле "Проанализируй содержимое репозитория и предложи расширения схемы данных и дополнительные записи, а также как его улучшить" помогают поймать пропуски в данных и проектировании, но на 100% на них полагаться нельзя поскольку часто ИИ агенты предлагают не те направления развития которые нужны.
5. Например, базу internacia-db я сводил из вручную составленных таблиц, слепков из Wikidata и API Worldbank, нескольких других реестров и тд и лишь с примерным видением итогового результата в части содержания. Итоговый результат появился после десятка итераций схемы и расширения содержания. Только архитектура де-факто не менялась.
6. ИИ агенты склонны к максимальной локализации, не задавая вопросов о широком контексте. Например, для internacia-db я изначально разделял репозитории с данными, с Python SDK, и с REST API. Но при любых попытках спросить ИИ ассистенты как улучшить репозиторий с данными он всегда предлагал добавить SDK прямо в него, пока в AGENTS.md не зафиксировать явно что это архитектурное решение вынесено в отдельный репозиторий.
7. По ощущениям, предел справочников поддерживаемых в виде таких баз данных до 20-30 тысяч записей. Большее число представляется сложно поддерживаемыми, хотя и вполне возможно что это надо проверять.

#opendata #thoughts #data

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

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

У дата продуктов есть несколько ключевых характеристик:
1. Они создаются с понимание того как их могут использовать пользователи и наличия базовых сценариев использования. И не имеет значения бесплатный и открытый ли это продукт или коммерческий, это понимание должно присутствовать всегда.
2. За дата продукт должен быть ответственный, человек понимающие и сами данные, и способы их предоставления, и пользователей. Способный ответить на вопросы и инициировать изменения после получения обратной связи. Можно назвать его куратором данных/куратором продукта
3. У дата продукта должна быть документация включающая как описание схем данных, так и примеры кода, сценарии использования и существующие ограничения.
4. Как правило дата продукт - это совокупность способов доступа к данным. Он может включать и API, и наборы данных для массовой выгрузки, и отдельные наборы данных срезов.
5. Дата. продукт может быть и базой данных с регламентированным доступом. Например, размещённой на облачной платформе вроде Google BigQuery, Databricks, AWS и так далее.
6. Дата продукты всегда делают акцент на качестве данных. Оно должно быть отражено в документации и быть предметом постоянной работы.
7. Дата продукты могут иметь интерактивные интерфейсы доступа к данным, но они вторичны к самим данным. Например, дашборд с визуализацией и возможностью экспорта данных в Excel не дата продукт, а документированные наборы данных у которых ещё и есть дашборд - это дата продукт
8. Хорошая практика для дата продуктов это версионирование схем и слепков данных. Как правило и схемы и сами данных в разных версиях остаются доступными.

Примеры дата продуктов:
- Данные Всемирного банка по странам. Представлены в виде API, датасетов для массовой выгрузки и детально докумнентированы
- Большие базы данных размещённые в registry.opendata.aws, например, базы Common Crawl и базы спутниковых снимков
- Российская база ФИАС в виде XML выгрузок и унаследованных выгрузок в DBF формате

Что не является дата продуктами:
- подавляющее большинство наборов данных на порталах открытых данных
- интерактивные дашборды позволяющие делать выгрузки данных, без данных опубликованных отдельно
- любые недокументированные данные и API для доступа к ним
- аналитические отчеты на данных и визуализации, без самих данных

А какие примеры хороших дата продуктов вы знаете?

#data #dataproducts #thoughts #questions