Ivan Begtin
7.99K subscribers
1.78K photos
3 videos
101 files
4.49K links
I write about Open Data, Data Engineering, Government, Privacy, Digital Preservation and other gov related and tech stuff.

Founder of Dateno https://dateno.io

Telegram @ibegtin
Facebook - https://facebook.com/ibegtin
Secure contacts [email protected]
Download Telegram
The Economics of Data Businesses [1] полезный текст от Abraham Thomas о том как устроен внутри бизнес основанный на данных продуктами которого являются дата-продукты. Если ещё проще, то это ответ на вопрос "чем живут те кто торгуют данными?". Текст включает много инсайтов и полезных мыслей для тех, так что могу его порекомендовать всем кто изучает этот рынок.

Автор известен как основатель Quandl, стартапа по агрегации альтернативных данных купленного Nasdaq. Так что его мнение о продуктах на данных более чем обосновано.

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

Ссылки:
[1] https://pivotal.substack.com/p/economics-of-data-biz

#databusiness #reading
Не могу не поделиться прекрасным опросом из циничного телешрам канала.
Рубрика "Циничный метаопрос"
Пришло время поговорить о метавселенных. Что вы думаете по поводу этой новой модной шизофрении? В контексте цифровой трансформации и вот этого вот всего, конечно.
Допускаются метаварианты ответов
Anonymous Poll
9%
Сквозь бури и штормы цифровых трансформаций - к светлой метавселенной будущего! Таков истинный путь!
7%
Мы все - аватары в метавселенной внеземного разума! Просто, как все аватары мы не осознаем этого
32%
Нам срочно нужно Министерство строительства метавселенных - Минметаверсстрой. И Росметаверснадзор
26%
Без создания ГИС "Реестр метавселенных" даже говорить не о чем. И без метадатасетов для мета-ИИ
28%
В каждом министерстве нужно назначить зама по метавселенным. И сформировать метавселенский спецназ
15%
А Центр метакомпетенций по метавселенным в Метааналитическом центре будем создавать?
15%
А кто метаметодологию создания метавселенных писать будет? Метаэксперты из МетаНИИ "МетаРасход"?
19%
Нужно подождать, пока Сбер построит свою метавселенную, а потом просто купить ее за бюджетные деньги
11%
Затея без шансов. Минфин денег не даст. Скажет - "На игрушки бюджета нету!"
31%
Этот опрос - просто какой-то метацинизм!
Для тех кто хочет самостоятельно изучить содержание федерального портала открытых данных data.gov.ru, его слепок выложен в промежуточное хранилище Национального цифрового архива (ruarxive.org).

Размер слепка 15GB, внутри метаданные полученные экспортом в CSV формате и для каждого пакета данных отдельная директория внутри которых файл files.jsonl с метаданными каждого выгруженного файла этого набора данных название файла, расширение, формат и размер. А в папке files внутри пакета сами сохранённые файлы этого набора данных.

Ограничения:
- в метаданных нередко форматы указаны неверно и в итоге файл может иметь расширение XML, а внутри это ZIP. Не удивляйтесь, просто будьте к этому готовы, это особенность первоисточника
- часть источников данных уже недоступны и не все файлы скачались. Пока не проверяли сколько да, сколько нет, но скорее не так много.
- часть источников данных сменили сайты и ссылки и вместо файлов с данными там HTML страницы. Это надо проверять по каждому файлу, пока такой проверки не проводили. Это скорее редкость, но вот у ФТС (таможни) все наборы данных в таком состоянии.

Файл пока в промежуточном хранилище с ограниченным трафиком, поэтому если хотите с этими данными поработать прямо сейчас, напишите, мне лично @ibegtin или в чат @begtinchat я дам прямую ссылку. Окончательный дамп с описанием и ссылкой на облачное хранилище будет на нашем общественном портале открытых данных hubofdata.ru, он сейчас используется для ведения метаданных и ссылок цифрового архива сайтов.

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

