Про разного рода технически сложные задачи и их решения.
Я тут регулярно пишу про разные форматы файлов данных и могу сказать что, конечно, файловых форматов как и стандартов какое-то бесконечное количество. Когда-то я и сам делал и периодически обновляю инструменты вроде undatum [1] по работе с некоторыми из них. Так в undatum я недавно добавил работу с множеством алгоритмов сжатия обработкой файлов с минимизацией объёма их хранения и нагрузкой на оперативную память, с быстрым преобразованием из JSON lines / BSON в аналогичные форматы со сжатием xzip, zstd и др. В общем-то из-за банальных задач уменьшения объёма хранения JSON lines файлов, но с возможностью работы с ними.
Однако вот сейчас я смотрю на задачу преобразования данных в условно "диком состоянии", а то есть в большинстве популярных форматов, среди которых, конечно, лидируют CSV и Excel файлы и могу сказать что самые типовые задачи решает DuckDB, а чуть более сложные DuckDB + Polars + Pandas + предобработка некоторых форматов файлов на входе.
Причём именно в такой комбинации. Почему так?
DuckDb - даёт большую скорость в работе с табличными и большей частью иерархичных данных. Но DuckDb не умеет читать файлы Excel, ORC, ORC и тд. Их умеют читать Pandas и Polars. И частично их писать.
Из фундаментальных проблем DuckDB - непонимание кодировок кроме utf-8 для CSV файлов что решается их предобработкой. Вторая проблема в том что DuckDB не умеет определять структуру CSV файлов если заголовки не в начале файла. Это вообще не все инструменты умеют и это, в принципе, умеют немногие инструменты, особенно с открытым кодом.
CSV самый распространённый формат, плохо стандартизированный в "диком виде", слишком часто CSV файлы лежат в открытом доступе после экспорта из Excel.
Еще один недостаток DuckDB при работе с CSV файлами - это отсутствие поддержки алгоритмов сжатия за исключением GZip. Если исходить из эффективности хранения и стоимости хранения - это важный фактор. Например, несколько сотен тысяч CSV файлов в Dateno - это около 4TB данных. Хранить их в оригинальном виде неэффективно, сжатыми GZip лучше, а ещё лучше в чём то вроде zstd или даже сразу в Parquet со сжатием. Что логично поскольку эти данные статичны.
Но в итоге именно DuckDB + Polars + Pandas + предобработка + постобоработка данных + хранение первичных данных в Parquet оказывается наиболее универсальным решением в таких задачах.
Ссылки:
[1] https://github.com/datacoon/undatum
#thoughts #data #datatools #fileformats #dateno
Я тут регулярно пишу про разные форматы файлов данных и могу сказать что, конечно, файловых форматов как и стандартов какое-то бесконечное количество. Когда-то я и сам делал и периодически обновляю инструменты вроде undatum [1] по работе с некоторыми из них. Так в undatum я недавно добавил работу с множеством алгоритмов сжатия обработкой файлов с минимизацией объёма их хранения и нагрузкой на оперативную память, с быстрым преобразованием из JSON lines / BSON в аналогичные форматы со сжатием xzip, zstd и др. В общем-то из-за банальных задач уменьшения объёма хранения JSON lines файлов, но с возможностью работы с ними.
Однако вот сейчас я смотрю на задачу преобразования данных в условно "диком состоянии", а то есть в большинстве популярных форматов, среди которых, конечно, лидируют CSV и Excel файлы и могу сказать что самые типовые задачи решает DuckDB, а чуть более сложные DuckDB + Polars + Pandas + предобработка некоторых форматов файлов на входе.
Причём именно в такой комбинации. Почему так?
DuckDb - даёт большую скорость в работе с табличными и большей частью иерархичных данных. Но DuckDb не умеет читать файлы Excel, ORC, ORC и тд. Их умеют читать Pandas и Polars. И частично их писать.
Из фундаментальных проблем DuckDB - непонимание кодировок кроме utf-8 для CSV файлов что решается их предобработкой. Вторая проблема в том что DuckDB не умеет определять структуру CSV файлов если заголовки не в начале файла. Это вообще не все инструменты умеют и это, в принципе, умеют немногие инструменты, особенно с открытым кодом.
CSV самый распространённый формат, плохо стандартизированный в "диком виде", слишком часто CSV файлы лежат в открытом доступе после экспорта из Excel.
Еще один недостаток DuckDB при работе с CSV файлами - это отсутствие поддержки алгоритмов сжатия за исключением GZip. Если исходить из эффективности хранения и стоимости хранения - это важный фактор. Например, несколько сотен тысяч CSV файлов в Dateno - это около 4TB данных. Хранить их в оригинальном виде неэффективно, сжатыми GZip лучше, а ещё лучше в чём то вроде zstd или даже сразу в Parquet со сжатием. Что логично поскольку эти данные статичны.
Но в итоге именно DuckDB + Polars + Pandas + предобработка + постобоработка данных + хранение первичных данных в Parquet оказывается наиболее универсальным решением в таких задачах.
Ссылки:
[1] https://github.com/datacoon/undatum
#thoughts #data #datatools #fileformats #dateno
Кому принадлежат языки? Я имею в виду не языки программирования, а я разговорные языки. Вопрос этот одновременно философский, не без политики, и очень практичный.
Практичный потому что во многих задачах связанных с аттрибутированием объектов, будь то документы, данные, тексты, изображения и тд. можно идентифицировать язык его содержания, то далеко не всегда содержатся сведения о его географической привязке/происхождении. К примеру, если содержание на испанском языке, то как понять связан ли объект/происходит ли из Испании, а может он из Мексики, или из Чили?
Аналогично, если содержание на арабском языке, то то есть десяток стран откуда оно может происходить. И так довольно много разных языков, в первую очередь межгосударственных языков, официальных языков ООН, языков распространившихся в результате культурной/колониальной экспансии с 14 по 20 века и тд.
Какие-то языки, такие как английский, французский, испанский, португальский, уже давно имеют меньше носителей речи в странах своего происхождения чем в странах культурной и языковой экспансии.
Одновременно с этим есть узко национальные языки, применение которых почти всегда означает что объект связан с конкретной культурной средой находящейся в конкретной стране. К примеру, японский, малайский, индонезийский, фарси, польский, финский и другие языки имеют почти 100% атрибуцию с конкретной географической территорией.
Всё так, языки можно частично разметить и использовать матрицу сопоставления языка и страны. Но так работает не всегда. Один объект может несколько языковых и территориальных характеристик. К примеру, румынский исследователь на румынском языке пишет о геологических разломах в Иране. Относить его статью к Румынии или к Ирану? Или польский турист публикует GPX трек путешествия по Греции, описывая его на польском языке. Относить ли его к Польше или к Греции? Эти случаи не самые сложные, их можно разбирать по приоритетности геопривязки. Имея несколько геоклассификацией определять несколько или одну приоритетными к контексте.
Самое сложное, пока что, из того что я встречал - это статьи в глобальных энциклопедиях вроде Википедии. Как их классифицировать? Как разметить все статьи в выбранной вики с точки зрения геопривязки? Как вообще превратить Википедию в базу именно геоданных? Понятно что часть статей имеющих координаты или указание территорий легко сопоставляются через Wikidata, но большую часть статей простым образом не разметишь.
Всё это практические, прикладные вопросы взгляда на языки. У меня перед глазами есть несколько задач анализа больших баз данных с содержанием на разных языках где такие вопросы очень актуальны.
А есть ещё те самые философские вопросы. Кому принадлежат языки, буквально? Примерно как некоторые развивающиеся страны пытающиеся отказаться от английского или французского языка, как языка колониального наследия. Потому что в их восприятии это не универсальные языки, а языки конкретных стран Великобритании и Франции.
Или почему, к примеру, у многих есть восприятие что у России монополия на русский язык? Санкционные действия многих создателей контента пошли по пути отказа от русского языка. Хотя кроме РФ у него широкая диаспора, это разговорный язык всей Центральной Азии и значительной части Кавказа.
Национальные регуляторы и цензоры также приоритетом видят для себя языки которые они считают "своими". Что добавляет давления на глобальные проекты знаний с их стороны.
Не должны ли все языки быть достоянием человечества и наступит ли тот момент когда ни одно национальное правительство не будет "владеть" языками тех кто живёт на территории их стран?
#languages #thoughts
Практичный потому что во многих задачах связанных с аттрибутированием объектов, будь то документы, данные, тексты, изображения и тд. можно идентифицировать язык его содержания, то далеко не всегда содержатся сведения о его географической привязке/происхождении. К примеру, если содержание на испанском языке, то как понять связан ли объект/происходит ли из Испании, а может он из Мексики, или из Чили?
Аналогично, если содержание на арабском языке, то то есть десяток стран откуда оно может происходить. И так довольно много разных языков, в первую очередь межгосударственных языков, официальных языков ООН, языков распространившихся в результате культурной/колониальной экспансии с 14 по 20 века и тд.
Какие-то языки, такие как английский, французский, испанский, португальский, уже давно имеют меньше носителей речи в странах своего происхождения чем в странах культурной и языковой экспансии.
Одновременно с этим есть узко национальные языки, применение которых почти всегда означает что объект связан с конкретной культурной средой находящейся в конкретной стране. К примеру, японский, малайский, индонезийский, фарси, польский, финский и другие языки имеют почти 100% атрибуцию с конкретной географической территорией.
Всё так, языки можно частично разметить и использовать матрицу сопоставления языка и страны. Но так работает не всегда. Один объект может несколько языковых и территориальных характеристик. К примеру, румынский исследователь на румынском языке пишет о геологических разломах в Иране. Относить его статью к Румынии или к Ирану? Или польский турист публикует GPX трек путешествия по Греции, описывая его на польском языке. Относить ли его к Польше или к Греции? Эти случаи не самые сложные, их можно разбирать по приоритетности геопривязки. Имея несколько геоклассификацией определять несколько или одну приоритетными к контексте.
Самое сложное, пока что, из того что я встречал - это статьи в глобальных энциклопедиях вроде Википедии. Как их классифицировать? Как разметить все статьи в выбранной вики с точки зрения геопривязки? Как вообще превратить Википедию в базу именно геоданных? Понятно что часть статей имеющих координаты или указание территорий легко сопоставляются через Wikidata, но большую часть статей простым образом не разметишь.
Всё это практические, прикладные вопросы взгляда на языки. У меня перед глазами есть несколько задач анализа больших баз данных с содержанием на разных языках где такие вопросы очень актуальны.
А есть ещё те самые философские вопросы. Кому принадлежат языки, буквально? Примерно как некоторые развивающиеся страны пытающиеся отказаться от английского или французского языка, как языка колониального наследия. Потому что в их восприятии это не универсальные языки, а языки конкретных стран Великобритании и Франции.
Или почему, к примеру, у многих есть восприятие что у России монополия на русский язык? Санкционные действия многих создателей контента пошли по пути отказа от русского языка. Хотя кроме РФ у него широкая диаспора, это разговорный язык всей Центральной Азии и значительной части Кавказа.
Национальные регуляторы и цензоры также приоритетом видят для себя языки которые они считают "своими". Что добавляет давления на глобальные проекты знаний с их стороны.
Не должны ли все языки быть достоянием человечества и наступит ли тот момент когда ни одно национальное правительство не будет "владеть" языками тех кто живёт на территории их стран?
#languages #thoughts
К вопросу о poor man data engineering, как обрабатывать данные в условиях ограниченных ресурсов с минимальными нагрузками на диск и на оперативную память, в первую очередь.
В работе в Dateno есть задача по добавлению стат. индикаторов в основной индекс и расширение фасетов на данными о частоте обновления индикаторов и временном промежутке который он охватывает (год начала и год окончания). Не у всех датасетов такие метаданные есть и есть особенность датасетов Европейского центрального банка (ECB) в том что для массовой выгрузки доступны сами данные, но не метаданные. Хотя обычно наоборот. А в данном случае можно скачать все значения, а метаданные из них надо извлечь.
Эти значения публикуются в виде коллекции из 108 CSV файлов общим объёмом в 93GB. Это не то чтобы много, но много для статистики и для обработки на десктопе. Первая мысль которая возникает, а не уменьшить ли эти данные в объёме. Можно их сжать, но ещё эффективнее преобразовать в parquet. После преобразования они занимают 664 MB. Это 0,7% от изначального объёма, итого сжатие в 140 раз! Такая эффективность редкость, обычно сжатие в 5-15 раз, но здесь накладывается эффект колоночного сжатия поскольку данные ECB денормализованные, эффективность хранения там уступает полноте публикации и простоте раскрытия.
Далее обработка. Чтобы получить метаданные каждого индикатора надо:
1. Получить список уникальных идентификаторов индикаторов
2. Для каждого ключа сделать запрос одной записи для извлечения метаданных
3. Получить минимальное и максимальное значения временного периода
4. Извлечь год из минимального и максимального значения если период не равен году.
Итого 3 запроса, которые, наверняка, можно было бы оптимизировать до 2-х и которые можно делать напрямую к файлам parquet. Однако ситуация осложняется тем что эти файлы parquet хотя и хорошо сжаты, но могут содержать до 570+ тысяч индикаторов, как это, например, происходит с датасетом Securities Issues Statistics, который в оригинале составляет 19GB CSV файл и содержит 30 миллионов строк.
При работе с этим датасетом, даже после преобразования в parquet, DuckDB "съедает" до 15GB RAM и работает, хотя и быстро, но не так быстро как хотелось бы.
Варианты решения:
1. Попробовать преобразовать данные в базу DuckDB, построить индексы и так обрабатывать. Минус: резко увеличивается объём хранения данных, не увеличивается скорость обработки.
2. Попробовать нормализовать данные и извлекать метаданные из нормализованных баз. Минус: время на преобразование многократно больше времени сбора метаданных из существующих parquet файлов, а также у разных датасетов разная схема данных и требуется потратить больше времени на их анализ.
Варианты с тем чтобы загрузить в какую-то другую СУБД или даже не рассматривались поскольку задача именно в обработке на среднемощном десктопе/ноутбуке и без резкого роста объёмов хранения.
Итоговое решение оказалось очень простым. Специфика запросов в том что они полностью локализованы внутри данных конкретного индикатора.
Но, так повезло, что в этих датасетах индикаторы разделены по группам являющихся странами или территориями, от 8 до 33 в одном датасете и разделять можно по ним. Данные отдельных индикаторов полностью попадают в один из разделённых файлов. И, одна из фишек DuckDB - это очень дешёвое разделение данных с точки зрения скорости и нагрузки на память. До обработки большого датасета через серию COPY TO операций из него создаются десятки меньших .parquet файлов каждый из которых обрабатывается по отдельности.
Итого:
- средняя скорость однопоточной обработки достигает 78 индикаторов в секунду
- потребление RAM не превышает 100MB, а в среднем держится менее 50MB
- потребление диска +664MB, теперь не в 140 раз меньше чем оригинальные CSV файлы, а только в 70 раз, но всё ещё очень и очень мало.
Понятно что перенеся всё это на серверную инфраструктуру, в несколько потоков и тд. можно многократно ускорить обработку данных, но и так с помощью DuckDB конвейеры данных можно запускать на очень дешёвом железе и получать приемлемый результат.
#data #thoughts #tech #duckdb #dataengineering
В работе в Dateno есть задача по добавлению стат. индикаторов в основной индекс и расширение фасетов на данными о частоте обновления индикаторов и временном промежутке который он охватывает (год начала и год окончания). Не у всех датасетов такие метаданные есть и есть особенность датасетов Европейского центрального банка (ECB) в том что для массовой выгрузки доступны сами данные, но не метаданные. Хотя обычно наоборот. А в данном случае можно скачать все значения, а метаданные из них надо извлечь.
Эти значения публикуются в виде коллекции из 108 CSV файлов общим объёмом в 93GB. Это не то чтобы много, но много для статистики и для обработки на десктопе. Первая мысль которая возникает, а не уменьшить ли эти данные в объёме. Можно их сжать, но ещё эффективнее преобразовать в parquet. После преобразования они занимают 664 MB. Это 0,7% от изначального объёма, итого сжатие в 140 раз! Такая эффективность редкость, обычно сжатие в 5-15 раз, но здесь накладывается эффект колоночного сжатия поскольку данные ECB денормализованные, эффективность хранения там уступает полноте публикации и простоте раскрытия.
Далее обработка. Чтобы получить метаданные каждого индикатора надо:
1. Получить список уникальных идентификаторов индикаторов
2. Для каждого ключа сделать запрос одной записи для извлечения метаданных
3. Получить минимальное и максимальное значения временного периода
4. Извлечь год из минимального и максимального значения если период не равен году.
Итого 3 запроса, которые, наверняка, можно было бы оптимизировать до 2-х и которые можно делать напрямую к файлам parquet. Однако ситуация осложняется тем что эти файлы parquet хотя и хорошо сжаты, но могут содержать до 570+ тысяч индикаторов, как это, например, происходит с датасетом Securities Issues Statistics, который в оригинале составляет 19GB CSV файл и содержит 30 миллионов строк.
При работе с этим датасетом, даже после преобразования в parquet, DuckDB "съедает" до 15GB RAM и работает, хотя и быстро, но не так быстро как хотелось бы.
Варианты решения:
1. Попробовать преобразовать данные в базу DuckDB, построить индексы и так обрабатывать. Минус: резко увеличивается объём хранения данных, не увеличивается скорость обработки.
2. Попробовать нормализовать данные и извлекать метаданные из нормализованных баз. Минус: время на преобразование многократно больше времени сбора метаданных из существующих parquet файлов, а также у разных датасетов разная схема данных и требуется потратить больше времени на их анализ.
Варианты с тем чтобы загрузить в какую-то другую СУБД или даже не рассматривались поскольку задача именно в обработке на среднемощном десктопе/ноутбуке и без резкого роста объёмов хранения.
Итоговое решение оказалось очень простым. Специфика запросов в том что они полностью локализованы внутри данных конкретного индикатора.
Но, так повезло, что в этих датасетах индикаторы разделены по группам являющихся странами или территориями, от 8 до 33 в одном датасете и разделять можно по ним. Данные отдельных индикаторов полностью попадают в один из разделённых файлов. И, одна из фишек DuckDB - это очень дешёвое разделение данных с точки зрения скорости и нагрузки на память. До обработки большого датасета через серию COPY TO операций из него создаются десятки меньших .parquet файлов каждый из которых обрабатывается по отдельности.
Итого:
- средняя скорость однопоточной обработки достигает 78 индикаторов в секунду
- потребление RAM не превышает 100MB, а в среднем держится менее 50MB
- потребление диска +664MB, теперь не в 140 раз меньше чем оригинальные CSV файлы, а только в 70 раз, но всё ещё очень и очень мало.
Понятно что перенеся всё это на серверную инфраструктуру, в несколько потоков и тд. можно многократно ускорить обработку данных, но и так с помощью DuckDB конвейеры данных можно запускать на очень дешёвом железе и получать приемлемый результат.
#data #thoughts #tech #duckdb #dataengineering
Почему я в последнее время много думаю и пишу про геоданные?
Есть 4 основных типов общедоступных данных данных которые собираются в Dateno:
- открытые данные (opendata). С ними всё довольно понятно, их много, не не бесконечно много. Большая часть порталов известны, далее просто длительная методическая работа по их систематизации и сбору датасетов
- научные данные. Тут не всё так понятно, и этих данных по объёму более всего в мире, но в каждой науке свои виды каталогов данных, стандарты и тд. За пределами отдельных научных дисциплин у этих данных не так много пользы
- статистика и индикаторы. Нужны всем, чаще стандартизированы, поддаются систематизированному сбору и "расщепляются" на множество поддатасетов в привязке к конкретным странам и территориям. Много усилий требуется по агрегации национальных каталогов статистики.
- геоданные. Их много, чаще стандартизированы, но поиск и каталогизация явно недостаточны. Предыдущие попытки чаше безуспешны.
Остальные типы данных - это данные для машинного обучения, данные из коммерческих маркетплейсов или датасеты из порталов микроданных (социология), все они сильно меньше количественно.
Существенный количественный рост данных в Dateno будет от трёх категорий: научные данные, данные индикаторов и геоданные.
При этом научные данные можно _очень быстро_ загрузить из 3-4 крупных источников и это добавит +20 млн датасетов и создаст огромные пузыри данных по нескольким языкам, категориям и темам.
Данные индикаторов стремительно превратят Dateno в портал по макроэкономике/макростатистике. Их также можно загрузить +5 млн датасетов в короткое время.
А в агрегированных геоданных сейчас есть объективный "пузырь", огромное число датасетов по Германии отчего в любом поисковике по данным доля геоданных их Германии достигает 40-60% от общего числа. Если не больше.
Конечно, в какой-то момент, можно перестать думать про этот баланс и залить в Dateno несколько десятков миллионов датасетов и уже потом заниматься вопросами качества индекса. Так, например, сделали в агрегаторах научных данных типа SciDb и OpenAIRE. Там очень много мусора который создаёт количество датасетов, но который и почти не найдёшь потому что эти мусорные данные даже не подпадают под фасеты. В общем-то там ставка однозначно сделана на количество датасетов, а в этом смысле нет проблемы достигнуть того же.
#opendata #data #dateno #thoughts #geodata
Есть 4 основных типов общедоступных данных данных которые собираются в Dateno:
- открытые данные (opendata). С ними всё довольно понятно, их много, не не бесконечно много. Большая часть порталов известны, далее просто длительная методическая работа по их систематизации и сбору датасетов
- научные данные. Тут не всё так понятно, и этих данных по объёму более всего в мире, но в каждой науке свои виды каталогов данных, стандарты и тд. За пределами отдельных научных дисциплин у этих данных не так много пользы
- статистика и индикаторы. Нужны всем, чаще стандартизированы, поддаются систематизированному сбору и "расщепляются" на множество поддатасетов в привязке к конкретным странам и территориям. Много усилий требуется по агрегации национальных каталогов статистики.
- геоданные. Их много, чаще стандартизированы, но поиск и каталогизация явно недостаточны. Предыдущие попытки чаше безуспешны.
Остальные типы данных - это данные для машинного обучения, данные из коммерческих маркетплейсов или датасеты из порталов микроданных (социология), все они сильно меньше количественно.
Существенный количественный рост данных в Dateno будет от трёх категорий: научные данные, данные индикаторов и геоданные.
При этом научные данные можно _очень быстро_ загрузить из 3-4 крупных источников и это добавит +20 млн датасетов и создаст огромные пузыри данных по нескольким языкам, категориям и темам.
Данные индикаторов стремительно превратят Dateno в портал по макроэкономике/макростатистике. Их также можно загрузить +5 млн датасетов в короткое время.
А в агрегированных геоданных сейчас есть объективный "пузырь", огромное число датасетов по Германии отчего в любом поисковике по данным доля геоданных их Германии достигает 40-60% от общего числа. Если не больше.
Конечно, в какой-то момент, можно перестать думать про этот баланс и залить в Dateno несколько десятков миллионов датасетов и уже потом заниматься вопросами качества индекса. Так, например, сделали в агрегаторах научных данных типа SciDb и OpenAIRE. Там очень много мусора который создаёт количество датасетов, но который и почти не найдёшь потому что эти мусорные данные даже не подпадают под фасеты. В общем-то там ставка однозначно сделана на количество датасетов, а в этом смысле нет проблемы достигнуть того же.
#opendata #data #dateno #thoughts #geodata
В качестве мини-хобби, очень мини, я время от времени систематизирую ссылки по темам в жанре awesome list на Github с некоторой надеждой что над этими списками не я один буду работать. Надежды, как правило, не оправдываются, за редким исключением.
Список Awesome Digital Preservation, за время существования всего 14 лайков. У цифровой архивации мало фанатов, увы.
Или, например, у меня есть список Awesome Open Data software с ПО и стандартами по работе с открытыми данными. Почти всё ПО из реестра каталогов данных в Dateno, плюс ссылки на форматы файлов и стандарты обмена данными. Звездочек маловато, всего 24, не самая популярная тема.😜
Или вот Awesome Data Takeout со ссылками на сервисы получения всех своих данных из онлайн сервисов. 54 звезды, тоже, очень мало.
Для дата журналистов Awesome data journalism со списками инструментов для визуализации и не только. Набрало, 178 звезд, давно не обновлялось.
Russian Awesome Open data каталог источников открытых данных по РФ. Составлялся очень давно, как-то собрал 200 звездочек, уже практически не пополняется. Вместо него развивали datacatalogs.ru
Побольше в Awesome Forensic Tools с подборкой ресурсов в задачах цифрового дознания. Набрало 472 лайка при том что я почти не прилагал усилий по его пополнению, только один раз собрал всё вместе.
И, наконец, Awesome Status Pages собравшее 2738 лайков. Активное настолько что утомляет, сплошным потоком разработчики создают очередные сервисы проверки и публикации статусов сервисов и используют всякую маркетинговую мишуру чтобы их продвинуть. Дважды предлагали выкупить у меня эту страницу. Чувствую зря я её не продал;)
В общем-то по настоящему выстрелило только последнее, хотя списки составлять я лично люблю. Списки это же частный вид таблицы, можно ещё жанр завести. Awesome table of <something>, но в форматы Github'а или Telegram'а они плохо укладываются. Но может найдется близкий интересный формат
#opendata #datajournalism #data #digitalforensics #readings #thoughts
Список Awesome Digital Preservation, за время существования всего 14 лайков. У цифровой архивации мало фанатов, увы.
Или, например, у меня есть список Awesome Open Data software с ПО и стандартами по работе с открытыми данными. Почти всё ПО из реестра каталогов данных в Dateno, плюс ссылки на форматы файлов и стандарты обмена данными. Звездочек маловато, всего 24, не самая популярная тема.😜
Или вот Awesome Data Takeout со ссылками на сервисы получения всех своих данных из онлайн сервисов. 54 звезды, тоже, очень мало.
Для дата журналистов Awesome data journalism со списками инструментов для визуализации и не только. Набрало, 178 звезд, давно не обновлялось.
Russian Awesome Open data каталог источников открытых данных по РФ. Составлялся очень давно, как-то собрал 200 звездочек, уже практически не пополняется. Вместо него развивали datacatalogs.ru
Побольше в Awesome Forensic Tools с подборкой ресурсов в задачах цифрового дознания. Набрало 472 лайка при том что я почти не прилагал усилий по его пополнению, только один раз собрал всё вместе.
И, наконец, Awesome Status Pages собравшее 2738 лайков. Активное настолько что утомляет, сплошным потоком разработчики создают очередные сервисы проверки и публикации статусов сервисов и используют всякую маркетинговую мишуру чтобы их продвинуть. Дважды предлагали выкупить у меня эту страницу. Чувствую зря я её не продал;)
В общем-то по настоящему выстрелило только последнее, хотя списки составлять я лично люблю. Списки это же частный вид таблицы, можно ещё жанр завести. Awesome table of <something>, но в форматы Github'а или Telegram'а они плохо укладываются. Но может найдется близкий интересный формат
#opendata #datajournalism #data #digitalforensics #readings #thoughts
Я тут тоже думал про всякое применение ИИ, как в продуктовых и рабочих делах, так и общечеловеческих. Рабочие дела - это как применять ИИ для обработки, классификации, повышения качества, поиска, обогащения и тд. в работе с данными. Применений много, о них как-то в другой раз и скорее уже когда будет что показать и рассказать живое.
А вот про рабочее и полезное человечеству.
1. Не теряю всё же надежду что хоть кто-то из разработчиков сделает умный Inbox, AI ассистента нормально работающего с почтой, контактами и документами в рамках корпоративных и личных коммуникаций. Для людей живущих асинхронной жизнью это просто необходимо. Я вот не хочу сортировать почту по папкам, довылавливать спам, дозаполнять контакты после внесения, вспоминать треды переписки и так далее. Это всё совершенно точно поддаётся качественной даже не автоматизации, а глубокой трансформации без потери качества.
2. Есть огромное число малых/не национальных языков, никак не защищаемых государствами или защищаемых незначительно. Какие-то из них стагнируют, некоторые развиваются, большая часть медленно или быстро вымирает. Если по ним есть хоть какая-то устная и письменная история то AI для сохранения и обучения вымирающих языков. Не только как предмет анализа, исследований и научных работ, а по автоматизированному созданию автопереводчиков, словарей, обучающих материалов и так далее. Коммерческой идеи тут, может не быть. Подчеркну что идея тут не в автоматизации перевода, а в автоматизации создания обучающих материалов.
#ai #thoughts
А вот про рабочее и полезное человечеству.
1. Не теряю всё же надежду что хоть кто-то из разработчиков сделает умный Inbox, AI ассистента нормально работающего с почтой, контактами и документами в рамках корпоративных и личных коммуникаций. Для людей живущих асинхронной жизнью это просто необходимо. Я вот не хочу сортировать почту по папкам, довылавливать спам, дозаполнять контакты после внесения, вспоминать треды переписки и так далее. Это всё совершенно точно поддаётся качественной даже не автоматизации, а глубокой трансформации без потери качества.
2. Есть огромное число малых/не национальных языков, никак не защищаемых государствами или защищаемых незначительно. Какие-то из них стагнируют, некоторые развиваются, большая часть медленно или быстро вымирает. Если по ним есть хоть какая-то устная и письменная история то AI для сохранения и обучения вымирающих языков. Не только как предмет анализа, исследований и научных работ, а по автоматизированному созданию автопереводчиков, словарей, обучающих материалов и так далее. Коммерческой идеи тут, может не быть. Подчеркну что идея тут не в автоматизации перевода, а в автоматизации создания обучающих материалов.
#ai #thoughts
Мысли вслух о индексировании датасетов
Я как то уже писал о том что потратил в своё время немало сил и времени на то чтобы научиться создавать данные из неструктурированных источников. Развивая мысль "всё таблица" в мысль "всё данные". Самое очевидное применение - это сайты к которым пишут многочисленные парсеры, но число сайтов бесконечно, а число парсеров конечно. И писать множество парсеров для каждого сайта не хватит и тысячи жизней.
Можно ли это автоматизировать? Можно ли автоматически понимать разметку страниц и извлекать из них смысл. Самый очевидный путь - это использовать микроформаты и разметку контента через Schema.org и вытаскивать объекты из индекса Common Crawl. Что, кстати, многие и делают для задач обучения ИИ и не только и что имеет свои ограничения из-за невысокого качества этой самой разметки.
Кроме того она используется далеко не всеми. Да чего уж там, огромное число государственных, корпоративных и академических вебсайтов не используют даже базовые инструменты для индексации поисковиками. У них нет файлов robots.txt, отсутствуют sitemaps и ещё много всего.
Когда я ещё возился начальной стадии с каталогами данных, казалось бы довольно типовыми функциями, то столкнулся с этим в полный рост. К примеру, большая часть каталогов данных не поддерживают Schema.org и не индексируются тем же краулером Google не говоря уже об остальных.
Геоданные почти все вообще не попадают в поисковые индексы как датасеты, для них нет разметки, а каталоги геоданных не оперируют метаданными из Schema.org, за редким исключением.
Как собирать метаданные в таких условиях?
По сути стратегия сбора метаданных о датасетах сводится к нескольким моделям:
1. Сбор стандартизированными инструментами через API каталогов данных или дампы каталогов.
Причём этих API может быть несколько. Тот же CKAN, к примеру, поддерживает собственное API и часто имеет дамп экспорта по стандарту DCAT, а у каталогов Dataverse ещё больше вариантов их индексации, с помощью внутреннего API, OAI-PMH, Sword и других вариантов. Это то что делают некоторые поисковики, например, научные или порталы агрегаторы данных, но они используют, как правило, 2-3 стандарта для сбора метаданных.
2. Индивидуализированное извлечение метаданных
В случае крупных каталогов данных написание парсеров исключительно под них и перенос метаданных в поисковый индекс. Это резко отличается от того что делают все остальные поисковики и агрегаторы, кроме тех которые используют большие открытые данные DataCite для каталогизации датасетов получивших DOI.
3. Краулинг + Schema.org
Стандартный механизм используемый Google Dataset Search и не используемый больше почти более нигде. В самом простом сценарии реализуется через поглощение sitemap файлов и последовательное извлечение разметки Schema.org Dataset из веб страниц. С одной стороны, не зависит от используемого в каталоге ПО, с другой стороны всё равно требует ручной верификации.
4. Умный анализ структуры каталога и автоматическое аннотирование датасетов
Это самое сложное и интересное. Как определить структура сайта? Как определить структуру веб страницы на которой размещён набор данных? Это можно делать по типовым шаблонам ссылок с префиксами типовыми для наборов данных, такими как /dataset/ и тд. Ещё один признак - это ссылки на дата файлы .csv, .json, .xml и им подобные, а также ключевые слова в разметке страниц и применение ИИ для понимания этой разметки. Всё вместе это может дать возможность приблизится к умному краулеру с обучением. Где-то с верификацией человеком, а где-то, возможно, даже без неё.
За бортом остаются порталы с собственным нестандартным API через которое рендерятся данные и другие порталы со встроенным AJAX'ом. Такие случаи даже умным краулером не обработать.
Всё это мысли вслух о поиске исходя из показателей количества охваченных каталогов данных и числа проиндексированных наборов данных как приоритетных. А есть и другие показатели качества, востребованности, удобства и не только.
#thoughts
Я как то уже писал о том что потратил в своё время немало сил и времени на то чтобы научиться создавать данные из неструктурированных источников. Развивая мысль "всё таблица" в мысль "всё данные". Самое очевидное применение - это сайты к которым пишут многочисленные парсеры, но число сайтов бесконечно, а число парсеров конечно. И писать множество парсеров для каждого сайта не хватит и тысячи жизней.
Можно ли это автоматизировать? Можно ли автоматически понимать разметку страниц и извлекать из них смысл. Самый очевидный путь - это использовать микроформаты и разметку контента через Schema.org и вытаскивать объекты из индекса Common Crawl. Что, кстати, многие и делают для задач обучения ИИ и не только и что имеет свои ограничения из-за невысокого качества этой самой разметки.
Кроме того она используется далеко не всеми. Да чего уж там, огромное число государственных, корпоративных и академических вебсайтов не используют даже базовые инструменты для индексации поисковиками. У них нет файлов robots.txt, отсутствуют sitemaps и ещё много всего.
Когда я ещё возился начальной стадии с каталогами данных, казалось бы довольно типовыми функциями, то столкнулся с этим в полный рост. К примеру, большая часть каталогов данных не поддерживают Schema.org и не индексируются тем же краулером Google не говоря уже об остальных.
Геоданные почти все вообще не попадают в поисковые индексы как датасеты, для них нет разметки, а каталоги геоданных не оперируют метаданными из Schema.org, за редким исключением.
Как собирать метаданные в таких условиях?
По сути стратегия сбора метаданных о датасетах сводится к нескольким моделям:
1. Сбор стандартизированными инструментами через API каталогов данных или дампы каталогов.
Причём этих API может быть несколько. Тот же CKAN, к примеру, поддерживает собственное API и часто имеет дамп экспорта по стандарту DCAT, а у каталогов Dataverse ещё больше вариантов их индексации, с помощью внутреннего API, OAI-PMH, Sword и других вариантов. Это то что делают некоторые поисковики, например, научные или порталы агрегаторы данных, но они используют, как правило, 2-3 стандарта для сбора метаданных.
2. Индивидуализированное извлечение метаданных
В случае крупных каталогов данных написание парсеров исключительно под них и перенос метаданных в поисковый индекс. Это резко отличается от того что делают все остальные поисковики и агрегаторы, кроме тех которые используют большие открытые данные DataCite для каталогизации датасетов получивших DOI.
3. Краулинг + Schema.org
Стандартный механизм используемый Google Dataset Search и не используемый больше почти более нигде. В самом простом сценарии реализуется через поглощение sitemap файлов и последовательное извлечение разметки Schema.org Dataset из веб страниц. С одной стороны, не зависит от используемого в каталоге ПО, с другой стороны всё равно требует ручной верификации.
4. Умный анализ структуры каталога и автоматическое аннотирование датасетов
Это самое сложное и интересное. Как определить структура сайта? Как определить структуру веб страницы на которой размещён набор данных? Это можно делать по типовым шаблонам ссылок с префиксами типовыми для наборов данных, такими как /dataset/ и тд. Ещё один признак - это ссылки на дата файлы .csv, .json, .xml и им подобные, а также ключевые слова в разметке страниц и применение ИИ для понимания этой разметки. Всё вместе это может дать возможность приблизится к умному краулеру с обучением. Где-то с верификацией человеком, а где-то, возможно, даже без неё.
За бортом остаются порталы с собственным нестандартным API через которое рендерятся данные и другие порталы со встроенным AJAX'ом. Такие случаи даже умным краулером не обработать.
Всё это мысли вслух о поиске исходя из показателей количества охваченных каталогов данных и числа проиндексированных наборов данных как приоритетных. А есть и другие показатели качества, востребованности, удобства и не только.
#thoughts
Давно размышляю о том как в научной среде публикуют данные и насколько всё зависит от научной дисциплины. В разных науках подход, инструменты, культура работы с данными и их доступность существенно отличаются.
Например, особняком идёт всё что касается life sciences особенно в части биоинформатики. Практически все исследования там, или создают данные, или используют и ссылаются на данные, или то и другое. Фактически это огромная связанная инфраструктура через стандарты, идентификаторы, специальные платформы и специализированные платформы и базы данных. Собственный мир развивающийся по собственным правилам.
Второй похожий блок - это науки о Земле включая климатологию, метеорологию, геофизику, науки о морях и океанах. По внутренним ощущениям там не так всё технологизировано, вернее, несколько консервативнее, но также это собственная экосистема.
Особняком данные связанные с ИИ, одна из областей где коммерческих данных может быть больше чем научных. Большая часть из них сконцентрированы в Kaggle и Hugging Face.
И отдельная история - это экономика, социальные науки, гуманитарные науки, госуправление и тд. Там данные если публикуются то скорее рассматриваются как один из результатов научной деятельности. Вот они публикуются, или на тех же ресурсах что и научные статьи, или на специализированных научных порталах общего типа.
Всё это сильно влияет на то как собирать данные, что считать датасетами, объём собираемых данных и так далее.
К примеру, сбор научных данных из репозиториев научных результатов - это, часто, поиск иголки в стоге сена. Не все научные репозитории поддерживают API и фильтрацию результатов по типу содержимого. Из репозиториев на базе DSpace, к примеру, надо вначале извлечь всё, а потом уже процеживать их по множеству критериев чтобы вытащить датасеты. Из 1 миллиона таких научных результатов, то что является датасетами будет 50-60 тысяч записей.
Возникает ситуация когда можно собирать научные данные и в процессе приходится ещё множество метаданных других научных работ и поисковик/поисковый индекс по научным работам получается автоматически. Как бы естественно. Но делать, его, вряд ли осмысленно поскольку таких поисковиков множество.
#thoughts #datasearch #openaccess #opendata
Например, особняком идёт всё что касается life sciences особенно в части биоинформатики. Практически все исследования там, или создают данные, или используют и ссылаются на данные, или то и другое. Фактически это огромная связанная инфраструктура через стандарты, идентификаторы, специальные платформы и специализированные платформы и базы данных. Собственный мир развивающийся по собственным правилам.
Второй похожий блок - это науки о Земле включая климатологию, метеорологию, геофизику, науки о морях и океанах. По внутренним ощущениям там не так всё технологизировано, вернее, несколько консервативнее, но также это собственная экосистема.
Особняком данные связанные с ИИ, одна из областей где коммерческих данных может быть больше чем научных. Большая часть из них сконцентрированы в Kaggle и Hugging Face.
И отдельная история - это экономика, социальные науки, гуманитарные науки, госуправление и тд. Там данные если публикуются то скорее рассматриваются как один из результатов научной деятельности. Вот они публикуются, или на тех же ресурсах что и научные статьи, или на специализированных научных порталах общего типа.
Всё это сильно влияет на то как собирать данные, что считать датасетами, объём собираемых данных и так далее.
К примеру, сбор научных данных из репозиториев научных результатов - это, часто, поиск иголки в стоге сена. Не все научные репозитории поддерживают API и фильтрацию результатов по типу содержимого. Из репозиториев на базе DSpace, к примеру, надо вначале извлечь всё, а потом уже процеживать их по множеству критериев чтобы вытащить датасеты. Из 1 миллиона таких научных результатов, то что является датасетами будет 50-60 тысяч записей.
Возникает ситуация когда можно собирать научные данные и в процессе приходится ещё множество метаданных других научных работ и поисковик/поисковый индекс по научным работам получается автоматически. Как бы естественно. Но делать, его, вряд ли осмысленно поскольку таких поисковиков множество.
#thoughts #datasearch #openaccess #opendata
Про то как публикуют и работают с опубликованными датасетами расскажу про их публикацию по стандарту 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
В 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
Давно пишу по кусочкам лонгрид про природу данных и наборов данных, про то как отличается их восприятие людьми разных профессий и потребностей и как от того где они применяются "плавает" это определение.
Самый простой пример - это всегда ли данные машиночитаемы? К примеру, данные в виде файлов csv, json, xml и тд. всегда можно рассматривать как машиночитаемые, а, к примеру, тексты, видео и изображения нет. Но если собрать тысячи, сотни тысяч текстов или фотографий, то вот, пожалуйста, датасет для обучения в data science. То есть данные не всегда машиночитаемы?
Другой пример, конфигурационные файлы приложений распространённо имеют машиночитаемые форматы как раз те же самые json, xml, yaml и ряд других. Делает ли это их наборами данных? Вообще-то нет, потому что не прослеживается модели их повторного использования.
Может быть именно повторное использование и востребованность тогда является главным критерием определения набора данных? В классических определениях набора данных это, или набор таблиц, или единица измерения информации опубликованной в открытом доступе.
А как рассматривать API? К примеру, в геоданных массово данные доступны не в виде файлов, а в виде API по стандартам OGC или ряду проприетарных. Их принято относить к наборам данных. Но там разные API, к примеру, WFS, WMS без сомнений можно относить к data api (API для доступа к данным), а какие-нибудь WPS уже точно не data api, а процессные API для обработки данных, а WCS что ближе к не API для данных, с помогающих в работе с геоинструментами. Для аудитории специалистов по геоанализу они нужны, но как бы не данные.
В научной среде репозитории данных очень часто совмещены с репозиториями ПО, во всяком случае для репозиториев общего типа. Главная идея тут в том что без ПО, причём конкретной версии, сложно повторить эксперимент/процессы в результате которых были данные получены.
Ещё пример, опять же про не машиночитаемость. С точки зрения архивации данных важно хранить данные в любой форме за условно любой период времени. К примеру, статистический сборник 19го века. Формально не машиночитаем, по факту исследователям статистикам может быть нужен? Безусловно. На многих порталах открытых данных опубликованы тысячи таких сборников как открытые данные. Но они не машиночитаемые. В такой логике к, примеру, Библиотека конгресса США или Национальная электронная библиотека в РФ это тоже каталоги данных? Или источники данных? Даже если они не машиночитаемы?
Всё это возвращает к размышлениям о том что наборы данных - это то о чём можно говорить как об опубликованным со смыслом (publish with the purpose), с пониманием аудитории и хотя бы одного сценария их применения.
В практическом применении это напрямую затрагивает, например, то какие данные индексируют и не индексируют поисковые системы. К примеру, Google Dataset Search не индексирует геоданные, они медленно, то уверенно склоняются к поисковику для исследователей. Научные поисковики вроде OpenAIRE, DataCite или BASE с самого начала декларируют что это не только поиск по данным, а по любым результатам научной деятельности до которых просто дотянутся. Для data science поисковика нет поскольку всего два основных ресурса, Hugging Face и Kaggle.
В Dateno индексируются геоданные (гео API) и порталы индикаторов причём с расширенной трактовкой индикаторов как то что датасетом является индикатор + страна во всех случаях когда можно сделать постоянную ссылку на файл или API. Так делают многие создатели этих порталов с индикаторами уже давно. Но это тоже некая форма интерпретации исходя из потребности и поиска пользователей.
Всё это, отчасти, философский вопрос о том строить ли поисковую систему по данным или поисковую систему для тех кто работает с данными. Разница между двумя этими понятиями весьма существенна. И поэтому она начинается с собственного определения того что такое набор данных
#thoughts #data #datasets
Самый простой пример - это всегда ли данные машиночитаемы? К примеру, данные в виде файлов csv, json, xml и тд. всегда можно рассматривать как машиночитаемые, а, к примеру, тексты, видео и изображения нет. Но если собрать тысячи, сотни тысяч текстов или фотографий, то вот, пожалуйста, датасет для обучения в data science. То есть данные не всегда машиночитаемы?
Другой пример, конфигурационные файлы приложений распространённо имеют машиночитаемые форматы как раз те же самые json, xml, yaml и ряд других. Делает ли это их наборами данных? Вообще-то нет, потому что не прослеживается модели их повторного использования.
Может быть именно повторное использование и востребованность тогда является главным критерием определения набора данных? В классических определениях набора данных это, или набор таблиц, или единица измерения информации опубликованной в открытом доступе.
А как рассматривать API? К примеру, в геоданных массово данные доступны не в виде файлов, а в виде API по стандартам OGC или ряду проприетарных. Их принято относить к наборам данных. Но там разные API, к примеру, WFS, WMS без сомнений можно относить к data api (API для доступа к данным), а какие-нибудь WPS уже точно не data api, а процессные API для обработки данных, а WCS что ближе к не API для данных, с помогающих в работе с геоинструментами. Для аудитории специалистов по геоанализу они нужны, но как бы не данные.
В научной среде репозитории данных очень часто совмещены с репозиториями ПО, во всяком случае для репозиториев общего типа. Главная идея тут в том что без ПО, причём конкретной версии, сложно повторить эксперимент/процессы в результате которых были данные получены.
Ещё пример, опять же про не машиночитаемость. С точки зрения архивации данных важно хранить данные в любой форме за условно любой период времени. К примеру, статистический сборник 19го века. Формально не машиночитаем, по факту исследователям статистикам может быть нужен? Безусловно. На многих порталах открытых данных опубликованы тысячи таких сборников как открытые данные. Но они не машиночитаемые. В такой логике к, примеру, Библиотека конгресса США или Национальная электронная библиотека в РФ это тоже каталоги данных? Или источники данных? Даже если они не машиночитаемы?
Всё это возвращает к размышлениям о том что наборы данных - это то о чём можно говорить как об опубликованным со смыслом (publish with the purpose), с пониманием аудитории и хотя бы одного сценария их применения.
В практическом применении это напрямую затрагивает, например, то какие данные индексируют и не индексируют поисковые системы. К примеру, Google Dataset Search не индексирует геоданные, они медленно, то уверенно склоняются к поисковику для исследователей. Научные поисковики вроде OpenAIRE, DataCite или BASE с самого начала декларируют что это не только поиск по данным, а по любым результатам научной деятельности до которых просто дотянутся. Для data science поисковика нет поскольку всего два основных ресурса, Hugging Face и Kaggle.
В Dateno индексируются геоданные (гео API) и порталы индикаторов причём с расширенной трактовкой индикаторов как то что датасетом является индикатор + страна во всех случаях когда можно сделать постоянную ссылку на файл или API. Так делают многие создатели этих порталов с индикаторами уже давно. Но это тоже некая форма интерпретации исходя из потребности и поиска пользователей.
Всё это, отчасти, философский вопрос о том строить ли поисковую систему по данным или поисковую систему для тех кто работает с данными. Разница между двумя этими понятиями весьма существенна. И поэтому она начинается с собственного определения того что такое набор данных
#thoughts #data #datasets