Разного рода накопившиеся технологические размышления и не только:

1. Читаю много размышлений о том что моделирование данных отмирает, из последнего [1], автор пишет
о том что у этой ниши нет бизнес модели и все активно ломанулись в направлении озер данных и отсюда столько болот данных (data swamps). Рассуждения обоснованные, а вот стенания нет. Моделирования данных никуда не исчезает, оно перестаёт быть вещью в себе и становится частью чего-то большего. Например, прослеживаемости данных (data lineage) и контроля качества и наблюдаемости (data quality и data observability) которые хотя и часто упоминаются в формате хайпа на грани булшита. А самое главное важно помнить что данных сейчас производится значительно больше чем даже десятилетие назад. Осуществлять тщательное моделирование всего практически невозможно, поэтому дата-команды определяют ключевое и уделяют этому много внимания, а остальное, действительно, часто находится в болоте данных.

2. Вижу всё более распространённую связку rust + python. На rust переписывают модули ранее написанные для Python или пишут их с нуля и делают очень быстрыми. Пример, connector-x [2] библиотека для быстрой загрузки датафреймов из СУБД в Pandas и иные движки для датафреймов․ Реально быстрый движок. И таких примеров много. Хочешь чтобы твой код на Python работал быстро? Перепиши его или зависимые библиотеки на Rust!

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

4. О софт скиллах и открытых проектах, вижу как взлетают и падают опенсорсные проекты по автоматизации чего-либо по модели: "открытый код можно скачать, а ещё мы предлагаем наш продукт как облачный с нашей крутой поддержкой". Так вот взлетают продукты с мощными сообществами и падают продукты с плохой коммуникацией. Вижу такие примеры успеха с dbt или Datahub и вижу противоположное с Splitgraph и Qri. Это из тех кто у меня на виду прямо сейчас. В то же время размер сообщества вообще не показатель его активности. Например, в сообществе Open Data Community в Slack 6641 участник, что довольно много. Но активность там - одно сообщение в месяц, что совсем мало. Очень многое зависит от организаторов сообществ, наличия общих тем и наличия потребности в коммуникации.


Ссылки:
[1] https://medium.com/@chris.jackson_46175/so-who-killed-data-modelling-f39f711c68
[2] https://github.com/sfu-db/connector-x

#thoughts #data #startups

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

Сейчас я выложил два репозитория.

Коллекция тетрадок по анализу данных [1]

Это подборка тетрадок для Jupyter Notebook по разным аспектам работы с госданными:
- datagovru - тетрадка для анализа статистики и реестра данных на портале data.gov.ru
- kremlinlaw - тетрадка с анализом статистики принятия законов собранных с kremlin.ru (не лучший источник)
- nalogstats - тетрадка с анализом статистики регистрации ИП и юр. лиц с сайта ФНС России
- ano-sub - тетрадка с анализом сумм выделяемых НКО через субсидии на основе уже закрытого Минфином реестра субсидий
- regbudgets-roskazna - тетрадка с кодом извлечения данных из отчётов федерального казначейства об исполнении федерального бюджета. Я её делал когда-то для оценки субсидирования СМИ и НКО, там есть примеры финансирования НКО

Последние две тетрадки я использую до сих пор для анализа госрасходов на НКО.

Библиотека анализа структуры госбюджета [2] писалась мной ещё довольно давно, изначально как API для анализа и сравнения изменений в бюджете. В качестве источника использовался budget.gov.ru портал электронного бюджета и был вариант использовать именно её в проекта Госрасходы, но, увы, качество данных в Электронном бюджете было и остаётся весьма посредственным до сих пор.
Сейчас я бы всё это переписал в универсальный формат описания и анализа финансовых данных, но мой интерес к анализу госфинансов слегка поугас за эти годы․

Финансовая отчетность политических партий [3] это код сбора файлов и архив самих финансовых отчетов политических партий за 2005-2020 годы. Сейчас всё это имеет скорее исторический смысл, чем какой-либо ещё. Для истории есть копия этих данных в @ruarxive, а в этом репозитории файлы и код их сбора. Но код применить сейчас сложно потому что ЦИК блокируют почти любые попытки выкачать с сайта что-либо не с помощью браузера. С другой стороны в этом архиве есть отчеты которые с сайта ЦИКа давно убраны. Например, на сайте ЦИКа отчеты начинаются с 2010 года, а здесь собраны с 2005.

Ссылки:
[1] https://github.com/ivbeg/runotebooks
[2] https://github.com/ivbeg/budgetlib
[3] https://github.com/infoculture/ru-cik-data