#opendata #datasets
Кстати, не могу не похвастаться, что более всего из всех площадок где я что-либо писал, получалось на Quora, англоязычной площадке вопросов и ответов. Я там был особенно активен в 2016-2017 годах [1] и до сих пор мои ответы смотрят по 2000 просмотров в неделю, в общем-то там и потребление контента не новостное с резким всплеском, а постоянное.

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

А Quora неплохой источник не только ответов, но и ссылок на разного рода продукты/проекты в области открытости и данных.

Ссылки:
[1] https://www.quora.com/profile/Begtin-Ivan

#quora #reading #data
Знаете ли Вы что в каталоге нормативных документов Минюста РФ [1] сложно/затруднено искать документы Минцифры РФ? В перечне принявших органов в разделе "Нормативные правовые акты федеральных органов исполнительной власти" Минцифры нет в списке (может и ещё чего нет, всё не проверял). По органу власти невозможно найти документы.

Хотя по ключевым словам "цифровой" или "цифрового" в названии документа некоторые документы находятся, около 60. В общем выгрузить или получить все документы Минцифры из системы Минюста нельзя. Интересно почему?

Приходится смотреть в других местах и сетовать что в России нет единой нормальной системы НПА.

Ссылки:
[1] https://pravo-search.minjust.ru:8080/bigs/portal.html

#legalit #government #data #laws
Продолжая вчерашний пост про засекречивание распоряжений Правительства, публикую диаграмму выпуска приказов Минцифры. Если в Правительстве число "закрытых" (непубличных, ДСП...) распоряжений было на уровне 8-9% с тенденцией к росту, то в Минцифре открытых приказов всего... 6%. Остальные 94% - ДСПшные и иные ограниченного распространения документы. А вы говорите открытость...

PS. Спасибо Ивану Бегтину за предоставленные цифры
В 2020 году Норвежский потребительский совет выпустил исследование о том как дейтинговые приложения собирают персональные данные и торгуют ими [1]. Несмотря на то что представители компаний всегда утверждали что это обезличенные данные, это оказалось не совсем так, и некоторые из них получили штрафы. Так штраф в $11,7M был наложен на компанию создавшую приложение Grindr для знакомства людей нетрадиционной ориентации.

А полгода назад случилась весьма показательная история с высокопоставленным католическим священником, монсеньёром Jeffrey Burrill, в США. Католическое издание The Pillar провело расследование включавшее покупку данных у одного из брокеров данных (его имя они не называют), но называют изначальный источник данных и это как раз приложение Grindr. Издание сопоставило анонимизированные данные пользователей и идентифицировало именно Jeffrey Burill как посетителя многочисленных гей-баров. В исследовании особенно подчеркивается легальность получения этих данных в США. Обо всём этом написали Washington Post [2], уже после того как священник подал в отставку, а The Pillar многие обвинили в скандальных методах проникновения в частную жизнь о чём они даже написали пространный текст объяснения баланса личной жизни, общественного интереса и их позицию [3].

Процесс определения человека по анонимизированным данным называется повторной идентификацией (data re-identification). Об этом явлении хорошая статья в Википедии [4]. В некоторых странах, например, в Австралии даже пытались законодательно ввести уголовное преследование за повторную идентификацию [5], но законопроект тогда не прошёл.

На сайте The Markup в статье 2020 г. When Is Anonymous Not Really Anonymous? [6] та же проблема описывается с большим числом примеров. Например, одно из исследований показало что 87% жителей США можно идентифицировать по полу, дате рождения и почтовому индексу.

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

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

Ссылки:
[1] https://fil.forbrukerradet.no/wp-content/uploads/2020/01/mnemonic-security-test-report-v1.0.pdf
[2] https://www.washingtonpost.com/technology/2021/07/22/data-phones-leaks-church/
[3] https://twitter.com/jdflynn/status/1417872232420974592/photo/1
[4] https://en.wikipedia.org/wiki/Data_re-identification#Examples_of_de-anonymization
[5] https://www.aph.gov.au/Parliamentary_Business/Bills_Legislation/bd/bd1617a/17bd055
[6] https://themarkup.org/ask-the-markup/2020/03/24/when-is-anonymous-not-really-anonymous

