Exciting News from Dateno!

We are thrilled to announce that Dateno has successfully closed its latest investment round, led by Blockchair! 🎉 This marks a major milestone in our mission to revolutionize data accessibility and search.

Since our launch just a few months ago, Dateno has been rapidly growing, now indexing over 15 million datasets. By the end of 2024, we aim to expand this number to 30 million! Our platform offers a focused and advanced data search experience, supporting 13 facets for filtering results, making it easier than ever for users to find the datasets they need.
With this new investment and partnership, we’re excited to roll out major updates, including the launch of the Dateno API. This will position Dateno as the world's largest search index for data, allowing other projects to integrate our robust data search capabilities directly into their platforms.

We’re also incorporating blockchain and web3 data from Blockchair and other decentralized finance players, and we’re hard at work on AI-powered features to improve search accuracy and relevance. These enhancements will empower data analysts worldwide, making their work more intuitive, efficient, and insightful.

We’re just getting started, and we’re grateful for the support of our investors, partners, and the entire Dateno community. Stay tuned for more updates, and thank you for being part of this journey with us! 🚀✨

#Dateno #DataSearch #Investment #Innovation #AI

Про то как публикуют и работают с опубликованными датасетами расскажу про их публикацию по стандарту schema.org.

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

Особенность в том что если объекты типа Dataset ещё более-менее встречаются, то DataCatalog - это безусловная редкость. К примеру, в проекте Web Data Common за 2023 год извлечено менее миллиона (839 тысяч) ссылок на страницы с объектами Dataset и совсем нет объектов типа DataCatalog. Нет не случайно, потому что даже беглая проверка по каталогам данных в Dateno registry показывает что в лучшем случае у каждого тысячного каталога данных есть эта разметка.

А вот разметка Dataset присутствует у многих каталогов, из широко известных, к примеру, Hugging Face и Kaggle. А вот к примеру, на общеевропейском портале data.europa.eu этой разметки нет, а на национальном портале США data.gov она сокращённая и даёт только минимальные атрибуты такие как название и ключевые слова, без детализации прикреплённых ресурсов или лицензий.

При этом в команде Google, полтора года назад упоминали что в их поисковом индексе Google Dataset Search есть 45 миллионов записей с 13 тысяч сайтов. Правда у них охват шире чем у Common Crawl, а также явно кроме объектов Dataset они добавляют в индекс объекты типа DataDownload, они тоже есть в спецификации schema.org и, наконец, Google Dataset Search индексирует датасеты через разметку RDFa, а по ней нет статистики из Common Crawl. В проекте Web Data Commons нет отдельной выгрузки объектов типа Dataset для RDFa.

Основных проблем со Schema.org две.

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

Вторая в том что реально интересные каталоги данных Schema.org не поддерживают. Особенно это справедливо в отношении геоданных и геопорталы практически все используют только собственные стандарты публикации данных.

Собственно поэтому в Dateno основная индексация не через краулинг объектов Schema.org, а несколько десятков видов API.

#thoughts #datasearch #dateno

Для тех кто давно не слышал новостей про наш стартап-проект Dateno.io, поисковой системы по данным, вот самая свежая новость - мы создали личный кабинет и доступ к поисковому индексу через API. Поисковый индекс тоже растёт и составляет уже 19 миллионов наборов данных и это не предел, цель была до конца года достичь хотя бы 20 миллионов, но реально будет больше, скорее всего.

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

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

#opendata #datasearch #data #dateno

Dateno Expands Data Capabilities for Professionals with API and Dashboard Tools!

We are thrilled to announce the launch of two powerful tools designed specifically for data professionals: the My Dateno personal dashboard and the Dateno API! These updates will greatly enhance your ability to manage and integrate data search into your workflows.

With My Dateno, users can now track their search history and access API keys, making it easier than ever to tap into Dateno's extensive data search capabilities. In the future, My Dateno will also provide access to premium features and additional data services. Plus, those who join our early access program will get free access to these new features during the testing period!

The Dateno API enables developers and businesses to integrate our platform’s search functionality directly into their products and infrastructure. This API offers fast, efficient search across 19 million datasets—including data files, geoAPI connections, and statistical indicators—with powerful filtering options. Retrieve comprehensive metadata and related resources, and streamline your data processing with ease.

We’re excited to empower data professionals with these new tools! 🚀

Learn more and sign up for early access at dateno.io