#opendata #opengov #opensource

В блоге Atlan, продукта для корпоративных каталогов данных, про то что Forrester поменял классификацию каталогов данных с каталогов данных для машинного обучения на каталоги для DataOps [1].

Новость интересная в смене акцентов, потому что ранее и Gartner заменили их "магический квадрат" по управлению метаданными [2] на руководство по активным метаданным [3].

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

Об активных метаданных писала [4] Prukalpa, сооснователь Atlan и из её описания сложно понять отличия идеи активных метаданных от платформ по наблюдению за данными (data observability platforms) таких как Monte Carlo [5]․ Лично по мне так наблюдаемость данных куда как более важный приоритет чем активные метаданные. В случае активных метаданных речь идет о том что "у вас много данных о которых вы не знаете или мало используете", а в случае наблюдаемости данных речь о том что "у вас много критических процессов сбора и обработки данных, вам нужно оперативно их исправлять если что-то идет не так". По аналогии: в одном случае это управление активами, а в другом процедурами и процессами. Что важнее?

Впрочем что Forrester, что Gartner, это известные собиратели трендов и хайпов вперемешку, часто оторвано от реальной практики, и их выбор важнее с точки зрения понимания движения рынка инвесторов чем для реальных технических задач.

Ссылки:
[1] https://humansofdata.atlan.com/2022/10/forrester-enterprise-data-catalogs-dataops/
[2] https://www.gartner.com/en/documents/3993025
[3] https://www.gartner.com/en/documents/4006759
[4] https://towardsdatascience.com/what-is-active-metadata-and-why-does-it-matter-add3408c228
[5] https://www.montecarlodata.com/blog-what-is-data-observability/

#datacatalogs #data #thoughts

По поводу постановления Правительства РФ о национальном репозитории кода [1] мне много что есть сказать. Хорошего, плохого и разного.

Начну с хорошего:
1) Раскрытие кода информационных систем органов власти - это правильно для внутреннего и внешнего их аудита, отчуждаемости систем от их разработчиков, обеспечения прослеживаемости кода, повышения качества его сопровождения и тд.
2) Важно помнить что репозитории кода есть во многих органах власти федеральных и региональных. Есть они у Федерального казначейства, ДИТа Москвы, МЧС РФ и большей части органов власти которые хоть немного заботятся о том что они делают. Но не всегда работа с этим кодом носит системный характер, не всегда есть даже внутренние документы обязывающие поставщиков передавать туда код.

Плохое:
1) Открытая лицензия - это свободная лицензия. Она должна быть OSI совместимой. Just google "osi-compatible open source licenses" и у того что под ней публикует должен быть выбор, потому что там есть вариации. То что вместо адаптации лицензий вроде MIT, Apache, Creative Commons и тд. изобретается велосипед приведет к невозможности или ограничениям использования кода в проектах под другими лицензиями.
2) На самом деле масштаб открытости кода мы не знаем. Репозиторий может включать много кода, но закрытого, а открываться будет лишь малая часть. А для целей "национальной безопасности" могут обязать для доступа авторизовываться только через Госуслуги.
3) То что создается именно государственная платформа для кода имеет те риски что туда могут начать запихивать не только код госпроектов, но и обязать туда сдавать код всех получателей господдержки и субсидий как обязательный шаг.

И, наконец, ключевое соображение. Для раскрытия кода не надо 2-х и более лет и даже больших расходов на создание новых платформ. Нужно только желание. Мало кто понимает что ключевое на платформах вроде Github или Gitlab их инфраструктурность и интегрируемость. Через них устанавливаются пакеты (библиотеки) кода для большинства известных языков программирования, это крупнейшие хабы для коммуникации разработчиков, это ещё много всего из-за чего оттуда разработчики не уходят даже несмотря на репутационные и иные риски когда Github запускал проект Co-Pilot.

Может ли такой платформой стать национальный репозиторий? Я пока не вижу сценария/стратегии/понимания подобного от регуляторов и инициаторов.

Ссылки:
[1] http://publication.pravo.gov.ru/Document/View/0001202210120022

#digital #opensource #russia

Незаслуженно упущенная мной публикация июля этого года What is the value of data? A review of empirical methods [1] от исследователей из Bennett Institute for Public Policy Университета Кэмбриджа. Они разбирают методы оценки стоимости/ценности данных, в первую очередь, с точки зрения экономических оценок их использования и ссылаются на их же работу 2020 года Value of Data report [2], а также на оценки ОЭСР и других.