#privacy #anonymity #mobileapps #stories
В рубрике интересных наборов данных The World Loanword Database (WOLD) [1] в виде базы заимствованных слов. Создатели из Института эволюционной антропологии им. Макса Планка собрали базу слов которые одни языки заимствуют из других на основе 41 источника публикаций исследователей лингвистов. В основном в базе слова заимствованные небольшими и вымирающими языками из языков более распространённых, но для специалистов в лингвистике и это может быть интересно. Общий объёмы базы невелик, около 3.5 мегабайт в ZIP архиве и 15 МБ в распакованном виде.

У Института им. Макса Планка есть плеяда проектов по компьютерной лингвистике с открытыми данными [3] включая такие проекты как: The World Atlas of Language Structures, Glottolog, Tsammalex, Dictionaria и многие другие. Во всех случаях данные публикуются, либо на сайте проекта, либо на портале Zenodo.

Ссылки:
[1] https://wold.clld.org/
[2] https://wold.clld.org/download
[3] https://clld.org/

#opendata #data #openaccess #liguistic
Профессор Albert Sanchez-Graells в заметке Let’s get real about AI’s potential to end corruption in procurement [1] пишет о применении ИИ для выявления коррупции при госзакупках, ссылается на его же статью Procurement Corruption and Artificial Intelligence: Between the Potential of Enabling Data Architectures and the Constraints of Due Process Requirements [2] и обозначает ограничения у алгоритмов ИИ, в первую очередь ограничениях в данных, их качестве, доступности ретроспективных данных и их оцифровке и юридических сложностях.

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

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

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

Но есть важные особенности. Алгоритмические системы определения нарушений хорошо работают при грамотно спроектированной и работающей системе закупок, а российская система по 44-ФЗ и частично по 223-ФЗ не про качество работы, а про модель гарантированного наличия нарушений у госзаказчиков. Когда сама система выстроена так что, вне зависимости, честные ли госзаказчик и поставщик или коррумпированные, и так и так совершают одни и те же нарушения, то система анализа от формальных нарушений начинает давать сбои.

Об этом я могу говорить и писать ещё долго, в последние годы тема госфинансов меня интересует скорее с точки зрения сбора данных. И в качестве небольшой рекламы я добавлю что мы поддерживаем общественный проект Госрасходы (clearspending.ru) с данным госконтрактов, наша команда создавала и продолжает поддерживать проект Счетной палаты Госрасходы (spending.gov.ru), вернее я покинул СП, а команда продолжает его развивать.

А также у нас есть коммерческий проект APICrafter.ru где можно подключиться к данным системы госзакупок России через API и с коммерческой поддержкой. Это уже не только данные о госконтрактах, но также данные по поставщикам, заказчикам, планам закупок, закупкам, отчетам и всем остальным сведениям.

А в каталоге DataCrafter (data.apicrafter.ru) в том числе есть архивные данные контрактов, сведения из региональных систем закупок и сопутствующие данные.

Ссылки:
[1] https://www.open-contracting.org/2022/01/20/lets-get-real-about-ais-potential-to-end-corruption-in-procurement/
[2] https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3952665

#opendata #procurement #ai
Как государства предоставляют данные и сервисы бизнесу? Через систематизированные каталоги API. Эти каталоги иногда интегрированы в порталы открытых данных, но чаще создаются отдельно потому что доступ через API почти всегда требует авторизации и удобного интерфейса тестирования и документации.

Такие каталоги API есть во многих странах, кроме Франции и портала api.gouv.fr который я ранее упоминал, они также есть:
- В Индии API Setu apisetu.gov.in [1] - 1343 точки подключения всех уровней власти
- В Бразилии Catálogo de APIs Governamentais www.gov.br/conecta/catalogo [2] - более 40 точек подключения
- В США API Data api.data.gov [3] - сотни API по единому ключу
- В Великобритании api.gov.uk [4] более 70 API на едином портале
- В Австралии api.gov.au [5] доступно 16 API

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

Ссылки:
[1] https://apisetu.gov.in/
[2] https://www.gov.br/conecta/catalogo/
[3] https://api.data.gov/
[4] https://www.api.gov.uk
[5] https://api.gov.au

