Новая версия dataportals-registry реестра всех существующих в мире каталогов открытых данных, используемого внутри поисковика Dateno для понимания того где брать датасеты для индексации.
В новой версии 1.9.0 нет новых каталогов данных, приоритет изменений был на исправлении ошибок и удалении дубликатов:
- было исправлено 240 ошибок негармонизированных справочников, теперь все приведены к унифицированному формату
- было удалено 34 дубликата
- исправлены все текущие критичные и значимые ошибки качества данных
- добавлены новые правила контроля качества данных (все выявленные ими ошибки исправлены)
Итого в реестре сейчас 14 436 каталогов данных включающих порталы открытых данных, порталы геоданных, статистические порталы, порталы микроданных, порталы данных для машинного обучения, поисковые системы по данным и так далее.
Все данные реестра доступны в форматах Parquet, NDJSON и в виде базы DuckDB.
#opendata #datasets #datacatalogs #data
В новой версии 1.9.0 нет новых каталогов данных, приоритет изменений был на исправлении ошибок и удалении дубликатов:
- было исправлено 240 ошибок негармонизированных справочников, теперь все приведены к унифицированному формату
- было удалено 34 дубликата
- исправлены все текущие критичные и значимые ошибки качества данных
- добавлены новые правила контроля качества данных (все выявленные ими ошибки исправлены)
Итого в реестре сейчас 14 436 каталогов данных включающих порталы открытых данных, порталы геоданных, статистические порталы, порталы микроданных, порталы данных для машинного обучения, поисковые системы по данным и так далее.
Все данные реестра доступны в форматах Parquet, NDJSON и в виде базы DuckDB.
#opendata #datasets #datacatalogs #data
GitHub
GitHub - datenoio/dataportals-registry: Registry of data portals, catalogs, data repositories including data catalogs dataset and…
Registry of data portals, catalogs, data repositories including data catalogs dataset and catalog description standard - datenoio/dataportals-registry
👍7✍2
Еще немного рефлексии про работу с референсными данными и применении ИИ ассистентов для создания и сопровождения контролируемых дата продуктов/датасетов. О чем-то из этого я уже писал с чуть другими акцентами, что-то новые мысли:
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
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
❤🔥4✍3