В Армении открыли National Open Access Desk (NOAD) [1] проект по открытости науки (open access) помогающий учёным не просто публиковать результаты исследований таких как статьи, публикации и данные, но и интегрировать результаты в общеевропейскую инициативу OpenAIRE [2]. Сама платформа NOAD работает на польском продукте DinGO dLibra [3], а в Армении поддерживается Институтом проблем информатизации и автоматизации.

Ссылки:
[1] https://noad.sci.am
[2] https://explore.openaire.eu/
[3] https://dingo.psnc.pl/

#opendata #openaccess

В прошлую пятницу я выступал на конференции по открытости финансов организованной НИФИ при Минфине РФ. Выступал я там, скорее, с экспертной презентацией о том как устроено раскрытие данных о госфинансах в России и в мире. Не знаю будут ли организаторы выкладывать запись, обычно то что я пишу на слайдах это 30-50% дополнения к тому о чём говорю. Если кто-то интересуется этой темой, моя презентация доступна по ссылке [1]

Ссылки:
[1] https://www.beautiful.ai/player/-MY3pm6wz-kYHb1obuzj

#budgets #govfinances

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

- Exodus Privacy [1] - набор инструментов и база трекеров от французской НКО Exodus Privacy
- Pithus [2] - инструмент для анализа приложений для Android с удобным интерфейсом. Ограничения: apk файлы не более 65 мегабайт
- Apkpure [3] - сервис для выгрузки APK файлов для телефонов Android
- Mobile Security Framework [4] - инструмент анализа APK файлов, с полностью открытым кодом
- Virustotal [5] - умеет выдавать подробную информацию, в том числе, про APK файлы.
- AppCensus [6] - база данных и консультанты/исследователи разбирающие мобильные приложения и отслеживающие передаваемый ими трафик. Публикуют отчёты об исследованиях, например, австралийских приложений
- AppBrain [7] - большая база собранных метаданных и данных по мобильным приложениям
- AppFollow [8] - сервис мониторинга инсталляций и отзывов о приложениях.

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

Ссылки:
[1] https://exodus-privacy.org
[2] https://beta.pithus.org
[3] https://apkpure.com
[4] https://opensecurity.in
[5] https://virustotal.com
[6] https://www.appcensus.io
[7] https://www.appbrain.com
[8] https://appfollow.io

#privacy #android #mobile

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

Итак, список:
- юридический анализ условий использования приложений (государственных, предустанавливаемых, банковских или других списками). Подсказка - у некоторых госприложений вместо условий использования эдакий "черновичок", не то чтобы совсем пустой документ, но юридически ничтожный.
- динамический анализ приложений трудоёмкая такая работа, требует полноценного стенда или перепрошитых телефонов, но позволяет собрать инфу по всем подключениям ко всем серверам. Работает не идеально, потому что некоторые особо хитрые разработчики научились передавать под видом TLS трафика совсем другое, так, например, разработчики приложения Calm делают.
- углублённый анализ с декомпиляцией Android приложения - это почти всегда Java и там почти всегда можно что-то прочитать, хотя и многое подвергается обфускации. Но есть и программные библиотеки скомпилированные под разные платформы и идущие в связке с этими приложениями (кстати сама экосистема андроида очень неэффективная в части хранения и передачи данных). Это такая часть требующая повышенной аккуратности чтобы ничьи права не нарушить, но в этих библиотеках чего только нет. Даже без докомпиляции, к примеру, в библиотеку для работы с Яндекс картами вшиты ссылки на закодированные файлы в Dropbox и на Amazon AWS.
- персональные данные тут, на самом деле, надо объяснить что такое рекламный идентификатор устройства Андроид, идентификатор пользователя, цифровой фингерпринтинг и тд. А также показать на примерах как они собираются и куда передаются, и таких примеров много.
- инфраструктура коммерческой слежки а вот это отдельная и самая интересная тема, я не буду указывать на конкретного национального цифрового чемпиона у которого инфраструктура его трекера находится одноверменно в России и в Евросоюзе. И, внимание вопрос, как код этого трекера понимает на какой из серверов ему необходимо передавать данные и по каким критериям? Ответ на этот вопрос можно отложить на какое-то время, а можно кто-то догадается самостоятельно.

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

#privacy #mobile

С 17 по 21 мая пройдёт неделя открытости государств, OpenGovWeek [1], мероприятие Open Government Partnership [2] посвящённое восстановлению доверия граждан, открытости государств, открытости данных, общественному диалогу и так далее. Несмотря на то что Россия в OGP так и не вступила и, судя по последним событиям, скорее всего не вступит, но темы которые там будут обсуждаться справедливы и для нас.

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