С научной точки зрения и с точки зрения лоббирования раскрытия данных и принятия политик представления данных (data sharing) в странах где прислушиваются к доводам исследователей - это полезный текст.

Ссылки:
[1] https://www.bennettinstitute.cam.ac.uk/publications/value-of-data/
[2] https://www.bennettinstitute.cam.ac.uk/wp-content/uploads/2020/12/Value_of_data_summary_report_26_Feb.pdf

#opendata #research #policies

Практика цифрового сохранения США

Программа сохранения цифровых данных (Digital Preservation Framework) Национального архива США (NARA) описывает оценку рисков и рекомендуемые планы сохранения для более 600 форматов файлов. Система цифрового сохранения архивов состоит из матрицы рисков, приоритетов и планов действий по сохранению форматов файлов. Планы открыто опубликованы для исследователей и архивистов в специальном репозитории.

В документации системы каждый формат данных отнесен к одной из 16 категорий, таких как «цифровое аудио», «электронные таблицы», «программное обеспечение и код». В августе этого года появилась категория «связанные открытые данные» (linked open data).

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

Также наборы данных коллекций доступны через API.

Подробнее о Digital Preservation Framework Linked Open Data: https://www.archives.gov/preservation/digital-preservation/linked-data

В рубрике регулярных напоминаний не могу не рассказать про сервис оценки простоты языка Простой язык (plainrussian.ru) [1] который я много лет назад сделал и передал в Инфокультуру при её создании.

Это очень простой сервис который на вход получает текст на русском языке и на выходе выдает его сложность в баллах где баллы - это число лет учёбы которые необходимо пройти чтобы понимать этот текст. Например, 11.97 баллов - это, примерно, 1-3 курс ВУЗа, а то есть около 12 лет учебы.

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

У сервиса есть API [2] и открытый код [3]. Код не обновлялся примерно лет 10, во всяком случае та его часть которая использовалась для расчета формул.

И вот в формулах и было самое сложное и интересное. Алгоритмы сервиса работают на тех же принципах что формулы читабельности текста созданные изначально для английского языка: Flesch-Kincaid, SMOG, Automatic Readability Index и другие. В их основе подсчет числа слов на предложение, среднее число слогов на слово, среднее число букв на слово, число редких слов и так далее.

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

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

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

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

Ссылки:
[1] https://plainrussian.ru/
[2] https://github.com/ivbeg/readability.io/wiki/API
[3] https://github.com/infoculture/plainrussian/tree/master/textmetric

#plainrussian #russian #language #api #tools

Похоже Google делают ключевую ставку на поглощённый ими продукт Looker и переименовывают Google Data Studio в Looker Studio [1] и планируют развивать этот бренд и направление․

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

Looker был куплен Google ещё 2.5 года назад [2] и уже сейчас вокруг него выстроена экосистема интегрированных продуктов и большого числа расширений где 20 источников данных предоставляются внутри Looker Studio, а 660 являются партнерскими источниками и коннекторами.

У всего этого, конечно, сильнейшая сторона в доступе к маркетинговым данным. Всё то что является частью "капитализма слежки".

В этом смысле Looker идеально соответствует бизнес модели Google о том что данные входят-данные не выходят.

Поэтому то что на Looker делается ставка, лично меня совершенно не удивляет.

Ссылки:
[1] https://www.youtube.com/watch?v=Bc_hcLVyFJI
[2] https://techcrunch.com/2020/02/13/google-closes-2-6b-looker-acquisition/

#datatools #clouds #google

