Размышляя над задачами поиска данных (data discovery) и их доступностью вспоминаю про ключевой принцип отличия открытых данных от общедоступной информации. Статус данных как открытых предполагает осознанность владельцем данных того что он делает. Чтобы опубликовать датасет, ему/ей надо подумать о метаданных, надо выбрать лицензию, надо подготовить данные в машиночитаемом виде и, желательно, убедится что данные разумного качества. Это всё хорошо работает когда такая осознанность у владельца данных есть и работает так себе когда её недостаточно.

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

Когда мы говорим про поиск данных, то пользователи редко ищут именно открытые данные, их, как правило, интересуют данные насколько возможно хорошего качества, желательно с максимальной свободой использования и желательно с минимальным техническим порогом для их использования. Желательно машиночитаемых, но часто если даже нет, то можно и скрейпить их из HTML или из документов .

Я довольно давно размышляю о том как можно охватить больше данных за пределами каталогов данных и идей и мыслей довольно много, но за каждым шагом есть свои ограничения и оценка востребованности.
1. Сейчас Dateno индексирует данные работая с ограниченным числом источников каталогизируемых полу-вручную. Если отказаться от этого принципа и подключить индексирование всего что есть через краулинг schema.org Dataset, то число наборов данных можно нарастить на 10-15 миллионов датасетов, одновременно снизится качество метаданных, появится SEO спам и просто мусор. Одна из претензий к Google Dataset Search именно по наличию такого мусора в индексе и сильная заспамленность.
2. Кроме датасетов по schema.org есть огромное число машиночитаемых ресурсов и API доступных через краулинг сайтов. Самые очевидные RSS/ATOM фиды которые к API можно отнести. Менее очевидные, к примеру, эндпоинты ArcGIS серверов которые и так уже активно в Dateno добавлялись , но не как датасеты, а как каталоги таблиц и с ручной проверкой. Тем не менее открытых API немало, но их поиск и доступность ближе к задачам OSINT и инфобеза, а не только data discovery.
3. Многие немашиночитаемые сведения можно делать машиночитаемыми автоматически. Извлекать таблицы из разных языков разметки, преобразовывать документы в таблицы или извлекать таблицы из контента там где они есть. Например, из НПА, из научных статей, из корпоративной отчетности и ещё много чего. Но это тоже много маленьких данных, интересных некоторым исследователям, журналистам, но не так вероятно что интересные data scientist'ам.
4. Тем не менее если оценивать качество поиска по числу наборов данных как основному критерию, то обогнать Google Dataset Search и другие поисковики по данным - это не то реальная, это не такая уж сложная задача. Вызовы в ней скорее в моделировании, как создавать фасеты на разнородных данных, не всегда имеющих геопривязку, например
5. Сложнее задача в создании нового качества доступа к общедоступным данным. Как сделать проиндексированные датасеты удобными? Как облегчить работу аналитиков и иных пользователей? И вот тут концептуальный момент в том где происходит переход от поисковика по метаданным к системе управления данными. К примеру, для статистических индикаторов невелика разница между тем чтобы индексировать их описание (метаданные) и сами значения. По ресурсоёмкости почти одно и то же, а имея копии сотен статистических порталов данных, остаёмся ли мы поисковиком или становимся агрегатором и можно превращаться во что-то вроде Statista ? Неочевидно пока что

#opendata #datasearch #datasets #dateno #thoughts

Я уже писал об этом, но можно и напомнить о том как готовят сейчас наборы данных. У Open Knowledge Foundation есть в работе инструмент Open Data Editor [1]. Последний его релиз был в октябре 2023 года и сейчас его активно разрабатывают. Из полезных его возможностей - это ручное аннотирование файлов, заполнение метаданных и простые операции по очистке данных и прямая публикация данных в дата серверах вроде CKAN и сервисах вроде Github и Zenodo.

Для всех кто использует CKAN как основной продукт для публикации данных инструмент весьма полезный.

С открытым кодом под лицензией MIT.

Ссылки:
[1] https://opendataeditor.okfn.org

#opendata #opensource