Пока в рамках этой недели анонсировано только несколько мероприятий в Канаде, Эстонии, Эквадоре, Румынии и Колумбии, но скоре всего в ближайшие недели их станет значительно больше.

Там нет обязательности в организации мероприятия только в странах OGP, можно и в других. Стоит ли нам провести вебинар или публичную дискуссию в России? Или, как это сделали в Румынии, мини-хакатон?

Ссылки:
[1] https://www.opengovweek.org/
[2] https://www.opengovpartnership.org/

#opendata #opengov

В день открытых данных в мире в 2021 году прошло 326 мероприятий по всему миру, Open Knowledge Foundation публикуют их списком для поиска и в виде открытых данных в CSV [1]

Вот немного статистики по итогам.

По форме поддержки
- 274 мероприятия (84%) проводились без внешней финансовой поддержки.
- 18 мероприятий (5.5%) получили мини гранты Microsoft
- 11 мероприятий (3%) получили поддержку МИД Великобритании, FCDO, Foreign, Commonwealth & Development Office
- 7 мероприятий (2%) получили поддержку MapBox
- 6 мероприятий (2.5%) получили поддержку GFDRR, Global Facility for Disaster Reduction and Recovery
- 5 мероприятий (1.5%) получили поддержку от ILDA, The Latin American Open Data Initiative
- 4 мероприятия (1%) получили грант OCP (Open Contracting Partnership)

По организаторам
- 25 мероприятий проводились организациями/сообществами движения Code for ..., например, Code for Sapporo и Code for Korea
- 14 мероприятий властями муниципалитетов и городов
- 13 мероприятий проводилось университетами
- 8 мероприятий проводились региональными группами Open Knowledge Foundation такими как OKF Nepal
- 8 мероприяти министерствами, органами власти
- 7 мероприятий проводились группами и сообществами OSM, OpenStreetMap
в остальных организаторах отдельные люди, НКО и коммерческие компании.

По местам проведения
- мероприятия прошли в 262 уникальных местах (большей частью онлайн, но с привязкой к локации)
- 8 параллельных мероприятий проходило в Найроби, Кения
- было много параллельных мероприятий и в других городах, например, по 3 разных мероприятия в Рио-де-Жанейро, Вашингтоне и Нью-йорке, и не меньше пары десятков городов где было по 2 параллельных мероприятия. И это скорее хорошо, показывает уровень развития сообществ.

По числу участников
- среднее число участников 85 человек
- максимальное число участников онлайн 2700, студенты факультета статистики и информатики Университета Веракруз, Мексика
- самое большое число участников оффлайн 1000, на Дне открытых данных в Таиланде, организованном Правительством страны

По способу проведения
- 222 мероприятия онлайн
- 104 мероприятия оффлайн

Ссылки:
[1] https://opendataday.org/events/2021/

#opendata #events

Продолжая тему про государственные информационные системы, мобильные приложения, передачу данных третьим сторонам. Рассмотрим одно мобильное приложение от Минцифры в подробностях.

Лидеры цифрового развития
Опубликовано в Google Play от Минцифры России [1], последний раз обновлялось 3 октября 2019 года.
В "политике кофиденциальности" указана ссылка на сайт самарской компании Eventicious [2] которая действительно, делает такие приложения для частного рынка и для разного рода госкомпаний по 223-ФЗ [3].

Особенность этих приложений в том что данные хранятся в России на серверах компании Ивентишес и тут возникает вопрос. А какой статус у этого приложения. Оно ГИС или не ГИС? Или оно часть услуги ? Если оно часть услуги, то почему приложение опубликовано от Минцифры РФ, если оно заказано как приложение (кстати, не могу найти контракт), то почему данные не хранятся на серверах Министерства или одного из его подведов?

К этим вопросам добавляется ещё один. В приложениях Eventicious есть код со ссылками на два сервиса за пределами РФ [4]. Это chat-prod.eventic.io с адресом в Ирландии и time.eventicious.com с адресом в Голландии.
—
А я напомню про наше исследование приватности в государственных мобильных приложениях [5] и ещё раз подчеркну что проблема чаще не в том что данные передаются за рубеж, а в двуличности государственной политики в этой области.

