Миллионы научных статей рискуют исчезнуть из онлайн-хранилищ

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

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

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

Для нового анализа Ив использовал выборку из 7 438 037 научных работ. Все изученные статьи снабжены цифровым идентификатором объекта, или DOI. Это последовательность цифр, букв и символов, которая действует как идентификационный код электронного документа. DOI позволяют однозначно распознать научную работу и использовать ее в качестве ссылки.

Из всех исследований, включенных в выборку, 28%, или более двух миллионов статей, не были доступны ни в одном из крупных цифровых архивов, даже если публикация имела действующий DOI. Только 58% DOI ссылались на статьи, хранящиеся хотя бы в одном архиве. Оставшиеся 14% работ были исключены из исследования, поскольку они были опубликованы слишком недавно, не являлись журнальными статьями или их изначальный источник не мог быть определен.

Полученные результаты не означают, что статьи вообще нельзя найти в сети. Например, они могут быть доступны на сайтах издательств. Однако если последние обанкротятся или что-то случится с их серверами, соответствующие научные работы могут исчезнуть из онлайн-хранилищ.

Оказалось, что менее 1% – или всего около 200 – издательств, загрузили свои статьи в несколько архивов. Около трех четвертей издателей добавили работы в три или более архивных сред. Менее 10% разместили свои материалы как минимум в двух хранилищах.

Треть издательств вообще не занимались постоянным архивированием.
По словам Мартина Ива, его анализ следует рассматривать с некоторыми оговорками. В частности, в выборку исследования вошли только статьи с DOI-метками. Кроме того, в него были включены не все цифровые хранилища, например, архивные среды самих исследовательских институтов не рассматривались.
Несмотря на эти оговорки, анализ хорошо приняли специалисты по хранению данных, не связанных с исследованием. Например, Микаэль Лааксо, сам занимающийся вопросами публикации научных работ в Школе экономики Ханкен в Хельсинки, говорит, что многие люди слепо верят в то, что наличие DOI гарантирует вечную доступность статьи. Вместе с коллегами в 2021 году он показал, что на самом деле в период с 2000 по 2019 год из интернета исчезло более 170 журналов с открытым доступом.

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

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

Исследование было опубликовано в журнале Journal of Librarianship and Scholarly Communication.

#DOI
____
@rujournals - Научные журналы и базы данных

В продолжение про то какие бывают форматы общедоступных данных, есть важный факт индикатор пересечения открытых данных с областями data science. Из, примерно, 29 миллионов ресурсов (файлов) привязанных к датасетам в Dateno, только 4700 - это файлы Parquet, ни одного файла Avro или Orc.

Только около 7 тысяч файлов - это данные в виде дампов Sqlite, и то почти все они - это данные экспортируем из разного рода каталогов геоданных и входящих в файлы geopackage.

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

А самые популярные общедоступные (public domain и открытые данные) данные остаются CSV, XML, XLSX, JSON, TAB, XLS и менее известные в инженерной среде, но известные в научной NetCDF.

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

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

#opendata #dateno #datasets #statistics

К вопросу об открытости данных в Казахстане свежая статья в Exclusive.kz [1]. Проблема с этим порталом в том что он к открытым данным отношения не имеет никакого. Видно что не проделано работы, ни по доступности данных, ни по свободе использования (открытые лицензии) и данные которые туда попадают из других источников парадоксальным образом становятся более, а не менее закрытыми.

Это на фоне того что в Казахстане много открытых геопорталов, баз статистики (ТАЛДАУ) и тд.

Всего 13649 датасетов по Казахстану у нас в Dateno проиндексировано [2], но почти все эти данные - это геоданные и индикаторы из международных источников потому что именно открытые данные, в строгом определении, не публикуются.

И ещё отдельная история о том почему во многих странах госорганы пытаются создавать порталы данных на нетиповых продуктах. В результате они не индексируются ни у нас в Dateno, ни в Google Dataset Search, ни в других поисковиках. При том что в том же data.egov.kz нет ничего такого что нельзя было бы сделать с помощью CKAN, DKAN и ещё ряда продуктов создания каталогов открытых данных.

И это только пока мы говорим про техническую сторону процесса, не затрагивая то какие, собственные данные должны публиковаться чтобы быть востребованными. Подсказка, простые опросы пользователей не работают. Работают приоритеты по high value datasets (датасеты особо ценные) которые формируют страны ЕС, к примеру.