Регулярная подборка ссылок про данные, технологи и не только:
- Desbordante [1] инструмент идентификации паттернов в данных. Обещают что может находить хависимости между колонками таблиц, на входе получает csv, на выходе список зависимостей. Команда разработчиков из СПбГУ, на английском и на русском языках есть пояснения как инструмент работает [2]. Лицензия AGPL, что слегка ограничивает использование, но сам продукт выглядит интересно для тех кто занимается exploratory analysis, data discovery и иными дисциплинами о том какие данные бывают и как они устроены. Я так понимаю что команда разработки имела/имеет какое-то отношение к компании Unidata, судя по тому что от неё был текст на русском на хабр
- Cloudzip [4] утилита на языке Go по дистанционному листанию и выгрузке отдельных файлов из больших ZIP архивов без скачивания ZIP архива целиком. Не первый вижу инструмент в этой области и но он безусловно выглядит практично, когда тебе надо скачать индивидуальный файл из многодесяткогигабайтного архива. Практического применения у такого инструмента много, а автор его Oz Katz, один из создателей lakeFS. Написано на языке Go. Лицензия Apache 2.0
- remotezip [5] в продолжение к предыдущему инструменту, то же самое но в виде библиотеки для Python. Да, идея давняя давно витающая и реализуемая.
- klib [6] набор функций в виде библиотеки для Python по очистке данных внутри датафреймов Pandas. Выполняет набор простых операций, в каком-то смысле заменяет OpenRefine. Для тех кто чистит данные в Jupyter Notebook'ах будет полезно.
- ydata-profiling [7] ещё один инструмент из области Exploratory Data Analysis, тоже интегрированный с датафреймами. У этой же команды есть коммерческий продукт каталога данных (только облачный увы) в котором явно profiling применяется.

Ссылки:
[1] https://github.com/Desbordante/desbordante-core
[2] https://medium.com/@chernishev/desbordante-2-0-0-released-8c174aa04e87
[3] https://habr.com/ru/companies/unidata/articles/667636/
[4] https://github.com/ozkatz/cloudzip
[5] https://github.com/gtsystem/python-remotezip
[6] https://github.com/akanz1/klib
[7] https://github.com/ydataai/ydata-profiling

#opensource #data #datatools

Я, в последнее время, реже пишу про тему приватности, но актуальности тема не теряет. Для тех кто интересуется этой темой в РФ, команда из Regional Privacy Professional Association (RPPA.pro) с мая месяца запускают курс по AI Governance [1] с акцентом на юридические аспекты разработки и применения AI решений.

Тем кто этой проблематикой интересуется, всячески рекомендую.

Ссылки:
[1] https://rppa.pro/training/aigovernance

#ai #privacy

К вопросу о том что порталы открытых данных довольно далеки от data инженерии. Есть и исключения, например, практически неизвестный широкой публике продукт Opendatasoft на котором работает, например, портал открытых данных Катара [1] и ещё чуть менее 400 порталов открытых данных в мире. И вот они добавили поддержку экспорта данных в формате Parquet к другим способам экспорта: CSV, Excel, JSON и REST API. Со многими датасетами которые приходится скачивать с порталов на их технологии стало проще работать.

Важная оговорка только в том что хотя инсталляций в Opendatasoft немало , но данных не так много. Реально их в районе 33-35 тысяч датасетов поскольку их софт требует только структурированных данных и превратить его в помойку из Excel файлов не получится. Что делает данные оттуда качеством повыше чем в среднем на порталах открытых данных, но значительно меньшими по числу записей.

Кстати по этой причине этот продукт хорошо годится для публикации официальной статистики и его в этой цели часто используют. Но для реализации принципа open by default он годится плохо потому что не все данные структурированы хорошо и ещё есть много legacy.

Пока же скажу что все каталоги Opendatasoft индексируются в Dateno и похоже что скоро надо будет обновлять индекс для возможности скачивать Parquet файлы.

Ссылки:
[1] https://www.data.gov.qa

#opendata #datacatalogs #datasets #qatar #dateno

Сколько в мире общедоступных данных? Количественно? Качественно? Объемно?

Я лично не могу сказать про всё-всё-всё, но могу оценить по тому с чем работаю. В Dateno сейчас проиндексировано чуть менее 15 миллионов наборов данных, к которым прилинковано около 34 миллионов ресурсов в виде файлов и точек подключения к API. Из них не менее 1.7 миллионов файлов - это CSV файлы. В реальности их больше, потому что не по всем ссылкам на ресурсы можно понять формат и поскольку часть CSV файлов находится внутри ZIP, GZ, XZ и других архивах, но для оценки снизу можно исходить из этой цифры.

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

Вот ещё цифры:
- 41 тысяча CSV файлов из 45 каталогов данных составляют в 192 GB
- в среднем получается 4.6 мегабайта на один CSV файл
- топ 100 CSV файлов из этого списка в несжатом виде - это 51 GB

Если сделать копию только всех CSV файлов ссылки на которые есть в Dateno то это будет порядка 4.6M*1.7M = 7.8TB

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

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

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