Ссылки:
[1] https://play.google.com/store/apps/details?id=ru.ddl
[2] https://eventicious.com/privacy/#ru
[3] https://clearspending.ru/supplier/inn=6311151902&kpp=631101001
[4] https://beta.pithus.org/report/23bd9b1823cfa48ef9f3ee5abb48f30ec3f5671f22e3059614690915967003c5
[5] https://privacygosmobapps.infoculture.ru/

#privacy #mobile #apps #digital

Регулярные полезные инструменты и ссылки для тех кто работает с данными регулярно:
- Data Connector [1] позволяет работать напрямую с Google таблицами из языка Python
- Process large datasets without running out of memory [2] - подборка статей о том как обрабатывать большие объёмы данных с помощью языка Python и без утечек в памяти
- MAD (for machine learning, AI and data) index [3] - индекс компаний по использованию машинного обучения, AI и данных, перекликается с большой картинкой/постером AI & Data Landscape 2020 [4]
- MC2 [5] - плафторма по аналитике и обработке зашифрованных данных безопасным образом. Да, такие задачи бывают, да, такое бывает необходимо.

Ссылки:
[1] https://github.com/brentadamson/dataconnector
[2] https://pythonspeed.com/memory/
[3] https://mattturck.com/madindex/
[4] https://46eybw2v1nh52oe80d3bi91u-wpengine.netdna-ssl.com/wp-content/uploads/2020/09/2020-Data-and-AI-Landscape-Matt-Turck-at-FirstMark-v1.pdf
[5] https://github.com/mc2-project/mc2

#data #tools

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

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

Ссылки:
[1] https://www.rosbalt.ru/moscow/2021/04/13/1897113.html

#privacy #mobile

В рубрике интересные наборы данных слепок всех отчетов кредитных организаций в России о их бенефициарах собранный с сайта Банка России [1]. Формально эти документы называются "Список лиц, под контролем либо значительным влиянием которых находится кредитная организация", их публикует ЦБ РФ на страницах кредитных организаций. Например, на странице Сбербанка на сайте ЦБ [2], но там опубликован только последний файл со схемой, а в этом архиве все изменения за всё время с начала подобной отчетности. Например, код Сбербанка в ЦБ 1481 и в архиве есть документы о структуре бенефициаров с 2015 года.

Вот такой список файлов:
- RB1481_20150814.pdf
- RB1481_20180416.pdf
- RB1481_20190826.pdf
- RB1481_20200413.pdf
- RB1481_20200508.pdf
- RB1481_20200907.pdf
и так по всем кредитным организациям.

Формат наименования документов: RB[кодбанка]_[YYYddmm].pdf , пример RB3535_20200904.pdf

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

Получить список кодов банков можно на сайте ЦБ РФ по ссылке [3].

Не стесняйтесь обратной связи и идей как можно превращать эти PDF документы в машиночитаемые наборы данных.

А мы тем временем начинаем восстанавливать и ре-активировать Хаб открытых данных [4], это один из самых первых порталов открытых данных в России который я когда создавал под брендом OpenGovData (ещё в 2010-2011 годах). В последние годы мы больше усилий положили на общественный портал данных для НКО NGOData [5], но есть много данных которые в тематику НКО не укладываются и они будут появляться на хабе.

Ссылки:
[1] https://hubofdata.ru/dataset/bankbenef
[2] http://www.cbr.ru/banking_sector/credit/coinfo/?id=350000004
[3] http://www.cbr.ru/banking_sector/credit/FullCoList/
[4] http://hubofdata.ru
[5] http://ngodata.ru

#data #opendata #cbr #banking #ownership

Open Ownership, проект по разработке стандарта и публикации данных о бенефициарах юридических лиц, опубликовали доклад о применении данных о бенефициарах при процедурах госзаказа Beneficial ownership data in procurement [1]. Об этом же исследовании и его контексте в их блоге [2] и в блоге Data in Government [3] на государственном портале Великобритании gov.uk

Не случайно что эту инициативу упоминают и работают над ней именно в Великобритании. В декабре 2020 года был опубликован документ Transforming public procurement (Green paper) [4] для обсуждения с экспертами и профессионалами. В нём, на 82 страницах текста были изложены вопросы реформы государственного заказа, по итогам года с COVID-19, ситуаций описываемых в документе как "экстремальный кризис" и с необходимостью адаптации процедур государственных расходов под современные технологии и реалии. И вот в этом документе и явным образом есть упоминание на необходимость введения обязательного требования по раскрытию конечных бенефициаров компаний, вплоть до того чтобы это было отсекающим критерием для любой конкурентной процедуры. Не раскрыл сведения о бенефициарах - не можешь получать деньги от государства.

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

