Ivan Begtin

Я периодически рассказываю о внутренностях не только Dateno, но и реестра каталогов данных на которых он основан. Я начинал его делать ещё в до самого поисковика и изначально он был разделен на две части.

1-я - это чистовые дата каталоги, по которым метаданные, в основном, собранные вручную. Они были в репозитории в каталоге entries и каждая запись выглядела как YAML файл по определённой структуре. У них был префикс 'cdi' для идентификаторов.

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

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

Поэтому одно из важных актуальных изменений реестра в том чтобы свести их в единую модель. И сейчас в последней версии реестра на Github'е [1] лежит датасет с переназначенными идентификаторами и теперь можно приступать к повышению качества каталога автоматизировав присвоение тегов, тем и описаний каждому из них. Это, кстати, то для чего можно применить LLM почти наверняка.

Но это то что является disruptive change поскольку даже временные каталоги данных индексировались в Dateno и их переиндексирование и обновление поиска поменяет некоторые ссылки и в реестре [2] и для датасетов в будущем. Поэтому на самом поиске это отразится не раньше чем через какое-то время, не в ближайшем обновлении.

Реестр - это важная часть качества поиска Dateno поскольку характеристики каталога данных транслируются на датасеты. Если, к примеру, источник данных посвящён здравоохранению то и его параметры переносятся на наборы данных в нём проиндексированные. Это позволяет искать даже те датасеты которые которые своих метаданных имеют мало или почти не содержат. К примеру, почти все датасеты на серверах ArcGIS и Geoserver, но вот их обогащение почти невозможно проводить автоматически, потому на них нет описания содержания этих данных. Геокаталоги, не все, но многие, автоматически документируются довольно плохо. Их наличие делает Dateno одним из наиболее полных поисковиков по геоданным, но искать их сложно если только эти данные не описаны где-то ещё, например, в каталогах Geonetwork со ссылками на георесурсы.

Ссылки:
[1] https://github.com/commondataio/dataportals-registry/
[2] https://dateno.io/registry

#dateno #opendata #datasets

GitHub

GitHub - commondataio/dataportals-registry: Registry of data portals, catalogs, data repositories including data catalogs dataset…

Registry of data portals, catalogs, data repositories including data catalogs dataset and catalog description standard - commondataio/dataportals-registry

www.group-telegram.com/jp/begtin.com/6363

856 viewsIvan Begtin, edited  Jan 15 at 19:06

Я периодически рассказываю о внутренностях не только Dateno, но и реестра каталогов данных на которых он основан. Я начинал его делать ещё в до самого поисковика и изначально он был разделен на две части.

1-я - это чистовые дата каталоги, по которым метаданные, в основном, собранные вручную. Они были в репозитории в каталоге entries и каждая запись выглядела как YAML файл по определённой структуре. У них был префикс 'cdi' для идентификаторов.

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

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

Поэтому одно из важных актуальных изменений реестра в том чтобы свести их в единую модель. И сейчас в последней версии реестра на Github'е [1] лежит датасет с переназначенными идентификаторами и теперь можно приступать к повышению качества каталога автоматизировав присвоение тегов, тем и описаний каждому из них. Это, кстати, то для чего можно применить LLM почти наверняка.

Но это то что является disruptive change поскольку даже временные каталоги данных индексировались в Dateno и их переиндексирование и обновление поиска поменяет некоторые ссылки и в реестре [2] и для датасетов в будущем. Поэтому на самом поиске это отразится не раньше чем через какое-то время, не в ближайшем обновлении.

Реестр - это важная часть качества поиска Dateno поскольку характеристики каталога данных транслируются на датасеты. Если, к примеру, источник данных посвящён здравоохранению то и его параметры переносятся на наборы данных в нём проиндексированные. Это позволяет искать даже те датасеты которые которые своих метаданных имеют мало или почти не содержат. К примеру, почти все датасеты на серверах ArcGIS и Geoserver, но вот их обогащение почти невозможно проводить автоматически, потому на них нет описания содержания этих данных. Геокаталоги, не все, но многие, автоматически документируются довольно плохо. Их наличие делает Dateno одним из наиболее полных поисковиков по геоданным, но искать их сложно если только эти данные не описаны где-то ещё, например, в каталогах Geonetwork со ссылками на георесурсы.

Ссылки:
[1] https://github.com/commondataio/dataportals-registry/
[2] https://dateno.io/registry

#dateno #opendata #datasets

BY Ivan Begtin