#Dateno #DataSearch #API #Innovation #DataIntegration #DataProfessionals

Мы пока ещё не закинули описания вакансий в телеграм канал Dateno, но скоро это сделаем. Пока напишу в режиме пред-анонса. Мы ищем Data engineer, AI engineer и Frontend developer в наш проект. Вот тут наш технологический стек (MongoDB, Python, React, Meilisearch) и много data инженерных задач, потребность в AI экспериментах и необходимость в разработке интерфейса. Работа дистанционная, идеально если кандидаты в Армении, но рассмотрим и в других странах. А делаем мы инновационный поиск по датасетам с очень большим и открытым поисковым индексом, API и множеством дополнительных фич.

Позиции не для джуниоров, ну или если джуниоров то problem solving навыки должны быть прокачены. Для инженеров навыки по построению конвееров данных (data pipelines) обязательны, а для фронтендера важно любить пользователей и думать о них.

Я чуть позже сделаю пост с вакансиями, а пока если есть резюме можно писать лично мне на ivan@begtin.tech или dateno@dateno.io.

#dateno #job #vacancies

Могу сказать что один из самых частых вопросов по Dateno - это как сделать чтобы мои данные были проиндексированы? Вопрос этот одновременно очень простой и сложный.

Модель индексирования данных в Dateno основано на доверии к источникам данных. Вместо того чтобы сканировать весь интернет на наличие датасетов, существует реестр каталогов данных [1] в котором более 10 тысяч каталогов и куча метаданных о них. Чуть более половины этих каталогов данных уже проиндексированы и доля проиндексированных постепенно растёт.

Индексирование датасетов таким образом, на самом деле, сложнее чем попытаться воспроизвести краулер Google Data Search (GDS), потому что для такого краулера можно было бы просто взять индекс Common Crawl и регулярно обновлять метаданные оттуда. Ресурсоёмкая, но интеллектуально простая задача. Если идти таким путём то немедленно всплывают все проблемы с качеством данных, с тем что существенная часть датасетов публикуется только для SEO продвижения и так далее.

Индексирование каталогов же предполагает что кто-то уже провел работу по валидации того что этот датасет не полное фуфло, а что-то осмысленное.

Поэтому как проще всего опубликовать датасеты? Проще всего, либо опубликовать на одном из каталогов данных которые Dateno индексирует. Второй вариант - это развернуть собственный каталог данных и прислать на него ссылку. Но этот каталог должен работать на типовом ПО таком как CKAN [2], DKAN [3], JKAN [4], InvenioRDM [5] и ряде других. Если Вы публикуете не один набор данных, а множество то использование типового портала для их публикации - это хорошая практика. Например, в РФ от Инфокультуры мы создавали Хаб открытых данных [6], а в Армении Data Catalog Armenia [7], оба на базе движка CKAN как наиболее продвинутого для публикации данных.

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

Тем не менее у нас в Dateno постоянно крутится идея того что иногда чтобы что-то проиндексировать, надо это что-то собрать в каталог. А Dateno не каталог, а именно поисковик. Например, крипто данные разбросаны по интернету. Возможно стоит создать каталог крипто данных и уже его проиндексировать в Dateno. Он будет указывать на первоисточники, конечно, но будет пополняем. Хорошая ли это идея? Пока непонятно, если бы был подтверждённый исследовательский интерес к теме то можно было бы хоть сразу запилить каталог данных для исследователей по этой теме.

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

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

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

Ссылки:
[1] https://dateno.io/registry
[2] https://ckan.org
[3] https://getdkan.org
[4] https://jkan.io
[5] https://inveniosoftware.org/products/rdm/
[6] https://hubofdata.ru
[7] https://data.opendata.am

#opendata #datasets #data #datasearch #dateno

Написал краткий обзор новых возможностей [1] в Dateno, включая открытую статистику, расширенный поисковый индексы, фасеты и API.

Лонгриды буду и далее разворачивать на Substack на русском языке, а на английском языке на Medium [2]

Ссылки:
[1] https://open.substack.com/pub/begtin/p/dateno?r=7f8e7&utm_campaign=post&utm_medium=web&showWelcomeOnShare=true
[2] https://medium.com/@ibegtin/just-recently-we-updated-our-dateno-dataset-search-dateno-io-065276450829

#opendata #datasearch #dateno #datadiscovery

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

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