#opendata #data #datasets #dateno

В рубрике особенно больших открытых данных для тех кто хочет поработать с данными большого размера Umbra Open Data [1] открытый каталог данных спутниковых снимков со спутников Umbra работающих по технологии Synthetic Aperture Radar (SAR) с разрешением до 16 сантиметров и способные делать изображения ночью, сквозь облака и отслеживать изменения.

В открытом каталоге опубликовано более 17 терабайт изображений в форматах NITF, GeoTIFF и CPHD. Доступ к данным через API Amazon AWS, напрямую скачивая из S3 корзины или через STAC Browser.

Всего в каталоге Amazon 20 крупных наборов спутниковых данных, все доступны под спецификацией STAC, а общий объём составляет сотни терабайт.

Ссылки:
[1] https://registry.opendata.aws/umbra-open-data/
[2] https://registry.opendata.aws/

#opendata #datasets #satellites #data #geodata

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

Итак:
- Идентификация условий использования данных. Датасеты и API часто сопровождают информацией об условиях использования и не всегда стандартизировано. Тексты могут быть короткими, может быть аббревиатурой одной из лицензий CC, а может быть ссылка на внешний ресурс. Эту задачу не обязательно решать через ML, например, в рамках Dateno я публиковал код cdi-licensemapper где нет ML, а только вручную собранные правила для сопоставления текстов и ссылок лицензий по словарю в режиме сравнения 1к1. Но ML тут применимо и может охватить гораздо больше датасетов и описаний API.
- Идентификации тематики данных. Отличается от идентификации тематики текста, данные могут быть структурированы, данные могут почти не содержать текста, метаданные могут почти не содержать детальных описаний, но почти всегда есть информация о первоисточнике. Когда первоисточник сам обладает тематикой (которую тоже надо идентифицировать вручную или автоматически), то иногда её можно сразу транслировать на датасет. Типа если у нас каталог данных по биоинформатике, логично что все датасеты по биоинформатике тоже. Но, много случаев, когда в крупнейших каталогах данных данные по разным темам. Это и портал данных США, и европейский портал данных и ещё много какие другие. Поэтому задача тут двойная, создать классификатор тем и автоматически по нему идентифицировать. В идеале решить сложную задачу, создать автоматически расширяемых классификатор тем и уметь привязывать к нему датасеты. Частично эта задача в Dateno решается через простые правила и простые справочники тем в коде cdi-topicmapper, но, опять же, пока без ML
- Понимание данных. Это не одна задача, а группа ML задач дающих ответ на вопросы: "А что там внутри датасета? А что это за формат данных? А что с ним можно делать?". Соответственно к таким практическим задачам можно отнести:
- идентификация формата файла. Это то что частично умеет делать Google Magika Эта задача много где актуальна и востребована, не только в отношении датасетов.
- идентификация структуры данных и простых типов данных. Большая часть современных инструментов умеют понимать когда получают на вход строки, числа, даты и тд., но вариативность типов гораздо больше и что важнее это понимание структуры файла. Например, стат показатель можно описать в режиме двух колонок, значение и год, а можно вытянуть в одну строку и каждому году дать отдельную колонку. И так и так встречается часто, в профессиональных статистических продуктах, чаще даже сложнее. Основные шаблоны структур файлов подаются типизации, но нет продуктов умеющих такое делать.
- идентификация семантических типов данных задача актуальная для всего что касается автоматического анализа баз данных, идентификации персональных данных, задач EDA (Exploratory Data Analysis) и ещё много чего другого. Я лично какое-то время назад писал специальную библиотеку и утилиту metacrafter которая много что умеет идентифицировать, но там есть над чем работать, в первую очередь по автообнаружению неизвестных типов и по снижению числа ошибочной классификации. Тут точно нужно много ML
- Автоматизированная обработка данных. Напрямую связана с задачами понимания данных и относится к тому какие автоматические операции над датасетом можно предпринять для изменений и преобразований. Можно разделить на несколько подзадач:
- автоматизация очистки данных. Идентифицируем структурные аномалии и аномалии значений, определяем способы их устранения, определяем можно ли действовать автоматически или требуется участие оператора. Много где уже об этом думают, постепенно будут появляться продукты помогающие в таких задачах на типовых данных. Примеров коммерческих продуктов очень много, с открытым кодом пока не так много как хотелось бы.

