В продолжение про обновление 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

Для тех кому интересна веб архивация, свежий релиз моего хобби инструмента metawarc для глубокого анализа WARC архивов используемых в Интернет Архиве и многочисленных национальных и частных веб-архивных инициативах. Инструмент позволяет индексировать веб-архивы для глубокого анализа и задач data science, а также извлекать метаданные из документов, изображений, видеофайлов и иных имеющих метаданные внутри файлов.

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

Инструмент может быть полезен для всех кто интересуется цифровым сохранением и OSINT, поскольку эти метаданные полезны при анализе слепков веб-сайтов.

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

#opensourc #webarchives #digitalpreservation

Новая версия 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

Почему невозможно избавиться от PDF ?

Вот уже долгое время меня поражает то какая индустрия, спектр открытых и платных инструментов появился вокруг преобразования неструктурированных данных/документов в структурированные Markdown или JSON. И здесь особняком идут файлы в PDF формате, которых, внезапно, оказалось чуть ли не большая часть всего созданного в текстах в виде разного рода банков документов: архивов научных статей, корпоративных банков документов, баз законов и законопроектов, архивов публичных отчетов компаний и так далее.

PDF изначально разрабатывался как универсальный формат адаптированный к чтению человеком, а не автоматизированными системами. Это его сильно отличает не только от форматов MS Office, но и многим другим спецификациям разметки документов.

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

Меня не покидает чувство что что-то в этой схеме не так. И вопрос в том как изменение потребления текстов поменяет их создание. Появятся ли новые форматы разметки и форматирования текстов? Появятся ли требования, к примеру, у научных изданий передавать не только PDF файлы, но и оригинальные в форматах MS Office/OpenOffice и других? Поменяются ли корпоративные правила создания банков документов?

Или все уже приняли тот факт что инструменты разбора PDF документов эволюционируют и это уже не проблема?

#thoughts #pdf

Я тут на днях читаю внутреннюю лекцию про дата продукты и задумался о том как наилучшим образом описать отличие дата продукта от просто опубликованных данных, 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

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

Существующие каталоги данных хотя и движутся в направлении описания дата продуктов, но, по своей сути, до сих пор являются именно каталогами данных/датасетов. Единицами измерения там являются наборы данных и приложенные к ним ресурсы (файлы и ссылки). Они ориентированны на массовую одноразовую публикацию и, если посмотреть на существующие наиболее известные порталы открытых данных то там обновляется регулярно, в лучшем случае, 5% опубликованного, а в худшем не обновляются данные совсем.

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

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

К каталогам дата продуктов ближе каталоги данных на базе Huwise (бывший OpenDataSoft) и значительно дальше каталоги датасетов на базе CKAN, DKAN, GeoNode, Geonetwork и так далее.

В моём понимании каталоги дата продуктов содержат гораздо меньше учетных единиц которыми дата продукты и являются и которые могут иметь множество форм доступа: API, срезы файлов, прямой доступ к СУБД через SQL, возможность получения в виде массовой выгрузки и так далее.

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

Дата продуктов довольно много и они весьма вариативны. Многие государственные реестры ведутся как дата продукты, их создатели хорошо понимают пользователей и дают API и файлы данных, документируют их в меру своего понимания. Коммерческие API к данным ещё более распространены и гораздо чаще включаются удобную документацию для разработчиков. Можно ли их все привести к одной спецификации? Есть стандарт ODPS который, может быть, приближается к этому, но он ИМХО не универсален.

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

#data #dataproducts #thoughts

Я как-то уже писал что практически ушел из большей части соцсетей и главная причина в том что так или иначе они превратились в потоки спама, нерелевантного контента, "заманух" в виде лент для бесконечного скроллинга и так далее. Это касается и российских VK, OK и международных Facebook'а, X, Instagram'а и тд. Есть ощущение что они все сильно испортились за последние годы. И чуть ли не единственная оставшаяся с адекватным профессиональным контентом - это LinkedIn. У нее есть та особенность что в ленту тебе подмешивается то о чем ты пишешь. Например, пишу я про data engineering и в suggested постах почти всё про дата инженерию. Пишу про открытый код и вижу посты про открытый код. А недавно я туда же закинул свои размышления про PDF формат, то же о чем писал тут и теперь почти все посты которые suggested подмешаны в ленту посвящены разным аспектам работы с PDF. Логика их рекомендационного сервиса вполне поддается объяснениям и хорошо что она такая, а не как у Facebook'а через подмешивание бесконечного числа нерелевантного контента.

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

Еще одна проблема в Github'е в спаме в issues и в PR, причем вычищать его оттуда и репортить проще не становится. В этом смысле Github вообще плохо приспособлен к репортам спама и злонамеренных действий. Хуже чем можно было бы ожидать во всяком случае.

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

#thoughts