В рубрике полезных инструментов и полезного чтения о данных:
- The Contract-Powered Data Platform [1] о платформе управления данными с дата-контрактом на каждый тип данных и о её ценности для всех пользователей. Можно весь текст свести к выводу что схемы данных - это хорошо, используйте их повсеместно.
- Compressed Log Processor [2] бесплатное ПО по автоматизации сбора сжатых логов и работы с ними без разжатия. Обещают большую экономию диска и памяти. Делают в стартапе YSCope который также предлагает это же как облачную услугу.
- Data Lineage: State-of-the-art and Implementation Challenges [3] обзор инструментов по прослеживаемости данных, Data Lineage. Главная польза в том что автор уже посмотрел на некоторые из них и, в целом, мои выводы подтверждаются что не все инструменты достаточно зрелые. Плюс в обзоре только инструменты с открытым кодом.
- RecSysOps: Best Practices for Operating a Large-Scale Recommender System [4] наступило время когда все придумывают новые термины. Вот у Netflix'а новая выдумка "RecSysOps" - управление рекомендательными системам. В их блоге сводка некоторых правил того как идёт работа над их внутренней рекомендательной системой. Технических подробностей мало, организационные выглядят любопытными.
- Crossmodal-3600 — Multilingual Reference Captions for Geographically Diverse Images [5] свежий большой набор данных от Google для генерации текстов к изображениям не на английском языке. Большая часть датасетов по этой теме именно на английском, а тут 36 языков.
- State of Data Science and Machine Learning 2022 [6] от Kaggle. Короткие выводы: наибольший рост специалистов по DS в Индии и в Японии, основные языки программирования: Python, SQL, R; основные среды разработки: Jupyter Notebook, RStudio, PyCharm, VSCode; популярность RStudio падает, VSCode растёт. И, популярность всех облачных платформ растёт.
- Microsoft Ignite Book of News [7] очень много новостей о развитии продуктов Microsoft Azule собранных в одной новости. Много про облачные версии их Cosmos DB, развитие MongoDB и множество других СУБД и связанных с базами данных и машинным обучением сервисов.
- The case for a query modification language [8] автор пишет про ещё один язык работы с запросами, QML - Query Modification Language, с акцентом на функции преобразования. Что-то много стало языков запросов и попыток их изменить.

Ссылки:
[1] https://buz.dev/blog/the-contract-powered-data-platform
[2] https://github.com/y-scope/clp
[3] https://medium.com/bliblidotcom-techblog/data-lineage-state-of-the-art-and-implementation-challenges-1ea8dccde9de
[4] https://netflixtechblog.medium.com/recsysops-best-practices-for-operating-a-large-scale-recommender-system-95bbe195a841
[5] https://ai.googleblog.com/2022/10/crossmodal-3600-multilingual-reference.html
[6] https://www.kaggle.com/kaggle-survey-2022
[7] https://news.microsoft.com/ignite-2022-book-of-news/
[8] https://www.thoughtspot.com/blog/the-case-for-a-query-modification-language-qml-and-why-dashboards-are-dead

#data #readings #opensource #opendata

Я продолжаю довольно много читать про то как развивается тема открытых данных в мире, того как развиваются корпоративные каталоги данных и научные репозитории данных. Всё это три разных направления о которых я много раз писал, например, тут [1].

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

Например, для Data Scientist'ов преимущественные инструменты для работы связаны с работой с хорошо структурированными данными, пригодными для быстрой загрузки в СУБД или инструменты вроде программных сред разработок. Почти все порталы открытых данных, или вообще никак, или довольно посредственно предоставляют документацию и схемы данных. Чаще всего эти описания не гармонизированы, а преобразование открытых данных в данные для машинного обучения требует существенных усилий.

Другой пример, стандарты вроде Frictionless Data [2] существуют давно, делает их команда которая когда-то имела отношение к проекту CKAN, наиболее популярному открытому ПО для каталогов открытых данных. Но реально почти нет внедрения этого стандарта за пределами научных сообществ [3] и научных проектов. Госорганы создающие порталы открытых данных очень медленно внедряют стандарты обеспечивающие качество данных. В лучшем случае в порталах внедряются стандарты метаданных вроде DCAT, позволяющие работать с метаданными наборов данных.

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

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

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

Причём, всё вышенаписанное, можно отнести практически к любой стране.

Ссылки:
[1] https://begtin.substack.com/p/11
[2] https://frictionlessdata.io/
[3] https://frictionlessdata.io/adoption/

#opendata #thoughts #datacatalogs

В рубрике открытых данных интересные наборы открытых данных и статьи:
- 1000 крупнейших налогоплательщиков Армении с суммами выплат налогов за 2022 год [1] в формате Excel, с указанием местонахождения компаний, без указания отрасли компании. По Армении, к сожалению, по юридическим лицам общедоступно гораздо меньше информации и так просто отрасль компании не определить без доступа к данным или их покупки. Тем не менее весьма любопытно, можно сделать немало инфографики
- Broken Links: Open Data to Advance Accountability and Combat Corruption [2] отчет и аналитика по открытости данных в области открытости гос-ва и противодействия коррупции на сайте OGP и на данных Global Data Barometer. Затрагивает только страны OGP, поэтому из постсоветских стран Грузия, Киргизия, Украина, Армения, Литва, Латвия, Эстония и Азербайджан там есть, а Казахстана, Беларуси, России, Туркменистана, Таджикистана, Узбекистана там нет
- The State of Open Data 2022 [3] доклад от Digital Science об открытых данных в науке. Состоит из набора статей, полезных к прочтению. Полезно и для понимания как мостика между открытостью науки и открытостью данных как явления в принципе.
- Open Food Facts database [4] если Вы пропустили этот проект базы данных о ингридиентах еды, то самое время на него посмотреть. В базе более чем 2.5 миллиона ингредиентов/продуктов. Есть кусок и по России в 10 тысяч продуктов, Казахстану 218 продуктов, Армении 97 продуктов. А более всего по Франции, почти 1 миллион продуктов (потому что этот проект родом оттуда). Отдают дампы MongoDB, CSV, API, дельты изменений. В общей крутой общественный проект глядя на который можно думать
"почему его сделал не я?". Шутка. А, база эта бесценна