- автоматизация обогащения данных, также напрямую зависит от задач по пониманию данных. Если мы знаем семантические типы данных то можем автоматически данные обогатить. Например, в данных есть коды стран, мы можем автоматически обогатить датасет информацией о макрорегионе, о размере территории, численности жителей, GDP, уровню дохода и тд. Особенно это важно при автоматизации визуализации данных, это резко сокращает время подготовки данных для дата аналитиков и дата журналистов.
- мэтчинг записей, очень распространённая задача связанная с данными об организациях и / или людях и/или адресах, недвижимости, имуществе и так далее. Это необходимость сопоставлять записи по наборам идентификаторов, не всегда нормализованных. Задача практическая во всех продуктах связанных с комплаенсом и анализе конкурентов.
- Автоматическая визуализация данных. Зависит от многих задач по пониманию данных, но даже когда и если известны типы полей и структура файла, отдельная задача в том как автоматически визуализировать датасет наиболее наглядным образом. Как сузить зону отображения для геоданных. Как лучше всего визуализировать статистические данные. Как визуализировать не статистические. Как избежать "перегрузки изображения" и ещё многое другое. Это задачи Auto-BI, понемногу решаются в частных случаев, и пока не решены в общем.

Кроме того ещё ещё немало ML задач в таких направлениях как обнаружение данных, извлечение данных, поиск данных и ещё многое другое, об этом я ещё думаю и напишу в одном из последующих постов.

Лично для себя, когда я смотрю на ML и data science то меня цепляют только вот такие задачи. Не самого прямого практического применения (это не распознавание людей или распознавание речи, к примеру), а именно в применении к данным как предмету исследований, а не как инструменту исследований.

#opendata #data #datascience #ml #machinelearning

Сегодня 109-я годовщина Геноцида армян, первой гуманитарной катастрофы XX века. 24-е апреля – день, когда была арестована и казнена армянская интеллигенция, однако систематическая резня армян в Османской империи началась ещё в 1890-х и завершилась лишь около 1922 года, распространившись также на территорию Арцаха и нынешнего Азербайджана.

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

Сайт Музея-института Геноцида армян
Houshamadyan – проект, направленный на реконструкцию жизни армян в селах и городах Османской империи
3D клипы и изображения из средневекового Ани, оставшегося по ту сторону границы

Историческая статистика

Данные об армянах, прибывших в США морским путем с начала XX в. до 1930-х, а также элементы статистики натурализации, заключения браков. смертности и др.
Статьи с деталями о демографии и миграциях в отдельных провинциях

Фотографии и истории

Репозиторий с оригинальными фотографиями, запечатлевшими армянский быт в Османской империи с 1860-х гг., включая портреты из лагерей и поселений беженцев
Истории сбережённых семейных вещей и фотографий
Архив исторических фотографий Granger

Свидетельства очевидцев и СМИ

Список записей о Геноциде в архивах дипломатов и миссионеров и частных коллекций
Освещение Геноцида в мировой прессе в 1915-1920 и в XXI в. На сайте Armenian National Institute также доступны фотоколлекции, списки памятников жертвам Геноцида по странам, публичные заявления о Геноциде и др.
Видео и аудио-свидетельства уцелевших во время Геноцида на разных языках с детальными метаданными и контекстом (требуется регистрация, многие видео с субтитрами)

Не забывайте делиться с нами важными находками.

В рубрике больших интересных наборов данных Global Contract-level Public Procurement Dataset [1] единая база из 72 миллионов госконтрактов по 42 странам собранная в Central European University. Охватывают 2006-2021 годы, обещают обновления тут [2], но пока их не выкладывали. Что характерно, это не база Open Contracting, данные собирались из разных источников и в разных форматах.

Много это или мало? В российском проекте Госзатраты собрано более 58 миллионов госконтрактов [3]. По стандарту Open Contracting в мире публикуют около 55 стран, точное число контрактов сказать не могу, но точно миллионы-десятки миллионов.

В США на портале USASpending [4] опубликовано тоже порядка 58 миллиона федеральных контрактов, а если считать все процедуры предоставления госсредств (гранты, субсидии, прямые платежи), то около 150 миллионов.

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

Ссылки:
[1] https://www.sciencedirect.com/science/article/pii/S2352340924003810
[2] https://www.govtransparency.eu/category/databases/
[3] https://clearspending.ru/
[4] https://usaspending.gov

#opendata #datasets #procurement #data #contracts

Стоило мне чуток отвлечься на активный отдых на майские праздники так тут столько всего интересного не-произошло. В РФ правительство не-сменилось и в мире много чего ещё не-приключилось. А я уже очень скоро вернусь к регулярным текстам про каталоги данных, природу данных, инструменты, регулирование и не только.

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

#opendata #data #blogging