При этом, судя по развитию реформ государственного заказа по развитым странам, я бы оценивал высокой вероятность перехода стандартов Open Ownership и Open Contracting [5] в международный статус и постепенное внедрение их в рекомендации ОЭСР, Всемирного банка и иных межгосударственных организаций. Они и так уже есть в рекомендациях OGP и далее вопрос лишь времени в дальнейшем развитии.

Ссылки:
[1] https://www.openownership.org/uploads/OO%20BO%20Data%20in%20Procurement.pdf
[2] https://www.openownership.org/blogs/beneficial-ownership-data-in-procurement-beyond-transparency-and-accountability/
[3] https://dataingovernment.blog.gov.uk/2021/04/08/who-really-benefits-from-uk-business-ownership/
[4] https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/943946/Transforming_public_procurement.pdf
[5] https://www.open-contracting.org/

#opendata #opengov #procurement

Ещё один "мелкий нюанс" с новым реестром отечественного ПО [1] - это "гниение ссылок". Ссылки из старого реестра не открываются в новом заменой домена, а также при формировании ссылок в них указывается не номер программы в реестре, а на технический идентифкатор в базе данных. Вот пример: [2], код программы в реестре ПО 10269, а идентификатор в ссылке 330494 (reestr.digital.gov.ru/reestr/330494/). Такое вообще не редкость и бывает когда разработчики изначально не думают о пользователях. Я знаю десятки сайтов органов власти где подобное происходило неоднократно при замене CMS системы или создании нового сайта госоргана/госучреждения.

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

Но есть и примеры постоянных ссылок с момента появления организации. W3C имеет W3C URI Persistence Policy [4] с 1999 года и все опубликованные документы W3C всегда доступны по тем ссылкам что они были размещены.

Впрочем, надо отдать должное коллегам из Минцифры, экспорт в XML из реестра, наконец-то, заработал, что, отчасти снимает проблему устаревания ссылок поскольку в экспортированных данных есть уникальные идентификаторы ПО. Но, счастье было бы полным, если бы экспорт в XML содержал _все_ данные по карточкам ПО, например, сейчас не экспортируются код ОГРН владельца ПО.

Кроме того, я напомню, в данных есть ошибки с реквизитами организаций. Сильно меньше чем в других госреестрах, но доли процента записей (около 10 невалидных кодов ИНН).

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

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

В остальном же лучше публиковать данные дампами на дату и создавать раздел "Открытые данные" и у этого есть 2 причины:
1. Так просто напросто удобнее в работе с данными которые меняются со временем. Пример похожей модели - это данные ФИАС где регулярные дампы в XML и DBF и всегда можно их сравнить
2. Некоторые криворукие разработчики делают экспорт данных динамическим. Когда таким образом экспортируется от 10 до 100 записей проблем не возникает. Когда идёт экспорт всего реестра - это гарантированный способ положить всю систему DDoS атакой. Кешировать данные для экспорта - это, также, подставка для кривых рук. Регулярные (ежесуточные/еженедельные) дампы и API - это правильное решение.

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

Ссылки:
[1] http://reestr.digital.gov.ru
[2] https://reestr.digital.gov.ru/reestr/330494/
[3] https://github.com/alphagov/open-standards/issues/75
[4] https://www.w3.org/Consortium/Persistence

#opendata #digital #registries

В рубрике интересных наборов данных, база монетарных мер центральных банков в исследовательской статье A global database on central banks' monetary responses to Covid-19 [1] и в виде Excel файла [2]. Материалы опубликованы на сайте банка международных расчётов (BIS) и является результатом мониторинга реакции центральных банков в виде 900 зарегистрированных событий от 39 банков.

Банка России нет в этом списке, но много других есть и сама база полезна для исследователям COVID-19 и реакции на него.

Ссылки:
[1] https://www.bis.org/publ/work934.htm
[2] https://www.bis.org/publ/work934_data.xlsx

#opendata #datasets

Я не люблю комментировать политику и политические решения, но, конечно, по поводу последних санкций США против нескольких не самых больших и известных российских ИТ компаний могут показаться довольно странными. Не крупнейшие компании, не так много взаимодействующие с контрагентами за рубежом, ну и ещё немало вопросов. Вот и в MIT Technology Review пишут об этом [1], несколько раз упоминая Kaspersky (Лаборатория Касперского) и упоминая их предыдущий инцидент в США и работу с правительствами многих стран. Намёк более чем прозрачен и похоже что эти санкции в США специально проведены по модели "давайте вломим по не самым важным и крупным, чтобы остальные заполошились и побежали договариваться". Так часто делают, во многих делах, меры против не самых крупных лоббистов принимаются не по причине их веса, а чтобы "открыть кассовую комнату" куда побегут лоббисты и нанятые GR специалисты.