Ссылки:
[1] https://www.petekamutner.am/Shared/Documents/_ts/_ti/Taxpayer_Information_Listings/2022/ck_hhpektt_2022_3_1000_khv_hark.xlsx
[2] https://www.opengovpartnership.org/broken-links/
[3] https://digitalscience.figshare.com/articles/report/The_State_of_Open_Data_2022/21276984/2
[4] https://world.openfoodfacts.org/

#opendata #opengov #datasets

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

Негосударственное
- datacatalogs.ru каталог порталов открытых данных, государственных, академических, некоммерческих и всех других. Охватывает практически порталы всех уровней кроме некоторых муниципальных.
- hubofdata.ru - общественный хаб открытых данных, здесь всегда можно опубликовать свои наборы данных
- clearspending.ru - общественный проект по прозрачности контрактной системы в России. Дампы данных по госконтрактам.
- Awesome opendata Russia - список ссылок в Github на ресурсы посвящённые открытым данным в России. Был прообразом для datacatalogs.ru.
- репозитории Инфокультуры - многочисленные репозитории с данными и кодом Инфокультуры, в том числе с большими датасетами

Государственное
- data.gov.ru - официальный портал открытых данных Российской Федерации.
- fedstat.ru - официальные статистические показатели, в том числе в форматах открытых данных
- data.mos.ru - официальный портал открытых данных Правительства Москвы
- ehd.moscow - единое хранилище данных г. Москвы (статпоказатели и отчеты, нет открытых лицензий)

Международное
- data.worldbank.org - портал данных Мирового Банка, есть данные статистики по России
- data.un.org - портал статистики ООН, есть данные статистики по России

Рекомендации и руководства
- opendatareview.infoculture.ru - работа с открытыми данными: особенности публикации и использования в российском правовом поле

Коммерческие
- datacrafter.ru - каталог проекта Датакрафтер, с открытыми и иными данными собранными из официальных источников и доступных в формате API.
- labelme.ru - каталог данных для машинного обучения от компании LabelMe

Академические
- sophist.hse.ru - единый каталог экономических и социологических данных НИУ ВШЭ
- social.ranepa.ru - социологические данные РАНХиГС

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

#opendata #russia

Только что прошла конференция Coalesce (вернее ещё идёт), я пересматриваю и переслушиваю многие доклады, они про то как data teams организуют свою работу.

Из того что особенно запомнилось.

Data teams: kill your service desk [1] о том почему дата-команды не могут и не должны работать по Agile. Основные аргументы в том что данные - это сложный мир, не модульный, не отчуждаемый, требует другого подхода.

Ссылки:
[1] https://docs.google.com/presentation/d/1-JmXX1RZHLf3VKRZJoPHw-QFUodODzOmu13GJSVdkM4/edit?usp=sharing

#data #datateams

Для тех кто интересуется темой приватности, завтра будет проходить одна из наиболее интересных русскоязычных конференций по этой теме Евразийский конгресс по защите данных [1].

Я также там буду выступать с краткой презентацией про трекеры в мобильных приложениях которые мы нашли в магазине мобильных приложений RuStore.

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

Ссылки:
[1] https://edpc.network/
[2] https://rustoreprivacy.infoculture.ru

#privacy #events

В связи с новостями о возможной ликвидации Роснано, напомню что мы проводили архивацию их сайтов и иных ресурсов в рамках Национального цифрового архива (@ruarxive). Все материалы доступны для прямой выгрузки по ссылке [1] у нас в хранилище, метаданные с описаниями пока хранятся отдельно, скорее всего загрузим уже всё вместе в Интернет-архив.

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

Ссылки:
[1] https://cdn.ruarxive.org/public/webcollect2021/rusnano2021/

#digitalpreservation #webarchives #archives