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

Например, особняком идёт всё что касается 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

Давно пишу по кусочкам лонгрид про природу данных и наборов данных, про то как отличается их восприятие людьми разных профессий и потребностей и как от того где они применяются "плавает" это определение.

Самый простой пример - это всегда ли данные машиночитаемы? К примеру, данные в виде файлов 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

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

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

Задача то довольно простая, присвоение цифровым объектам геолокации не по принципу координат или адреса, а в привязке к территории от макрорегиона/группы стран, до конкретного города/территории субрегионального уровня. В Dateno это делается через привязку всего к справочникам UN M49, ISO3166-1 и ISO3166-2. Сложности возникают в том что в каталогах данных где есть геоаннотирование чаще всего нет уникальных кодов территорий и чаще всего названия макрорегионов, к примеру, не гармонизированы.

А потребность в аннотировании есть не только к датасетам, но и ко множеству других объектов: тексты, архивы, документы, изображения и тд.

#thoughts #modelling #geospatial

У меня довольно небольшой телеграм канал у которого чуть более 8 тысяч подписчиков и, честно говоря, я практически не вкладывался в его продвижение чем-либо кроме контента, но мне регулярно пишут с просьбой опубликовать тот или иной материал и несмотря на малость канала, похоже, нужна какая-то публичная политика с вопросами и ответами.

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

2. Но если Вы публикуете открытые данные или создаете продукт с открытым кодом по работе с данными и они любопытные, то я обязательно об этом захочу написать.

3. Также как если Вы проводите какое-либо интересное открытое мероприятие, особенно если оно посвящено таким редким темам как архивация цифрового контента. Напомню что про архивацию я также модерирую телеграм канал @ruarxive.

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

5. Я редко пишу про мероприятия где я не участвую, не участвовал или не участвовала Инфокультура или Open Data Armenia. Только если оно по каким-то причинам важно мне лично.

6. Я стараюсь писать про все случаи закрытых данных в РФ и не только, они все под хэшем #closeddata и если Вы такие новые факты знаете, я обязательно об этом напишу и упомяну.

7. То же самое в отношении недокументированных API о которых я пишу тут время от времени с оговоркой что публикация этой информации не приводит к каким-либо неприятным последствиям вроде исчезновения этих данных.

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

9. Во всём остальном действует очень простое правило. К публичному телеграм каналу я отношусь как открытой записной книжке. Фильтр который я задаю себе при любой публикации захочу ли я это перечитать в будущем? Если нет, то и зачем писать?

#thoughts #contentpolicy #blogging

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

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

С одной стороны я вижу огромное число продуктов/проектов/компаний имеют число трамвая, равное единице. Это практически все частные инициативы основанные на пассионарности и харизме основателя, а не на выстроенности процессов.

С другой многие компании отказываются от использования того или иного опенсорсного или проприетарного продукта если у него всего один разработчик. В случае опен сорса это довольно легко проверить, в случае коммерческого ПО сложнее, но то что лишь один человек стоит за чем-то важным - это очень большие риски.

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

#thoughts

Я как раз собирался составить очередную подборку интересного чтения про данные и понял что один из текстов стоит упомянуть отдельно и поговорить про него. Это заметка Is Excel immortal? [1] от Benn Stancil. Бэн регулярно пишет интересно про данные, венчурный рынок, стартапы, аналитику и про Excel он пишет очень правильные слова.

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

Причём тут важна сильная сторона Excel, это сочетание гибкой манипуляции табличными данными, внутреннего языка и формул и (самое главное!) гибкой визуализации.

Даже в самых продвинутых сервисах с визуальной аналитикой, например, продаж и посещаемости, менеджеры скачивают Excel файлы и работают с данными внутри них.

Бэн упоминает замену в виде Tableau, но Tableau не поставляется по умолчанию на почти все десктопы и у него отсутствует (?) сильный инструмент по операциями с данными. Странно что при этом он не упоминает PowerBI от MS.

