Про то как ИИ хайп влияет на открытость данных. Патентная служба США USPTO ограничила доступ к своему порталу открытых данных data.uspto.gov только для зарегистрированных пользователей. Теперь чтобы скачать большие слепки данных или подключится через API надо заполнить регистрационную форму, а с августа включать в нее еще и дополнительную информацию.

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

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

#opendata #closeddata #usa #patents #ai

Свежий текст от The GovLab о том как меняется политика доступа к данным в эпоху ИИ. Текст, как я понимаю, по итогам нескольких сессий прогнозирования развития открытости данных, открытого доступа и обмена данными с ведущими экспертами и про то куда все двигается на основе этих разговоров.

Там все те же темы о которых я регулярно пишу, то что парадигма открытых данных
испытывает трудности, то что государства хотят больше контроля над данными, то тема данных стала синонимична ИИ и еще много всего.

#opendata #readings

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

Все это про мир 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

Ещё полезных ссылок про данные технологии и не только:
- Introducing MAI-Cyber-1-Flash inside MDASH свежая модель от Microsoft по поиску уязвимостей. Интересная архитектура и технические подробности про то как там устроена мультиагентность
- Pi Web веб интерфейс для известного кодирующего агента pi. С ним привычно уже работать с командной строки, но UI также удобно и полезно
- EU delays release of Copernicus imagery over Gulf of Oman Евросоюз установил 24 часовую задержку в публикации снимков Оманского Залива со спутников Sentinel-1 и Sentinel-2. Конечно же по просьбе властей США😉 Подозреваю что рано или поздно крупные медиа реально будут запускать свои спутники чтобы получать оперативную информацию. Кстати, тут есть материал для хорошего фантастического рассказа

#opendata #ai #eu #satellite #security #microsoft

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

Что вошло в эту версию 1.8.0:
- добавлено 3 новых записи межгосударственных организаций, удалена одна (две объединены как дубликаты)
- обновлены данные ~500 междгосударственных структур, это около половины от общего числа. Обновлялись списки участвующих стран, классификация, тэги, описания и подтверждения происхождения информации, записи provenance и многое другое
- расширен контроль качества записей для проверки наличия хотя бы 4-х provenance ссылок на каждую записи о межгосударственной структуре
- исправлено множество ошибок по итогам контроля качества данных: битые ссылки на Wikidata, указания уже несуществующих стран и так далее.

Особенность internacia-db в способе распространения. Это то что называется контролируемый датасет или дата-продукт. В репозитории содержатся первичные YAML файлы с описанием каждой страны и каждой международной структуры из которых собираются финальные наборы данных в форматах JSONL, YAML, Parquet и базы DuckDB.

#opendata #datasets #dateno

В продолжение про обновление internacia-db, вот немного фактов про страны и межгосударственные структуры:
- членами ООН является 193 страны, коды ISO (ISO 3166-1) присвоены 249 странам и территориям, в internacia-db всего 256 стран и территорий. разница в цифрах происходит от того что в internacia-db включены 7 территорий с оспариваемым статусом действующие и устаревшие. Это Косово, Абхазия, Южная Осетия, Приднестровье, Арцах, Нидерландские Антилы, Нормандские острова.
- возможно Нидерландские Антилы и Нормадские острова надо будет убрать из этого списка поскольку они де-факто разделены на несколько зависимых территорий у которых есть присвоенные ISO коды
- единственной страной которая независима и не член ООН является Ватикан. У Ватикана в ООН статус организации наблюдателя, это в internacia-db не фиксируется, тут только про страны. Но вообще Ватикан входит в 40 межгосударственных структур упомянутых в internacia-db
- с марта 2022 года формально РФ вышла из 3-х организаций: European University Association, European Court of Human Rights и International Council for the Exploration of the Sea. Во многих других её участие заморожено, но формально выхода или исключения нет поэтому простым запросом все случаи пока не отследить
- наиболее широко в межгосударственных структурах присутствуют Франция, Великобритания, Германия, Италия и США. Наименее - Северная Корея.
- если посмотреть на связи стран ОЭСР со всеми другими странами не входящими в эту межгосударственную структуру, то окажется что через соглашения они тесно связаны с Китаем, Россией и Индией и наименее всего с Северной Кореей
- из всех оспариваемых территорий Косово наиболее представлено в межгосударственных структурах и входит как страна во многие европейские соглашения, объединения и тд.

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

#opendata #datasets #documentation #dateno

Ещё немного рефлексии про разное сугубо технологическое:
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