К теме данных в Центральной Азии я ещё буду неоднократно возвращаться.

Ссылки:
[1] https://exclusive.kz/chto-skryvaet-otkrytoe-pravitelstvo-kazahstana/
[2] https://registry.commondata.io/country/KZ

#opendata #opengov #kazakhstan #dataportals

One Trillion Row Challenge - совершенно замечательный по задумке конкурс по работе с датасетом в триллион строк [1] для тех кто работает большими, очень большими и очень-очень большими (шутка) данными на обычном железе или во временно арендуемом облаке, а не на мейнфреймах. Конкурс в том чтобы подсчитать минимальную, среднюю и максимальную температуру по погодным станциям отсортированным по алфавиту. Данные хранятся в 100 тысячах Parquet файлах, по 10 миллионов строк в каждом, а заявки отправляются через открытие issue в репозитории конкурса [2].

Сам конкурс - это продолжение другого конкурса, One Billion Row Challenge [3], где данных было только 1 миллиард, и принимались решения только в виде Java кода.

Решения можно отправлять в дискуссиях на Github в репозитории [4].

Конкурс интересный тем что по многим продуктам не-неожиданно, но подтверждённо очень высокая производительность. Например, в Clickhouse SQL задача с 1 миллиардом строк решается за менее чем 7.5 секунд [5] и у них же 3 минуты на конкурс в 1 триллион строк [6] и пишут что за $0.56, это совсем мало если что.

А в оригинальном посте Dask в облаке Coiled отрабатывает за 8.5 минут или $3.26 в стоимости Amazon Cloud, что тоже очень мало.

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

Ссылки:
[1] https://docs.coiled.io/blog/1trc.html
[2] https://github.com/coiled/1trc
[3] https://www.morling.dev/blog/one-billion-row-challenge/
[4] https://github.com/gunnarmorling/1brc/discussions
[5] https://github.com/gunnarmorling/1brc/discussions/80
[6] https://clickhouse.com/blog/clickhouse-1-trillion-row-challenge

#data #datasets #opensource #datatools

Продолжаю рассказывать понемногу про поисковик Dateno и про то как в нём индексируются датасеты. Его особенность в тех индикаторах которые используются внутри для наполнения базы данных. Иначе говоря как мы понимаем что надо проиндексировать? Какие данные добавить в первую очередь? По каким критериям их собирать ? Эти вопросы важные, потому что сейчас проиндексирована только половина реестра всех каталогов данных и это только по числу каталогов, а если считать в датасетах, то не около 10% от всех (точно оценить сложно, никто просто не знает).

Так вот эти критерии - это:
- число проиндексированных датасетов - самое простое и очевидное, не нужно объяснять почему
- число охваченных каталогов данных - тоже важный показатель того как хорошо индексирование идёт
- число охваченных стран (geographic coverage) - это уже сложнее, условно по каждой стране должны находится наборы данных. Отчасти легко решается за счёт международных каталогов статистики, но лишь отчасти и с большим искаженим только в эту статистику.
- степень диверсификации данных (data diversity) - самостоятельно выдуманный термин основная идея которого в том что данные в поиске должны быть разные: геоданные, научные данные, открытые данные, статистика, данные для ML, микроданные и тд. Понятно что каких-то данных больше, каких-то меньше, но всех должно быть значимое количество. Условно не меньше 50% проиндексированных каталогов по типам, не меньше 50 тысяч датасетов каждого типа

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

Поэтому поисковый индекс Dateno с самого начала собирался сложным путём, по приоритетам достижения этих индикаторов. И 10 миллионов охваченных датасетов - это самоограничение именно такого подхода, потому что очень, действительно, очень просто сделать поисковик на 30-50 миллионов датасетов из которых 50% будет исследовательскими данными в США, ещё 25% исследовательскими данными Китая, ещё 20% научными данными ЕС и только 5% что-то ещё. Моментально получится поисковик по научным данным с лёгким добавлением всего остального.

Но для науки есть свои поисковые системы, поэтому в Dateno хотя и важным приоритетом является индексирование как можно большего объёма всех наборов данных, но не в ущерб их качеству.

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

#opendata #dateno #datasets #crawling