Хуже то что власти в США реально могут похоронить ИТ бизнес/ИТ рынок в России не только через санкции на компании, но и через запрет участие российским компаниям в технологических экосистемах в их юрисдикции. Это всё достаточно серьёзно и, честно говоря, я не понимаю что с этим можно будет сделать потому что госполитика в части поддержки российского бизнес/цифровых платформ была, если честно, хреноватая.

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

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

Ссылки:
[1] https://www.technologyreview.com/2021/04/15/1022895/us-sanctions-russia-positive-hacking/

#digital

Обновилась документация, появился новый портал с документацией [1], по проекту Frictionless Data. Теперь там довольно удобно собраны примеры, описания и руководства по работе с этим фреймворком. Лично я уделяю ему столько внимания потому что на сегодняшний день - это одна из наиболее продуманных инициатив с открытым кодом по стандартизации наборов данных.

Альтернативы ему, или коммерческие, с централизованными реестрами/репозиториями такими как QRI, или узкоспециализированные под академическую работу - RO-CRATE или под архивацию цифровых объектов такие как BagIt.

Но, конечно, есть и множество альтернатив: DataCrate [2], BioCompute [3], стандарты RDA [4], стандарты Force11 [5], CodeMeta [6] и многочисленные стандарты публикации данных и метаданных используемые на национальном уровне и в рамках отдельных отраслей (биоинформатика, лингвистика и тд).

Впрочем большая часть стандартов, всё же, про научную сферу, а Frictionless Data про общепринятую. Ещё год-два и публиковать данные в виде "голого" CSV или XML файла будет неприличным. Упакованные данные куда ценнее и пригоднее к работе.

Ссылки:
[1] https://framework.frictionlessdata.io
[2] https://github.com/UTS-eResearch/datacrate
[3] https://github.com/biocompute-objects/BCO_Specification
[4] https://rd-alliance.org/
[5] https://www.force11.org/
[6] https://codemeta.github.io/

#opendata #data #standards

The Verge пишет о запрете в Евросоюзе на применение ИИ для массовой слежки и систем социальных кредитов [1]. Причём, ожидаемо, новое регулирование будет экстерриториальным, с оборотными штрафами и прочими подходами уже опробованными в GDPR. Подробнее об этом в материалах Politico [2], которые и раздобыли черновик регулирования.

Это регулирование сильно отличается от того что происходит в этой теме в США или в Китае, много аргументов про инновации и не только.

Если говорить про экономику, да, такие ограничения сдержат часть инноваций. Но если говорить про смысл, то не все инновации одинаково полезны. Можно приравнять ИИ в массовой слежке к опытом на людях. Да, запрет опытов над людьми тоже сдерживает инновации, но может оно и неплохо?

Ссылки:
[1] https://www.theverge.com/2021/4/14/22383301/eu-ai-regulation-draft-leak-surveillance-social-credit
[2] https://www.politico.eu/article/europe-strict-rules-artificial-intelligence/

#ai #data #regulation #eu

В 2020 году в России было зарегистрировано 605.5 тысяч ИП и ликвидировано 947.5 тысяч ИП, зарегистрировано 232.1 тысячи юридических лиц и ликвидировано 545.6 тысяч юридических лиц. Это наибольшее число ликвидаций ИП с 2012 года, наименьшее число регистраций ИП с 2014 года и наименьшее число регистраций юридических лиц с 2012 года.

Причин может быть множество:
- снижение деловой активности на время COVID-19
- ухудшение экономической ситуации
- ограниченный режим регистрации ИП и юридических лиц и ограничения в сроках приёма в налоговых органов
А может быть и что-то ещё.

В рубрике "полезные наборы данных", актуализированный набор данных временных рядов налоговой статистики [1] регистрации юр. лиц и индивидуальных предпринимателей.
Набор данных включает:
- данные статистики по субъектам федерации в виде временных рядов
- данные статистики по субъектам федерации по годам и индикаторам
- данные статистики по Российской Федерации (агрегировано)
- первичные данные с сайта ФНС России в формате Excel файлов
- исходный код для обработки Excel файлов и генерации файлов статистики

С помощью примера исходного кода можно извлечь и другую статистику, например, по видам юр. лиц, детальные цифры по которым тоже есть в статистических формах ФНС России.

