Продолжая вчерашний пост про засекречивание распоряжений Правительства, публикую диаграмму выпуска приказов Минцифры. Если в Правительстве число "закрытых" (непубличных, ДСП...) распоряжений было на уровне 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

У Бэна Стэнсила, основателя и руководителя аналитиками в стартапе Mode, замечательная заметка в его рассылке, с рефлексией о том как компании сейчас потребляют данные и как это возможно в будущем [1]. Основной посыл заметки в том что "фронтэнд разваливается" и приводит в пример десятки разных способов донесения данных через дашборды, тетрадки, сервисы визуализации, разные виды, формы и ориентации BI продукты и так далее. Идея в том что можно ли сделать открытый продукт к которому разные формы потребления данных можно было бы добавлять плагинами? По аналогии с Wordpress'ом и другими аналогичными экосистемными продуктами.

Идея интересная, созвучная многим, включая меня. Хотя я пока и не чувствую что разваливается именно фронтэнд и конечное потребление данных, скорее современный стек данных превращается в набор для сборки, а для кого-то и в паззл где своими силами ты делаешь только то что не можешь собрать из кубиков. Или делаешь то что хочешь продать/продавать. Отсюда и растущий запрос не просто на дата-инженеров, а на платформенных дата-инженеров, а может уже пора ввести понятие data-constructor ?

Когда я сейчас проектирую стартап и продукт по анализу и/или/или не обработки данных, я, как и многие, не мыслю категориями разработать его с нуля. Я смотрю на open source и облачные продукты и понимаю что: вот тут для ELT можно взять вот это, вот тут для BI вот это, вот тут для хранилища вот это, вот тут для сбора данных в реальном времени вот это, для пользовательского интерфейса вот это и так далее.

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

Ссылки:
[1] https://benn.substack.com/p/business-in-the-back-party-in-the-front

#data #thoughts #reading #dataengineering #bi

Я много раз писал про такое явление как executable papers [1] [2] [3] о том как меняется создание научных статей в сторону написания тетрадок с кодом интегрированных или сопровождающих научный текст.

К этому хочу дополнить ещё один похожий и важный проект Executable books (исполняемые книги). Создание интерактивных книг/справочников/руководств по общему стандарту и с сохранением структуры именно книги. Довольно большое сообщество в Github - Executable book [4] вот уже несколько лет как создаёт Jupyter Book [5], специальный движок позволяющий писать руководства используя тетрадки Jupyter Notebook и предоставляя возможность создавать контент пригодный к публикации и с экспортом в HTML, PDF и другие форматы.

У авторов собрана большая галерея примеров [6], больше всего примеров с описанием open source пакетов по работе с данными. Авторы же даже создали своё расширение для языка Markdown под названием MyST - Markedly Structured Text для более удобного написания технической документации [7].

Executable books и их продукты происходят из научной среды, с командой из 3-х университетов и большим сообществом и поддержкой Alfred P.Sloan Foundation.

На мой взгляд у них есть явно недооценённый коммерческий потенциал. Удобных онлайн сервисов по написанию технической документации и руководств не так много. Есть Readme.io, Gitbook и ещё несколько, со своими достоинствами и недостатками, но не почти не включают часть связанную с "исполнимостью текста".


Ссылки:
[1] https://yangx.top/begtin/2147
[2] https://yangx.top/begtin/2607
[3] https://yangx.top/begtin/3386
[4] https://github.com/executablebooks
[5] https://jupyterbook.org
[6] https://executablebooks.org/en/latest/gallery.html
[7] https://myst-parser.readthedocs.io

#executablebooks #executablepapers #opensource #data #datadocumentations #datatools

В блоге SeattleDataGuy (консультант по дата платформам Ben Rogojan) две публикации про The Baseline Data Stack [1] [2] о том что нет универсального стека ьтехнологий для данных и есть много разных вариантов сборки. Можно сделать полностью на открытом коде, можно на основе ведущих продуктов и можно сделать только на базе облачных продуктов.
Реальность, как правило, где-то посередине, достаточно вспомнить Gitlab у которых смешаны open source Airbyte и dbt, коммерческий Fivetran, хранилище в Snowflake и собственноручно написанный Meltano, уже выделенный в отдельную компанию/стартап/продукт.

Основная мысль в том что под разные задачи - разные решения и это, конечно, так оно и есть. И я также вижу тренд как вначале появляется/давно существует коммерческий продукт, потом кто-то делает open source продукт который воспроизводит ключевые/значимые возможности этого коммерческого продукта и далее _очень быстро_ получают венчурное финансирование на создание облачного продукта на базе этого open source. Раньше такое тоже было, но сейчас всё ускоряется.