Новая версия 1.7.0 утилиты undatum для обработки данных с командной строки включая поддержку форматов данных с вложенными структурами такие как JSONL (NDJSON), Parquet, Avro и более 140 других.

Ключевые изменения:
- появился текстовый интерфейс TUI для интерактивной работы с данными. Вызывается как undatum tui <название файла>
- появился веб интерфейс для для просмотра данных. Пока незавершенный, в экспериментальном режиме. Вызывается как undatum web <название файла>
- убраны опции запросов к данным через язык MistQL, вместо него можно использовать синтаксис SQL от DuckDB
- большая синхронизация с опциями и функциями библиотеки iterabledata, в первую очередь в части развертывания вложенных структур, например, для обращения к данным как capital_city.lat где lat - это вложенное поле в структуре capital_city
- множество изменений поменьше

#opensource #datatools #data #dataengineering

Полезное чтение про данные, технологии и не только:
- How AI is breaking the British state статья в The Economist о том что граждане в Великобритании начали массово использовать ИИ агенты для подачи жалоб и аппеляций, так что скоро суды будут перегружены если не уже. И о том что эта ситуация грозит повториться во всех богатых демократиях где у граждан есть многие права и теперь ИИ заменяет юристов которые подавали такие жалобы. Статья за пэйволом, вот тут можно почитать ее краткое изложение
- Reimagining Development Data каталог каталогов (data inventory) наиболее значимых баз по тематике международного развития. Полезно для тех кто интересуется темой и мне для пополнения реестра каталогов данных Dateno
- The Prediction Revolution книга от Grace Huckins о том как ИИ дает возможности предсказывать то что ранее предсказывать было невозможно.

#ai #opendata

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

1. Наиболее актуальная практика сжатия файлов с данными сейчас - это применение Zstandard (расширение .zst). Большая часть современных инструментов обработки данных и их анализа, умеют с ними работать. К примеру, они естественным образом читаются с помощью DuckDB, Polars или Pandas. Да и другие инструменты работающие с дата фреймами их поддерживают.
2. Но большая часть - это далеко не все, к примеру, табличные редакторы вроде Excel или BI системы сжатые файлы не поддерживают, за исключением разве что Parquet, который, впрочем, тоже поддерживают не все.
3. Parquet - это другой важный формат распространения данных, он не только поддерживает разные кодеки сжатия данных, но и даёт лучшее сжатие за счет применения компрессии к колонкам. Распространять данные в виде Parquet файлов с внутренним сжатием - это хорошая практика и один из признаков что те кто данные распространяют ориентируются на профессиональную аудиторию и сами с данными работать умеют.
4. Один из худших форматов для распространения данных - это большие XML дампы, которые даже если сжатые требуют специальных усилий чтобы не считывать весь файл в оперативную память. К примеру, Фонд Викимедия (Википедия и тд.) распространяет дампы википедий в виде больших сжатых XML и для обработки их нужны SAX парсеры. Впрочем там уже есть экосистема инструментов которая эту проблема успешно решает.
5. Есть множество старых дата продуктов в которых до сих пор используются сжатие GZip, Bzip2 и тд. по принципу сохранения совместимости и потому что "тут так сложилось". Тем не менее это могут быть хорошие дата продукты
6. Но самый распространный формат распространения данных - это, конечно, ZIP файлы. Например, нарезая данные из базы данных на сотни ZIP файлов в которых сотни/тысячи XML или CSV файлов и, иногда, заодно и документация и сопроводительные материалы. Внутри они могут быть очень по разному устроены.
7. В разное время появлялись стандарты описания пакетов с данными. BagIt, Frictionless Data Package, DataCrate, Research Objects, ReproZip. У них у всех есть свои ограничения и свое применение. Главный недостаток - неадаптированность к облачному хранению, невозможность работать с частью пакета данных не скачивая его контейнер целиком.
8. Некоторые большие наборы данных/базы данных/дата продукты их владельцы распространяют вообще через такие инструменты как rsync (open-source ПО для синхронизации данных между серверами) и тогда сжатие обеспечивается на этапе передачи данных даже если оригинальные файлы не сжаты. Особенно часто такое бывает в астрофизике, сейсмологии, биоинформатике и тд. Естественных науках где есть организации предоставляющие профессиональные data services по синхронизации больших баз данных.


#opendata #compression #data #thoughts

В Reuters статья о том что Госдепартамент США потребовал у стран определиться в какой из глобальных ИИ инициатив они участвуют - в Pax Silica или WAICO. Я чуть менее месяца назад писал об этом же, что эти две инициативы словно создают новых двух полярный мир и единственная страна которая сейчас пытается усидеть на двух стульях - это Казахстан, но думаю что тут США надавят. Интересно уже даже появится ли на фоне этого своеобразное движение цифрового неприсоединения, участники которого будут де-факто отказываться от участия в обеих этих инициативах? В любом случае чем дальше тем больше вокруг ИИ будет завязано геополитики и страсти накаляться по мере применения основанных на них инструментов в военных целях, кибербезопасности, террористами и так далее.