#opendata #openapi #api #government
В России обсуждали кейс директора XSolla уволившего кучу людей по итогам автоматизированного анализа, а в США и Европе во всю обсуждают риски появления ИИ боссов (AI Bosses) на примере Amazon'а и других компаний. Когда за твоим рабочим процессом следит ИИ и "всё докладывает кому надо". В Tribune статья именно об этом [1] и в России такие кейсы тоже есть.

Как говорится все ждали большого брата от гос-ва, а на деле первыми внедряют их работодатели. Чем более оцифруема твоя работа, тем более вероятно что у тебя будет AI Boss.

Ссылки:
[1] https://tribunemag.co.uk/2022/01/amazon-algorithm-human-resource-management-tech-worker-surveillance

#ai #aiethics
Стартап Canvas [1] делает возможность превращать работу с данными из технической в визуальную задачу, сделав удобный интерфейс по визуализации и работы с данными в СУБД через веб интерфейс.

Сейчас поддерживают Redshift и Snowflake как облачные СУБД и Postgres.

Работа с таблицами очень напоминает Google Spreadsheets или Airtable, но, при этом, визуально сформированные таблицы можно увидеть и в виде SQL запросов.

Сами данные они не хранят, только дают интерфейс над ними.

Берут по $100 в месяц за редактора данных в месяц.

Подняли инвестиций в $4.2M и думаю что у них хорошая перспектива быть купленными одним из крупных облачных провайдеров, потому что выглядит как очень хорошее дополнение к облачным СУБД.

Ссылки:
[1] https://canvasapp.com

#startups #dataviz #spreadsheets
Metadata Guardian [1] [2] свежая утилита для Python, делающая практически то же что и наш движок по идентификации полей и даже теми же самыми способами, только с акцентом на PII (Personally Identifiable Information). Поставляется в виде утилиты командной строки, поддерживает Snowflake, AWS, GCP, MySQL и файлы Avro, Arrow, ORC и Parquet.

Все правила оформлены прям как и у меня в виде YAML файлов [3] с регулярными выражениями. Правила также разделяются на те которые применяются к названиям колонок и те которые применяются

В общем это хорошая утилита, разница между ней и тем что делаю я тоже есть:
1. Правил нашем классификаторе кратно больше. В metadata guardian их около 20, в нашем боте их уже более 150.
2. В нашем классификаторе правила и идентификаторы разделены. Много разных правил могут указывать на один и тот же идентификатор. Например, отдельное правило для почтовых индексов и их написания на английском языке и общее для всех, такое как "postindex" или "postcode" и отдельно для написания на русском "почтовый_индекс" или "pochtoviy_indeks". Это позволяет разделять правила по контексту языка.
3. Это особенность нашего движка, контекстное и языковое разделение правил. Можно задать фильтр и подгрузить любые правила, а не только преднастроенные.
4. В Metadata Guardian используют регулярные выражения, у нас вместо них три типа правил: прямое сравнение, внешние функции и конечные автоматы на PyParsing через которые также можно запускать регулярные выражения.
5. У нас в движке предусмотрена доп. валидация данных после определения. Для этого можно указать внешнюю функцию.
6. Пока наш движок работает с базовым объектом как словарь для Python (python dict), а в качестве входного потока принимает СУБД MongoDB, JSON lines и CSV. А Metadata Guardian нацелен на базы и форматы для облачного применения и для data science.

Причины отличий в том что MG создан для идентификации PII, а наш Data Classifier для задач более общих и, более того, как основа для оценки качества данных и их обогащений. Напомню что наш движок можно потестить вот тут @DataClassifierBot как телеграм бот и скоро будет API.

Тем не менее на Metadata Guardian стоит посмотреть и попробовать, потому что направление движения правильное. К тому же он хоть и меньше может, но более production ready и стыкуется с СУБД.

Ссылки:
[1] https://medium.com/@florian.valeye/metadata-guardian-protect-your-data-by-searching-its-metadata-fe479c24f1b1
[2] https://github.com/fvaleye/metadata-guardian
[3] https://github.com/fvaleye/metadata-guardian/blob/main/python/metadata_guardian/rules/pii_rules.yaml