Отвлекаясь немного от темы данных и технологий.

В Испании Верховный суд постановил временно заблокировать Телеграм после жалобы группы "копирастов" из ведущих медиа компаний: Mediaset, Atresmedia, Movistar и Egeda на то что в Телеграм'е пиратят и не удаляют спираченный у них контент [1].

Не менее важна причина решения суда, главный аргумент в "недостаточной кооперации" со стороны руководства Телеграма, непонятно ли кооперация с кем, с властями страны или с владельцами контента.

В любом случае, блокировкой Телеграма, Испания присоединилась к клубу стран состоящему из Кубы, Ирана, Пакистана и Таиланда.

Что тут скажешь, пора испанцам перенимать иранский опыт по обходу блокировок соцсетей.

Ссылки:
[1] https://www.euronews.com/next/2024/03/23/spains-high-court-orders-block-on-telegram-messaging-app-as-a-precautionary-measure

#privacy #piracy #telegram

Я регулярно пишу про такое явление как датацентричное мышление "что угодно как таблица" и в более узком звучании "что-угодно как SQL". Причём последнее попадается всё чаще и всё чаще всё то ранее было доступно каким-то другим образом через API или в иной специфической форме доступно как таблицы.

Из последнего, sqlelf, это программная библиотека и утилита превращающая метаданные из исполняемых Linux файлов в базу Sqlite и позволяют проделывать все дальнейшие операции по чтению этих метаданных из SQL таблиц. Удобно для всех кто занимается форенсикой под Unix-like системы.

Из похожего, несколько лет назад я делал утилиту metawarc, индексирует содержание веб-архивов в формате WARC и создаёт локальную Sqlite базу с результатами. Что позволяет сильно ускорить задачи по подсчёту статистики, экспорту файлов из архива (архивы бывают большие и это важна задача) и многое другое. Единственное что я не сделал - это там нет SQL интерфейса, хотя добавить такую команду и примеры это дело пары часов.

Похожий код у меня есть для HTML страниц, он превращает дерево HTML в плоскую таблицу с дополнительным обсчётом ряда параметров. Я его всё подумывал опубликовать и возможно что база в памяти это решение. Возможно, потому сколько я не пытался не удаётся сильно уменьшить размеры таблицы тэгов. Она выходит больше оригинального файла от 7 до 21 раза, это без использования СУБД внутри, только размер pandas Dataframe.

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

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

Аналогично для многих других сервисов и продуктов которые сейчас интегрируются через ETL и ELT костыли.

А сама идея "что-угодно как SQL" может развиваться ещё применительно много к чему. К файловой системе, к реестру Windows, к работе с Excel/ODS файлами, к работе с онлайн таблицами (типа Google Sheets), к вебсайтам и ещё много к чему.

#thoughts #data #datatools #sql #everythingisdata

Поскольку существенная часть моей деятельности некоммерческая, то приличия не позволяют не клянчить на неё просить на неё поддержку с какой-то регулярностью.

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

В Армении на Open Data Armenia

На что мы собираем деньги?
1. На сбор и публикацию открытых данных (github.com/opendataam)
2. На организацию мероприятий таких как Open Data Day (odd.opendata.am)
3. На конкурсы вроде конкурса Open Data Armenia Contest (contest.opendata.am)

Как помочь?

Самый простой способ это стать подписчиком Open Data Armenia на Github https://github.com/sponsors/opendataam/ Мы будем ещё много выкладывать открытого кода и наборов данных и подписка через Github - это самое логичное что только возможно.

Альтернативно можно перевести по банковским реквизитам:
номер счёта 163618011379 для пожертвований в Евро, назначение ""OPEN DATA" development centre public organization" Donation. Если хотите пожертвовать в другой валюте, то напишите мне, перешлю реквизиты.


В России на Инфокультуру

В России деятельность сейчас очень сильно ограничена, но АНО Инфокультура всё ещё существует и всё ещё делает проекты по открытым данным и не только. В приоритеты работа по архивации данных, значимого контента и работа над Национальным цифровым архивом (ruarxive.org).

Как поддержать?

Самое простое - это пожертвовать через форму на сайте https://www.infoculture.ru/donation/, а если Вы представляете организацию то можно напрямую перевести на счёт, достаточно написать мне, я перешлю реквизиты.

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

#support #ngo #donation