Объём данных небольшой, но полезный в рамках исследований по COVID-19 и деловой активности в принципе.

Ссылки:
[1] https://hubofdata.ru/dataset/nalogstats-timeseries

#opendata #datasets #statistics

В рубрике интересные наборы данных (за рубежом). Национальное управление архивов и документации США опубликовало два больших набора данных на инфраструктуре Amazon AWS. Это национальный архивный каталог [1] и данные переписи 1940 года [2].

Национальный архивный каталог - это база из 225 гигабайт с описанием 127 миллионов цифровых объектов
Перепись 1940 года - это 15 терабайт включающих метаданные к 3.7 миллионам сканированных документов и сами документы с описанием переписных листов, карт переписи и так далее.
Обо всём этом подробнее в блоге NARA [3]

Надо отдать должное Amazon, в их реестре открытых данных [4] всего 233 набора, довольно скудные метаданные по ним, но все эти наборы и базы данных огромного размера и востребованные аудиторией для которых они публикуются.

Ссылки:
[1] https://registry.opendata.aws/nara-national-archives-catalog/
[2] https://registry.opendata.aws/nara-1940-census/
[3] https://aotus.blogs.archives.gov/2021/04/15/nara-datasets-on-the-aws-registry-of-open-data/
[4] https://registry.opendata.aws/

#opendata #datasets #archives #usa #amazon #aws

Я уже написал несколько лонгридов в рассылку [1] о том как собирать, анализировать и описывать данные. Но, всё время чувствую что недостаточно раскрываю эту тему.
Управление метаданными не такая сложная штука в концептуальном смысле, но тяжело ложится в логику российского планирования. Потому что метаданные к данным, документация, хорошо описанный код, пометки к исследованиям, просто заметки к своей работе - это всё культура помнить о себе и других не только в моменте, а в будущем, через много лет. Обычно к этому приходят, или с годами, особенно когда сталкиваются с невозможностью разобрасться с чужими или собственными документами/кодом/данными и тд. многолетней давности, или через культуры среды, например, воспроизводимость исследований - это часть культуры и принципов работы исследователей. Кто-то трактует это узко - возможность воспроизвести в коротком промежутке времени, а кто-то как возможность воспроизвести исследование и через 20 лет.

Управление метаданными - это именно вопрос стратегического понимания зачем данные или иные цифровые объекты создаются.

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

Научные архивы отличаются тем что, с одной стороны, они "ближе к земле", а с другой требуют всё того стратегического подхода. Поэтому есть десятки стандартов метаданных по отраслям: лингвистика, биоинформатика, генетика, метеорология и тд.
Но научные архивы напрямую связаны с таким понятием как "воспроизводимость исследований", а в современном мире технологических исследований - это "воспроизводимое вычислительное исследование" (reproducible computational research, RCA). А особенность таких исследований что не только данные нужны, но и методика и все инструменты. А эти инструменты могут быть как жёстко проприетарными (и как тогда воспроизводить?) так и самописными и во всех случаях для них необходимо воссоздание необходимой среды. Вот очень полезная статья о роли метаданных для RCA, оттуда новый термин "капитал метаданных" (metadata capital) - это вложения организации в создание высоко-качественных метаданных для своих данных.

Отдельно можно поговорить про данные в корпоративных каталогах, а вернее системах управления данными (data management systems) и в каталогах данных для ИИ или иных каталогов данных особенно большого размера. Корпоративный мир предельно практичен. К наборам данных добавляются лишь критически значимые метаданные, те же каталоги Kaggle, Amazon Open Data или открытые данные Azure - радикально минималистичные. А вот внутрикорпоративные каталоги для data science наоборот, часто весьма детальные, но с чётким акцентом на data discovery (находимость данных) в достаточно ограниченном промежутке времени.

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

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

Ссылки:
[1] https://begtin.substack.com
[2] https://arxiv.org/ftp/arxiv/papers/2006/2006.08589.pdf

#metadata

Главная проблема большей части утечек личных данных именно в сопоставлении. Даже сопоставление десятка баз по email адресам может дать очень много инсайтов. Неприятных инсайтов(

Что и требовалось доказать. Уже стали появляться обогащенные базы сторонников Навального :-( "Да там просто e-mail и ничего больше", - говорили они. Ага, щазззз. Сейчас еще смапят в утекшую базу LovePlanet и вперед :-) pic.twitter.com/B5zazapYT7
— Alexey Lukatsky (@alukatsky) April 19, 2021