#metadata #data #datatools #privacy #opensource
Для тех кто ищет больших данных и побольше, Academic Torrents [1] раздает 83ТБ открытых данных, в основном для научного применения - в data science и не только. Например, там есть свежий слепок Wikidata в 109ГБ и множество климатических датасетов, датасетов по распознаванию изображений и многого другого.

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

Ссылки:
[1] https://academictorrents.com

#opendata #datascience #openacces
О данных, веб-сайтах и том как с ними работают. Я рассказывал что веду архивацию госсайтов, в том числе самописными инструментами, которые архивируют данные из открытых API которые веб-краулеры не поддерживают. Такая утилита есть APIBackuper для сфокусированной архивации и ещё для 5 популярных CMS у которых такое общедоступное API есть по умолчанию. Некоторые владельцы сайтов это API по умолчанию сразу отключают, но у большинства оно доступно и через него можно скачивать весь тот же контент что есть на сайте, только быстрее, удобнее и автоматически.

Но бывают и вопиющие случаи. Не буду называть конкретный орган власти/госорганизацию, но у них на веб-сайт предусмотрена подписка на рассылки СМИ. Подписка реализована встроенными средствами CMS и, барабанная дробь, открытые интерфейсы этой CMS отдают данные о всех подписчиках. К счастью, их там не так много, чуть более 200 человек и данные там хоть и персональные, но не самые чувствительные, только email+ФИО+факт подписки, но картина показательная о том как организована работа с данными в госорганах.

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

Таких случаев много, много случаев публикации чувствительных данных, просто доступа к данным и тд. Госзаказчики чаще всего просто не знают на каких инструментах создана их инфраструктура и поэтому так много недокументированных API у госсайтов и государственных информационных систем. Это вопрос не только культуры работы с данными, но и обычной технологической культуры и полнейшее отсутствие централизованного аудита и мониторинга государственного технологического сектора.

#tech #government #governmentit #privacy #leaks
Нужно ли создание в России api.gov.ru ?
anonymous poll

Конечно! Пусть Минцифра его создаст, наконец – 85
👍👍👍👍👍👍👍 73%

Нужно, но на госорганы надежды нет, скорее как частный проект – 17
👍 15%

Мне лень отвечать, я просто хочу посмотреть ответы других – 5
▫️ 4%

Не нужно, пусть госорганы сами задокументируют API к своим системами и на этих системах разместят документацию – 4
▫️ 3%

Никому не нужно, некому пользоваться – 3
▫️ 3%

Что? Где? Что такое API? Ничего не понимаю – 3
▫️ 3%

👥 117 people voted so far.
Кстати по итогам моего прошлого опроса/голосования о том о чём я пишу, большинство проголосовавших, как оказалось, заинтересовано в материалах про приватности. Постараюсь добавлять об этом больше публикаций. Хотя мои лично самые любимые темы - это технологии работы с данными и доступность/открытых данных. А вот, как ни странно, международные практики мало кому интересны. Может быть, правда, это искажение инструмента голосования где нельзя проголосовать за несколько вариантов.

#votes #polls
Про формат Parquet я многократно писал и давал ссылки, а вот сравнение от Databricks его же с CSV [1]. Если кратко то CSV проигрывает Parquet по всем статьям, сравнение проводилось в экосистеме Amazon AWS:
- экономия при хранении данных на 87%
- в 34 раза быстрее отрабатываются запросы
- на 99% меньше данных надо сканировать
- финансовая экономия до 99.7%

Недостаток Parquet'а для человекочитаемости компенсируется появлением инструментов для GUI и командной строки которые эту проблему снимают. Она, вообще не так значима как кажется.

Лично я считаю что статистику, многие другие данные с временными рядами и иные большие наборы данных которые сразу берут в работу аналитики, можно и нужно публиковать сразу в Parquet. Это даёт не только экономию в хранении, но и сильно облегчает работу аналитиков. Тем более что многие инструменты вроде Power BI и Tableau их его поддерживают.

Ссылки:
[1] https://databricks.com/glossary/what-is-parquet

#fileformats #data #parquet