К вопросу о дата-инженерии и Dateno, одна из особенностей проекта в том что практически вся работа с данными построена на собственных инструментах с открытым кодом, что имеет кучу преимуществ при старте, и накапливающиеся ограничения в будущем которые уже хочется избежать.
И здесь не последнюю роль играет выбор итогового технического стека который, в свою очередь, ограничен спецификой проекта, данных, их источников и тд.
Вот некоторые важные особенности:
1. Почти все первичные данные в Dateno - это JSON, JSON lines, и сильно реже CSV, которые тоже преобразуются в JSON. Отсюда и хранение первичных данных в MongoDB как наиболее естественно подходящем хранилище. Хотя уже можно рассматривать альтернативы. В любом случае сейчас в проекте нет SQL, за исключением DuckDB для аналитики и экспериментов.
2. В отличии от корпоративной дата инженерии тут огромное число неуправляемых внешних источников метаданных. Их более 10 тысяч всего из которых 5 тысяч уже подключено и индексируются. Вместе с отсутствием SQL это делает малопригодными классические оркестраторы задач и ETL/ELT инструменты.
3. Другая особенность в итеративности задач и в работе с первичными данными. Логика сбора построена на постобработке первичных данных. Вначале они собираются AS IS из первоисточников и далее, отдельными процессами, преобразуются в эталонную схему и финальную базу данных (поисковый индекс). При этом все первичные данные хранятся и используются для аналитической работы когда надо построить новый фильтр, то вначале проверяется есть ли опора для него в первичных метаданных.
4. Конвееры данных могут оперировать как очень большими, так и очень малыми данными. Число датасетов из каталога данных Всемирного банка может быть более 6 миллионов за раз, а из ряда малых каталогов данных это может быть всего 2-3 датасета.
5. Если рассмотреть инструменты для оркестрации и ETL/ELT в контексте этих особенностей то вылезает следующее:
- Meltano - ключевая фишка в большом числе коннекторов которые надо писать под каждый источник данных. Потенциальный ETL/ELT инструмент в связке с инструментом оркестрации.
- Dagster - выглядит симпатично на небольшом числе конвееров, нет результатов экспериментов на большом их числе, условно на тысячах.
- Kestra - внешне выглядит неплохо, но написан полностью на Java что заранее накладывает сомнения применимости в Python-only инфраструктуре.
- Airflow - чистый оркестратор, может быть применён в связке с собственной или донастроенным внешним ETL/ELT
- Prefect - хорошо выглядящий оркестратор на Python, но с заложенными ограничениями в бесплатной версии.
6. Какой стек работы с данными в итоге выбрать? Из того что я видел на практике, ни один нельзя использовать как единственно возможный и даже выбрав надо всё равно делать свой дашборд мониторинга работы с источниками данных потому что пока ни в одном из инструментов я ещё не встречал работы с цепочками конвееров данных.
7. И это ещё не доходя до вопроса контроля качества данных. Контроль качества данных вроде как должен быть частью конвееров сбора данных, но практика в том что неполнота и недостаточное качество не должно быть ограничением для включения в поисковый индекс, но должно быть механимом пост-контроля выявления проблем и перезагрузки датасетов или доработкой процедур обогащения и очистки данных.
8. Поэтому один из путей решения - это условное разделение источников поступления эталонных данных. Неважно как именно отработал пайплайн, оркестратором, ad-hoc скриптами или пушем из другого сервиса, главное что он соответствует заданной схеме и проходит валидацию. Поступающие данные идут в staging (промежуточную) базу данных, а уже в ней работает конвеер по преобразованию данных в эталонные.
9. Это позволяет переводить инфраструктуру сбора и обработки метаданных датасетов на конвееры итеративно, но требует документирования схем, хорошего их проектирования под дальнейшую эволюцию и тд. Впрочем проектирование схем это нечто неизбежное поскольку без них контроль качества данных недостаточен.
#dateno #thoughts #dataengineering #elt #etl #datapipelines
И здесь не последнюю роль играет выбор итогового технического стека который, в свою очередь, ограничен спецификой проекта, данных, их источников и тд.
Вот некоторые важные особенности:
1. Почти все первичные данные в Dateno - это JSON, JSON lines, и сильно реже CSV, которые тоже преобразуются в JSON. Отсюда и хранение первичных данных в MongoDB как наиболее естественно подходящем хранилище. Хотя уже можно рассматривать альтернативы. В любом случае сейчас в проекте нет SQL, за исключением DuckDB для аналитики и экспериментов.
2. В отличии от корпоративной дата инженерии тут огромное число неуправляемых внешних источников метаданных. Их более 10 тысяч всего из которых 5 тысяч уже подключено и индексируются. Вместе с отсутствием SQL это делает малопригодными классические оркестраторы задач и ETL/ELT инструменты.
3. Другая особенность в итеративности задач и в работе с первичными данными. Логика сбора построена на постобработке первичных данных. Вначале они собираются AS IS из первоисточников и далее, отдельными процессами, преобразуются в эталонную схему и финальную базу данных (поисковый индекс). При этом все первичные данные хранятся и используются для аналитической работы когда надо построить новый фильтр, то вначале проверяется есть ли опора для него в первичных метаданных.
4. Конвееры данных могут оперировать как очень большими, так и очень малыми данными. Число датасетов из каталога данных Всемирного банка может быть более 6 миллионов за раз, а из ряда малых каталогов данных это может быть всего 2-3 датасета.
5. Если рассмотреть инструменты для оркестрации и ETL/ELT в контексте этих особенностей то вылезает следующее:
- Meltano - ключевая фишка в большом числе коннекторов которые надо писать под каждый источник данных. Потенциальный ETL/ELT инструмент в связке с инструментом оркестрации.
- Dagster - выглядит симпатично на небольшом числе конвееров, нет результатов экспериментов на большом их числе, условно на тысячах.
- Kestra - внешне выглядит неплохо, но написан полностью на Java что заранее накладывает сомнения применимости в Python-only инфраструктуре.
- Airflow - чистый оркестратор, может быть применён в связке с собственной или донастроенным внешним ETL/ELT
- Prefect - хорошо выглядящий оркестратор на Python, но с заложенными ограничениями в бесплатной версии.
6. Какой стек работы с данными в итоге выбрать? Из того что я видел на практике, ни один нельзя использовать как единственно возможный и даже выбрав надо всё равно делать свой дашборд мониторинга работы с источниками данных потому что пока ни в одном из инструментов я ещё не встречал работы с цепочками конвееров данных.
7. И это ещё не доходя до вопроса контроля качества данных. Контроль качества данных вроде как должен быть частью конвееров сбора данных, но практика в том что неполнота и недостаточное качество не должно быть ограничением для включения в поисковый индекс, но должно быть механимом пост-контроля выявления проблем и перезагрузки датасетов или доработкой процедур обогащения и очистки данных.
8. Поэтому один из путей решения - это условное разделение источников поступления эталонных данных. Неважно как именно отработал пайплайн, оркестратором, ad-hoc скриптами или пушем из другого сервиса, главное что он соответствует заданной схеме и проходит валидацию. Поступающие данные идут в staging (промежуточную) базу данных, а уже в ней работает конвеер по преобразованию данных в эталонные.
9. Это позволяет переводить инфраструктуру сбора и обработки метаданных датасетов на конвееры итеративно, но требует документирования схем, хорошего их проектирования под дальнейшую эволюцию и тд. Впрочем проектирование схем это нечто неизбежное поскольку без них контроль качества данных недостаточен.
#dateno #thoughts #dataengineering #elt #etl #datapipelines
К вопросу о дата продуктах, реестр каталогов данных Dateno [1] - это как раз один из них, как сайт, и как репозиторий кода [2]. В нём и собственные результаты сбора каталогов так и то что присылали и присылают пользователи.
И если сам Dateno - это продукт с потенциальной монетизацией и доступом по API (кстати не забудьте зарегистрироваться и попробовать API тут dateno.io), то каталог - это датасет в JSON lines, а теперь ещё и в формате parquet, вот ту можно его забрать [3].
Как и у любого дата продукта у него есть метрики качества. Некоторые из них трудно измерить - это полнота, поскольку референсных каталогов теперь нет, Dateno давно уже превосходит по масштабу все аналогичные. Не хвастаюсь, а печалюсь, не с чем сравнить.
Но то что касается постепенного обогащения данных можно измерить. Например, у каждого каталога есть поле status оно может иметь значения active и scheduled. Значение active то что каталог прошёл ручное заполнение и обогащение метаданными, у него у уникального uid'а есть префикс cdi. А есть значение scheduled у него префикс temp и это означает что это скорее всего каталог данных, но не проверенный вручную и не обогащённый метаданными.
Таких временных каталогов данных примерно 60%. Сначала я непроверенные каталоги вёл в отдельном реестре, потом стало понятно что неполнота их метаданных это не повод их не индексировать и они были слиты в единый реестр с чистовыми записями.
При этом часть метаданных автозаполнены даже для таких каталогов. Для некоторых каталогов данных - это название, страна, язык, точки подключения API, тип ПО. Для других незаполнены эти атрибуты и ряд других.
При этом даже для тех каталогов данных которые чистовые может не быть привязки к темам, может не быть тегов, могут быть неуказаны точки подключения API и тд.
Иначе говоря всё это и есть то что надо измерять в метриках качества потому что часть этих атрибутов переходят в фасеты Dateno.
Самые простые метрики качества реестра могут измеряться несколькими достаточно простыми SQL запросами. Чуть более сложные метрики, запросами посложнее и набором правил в коде на Python.
Всё это, конечно, хорошо линкуется с работой над качеством самого индекса Dateno. А пока я могу в очередной раз порекомендовать DuckDB как универсальный инструмент для таких задач.
Ссылки:
[1] https://dateno.io/registry
[2] https://github.com/commondataio/dataportals-registry
[3] https://github.com/commondataio/dataportals-registry/raw/refs/heads/main/data/datasets/full.parquet
#dateno #dataquality #sql #duckdb #metrics #datacatalogs
И если сам Dateno - это продукт с потенциальной монетизацией и доступом по API (кстати не забудьте зарегистрироваться и попробовать API тут dateno.io), то каталог - это датасет в JSON lines, а теперь ещё и в формате parquet, вот ту можно его забрать [3].
Как и у любого дата продукта у него есть метрики качества. Некоторые из них трудно измерить - это полнота, поскольку референсных каталогов теперь нет, Dateno давно уже превосходит по масштабу все аналогичные. Не хвастаюсь, а печалюсь, не с чем сравнить.
Но то что касается постепенного обогащения данных можно измерить. Например, у каждого каталога есть поле status оно может иметь значения active и scheduled. Значение active то что каталог прошёл ручное заполнение и обогащение метаданными, у него у уникального uid'а есть префикс cdi. А есть значение scheduled у него префикс temp и это означает что это скорее всего каталог данных, но не проверенный вручную и не обогащённый метаданными.
Таких временных каталогов данных примерно 60%. Сначала я непроверенные каталоги вёл в отдельном реестре, потом стало понятно что неполнота их метаданных это не повод их не индексировать и они были слиты в единый реестр с чистовыми записями.
При этом часть метаданных автозаполнены даже для таких каталогов. Для некоторых каталогов данных - это название, страна, язык, точки подключения API, тип ПО. Для других незаполнены эти атрибуты и ряд других.
При этом даже для тех каталогов данных которые чистовые может не быть привязки к темам, может не быть тегов, могут быть неуказаны точки подключения API и тд.
Иначе говоря всё это и есть то что надо измерять в метриках качества потому что часть этих атрибутов переходят в фасеты Dateno.
Самые простые метрики качества реестра могут измеряться несколькими достаточно простыми SQL запросами. Чуть более сложные метрики, запросами посложнее и набором правил в коде на Python.
Всё это, конечно, хорошо линкуется с работой над качеством самого индекса Dateno. А пока я могу в очередной раз порекомендовать DuckDB как универсальный инструмент для таких задач.
Ссылки:
[1] https://dateno.io/registry
[2] https://github.com/commondataio/dataportals-registry
[3] https://github.com/commondataio/dataportals-registry/raw/refs/heads/main/data/datasets/full.parquet
#dateno #dataquality #sql #duckdb #metrics #datacatalogs
Forwarded from Выше квартилей
Dateno: первые опыты
Современная наука во многом построена на больших массивах данных, доступ к которым можно получить через репозитории, однако инструментов, позволяющих осуществлять поиск сразу по нескольким из них не так много. Так, Google Dataset Search выглядит подходящим инструментом, но исследователи, для которых предметом изучения являются сами данные, сталкиваются с ограничениями по автоматизации их получения.
Мы давно обратили внимание на проект Dateno (команда под руководством Ивана Бегтина), о котором упоминали в мартовском дайджесте. На сегодняшний день Dateno содержит информацию о 19 миллионах датасетов, но самое главное - имеет достаточно понятный и удобный API-интерфейс, с которым мы и решили, наконец, попробовать поработать.
Простая инструкция с примером очень хорошо описана в телеграм-канале И. Бегтина: пользователь регистрируется, получает токен, а дальше применение API возможно как напрямую из браузерной строки, так и через консольный инструмент, скрипт Python/R и т.д.
Зарегистрировавшись, мы сразу запросили данные о датасетах, в заголовке которых есть слово "scientometric*". Таких нашлось 92. Всего включено 35 параметров, в том числе данные о самих датасетах (название, ссылка, тематика, описание, формат и др.) и об источниках этих датасетов (название и тип каталога, название и тип его владельца, страна, язык и прочее).
Конкретно по нашей тематике данные размечены не полностью — например, лицензия указана всего для 10 датасетов из 92, тематика — для 16, а макрорегион — для 33. Подавляющее большинство наборов данных (56) принадлежит Европейскому Союзу, а вот в США их всего 17. Самые распространенные форматы .tsv и .txt (по 13). Датасетов в формате .json, к нашему удивлению, всего 2.
В целом, Dateno оказался действительно удобным инструментом, как с точки зрения технической доступности (открытый API есть у немногих репозиториев), так и с точки зрения покрытия данных. Предлагаем поделиться своим опытом использования Dateno в комментариях.
#dateno #датасеты #открытыеданные
Современная наука во многом построена на больших массивах данных, доступ к которым можно получить через репозитории, однако инструментов, позволяющих осуществлять поиск сразу по нескольким из них не так много. Так, Google Dataset Search выглядит подходящим инструментом, но исследователи, для которых предметом изучения являются сами данные, сталкиваются с ограничениями по автоматизации их получения.
Мы давно обратили внимание на проект Dateno (команда под руководством Ивана Бегтина), о котором упоминали в мартовском дайджесте. На сегодняшний день Dateno содержит информацию о 19 миллионах датасетов, но самое главное - имеет достаточно понятный и удобный API-интерфейс, с которым мы и решили, наконец, попробовать поработать.
Простая инструкция с примером очень хорошо описана в телеграм-канале И. Бегтина: пользователь регистрируется, получает токен, а дальше применение API возможно как напрямую из браузерной строки, так и через консольный инструмент, скрипт Python/R и т.д.
Зарегистрировавшись, мы сразу запросили данные о датасетах, в заголовке которых есть слово "scientometric*". Таких нашлось 92. Всего включено 35 параметров, в том числе данные о самих датасетах (название, ссылка, тематика, описание, формат и др.) и об источниках этих датасетов (название и тип каталога, название и тип его владельца, страна, язык и прочее).
Конкретно по нашей тематике данные размечены не полностью — например, лицензия указана всего для 10 датасетов из 92, тематика — для 16, а макрорегион — для 33. Подавляющее большинство наборов данных (56) принадлежит Европейскому Союзу, а вот в США их всего 17. Самые распространенные форматы .tsv и .txt (по 13). Датасетов в формате .json, к нашему удивлению, всего 2.
В целом, Dateno оказался действительно удобным инструментом, как с точки зрения технической доступности (открытый API есть у немногих репозиториев), так и с точки зрения покрытия данных. Предлагаем поделиться своим опытом использования Dateno в комментариях.
#dateno #датасеты #открытыеданные
К вопросу о том что есть и чего нет в Dateno в контексте того доступно через наше API и того что исследователи уже искали по наукометрии. Есть специфика данных в Dateno в том что пока ещё исследовательских данных в нём маловато и по очень объективным причинам.
В реестре каталогов данных Dateno сейчас 874 репозитория научных данных из которых проиндексировано пока только 99 репозиториев, а это чуть более 11% источников метаданных такого типа. И даже эти 874 репозитория - это не все репозитории научных данных в мире, а наиболее очевидные. Точное число, скорее всего, никто не знает потому что реестры вроде Re3Data и Fairsharing более широко трактуют научные дата-ресурсы и включают туда не только каталоги данных, но и базы данных.
Возвращаясь к источникам, в чём с ними сложность:
1. Коммерческие каталоги научных данных вроде облачных продуктов Elsevier и Figshare значительно ограничивают возможности их индексирования. Проиндексировать их можно, но высока вероятность блокировок с их стороны. это примерно 34% каталогов научных данных в реестре Dateno.
2. Каталоги результатов научной деятельности на DSpace легко индексируются, но устроены так что невозможно отдельно индексировать только датасеты. Чтобы проиндексировать их надо скачать все метаданные всех объектов и далее уже фильтровать датасеты. Причем последних будет не более 5% от всего общего числа материалов
3. Некоторые каталоги научных данных вроде тех что основаны Thredds или Galaxy имеют очень скудный набор метаданных, по сути они выглядят как большие научные файлохранилища. Правда и области применения у них узкие: метеорология и биоинформатика, поэтому они пока отложены
4. Для научных репозиториев данных главное API до сих пор это OAI-PMH 2.0. Очень унаследованное, очень неудобное по многим критериям, очень стандартизированное и обладающее критическим недостатком: оно не отдаёт ссылки на файлы в метаданных. Иначе говоря карточку датасета получить можно с базовыми полями метаданных, но метаданных связанных с ним файлов нельзя. Это решается, но тем не менее.
5. Есть очень крупные источники научных наборов данных в OpenAIRE, ScienceDB, ScienceBase, DataCite, BASE и ещё ряде других. Проиндексировав даже парочку из них можно добавить сразу +10-20 миллионов записей, но..., качество датасетов будет посредственное. Честно говоря я тяну с их подключением так долго как могу не потому что это сложно, а потому что качество содержания поискового индекса снизится, у этих источников нет ссылок на ресурсы. Потому что все они агрегируют через OAI-PMH 2.0 Если бы единственным критерием качества в Dateno было бы только число записей, то вопросов бы не было.
Итого это развёрнутый ответ на невысказанный вопрос "Почему в Dateno так мало научных данных, всего 488 тысяч датасетов?" Краткий ответ: из-за качества данных, а более полный ответ выше.
В любом случае крайне важно что ключевой продукт Dateno, резко отличающий его от Google Dataset Search, - это открытый индекс. Помимо открытого API к поиску это ещё и открытый реестр каталогов данных и открытая статистика.
При этом открытый индекс - это большая ответственность потому что все косяки вылезают наружу достаточно быстро, ошибки находятся, также очень быстро.
Открытый индекс - это, также, дата-продукт и у него куча метрик качества о которых я когда-нибудь расскажу в подробностях, но скорее это будет в форме выступления на конференции чем короткая заметка.
А пока покажу некоторые существенные отличия и сравнение GDS (Google Dataset Search) и Dateno.
#opendata #dateno #thoughts #datacatalogs #datasets
В реестре каталогов данных Dateno сейчас 874 репозитория научных данных из которых проиндексировано пока только 99 репозиториев, а это чуть более 11% источников метаданных такого типа. И даже эти 874 репозитория - это не все репозитории научных данных в мире, а наиболее очевидные. Точное число, скорее всего, никто не знает потому что реестры вроде Re3Data и Fairsharing более широко трактуют научные дата-ресурсы и включают туда не только каталоги данных, но и базы данных.
Возвращаясь к источникам, в чём с ними сложность:
1. Коммерческие каталоги научных данных вроде облачных продуктов Elsevier и Figshare значительно ограничивают возможности их индексирования. Проиндексировать их можно, но высока вероятность блокировок с их стороны. это примерно 34% каталогов научных данных в реестре Dateno.
2. Каталоги результатов научной деятельности на DSpace легко индексируются, но устроены так что невозможно отдельно индексировать только датасеты. Чтобы проиндексировать их надо скачать все метаданные всех объектов и далее уже фильтровать датасеты. Причем последних будет не более 5% от всего общего числа материалов
3. Некоторые каталоги научных данных вроде тех что основаны Thredds или Galaxy имеют очень скудный набор метаданных, по сути они выглядят как большие научные файлохранилища. Правда и области применения у них узкие: метеорология и биоинформатика, поэтому они пока отложены
4. Для научных репозиториев данных главное API до сих пор это OAI-PMH 2.0. Очень унаследованное, очень неудобное по многим критериям, очень стандартизированное и обладающее критическим недостатком: оно не отдаёт ссылки на файлы в метаданных. Иначе говоря карточку датасета получить можно с базовыми полями метаданных, но метаданных связанных с ним файлов нельзя. Это решается, но тем не менее.
5. Есть очень крупные источники научных наборов данных в OpenAIRE, ScienceDB, ScienceBase, DataCite, BASE и ещё ряде других. Проиндексировав даже парочку из них можно добавить сразу +10-20 миллионов записей, но..., качество датасетов будет посредственное. Честно говоря я тяну с их подключением так долго как могу не потому что это сложно, а потому что качество содержания поискового индекса снизится, у этих источников нет ссылок на ресурсы. Потому что все они агрегируют через OAI-PMH 2.0 Если бы единственным критерием качества в Dateno было бы только число записей, то вопросов бы не было.
Итого это развёрнутый ответ на невысказанный вопрос "Почему в Dateno так мало научных данных, всего 488 тысяч датасетов?" Краткий ответ: из-за качества данных, а более полный ответ выше.
В любом случае крайне важно что ключевой продукт Dateno, резко отличающий его от Google Dataset Search, - это открытый индекс. Помимо открытого API к поиску это ещё и открытый реестр каталогов данных и открытая статистика.
При этом открытый индекс - это большая ответственность потому что все косяки вылезают наружу достаточно быстро, ошибки находятся, также очень быстро.
Открытый индекс - это, также, дата-продукт и у него куча метрик качества о которых я когда-нибудь расскажу в подробностях, но скорее это будет в форме выступления на конференции чем короткая заметка.
А пока покажу некоторые существенные отличия и сравнение GDS (Google Dataset Search) и Dateno.
#opendata #dateno #thoughts #datacatalogs #datasets
Telegram
Ivan Begtin
Dateno: первые опыты
Современная наука во многом построена на больших массивах данных, доступ к которым можно получить через репозитории, однако инструментов, позволяющих осуществлять поиск сразу по нескольким из них не так много. Так, Google Dataset Search…
Современная наука во многом построена на больших массивах данных, доступ к которым можно получить через репозитории, однако инструментов, позволяющих осуществлять поиск сразу по нескольким из них не так много. Так, Google Dataset Search…
В качестве некоторых, самых очевидных примеров почему Dateno эффективнее поиска данных через GDS. Разница ощущается когда ищешь запросы связанные с экономикой и наиболее популярные у SEO'шников коммерческих сервисов. Например, поиск по ключевым словам "andorra population" и многим другим.
Google, даже в режиме поиска по бесплатным датасетам (режим Free) выдаёт в первой 20 результатов:
- tradingeconomics.com
- theglobaleconomy.com
- napoleoncat.com
Ни один из них ни открытым, ни свободным не является. Надо платить деньги и регистрироваться. Иначе говоря разметка Schema.org для этих датасетов на этих сайтах - недостоверная.
И среди них только где-то в глубине есть в глубине ссылка на data.humdata.org (проект ООН с данными статистики).
В Dateno первыми результатами идут данные Всемирного банка, данные ВОЗ, данные data.humdata.org и данные сообщества AmeriGEOSS.
А если мы изменим текст и напишем его на испанском Poblacion Andorra (Население Андорры) , то GDS не вернет результатов вовсе, а в Dateno результат найдётся.
Почему так? Потому что Google не индексирует каталоги геоданных потому что они не поддерживают Schema.org
Это один пример из многих, по мере индексации национальных статистических баз данных результаты поиска Dateno будут даже лучше.
#opendata #datasets #gds #dateno #andorra #statistics
Google, даже в режиме поиска по бесплатным датасетам (режим Free) выдаёт в первой 20 результатов:
- tradingeconomics.com
- theglobaleconomy.com
- napoleoncat.com
Ни один из них ни открытым, ни свободным не является. Надо платить деньги и регистрироваться. Иначе говоря разметка Schema.org для этих датасетов на этих сайтах - недостоверная.
И среди них только где-то в глубине есть в глубине ссылка на data.humdata.org (проект ООН с данными статистики).
В Dateno первыми результатами идут данные Всемирного банка, данные ВОЗ, данные data.humdata.org и данные сообщества AmeriGEOSS.
А если мы изменим текст и напишем его на испанском Poblacion Andorra (Население Андорры) , то GDS не вернет результатов вовсе, а в Dateno результат найдётся.
Почему так? Потому что Google не индексирует каталоги геоданных потому что они не поддерживают Schema.org
Это один пример из многих, по мере индексации национальных статистических баз данных результаты поиска Dateno будут даже лучше.
#opendata #datasets #gds #dateno #andorra #statistics
Написал очередной лонгрид про то почему так непросто искать данные по России и из России. Целый жанр уже который можно обозвать как "почему всё не так хорошо как хотелось бы, но не до конца так плохо как многие опасаются".
#opendata #dateno #data #datasets #russia
#opendata #dateno #data #datasets #russia
Ivan’s Begtin Newsletter on digital, open and preserved government
Почему данные по России так непросто найти
Легче найти иголку в стогу сена если она там есть, чем стог сена в поле если его там нет.
В рубрике как это устроено у них я уже несколько раз писал про проект DBNomics [1] от французского think tank'а Cepremap и поддерживаемый пр-вом Франции.
Это огромный каталог, в основном, макроэкономических показателей из 92 источников, и в виде 35 тысяч датасетов и 1.4 миллиона временных рядов.
Реально огромная база индикаторов из всех ключевых источников. Чем-то похоже на то что у нас в Dateno, с той лишь разницей что в Dateno индикаторы - это лишь часть индексируемых данных и индексируются индикаторы вообще все, а не только экономические, но число источников пока и больше и меньше. Больше потому что сбор из стандартизированных источников, а меньше потому что основные данные не в них а в крупных больших базах индикаторов для которых надо писать отдельные парсеры.
Тем не менее, в нашей трактовке то что в DBNomics называется временным рядом, у нас скорее это датасет. Возможно даже, нам надо добавить отдельную типизацию данных по типам для большей точности.
Глядя на DBNomics всегда возникает вопрос, надо ли его индексировать или рассматривать только как источник информации о каталогах данных? Потому что он не первоисточник и по мере индексации первичных источников будет много дублей. А с другой стороны, данные в нём представлены куда более удобно и с ними легче работать.
До конца года хочется подключить к Dateno ещё хотя бы 5-6 миллионов наборов данных, что не так сложно, как хочется максимальной пользы от этого.
А у DBNomics также, есть открытый код, кстати, хорошее API и вообще это скорее дата продукт полноценный чем просто статистический портал.
Ссылки:
[1] https://db.nomics.world
#opendata #statistics #indicators #france #dateno
Это огромный каталог, в основном, макроэкономических показателей из 92 источников, и в виде 35 тысяч датасетов и 1.4 миллиона временных рядов.
Реально огромная база индикаторов из всех ключевых источников. Чем-то похоже на то что у нас в Dateno, с той лишь разницей что в Dateno индикаторы - это лишь часть индексируемых данных и индексируются индикаторы вообще все, а не только экономические, но число источников пока и больше и меньше. Больше потому что сбор из стандартизированных источников, а меньше потому что основные данные не в них а в крупных больших базах индикаторов для которых надо писать отдельные парсеры.
Тем не менее, в нашей трактовке то что в DBNomics называется временным рядом, у нас скорее это датасет. Возможно даже, нам надо добавить отдельную типизацию данных по типам для большей точности.
Глядя на DBNomics всегда возникает вопрос, надо ли его индексировать или рассматривать только как источник информации о каталогах данных? Потому что он не первоисточник и по мере индексации первичных источников будет много дублей. А с другой стороны, данные в нём представлены куда более удобно и с ними легче работать.
До конца года хочется подключить к Dateno ещё хотя бы 5-6 миллионов наборов данных, что не так сложно, как хочется максимальной пользы от этого.
А у DBNomics также, есть открытый код, кстати, хорошее API и вообще это скорее дата продукт полноценный чем просто статистический портал.
Ссылки:
[1] https://db.nomics.world
#opendata #statistics #indicators #france #dateno
Вдогонку к порталу данных Нацбанка Казахстана, сделаю краткий обзор состояния открытых данных в Республике Казахстан.
Во первых, конечно, начать стоит с профиля страны [1] у нас в реестре Dateno там сейчас 38 каталогов данных и вскоре пополнится большим их числом.
Что можно сказать про Казахстан?
1. Много порталов геоданных, причём многие на каких-то собственных разработках, но есть и на открытом коде. В частности проект Национальная инфраструктура пространственных данных Республики Казахстан [2] работает на GeoNode и содержит 183 набора данных. На самом деле материалов там должно быть куда больше, ранее там всё было общедоступно, но теперь требуется авторизация с электронной подписью. Ещё ряд геопорталов доступны в виде серверов ArcGIS и Geoserver
2. Портал открытых данных РК [3], к сожалению, не открытых. Раньше для любой операции требовалась авторизация, а сейчас просто ограничивают выгрузку по 100 записей (!) из набора данных. Пожалуй худшая из практик в РК по публикации данных
3. Water resources data portal [4] портал данных водных ресурсов который делают в стартапе Ozen-M. Данных там немного, но датасеты хорошо организованы и все опубликованы на Github.
4. Статистическая система ТАЛДАУ [5] статслужбы РК, что удобно - наличие API и есть экспорт данных. Правда только в Excel. Выглядит работоспособно, хотя и довольно консервативно.
5. Почти нет открытых научных данных. У университетов есть развёрнутые репозитории публикаций, но датасеты среди них упоминаются только в репозитории научных результатов Университета Назарбаева и только единожды [6]. В целом такая же картина во многих постсоветских странах, не только в РК
6. Оказывается была/есть небольшая активность и группа Open Data Kazakhstan [7] на Github, но не очень масштабная и небольшими всплесками.
7. То что я знаю так то что в рамках Smart Data Ukimet в Казахстане экспериментируют сейчас с развертыванием австралийского проекта Magda [8], но пока это из пушки по воробьям, потому что Magda тяжёлый продукт и оправдывает себя на десятках тысяч наборов данных. Публичного анонса этого я не видел, поэтому прямой ссылки не даю
—
Какое-то время назад мы с коллегами думали про создание портала/порталов данных по странам Центральной Азии, но в итоге с запуском Dateno сфокусировались на индексации всех данных туда и сейчас в Dateno более 34 тысяч наборов данных классифицированных как относящихся к Казахстану [9]. Все они относятся к открытым индикаторам из международных баз данных и к геоданным. По мере того как мы улучшим инструменты геоклассификации, из других источников добавится ещё 5-6 тысяч наборов данных.
Данных о территории РК, также, много в тех глобальных каталогах научных данных о Земле которые мы ещё пока не проиндексировали.
Ссылки:
[1] https://dateno.io/registry/country/KZ/
[2] https://map.gov.kz
[3] https://data.egov.kz
[4] https://data.qiot.kz/en
[5] https://taldau.stat.gov.kz
[6] https://research.nu.edu.kz/en/publications/?type=%2Fdk%2Fatira%2Fpure%2Fresearchoutput%2Fresearchoutputtypes%2Fnontextual%2Fdatabase&nofollow=true
[7] https://github.com/open-data-kazakhstan/
[8] https://magda.io
[9] https://dateno.io/search?refinementList%5Bsource.countries.name%5D%5B0%5D=Kazakhstan
#opendata #data #kazakhstan #datasets #dateno
Во первых, конечно, начать стоит с профиля страны [1] у нас в реестре Dateno там сейчас 38 каталогов данных и вскоре пополнится большим их числом.
Что можно сказать про Казахстан?
1. Много порталов геоданных, причём многие на каких-то собственных разработках, но есть и на открытом коде. В частности проект Национальная инфраструктура пространственных данных Республики Казахстан [2] работает на GeoNode и содержит 183 набора данных. На самом деле материалов там должно быть куда больше, ранее там всё было общедоступно, но теперь требуется авторизация с электронной подписью. Ещё ряд геопорталов доступны в виде серверов ArcGIS и Geoserver
2. Портал открытых данных РК [3], к сожалению, не открытых. Раньше для любой операции требовалась авторизация, а сейчас просто ограничивают выгрузку по 100 записей (!) из набора данных. Пожалуй худшая из практик в РК по публикации данных
3. Water resources data portal [4] портал данных водных ресурсов который делают в стартапе Ozen-M. Данных там немного, но датасеты хорошо организованы и все опубликованы на Github.
4. Статистическая система ТАЛДАУ [5] статслужбы РК, что удобно - наличие API и есть экспорт данных. Правда только в Excel. Выглядит работоспособно, хотя и довольно консервативно.
5. Почти нет открытых научных данных. У университетов есть развёрнутые репозитории публикаций, но датасеты среди них упоминаются только в репозитории научных результатов Университета Назарбаева и только единожды [6]. В целом такая же картина во многих постсоветских странах, не только в РК
6. Оказывается была/есть небольшая активность и группа Open Data Kazakhstan [7] на Github, но не очень масштабная и небольшими всплесками.
7. То что я знаю так то что в рамках Smart Data Ukimet в Казахстане экспериментируют сейчас с развертыванием австралийского проекта Magda [8], но пока это из пушки по воробьям, потому что Magda тяжёлый продукт и оправдывает себя на десятках тысяч наборов данных. Публичного анонса этого я не видел, поэтому прямой ссылки не даю
—
Какое-то время назад мы с коллегами думали про создание портала/порталов данных по странам Центральной Азии, но в итоге с запуском Dateno сфокусировались на индексации всех данных туда и сейчас в Dateno более 34 тысяч наборов данных классифицированных как относящихся к Казахстану [9]. Все они относятся к открытым индикаторам из международных баз данных и к геоданным. По мере того как мы улучшим инструменты геоклассификации, из других источников добавится ещё 5-6 тысяч наборов данных.
Данных о территории РК, также, много в тех глобальных каталогах научных данных о Земле которые мы ещё пока не проиндексировали.
Ссылки:
[1] https://dateno.io/registry/country/KZ/
[2] https://map.gov.kz
[3] https://data.egov.kz
[4] https://data.qiot.kz/en
[5] https://taldau.stat.gov.kz
[6] https://research.nu.edu.kz/en/publications/?type=%2Fdk%2Fatira%2Fpure%2Fresearchoutput%2Fresearchoutputtypes%2Fnontextual%2Fdatabase&nofollow=true
[7] https://github.com/open-data-kazakhstan/
[8] https://magda.io
[9] https://dateno.io/search?refinementList%5Bsource.countries.name%5D%5B0%5D=Kazakhstan
#opendata #data #kazakhstan #datasets #dateno
Open Data
Сервис предоставляет возможость найти наборы данных в форматах XML, EXCEL, JSON.
Про метрики качества данных и дата продуктов.
Я ранее писал про метрики качества в Dateno и что количество проиндексированных датасетов является важной метрикой, но далеко не единственной. Кроме него важно ещё то какие именно датасеты и их представленность - это метрика разнообразия данных, ещё важна метрика разнообразия источников данных, а то есть чтобы вся база не состояла только из научных данных или только из статистики. Ещё есть метрики глубины охвата, качества метаданных, частоты обновления и тд.
И, наконец, важная лично для меня метрика - это метрика географического охвата. Одна из изначальных идей была в том что Dateno Должно охватывать вообще все страны и территории мира. А то есть данные должны быть не только по крупнейшим развитым странам (это особенность научных каталогов данных), но и по малым развивающимся странам.
И вот, ура-ура, в последнем обновлении Dateno эта цель была окончательно достигнута. В Dateno сейчас есть датасеты привязанные ко всем странам и зависимым территориям в мире, по крайней мере при проверке по реестру стран Всемирного банка.
Как это получилось? Главное - это глобальные базы статистики международных организаций. Даже если у страны нет веб-сайта и доступа в Интернет, статистические службы взаимодействуют с ООН и статистика о них накапливается в глобальных базах индикаторов. Дальше вопрос только сбора этих данных и привязывания к странам.
Второй фактор - это то что у многих развивающихся стран нет порталов открытых данных, но есть геосервера и геопорталы которые и проиндексированы в Dateno.
Геоданных в развивающихся странах тоже мало, но больше чем открытых данных.
Итого по каждой стране есть, как минимум, данные индикаторов. Эти данные настолько хороши и полны, насколько они полны в данных первоисточников. Поэтому теперь метрика полноты данных в Dateno для меня звучит как географическое разнообразие данных не являющихся индикаторами.
И по этому критерию у нас нет датасетов по 38 странам, все они наименее развитые, или островные или иные микрогосударства. По многим из них есть каталоги данных в реестре, но пока они не проиндексированы поскольку, или нестандартны, или блокируют внешний доступ или с ними что-то ещё не так.
При этом список можно сократить и охватить почти все страны привязать к ним датасеты из других глобальных каталогов вроде Humanitarian Data Exchange или датасетов наук о земле, которые привязаны де-факто не к юрисдикации, а к инструментам/командам наблюдения и публикации научной работы.
#opendata #dateno #data #datasets
Я ранее писал про метрики качества в Dateno и что количество проиндексированных датасетов является важной метрикой, но далеко не единственной. Кроме него важно ещё то какие именно датасеты и их представленность - это метрика разнообразия данных, ещё важна метрика разнообразия источников данных, а то есть чтобы вся база не состояла только из научных данных или только из статистики. Ещё есть метрики глубины охвата, качества метаданных, частоты обновления и тд.
И, наконец, важная лично для меня метрика - это метрика географического охвата. Одна из изначальных идей была в том что Dateno Должно охватывать вообще все страны и территории мира. А то есть данные должны быть не только по крупнейшим развитым странам (это особенность научных каталогов данных), но и по малым развивающимся странам.
И вот, ура-ура, в последнем обновлении Dateno эта цель была окончательно достигнута. В Dateno сейчас есть датасеты привязанные ко всем странам и зависимым территориям в мире, по крайней мере при проверке по реестру стран Всемирного банка.
Как это получилось? Главное - это глобальные базы статистики международных организаций. Даже если у страны нет веб-сайта и доступа в Интернет, статистические службы взаимодействуют с ООН и статистика о них накапливается в глобальных базах индикаторов. Дальше вопрос только сбора этих данных и привязывания к странам.
Второй фактор - это то что у многих развивающихся стран нет порталов открытых данных, но есть геосервера и геопорталы которые и проиндексированы в Dateno.
Геоданных в развивающихся странах тоже мало, но больше чем открытых данных.
Итого по каждой стране есть, как минимум, данные индикаторов. Эти данные настолько хороши и полны, насколько они полны в данных первоисточников. Поэтому теперь метрика полноты данных в Dateno для меня звучит как географическое разнообразие данных не являющихся индикаторами.
И по этому критерию у нас нет датасетов по 38 странам, все они наименее развитые, или островные или иные микрогосударства. По многим из них есть каталоги данных в реестре, но пока они не проиндексированы поскольку, или нестандартны, или блокируют внешний доступ или с ними что-то ещё не так.
При этом список можно сократить и охватить почти все страны привязать к ним датасеты из других глобальных каталогов вроде Humanitarian Data Exchange или датасетов наук о земле, которые привязаны де-факто не к юрисдикации, а к инструментам/командам наблюдения и публикации научной работы.
#opendata #dateno #data #datasets
Telegram
Ivan Begtin
Я тут задумался о KPI которые должны/могут быть у поисковика по данным, если рассматривать его как глобальный, причём эти критерии могут существенно как пересекаться так и давать разные направления усилий.
Например, критерий разнообразности. То что данные…
Например, критерий разнообразности. То что данные…
К вопросу, во многом философскому, но с практическим умыслом, о том что считать данными, а что нет приведу пример в временными рядами. Не для всех, но для многих пользователей данные имеют географическую привязку и работая даже с большой данных стат наблюдений интересуют конкретные страны/страна и временной ряд получаемый из этой большой базы также имеет привязку к одной или двум странам. Но есть и задачи когда надо работать с базой целиком.
На некоторых порталах открытых данных, таких как портал данных ЕЦБ или Банка международных расчётов есть понятие набора данных, их мало и они велики, и есть понятие как раз временного ряда у каждого из которых есть пермалинк. Потребители есть у обоих типов данных. В Dateno эти данные уже частично агрегируются, около 30% карточек в Dateno - это агрегированные временные ряды и это оправдано поскольку пользователи, напомню, ищут чаще в привязке к территории. Но это выходит что отдельный тип данных, который может быть, а может не быть отдельным датасетом. Потому что ещё бывает так что временные ряды публикуют как-то ещё, а не в базе статистики. Что с этим делать для большей понятности? По хорошему разделять наборы данных и временные ряды, дать возможность фильтровать в поиске только их.
Аналогичным образом с геоданными/слоями карт. Слои карт - это чаще всего не файлы, а ссылки на точки подключения к API - ArcGIS или OGC. Их можно рассматривать как наборы данных, и иногда и часто так рассматривают, но, по хорошему, это некоторое отдельное явление, которое так и надо называть "Map layer".
Таких видов данных есть ещё некоторое количество, я же добавлю ещё что кроме них есть и более сложные случаи. Например, фиды новостей RSS и ATOM. Они данные или нет? ATOM фидов довольно много, только на европейском портале данных их более 141 тысячи, поскольку они являются одним из способов экспорта и доступа к геоданным на платформах на базе Geonetwork и ряда других.
ATOM Feed'ы также используются в каталогах данных на базе Thredds для доступа к метеорологическим данным.
Но, также их условно бесконечное число разбросано по интернету, как для доступа к новостям на сайтах, так и ко многим другим типам контента.
Можно ли выделять ATOM/RSS как отдельную категорию API и рассматривать их как данные и индексировать, например, нам в Dateno?
Ответ на этот вопрос содержится в контрвопросах - А зачем? А кому это нужно?
Один из важнейших критериев отнесения цифровых объектов/артефактов в к данным - это их востребованность целевой аудиторией тех кто с данными работает: дата инженеров, дата сайентистов, дата аналитиков, геоаналитиков, статистиков, экономистов, бизнес аналитиков и так далее.
И таких примеров очень много и всё больше возникает в процесс обнаружения новых, потенциально интересных источников данных.
P.S. Мне давно уже пора завести рубрику #whatisdata, пожалуй, буду помечать будущие размышления на эту тему именно ей
#whatisdata #thoughts #dateno #data
На некоторых порталах открытых данных, таких как портал данных ЕЦБ или Банка международных расчётов есть понятие набора данных, их мало и они велики, и есть понятие как раз временного ряда у каждого из которых есть пермалинк. Потребители есть у обоих типов данных. В Dateno эти данные уже частично агрегируются, около 30% карточек в Dateno - это агрегированные временные ряды и это оправдано поскольку пользователи, напомню, ищут чаще в привязке к территории. Но это выходит что отдельный тип данных, который может быть, а может не быть отдельным датасетом. Потому что ещё бывает так что временные ряды публикуют как-то ещё, а не в базе статистики. Что с этим делать для большей понятности? По хорошему разделять наборы данных и временные ряды, дать возможность фильтровать в поиске только их.
Аналогичным образом с геоданными/слоями карт. Слои карт - это чаще всего не файлы, а ссылки на точки подключения к API - ArcGIS или OGC. Их можно рассматривать как наборы данных, и иногда и часто так рассматривают, но, по хорошему, это некоторое отдельное явление, которое так и надо называть "Map layer".
Таких видов данных есть ещё некоторое количество, я же добавлю ещё что кроме них есть и более сложные случаи. Например, фиды новостей RSS и ATOM. Они данные или нет? ATOM фидов довольно много, только на европейском портале данных их более 141 тысячи, поскольку они являются одним из способов экспорта и доступа к геоданным на платформах на базе Geonetwork и ряда других.
ATOM Feed'ы также используются в каталогах данных на базе Thredds для доступа к метеорологическим данным.
Но, также их условно бесконечное число разбросано по интернету, как для доступа к новостям на сайтах, так и ко многим другим типам контента.
Можно ли выделять ATOM/RSS как отдельную категорию API и рассматривать их как данные и индексировать, например, нам в Dateno?
Ответ на этот вопрос содержится в контрвопросах - А зачем? А кому это нужно?
Один из важнейших критериев отнесения цифровых объектов/артефактов в к данным - это их востребованность целевой аудиторией тех кто с данными работает: дата инженеров, дата сайентистов, дата аналитиков, геоаналитиков, статистиков, экономистов, бизнес аналитиков и так далее.
И таких примеров очень много и всё больше возникает в процесс обнаружения новых, потенциально интересных источников данных.
P.S. Мне давно уже пора завести рубрику #whatisdata, пожалуй, буду помечать будущие размышления на эту тему именно ей
#whatisdata #thoughts #dateno #data
Я тут задумался над тем какие практические инструменты с LLM внутри я использую в работе и для чего хотелось бы использовать ещё. Хотелось бы, для многого конечно, но не всё ещё существует
Самое очевидное это переписывание текстов с помощью DeepL Write. Очень удобно для переписке и публикаций не на родном языке, поскольку сильно выправляет текст. Похоже на Grammarly, но ощущение что итоговый текст гораздо лучше и поддерживается не только английский язык. Главный минус пока только в том что поддерживаются только 8 языков. В любом случае очень удобно для публикации в англоязычных и других соцсетях
Совсем не такое очевидное, но важное для меня это сбор информации о дата каталогах. Это довольно специфическая лично моя задача по обновлению реестра каталогов данных в Dateno. Этот процесс на текущей стадии ручной, поскольку автоматизированный ранее собранных каталогов уже выполнен и оставшаяся часть работы - это ручная разметка. В частности вручную проставляется инфа по каталогу данных:
- название
- описание
- название владельца
- тип владельца (гос-во, муниципалитет, ученые и тд.)
- тематики
- теги
А также простановка геопривязки для тех ресурсов у которых её нет или если выясняется что они уровня регионов.
Это много ручной работы напрямую влияющей на качество данных в Dateno, поскольку тип владельца, геопривязки и тематики идут в фасеты поиска, а остальные поля отображаются в карточках датасетов.
Оказалось что Perplexity отлично выдаёт ответы на такие вопросы как:
- Who owns <> website ?
- About what this website is <> ?
А также, что очень практически удобно, Perplexity умеет точно отвечать на такие вопросы как "What is ISO3166-2 code of the Magallanes and Chilean Antarctica ?" и выдавать точный код.
Скорее всего Perplexity можно заменить на другую модель, но и текущие результаты вполне полезны.
Сейчас в Dateno около 18% (3.4 миллиона) наборов данных не имеют пометки типа владельца данных, а 2.4 миллиона не имеют привязки к стране/территории.
Это, в любом случае лучше чем у Google Dataset Search, но всё ещё недостаточно хорошо.
Применение LLM в повышении качества метаданных кажется очень реалистичной задачей.
#ai #thoughts #dateno #datasets #data
Самое очевидное это переписывание текстов с помощью DeepL Write. Очень удобно для переписке и публикаций не на родном языке, поскольку сильно выправляет текст. Похоже на Grammarly, но ощущение что итоговый текст гораздо лучше и поддерживается не только английский язык. Главный минус пока только в том что поддерживаются только 8 языков. В любом случае очень удобно для публикации в англоязычных и других соцсетях
Совсем не такое очевидное, но важное для меня это сбор информации о дата каталогах. Это довольно специфическая лично моя задача по обновлению реестра каталогов данных в Dateno. Этот процесс на текущей стадии ручной, поскольку автоматизированный ранее собранных каталогов уже выполнен и оставшаяся часть работы - это ручная разметка. В частности вручную проставляется инфа по каталогу данных:
- название
- описание
- название владельца
- тип владельца (гос-во, муниципалитет, ученые и тд.)
- тематики
- теги
А также простановка геопривязки для тех ресурсов у которых её нет или если выясняется что они уровня регионов.
Это много ручной работы напрямую влияющей на качество данных в Dateno, поскольку тип владельца, геопривязки и тематики идут в фасеты поиска, а остальные поля отображаются в карточках датасетов.
Оказалось что Perplexity отлично выдаёт ответы на такие вопросы как:
- Who owns <> website ?
- About what this website is <> ?
А также, что очень практически удобно, Perplexity умеет точно отвечать на такие вопросы как "What is ISO3166-2 code of the Magallanes and Chilean Antarctica ?" и выдавать точный код.
Скорее всего Perplexity можно заменить на другую модель, но и текущие результаты вполне полезны.
Сейчас в Dateno около 18% (3.4 миллиона) наборов данных не имеют пометки типа владельца данных, а 2.4 миллиона не имеют привязки к стране/территории.
Это, в любом случае лучше чем у Google Dataset Search, но всё ещё недостаточно хорошо.
Применение LLM в повышении качества метаданных кажется очень реалистичной задачей.
#ai #thoughts #dateno #datasets #data
В рубрике как это устроено у них порталы данных эпидемиологических исследований, для них существует специальное ПО с открытым кодом Obiba Mica [1], я в прошлом году упоминал [2] портал с данными по COVID-19, но это далеко не единственный такой проект с данными.
На базе Obiba Mica работает несколько десятков порталов данных в рамках проектов RECAP Preterm [3], европейский проект мониторинга детей с недостаточным весом и рождённых до срока и EUCAN Connect [4] совместные проекты Евросоюза и Канады в области персонализированной и превентивной медицины. Инсталляции на базе Obiba Mica разбросаны по разным странам: Испания [5], Португалия [6] и многие другие.
В чём особенность этих порталов? Во первых они не содержат открытые данные. Практически всегда содержащиеся там данные - это медицинские сведения, даже если они деперсонализированы, они более всего похожи на микроданные переписей и также организованы.
У датасетов есть переменные и метаданные которые детально описаны, доступны, стандартизированы, но сами данные доступны только после регистрации, направления запроса и получения подтверждения.
И, конечно, это продукт с открытым исходным кодом [7].
Во многих научных дисциплинах есть специализированные продукты/каталоги данных используемых для доступа к данным исследований в форме специфичной для этой дисциплины и Obiba Mica - это один из таких примеров.
В реестре Dateno есть около 20 дата порталов на базе Obiba Mica, в дикой среде их ещё где-то столько же, но в индексе Dateno их нет, поскольку данные из таких каталогов недоступны, а есть только метаданные. А это снижает приоритет индексирования, не говоря уже о том что наборов данных в таких порталах немного, от единиц до пары сотен датасетов.
Ссылки:
[1] https://www.obiba.org/pages/products/mica/
[2] https://t.iss.one/begtin/5053
[3] https://recap-preterm.eu/
[4] https://eucanconnect.com/
[5] https://coral.igtp.cat/pub/
[6] https://recap-ispup.inesctec.pt/pub/
[7] https://github.com/obiba
#opendata #datacatalogs #datasets #dateno #microdata #epidemiology
На базе Obiba Mica работает несколько десятков порталов данных в рамках проектов RECAP Preterm [3], европейский проект мониторинга детей с недостаточным весом и рождённых до срока и EUCAN Connect [4] совместные проекты Евросоюза и Канады в области персонализированной и превентивной медицины. Инсталляции на базе Obiba Mica разбросаны по разным странам: Испания [5], Португалия [6] и многие другие.
В чём особенность этих порталов? Во первых они не содержат открытые данные. Практически всегда содержащиеся там данные - это медицинские сведения, даже если они деперсонализированы, они более всего похожи на микроданные переписей и также организованы.
У датасетов есть переменные и метаданные которые детально описаны, доступны, стандартизированы, но сами данные доступны только после регистрации, направления запроса и получения подтверждения.
И, конечно, это продукт с открытым исходным кодом [7].
Во многих научных дисциплинах есть специализированные продукты/каталоги данных используемых для доступа к данным исследований в форме специфичной для этой дисциплины и Obiba Mica - это один из таких примеров.
В реестре Dateno есть около 20 дата порталов на базе Obiba Mica, в дикой среде их ещё где-то столько же, но в индексе Dateno их нет, поскольку данные из таких каталогов недоступны, а есть только метаданные. А это снижает приоритет индексирования, не говоря уже о том что наборов данных в таких порталах немного, от единиц до пары сотен датасетов.
Ссылки:
[1] https://www.obiba.org/pages/products/mica/
[2] https://t.iss.one/begtin/5053
[3] https://recap-preterm.eu/
[4] https://eucanconnect.com/
[5] https://coral.igtp.cat/pub/
[6] https://recap-ispup.inesctec.pt/pub/
[7] https://github.com/obiba
#opendata #datacatalogs #datasets #dateno #microdata #epidemiology