Меня, кстати, поражает насколько медленно развиваются Яндекс.Облако и облачные сервисы VK. Фактически если ты работаешь с современным стеком технологий то зарубежные платформы почти безальтернативны. Почти, потому что всегда есть "танцы с бубном", но в целом это так. Вообще в области работы с данными "импортозамещения" очень мало, только замена на open source.


Ссылки:
[1] https://medium.com/coriers/the-baseline-data-stack-going-beyond-the-modern-data-stack-part-1-9791b7d49e85
[2] https://medium.com/coriers/the-baseline-data-stack-the-different-types-of-data-stacks-part-2-c6a826d8f2f1

#data #readings #thoughts

В рубрике полезных наборов данных Unicode Common Locale Data Repository [1] [2], 18 летний проект по систематизации и публикации базы языковых данных включая: переводы названий языков, переводы названий стран, шаблоны для форматирования валют, дат, правила сортировки и ещё много всего.

Большинство из нас с этими данными сталкивается неявно, поскольку CLDR используется в операционных системах и во многих других продуктов где необходимо учитывать местные языковые и иные культурные особенности. Для работы с CLDR есть инструменты для всех наиболее популярных языков программирования, например, для Javscript [3] или Python [4] и многих других.

Традиционно CLDR распространялся в XML формате, но есть и версия в формате JSON [5], одна её сборка в сжатом виде - это около 59МБ, а в распакованном виде около 525MB.

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

Ссылки:
[1] https://ru.wikipedia.org/wiki/Common_Locale_Data_Repository
[2] https://cldr.unicode.org
[3] https://github.com/cldr-tools/cldr-tools
[4] https://github.com/carlospalol/money
[5] https://github.com/unicode-org/cldr-json

#datasets #opendata #dictionaries #data #unicode

Тем временем в РБК статья посвящённая теме нормативной закрытости ведомств [1] со ссылкой на мою заметку про рост числа постановлений и распоряжений Правительства РФ [2].

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

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

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

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

Ссылки:
[1] https://www.rbc.ru/politics/07/02/2022/61fbe8909a794784a2243429
[2] https://yangx.top/begtin/3511

#russia #npa #laws #legal #statistics

Итого проголосовало 104 человека из которых большинство, 71% за то что нужен api.gov.ru и что хорошо бы Минцифре РФ его создать (наконец) и около 16% за то что только если в рамках частной инициативы.

По моему запрос вполне очевиден.

#opendata #openapi #government

В нашем движке по распознаванию типов данных внутри баз данных, таблиц и файлов теперь 195 правил охватывающих геоданные, данные об организациях, о людях, о медицинских препаратах, финансах, госфинансах, справочниках и классификаторах и так далее. Прежде чем запускать бета-тестирование API, я выложил сам движок как открытый код и он доступен на Github как metacrafter [1].

Главные достоинства по сравнению с аналогичными инструментами:
* легко расширяется новыми правилами, правила описываются в файлах в YAML формате
* быстро работает без дополнительных расширений. Вместо регулярных выражений используются конечные автоматы PyParsing
* обычно такие инструменты работают с колоночными данными, а тут наоборот поддержка любых построчных.
* поддерживает MongoDB, любую СУБД через SQL Alchemy, файлы в форматах CSV, JSON, JSON lines, BSON, Parquet
* прицел именно на распознавание идентфикаторов, а не просто идентификацию PII.

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

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

Обратите внимение что в среди правил есть правила идентификации персональной информации (PII). Сейчас нет команды поиска только и именно PII, но это несложно добавить.

Плюс в него же встроен веб-сервер для запуска движка распознавания в серверном варианте, с API.

Для того чтобы правила и выявляемые идентификаторы были систематизированы, в отдельном репозитории metacrafter-registry [2] доступны данные по всем идентифицируемым объектам. По списку идентификаторов [3] в нём можно понять, то какие правила существуют и какие данные идентифицируются. Этот реестр будет расширяться, дополняться и пополняться.

Наше коммерческое API использует этот же движок, включает все 195 правил идентификации объектов и скоро будет доступно для бета-тестирования.

Ссылки:
[1] https://github.com/apicrafter/metacrafter
[2] https://github.com/apicrafter/metacrafter-registry
[3] https://github.com/apicrafter/metacrafter-registry/blob/main/data/entities.yaml

#metadata #data #opensource