Но в, самом деле, какой может быть замена Excel к 2075 году?

Лично я много что перепробовал в своей жизни:
- Airtable для ведения таблиц онлайн. Скорее онлайн замена MS Access, непомерно дорогая при коммерческом использовании, удобная при личном, но
- OpenRefine для того что называют data wrangling. Он заменяет Excel в задачах визуальной чистки данных.
- PowerBI для визуализации данных, но, признаюсь, в простых задачах Excel удобнее

Что печально, продуктов с открытым кодом для таких задач маловато. Но и коммерческие продукты пока не тянут что-то кроме ограниченных задач.

Обратите внимание, что обычно Excel'ю противопоставляют LibreOffice/OpenOffice, но я лично считаю что времена такого сравнения давно прошли. LibreOffice/OpenOffice обладает очень ограниченными функциями визуализации и манипуляции с данными.

Каким может быть Excel будущего?

1) Разделение данных и представления. Таблицы с данными в embedded базе, а ля DuckDB или SQlite, а разметка в гипертексте, может быть на основе одного из существующих стандартов.
2) Разделение визуализации и представления. Звучит странно, но это как с данными. Визуализация строится на основе одного из будущих стандартов описания дашбордов, а разметка это как накладываемые на неё стили.
3) Облачная синхронизация, но local-first.
4) Отсутствие ограничений на объёмы хранимых данных
5) Типизация вкладок. Сейчас когда в Excel готовят данные некоторые вкладки - это таблицы, а другие это тексты с пояснениями к ним и третьи - это формы. Нужны вкладки которые останутся дата таблицами, вкладки заметок, вкладки форм и вкладки аля markdown notebooks

Что можно добавить?

Ссылки:
[1] https://benn.substack.com/p/is-excel-immortal

#thoughts #excel #data #datatools

Симпатичный жанр NO SLIDES, выступления без презентаций и одноимённая конференция [1] где нет презентаций в виде слайдов, только прямая речь и демонстрация экрана. А также таблица с выступлениями прошедшей конференции со ссылками на видеозаписи на Youtube [2]. Почти всё про данные и про аналитику, есть немало интересного что посмотреть.

Но самое главное жанр, я вот лично им не владею в достаточной мере, у меня вместо этого буквально тысячи слайдов. Даже при том что я начиная с ковида сильно снизил публичную активность с выступлениями, но жанр NO SLIDES пробовал всего 3-4 раза за свою жизнь.

Ссылки:
[1] https://noslides.wtf/conference
[2] https://docs.google.com/spreadsheets/d/1Wx6S3qUjjSuK-VX2tkoydTZGb1LzcYnht4N_WkBwApI/edit?ref=blef.fr&gid=0#gid=0

#thoughts #presentations #conferences

Хорошая статья в Системном блоке про судьбу ABBYY, их продукта Compreno и научного подхода в переводе текстов [1]. Если вкратце, то судьба печально, LLM ИИ пожирают мир. Я помню в 2010-х разговоры про Compreno как люди вовлеченные в этот проект его расхваливали, но вживую его так и не успел попробовать, а теперь уже и непонятно зачем.

А вообще то что пишет автор про то что простые методы обученные на бесконечном объёме данных дают больший эффект - это не только про гибель трансформацию компьютерной лингвистики, это и про будущее онтологического моделирования, это про судьбу проектов вроде Wolfram Alpha (похоже недолгую уже), это про применение LLM в моделировании и систематизации данных.

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

А что говорить про задачи онтологического моделирования во многих исследовательских проектах. Я всё жду когда появятся научные статьи с тезисами вроде "Мы заменили команду из 10 онтологов на LLM модель и результат был не хуже".

Ссылки:
[1] https://sysblok.ru/blog/gorkij-urok-abbyy-kak-lingvisty-proigrali-poslednjuju-bitvu-za-nlp/

#thoughts #readings #ai

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

Например, в 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