Подборка ссылок про данные, технологии и не только:
- Redistricting Data Hub портал открытых данных о перераспределении округов, включает много данных по разным штатам США. В чистом виде общественно-политический проект множества партнерских избирательных организаций. Интересен технологичностью и четким фокусом
- OpenData набор проектов построения объектных и векторных хранилищ. Назвались очень странно OpenData, все таки, про другое. Делают что-то интересное, но непонятное потому что с названием не коррелирует.
- Headroom комплексный инструмент сжатия контекста для кодирующих ИИ агентов, помогает оптимизировать токены и скорость разработки. Обещают сжатие использования токенов в 60-95%
- AI Engineering from Scratch вводный курс для ИИ инженеров, 503 урока в 20 фазах. С открытым кодом

#opendata #opensource #ai #tools

В рубрике закрытых открытых данных в России Минтранс РФ уже полгода как не публикует статистический бюллетень "Транспорт России". Последний бюллетень размещался у них на сайте 11 декабря 2025 года и за 9 месяцев 2025 года, а до этого 8 сентября, а до этого 9 июня, а до этого 14 марта.

То есть бюллетень публиковался примерно через 2.5 месяца после прошлого отчетного периода и в 2026 году до 15 марта должен был быть опубликован бюллетень за 2025 год, а до середины июня (в течении 10 дней от сегодня) ожидался бы бюллетень за первый квартал 2026 года.

Но бюллетеня за 2025 год нет, почему непонятно, анонсов на сайте Минтранса РФ я лично тоже не видел.

Записываем этот случай в очередной пример закрытия официальной статистики в РФ.

#opendata #closeddata #russia

В Великобритании национальный портал открытых данных data.gov.uk переименовали в National Data Library (Национальная библиотека данных) и рассказали о том почему и как они это делают.

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

Ключевой двигатель изменений нац порталов открытых данных в том что в какой-то момент многие из них превратились в помойки. Идея open by default без методической поддержки привела к большому числу бессмысленных маленьких наборов данных не востребованных и не нужных 99% пользователей. Преодолевают эту проблему очень по разному:
- в Евросоюзе - фокусируются на данных особой ценности выводимых в отдельную категорию
- в США - откровенно забивают на портал data.gov, он давно наполняется, но качественно не меняется. Поэтому параллельно создают много разной открытой инфраструктуры для геоданных, научных данных и тд.
- в Индонезии - кратно увеличивают число опубликованных открытых данных публикуя на них чуть ли не каждый файл созданный госорганами. Сейчас там больше 580 тысяч файлов на data.go.id

И вот в Великобритании это решили делать через curated datasets, не особо понимая своих реальных и потенциальных пользователей и не обеспечивая технологической основы.

С одной стороны удивительно, а с другой не очень. Как хороший пример, data.gov.uk я пока приводить не могу.

#opendata #uk #thoughts

Data.gov: Implementation and Perspectives on Its Functions на сайте Конгресса США обзор истории портала Data.gov и перспектив его развития. Документ в форме отчета Конгресса, написан очень бюрократизированным языком, читать его непросто, хотя и интересно.

А заодно полезно для понимания проблем с которыми сталкиваются при разработке порталов открытых данных. Data.gov в довольно запущенном состоянии уже давно, как и ряд других национальных порталов открытых данных.

#opendata #usa #data #datacatalogs

Мне много что есть сказать по поводу отзыва компанией 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

ORD (Open Reaction Database) открытая база реакций состоящая из более 500 наборов данных и сотен тысяч реакций описанных в структурированной форме.

У проекта открытый код и открытые данные на Github.

Из необычного данные публикуются в форматах Parquet и сжатом Protobuf (.pb.gz).

Основным источником является база патентов США, а кроме того там используется некоторое число открытых датасетов к которым привязаны реакции. Внутри используется CML (Chemical Markup Language) язык разметки для химических реакций.

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

#opendata #opensource #chemistry

findgovdata.org свежий поисковик по открытым данным США, конкретно по данным портала data.gov . Кажется очень небольшим по сравнению с нашим Dateno (тут около 540 тысяч датасетов, а в Dateno больше 20 миллионов). Однако тоже любопытен по своему.

По сути проект - это демка opensource поискового движка Amgix как альтернативы Elasticsearch. Внутри него векторные базы данных (можно выбрать одну из) и набор полезных фич.

Из заметных минусов - все под лицензией AGPL-3.0, а значит что создатели явно нацелились на то чтобы вскоре запилить SaaS продукт и получить на него венчурные инвестиции.

#opensoure #opendata #search #datasets

Про то как ИИ хайп влияет на открытость данных. Патентная служба США 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