Так вот одна из интересных особенностей Dateno - это бесконечный источник данных для обучения чего-либо. Например, у меня сейчас для экспериментальных целей уже собрано около 5TB CSV файлов из ресурсов Dateno, а также несколько миллионов мелких CSV файлов из потенциальных каталогов данных, ещё в Dateno не подключённых. А это гигантская база для обучения алгоритмов на выявление типовых паттернов и атрибутов.

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

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

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

Впрочем в Dateno проиндексированы не только CSV файлы, но и многие JSON, NetCDF, Excel, XML, KML, GeoTIFF, GML, DBF и других. Можно собирать уникальные коллекции именно для обучения.

А какие файлы для каких задач для обучения нужны вам?

#opendata #thougths #dateno #algorithms

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

Например, в Dateno есть геопривязка датасетов к странам, макрорегионам и субрегионам (территориям). Она, в большей части, реализована относительно просто. Изначально полувручную-полуавтоматически геокодированы источники данных, а их всего около 10 тысяч и далее с них геопривязка транслируется на датасеты. Это довольно простая логика работающая со всеми муниципальными и региональными порталами данных и куда хуже работающая в отношении национальных порталов данных, реестров индикаторов, каталогов научных данных и так далее.

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

Для самых крупных каталогов данных у нас есть дополнительная геопривязка датасетов через простое геокодирование стран по внутреннему справочнику и использованию pycountry.

Но это всё даёт геокодирование, максимум, 40-60% всех датасетов и многие значимые наборы данных привязки к конкретной стране/региону могут не иметь.

Что с этим делать?

Один путь - это использовать существующие открытые и коммерческие API геокодирования такие как Nominatim, Geonames, Googe, Yandex, Bing и другие. У автора библиотеки geocoder они хорошо систематизированы и можно использовать её как универсальный интерфейс, но одно дело когда надо геокодировать тысячи объектов и совсем другое когда десятки миллионов. Кроме того остаётся то ограничение что может не быть отдельных полей с данными геопривязки у первичных датасетов. На национальном портале могут быть опубликованы данные у которых геопривязка может быть только в названии или в описании, но не где-то отдельным полем.

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

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

Другой путь в попытке применить LLM для геокодирования в идеале так чтобы отправить туда JSON объект с кучей атрибутов и запросом на то чтобы по нему получить код территории/страны по ISO 3166-1 или ISO 3166-2.

Что выглядит интересно ещё и потому что у всех API геокодирования есть серьёзные ограничения на число запросов и на их кеширование.

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

#opendata #dateno #geodata #thoughts

Лично я постоянно ищу какие есть поисковики по данным, глобальные и национальные, а недавно обнаружил что оказывается такой поисковик есть у правительства Шотландии find.data.gov.scot и по многим параметрам он напоминает Dateno, что хорошо😜, но тысячу раз меньше поэтому не конкурент😂.

Итак, в Шотландии пр-во достаточно давно планирует осуществить открытие портала открытых данных data.gov.scot, но пока они этого не сделали они пошли по австралийскому пути создания национального поисковика по данным.

Всего на портале на главной странице декларируется что присутствует 17 тысяч датасетов, а на странице поиска только 11 тысяч. Метаданные о них собираются из примерно 60 источников данных (data hosts) через парсеры нескольких видов API.

Что мне нравится, ребята явно идут нашим путём и проанализировали не меньше пары сотен источников данных, систематизировали их API, идентифицировали ПО некоторых каталогов данных о которых я не знал (MetadataWorks, USmart и др.), но при этом про наш каталог Dateno registry явно не знали. Плюс у них в источниках данных многое что каталогами данных назвать нельзя, публикации файлов отдельными ведомствами, но для сбора датасетов на региональном уровне явно полезно..

В итоге поисковик у них получается, на самом деле, не совсем поисковик, поскольку у каждого датасета есть веб страница с метаданными.

Из всего что я видел - это, пока, наибольшее приближение к подходу в Dateno, за исключением, масштаба, конечно.

Если делать внутристрановой поисковик по данным то на их проект стоит обратить внимание. Они явно писали HTML парсеры под разделы статистики на многих сайтах и значительная часть датасетов там - это PDF файлы статистики нескольких инспекций.

В любом случае любопытно, в том числе как референсные оценки числа датасетов в Шотландии. В Dateno их сейчас около 8 тысяч, в этом местном поисковике их около 11 тысяч. Есть куда стремиться 🛠

#opendata #scotland #datasets #data #datasearch #dateno

К вопросу о дата-инженерии и 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