#ai #geopolitics #usa #china

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

#opendata #statistics #pakistan #datacatalogs

В мире есть всего 3 страны в которых нет ни одного портала данных - это Северная Корея, Сент-Китс и Невис и Гренада. Это не значит что никаких данных о них нет, есть данные межгосударственных структур которые собирают данные по всем странам, но вот конкретно в этих случаях сами страны публикуют информацию очень скудно. В этом списке мог бы быть Туркменистан, но там есть хотя бы портал показателей устойчивого развития sdg.stat.gov.tm в остальном же тоже все очень скудно.

У 43 стран нет национальных каталогов статистических индикаторов. Не сайтов статслужб с публикациями в PDF/Excel, а именно каталогов с индикаторами/временными рядами. Большая часть этих стран - это малые страны Карибского моря, Океании и другие беднейшие страны. Что характерно почти у всех стран Африки есть порталы статпоказателей в рамках проекта Африканского банка развития.

У 82 стран нет национальных порталов открытых данных, из европейских стран это только Андорра, Сан Марино и Беларусь. У большей части стран Океании и Африки также нет национальных порталов открытых данных. В ряде стран вроде Пакистана то что официально так называется де-факто этим не является.

Всё это цифры на основе последнего релиза dataportals-registry реестра каталогов данных Dateno. Там был добавлено 92 новых каталога данных и обновлены метаданные существующих. Например, национальные порталы открытых данных в этом году появились у таких стран как:
- Бутан - data.gov.bt
- Иордания - opendata.gov.jo
- Камбоджа - data.mef.gov.kh
- Лихтенштейн - opendata.li
- Монако - data.gouvernement.mc
- Оман opendata.gov.om

#opendata #datacatalogs #data

В продолжение про обновление реестра каталогов данных Dateno, поделюсь ещё наблюдением то что модели внутри Cursor'а и выполнение задач агентами стало, в некоторых задачах, сравнимо с внешними аналитическими ИИ агентами вроде Manus'а. Например, в рамках ведения этого реестра самая сложная часть - это поиск новых каталогов данных. В какой-то момент все "низковисвящие фрукты" сорваны и надо целенаправленно искать новые каталоги данных чтобы их добавлять. А можно было отправить задачу в тот же Manus или другие размышляющие ИИ агенты с deep research и wide research в стиле "Найди мне дата каталоги по такой-то стране/такой-то тематике" и далее найденное уже добавлять в реестр.

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

Это хорошее открытие, позволяющее из интерфейса того же Cursor'а искать новые каталоги данных и меньше использовать внешние сервисы, у которых меньше контекста. Скорее всего благодаря этому я довольно скоро существенно обновлю реестр каталогов данных по многим странам.

#opendata #datacatalogs

Новый бенчмарк DataBench LLM для аналитичекской работы с данными от Hex. Вот тут они подробно рассказывают про то как он работает. Ожидаемо хорошие результаты у Fable 5, и самые дорогие, конечно же, по стоимости. Сравнивают, в основном, модели из США от OpenAI и Anthropic. Из китайских там только Kimi 2.7, хотя уже вышла Kimi K3, хотелось бы посмотреть сравнение с ней, и с GLM-5.3

#data #aiagents

Как я и писал ранее удалось сильно улучшить обнаружение каталогов данных и вышла новая версия реестра каталогов данных. В нее вошло:
- плюс 1748 новых каталогов данных, это более 12% от общего числа, иначе говоря очень много. Среди добавленных каталогов много геопорталов, инсталляций CKAN в Индонезии и Таиланде, китайских порталов научных данных, порталов данных по биоразнообразию, порталов микроданных переписей и так далее.
- 12 новых типов программных продуктов на которых делаются каталоги данных: oportal, piveau, knoema, redatam, datafair и другие
- исправления и улучшения в метаданных существующих описания каталогов данных

Из явных находок:
- картографический сервис ewmapa в Польше на базе которого есть сайты для всех муниципалитетов
- шведская специфика, почти все порталы открытых данных на базе их местного продукта EntryScape
- китайские научные порталы данных почти все работают на базе Instdb, ПО Китайской Академии Наук, их много прибавилось
- NextGIS Web массово используется по всему миру, много инсталляций за пределами РФ добавилось в реестр
- оказывается data.europa.eu создан на базе open source каталога данных Piveau, я все это время думал что там своя разработка

И еще немного цифр:
- 5,906 всех каталогов данных в Европе - это 36.3% от общего числа
- 4,619 всех каталогов данных в США - это 28.4% от общего числа

В Европе страна с наибольшим числом каталогов данных Франция - 801
В США более всего каталогов данных находится в Калифорнии - 481

Подробнее в CHANGELOG, код и данные в репозитории

#opendata #datacatalogs