Хороший обзор проектов с экспериментальной статистикой в США, с примерами компаний которые создают публичные дата продукты и их начинают использовать официально.

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

В обзоре из интересных примеров - это оценка масштабов строительства через анализ спутниковых снимков.

#opendata #statistics

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

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

Тем не менее хорошие идеи там тоже есть и посмотрим куда автор свой проект будет развивать.

#opensource #opendata #datacatalogs

Как обеспечивать доступность данных для пользователей внутренних или внешних?

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

Когда сталкиваешься с существующими инструментами с помощью которых можно опубликовать данные и делать их доступными очень быстро появляется желание придумать свой велосипед. Я лично такой велосипед придумывал делая команду api serve в утилите undatum, а до этого делая утилиту apicrafter для автоматического создания API поверх баз MongoDB.

А кроме этого существует такой фрейморк как roapi, существует API в каталоге данных CKAN для доступа к структурированным данным, есть возможность публиковать данные просто в дата каталогах как файлы и тут уже выбор большой - CKAN, DKAN и тд. Для геоданных есть ещё GeoNode и Geoserver и все они так или иначе дают интерфейсы для доступа к данным. Плюс есть множество коммерческих провайдеров ArcGIS Hub, HuWise, DoltHub и другие, но их так просто в свой технологический стек не положишь без проприетарной зависимости.

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

Старые способы вообще не про каталоги данных, а про правильно организованные доступы для массовой выгрузки, еще на FTP серверах где все организовано по папкам и подпапкам рассортированным по схемам данных, с полными дампами и инкрементальным доступом. Хорошо работает для массовой выгрузки, плохо для всего остального.

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

В итоге оказывается что для внутренних пользователей самые простые способы в том чтобы загружать данные в таблицы в СУБД и давать пользователям доступ туда на чтение, а документацию предоставлять через каталоги метаданных вроде OpenMetadata или Datahub. Это такой SQL-first подход, удобный для внутренних задач сильно ограничивающий в предоставлении внешним пользователям. Для внешних пользователей все равно необходимо сооружать API, экспорт для массовой выгрузки (и он не должен быть динамическим) и экспорт документации в некий внешний формат/сайт. Чаще всего разработчики делают отдельное внешнее API заточенное под эти данные, реже более универсальное с GraphQL или OData.

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

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

Сейчас чуть ли не единственным продуктом который можно использовать как Headless DMS является CKAN, при том что у него огромные ограничения по масштабированию, объёмам поддерживаемым данных и управлению правами доступа.

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

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

Вот такие мысли вслух про создание каталогов данных и доступе к данным через API.

#opendata #datacatalogs #thoughts

Я тут задумался над одной из главных проблем большей части проектов/порталов с открытыми данными. Они очень редко существуют в понятиях дата продуктов (продуктов данных). Хотя, по своей сути, являются их подвидом. Должны бы являться, в каком-то идеальном мире.

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

Гораздо ближе к дата продуктам коммерческие порталы с данными, отдельные госпроекты где доступность данных - это одна из форма доступа к ним и коммерческие дата продукты.

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

Все это к тому что преобразование порталов открытых данных в AI-готовые продукты ограничено тем что дата продуктов на них мало, метаданные не адаптированы для работы ИИ агентов и, в целом, требуются отдельные и существенные усилия чтобы строить на них семантические слои.

Картинка для привлечения внимания, честно переведена с помощью LLM, а тут первоисточник

#opendata #ai #thoughts #dataengineering #datacatalogs

Feasibility study European Books Data Commons еще один интересный документ для чтения, техническое обоснование создание корпуса книг / датасетов на основе книг в библиотеках Евросоюза. Называется EBDC (European Books Data Commons). В тексте смешение технической реализации и смысловых обоснований зачем это нужно и как это можно организовать, включая интеграцию с Europeana, создание корпусов текстов, датасетов и есть какое-то количество примеров подобного в мире, в основном несколько проектов в США.

Собственно основное там - это массовый OCR с помощью VLM (Vision Language Model) и основные расходы идут на компьютеры с GPU для этой задачи.

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

#opendata #europe #books

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

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

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

#opendata #datasets #data #opensource

Одно из наблюдаемых мной явлений - это как AI и Data стали почти синонимами и как взлетают по популярности новые инструменты работы с данными и как медленно умирают инструменты периферийные к трендам.

К примеру, OpenRefine довольно старый проект по чистке данных, возможно лучший из тех что открытым кодом уже с марта 2026 года перестал выпускать новые релизы. Разработка в репозитории ведется, но явно гораздо медленнее чем раньше и ничего радикально нового там не появляется.

Проект изначально был устроен так что работа с данными в нем ведется полностью в памяти и после определенных объемов он не справляется. При этом он позволяет вручную или с помощью синтаксисов Python или GREL (специальный язык для манипуляции данными) править данные в строках и колонках сохраняя полную историю изменений с возможностью их отката.

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

Интересно выживет ли он вообще? Не бросит ли его команда в какой-то момент?

Я как-то рассуждал тут вслух о том что если делать подобный инструмент современными методами, то движок внутри должен быть на базе DuckDB или Polars. Практически все операции можно делать SQL запросами, а вместо кода на GREL можно использовать text-to-SQL формы запросов совмещая инструмент очистки данных с data exploration.

#opensource #opendata #datatools