Сейчас многие активно обсуждают решение Сената Франции с рекомендацией Правительству Франции о признании Нагорно-Карабахской республики и призывом к выводу азербайджанских войск с территории Республики Армения [1], а я как раз давно планировал написать о том как Сенат Франции публикует данные о своей деятельности.

На сайте Сената есть баннер со ссылкой на их портал открытых данных [2] где не только собраны сведения о выборах, принятых законопроектах, сенаторах, полученных ими грантах и всё это в форматах CSV, JSON и XML, но там также есть такое редкое явление как полные дампы базы данных публикуемые в формате SQL дампов для СУБД Postgres.

Например, база поправок в законодательство, Ameli [3] и в 100 мегабайтном ZIP файле содержит 500 мегабайтный SQL файл. Для полной радости не хватает только чтобы они вообще всю базу целиком публиковали для выгрузки, а не несколькими SQL файлами и чтобы к данным и к дампам баз данных была бы более полная документация.


Ссылки:
[1] https://www.senat.fr/dossier-legislatif/ppr22-003.html
[2] https://data.senat.fr/
[3] https://data.senat.fr/ameli/

#opendata #datasets #france #parliaments #opengov

По поводу новости о том что российские власти в лице Минюста РФ хотят публиковать в открытом доступе СНИЛС и ИНН иностранных агентов [1] я многое могу об этом сказать, но начну с того что сама практика публикации персональных и личных данных граждан является ущербной.

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

Несколько лет назад я публиковал исследование Утечки персональных данных из государственных информационных систем. Открытая часть доклада [2] со множеством примеров когда из государственных официальных информационных систем и реестров публиковались паспортные данные, ИНН, СНИЛС и иные персональные данные граждан. Самая яркая из описанных там историй - это раскрытие данных о СНИЛС в электронных сертификатах и цифровых подписях к документам сделанных этими сертификатами.

Другой пример в виде дискриминируемых групп был в раскрытии данных о людях подозреваемых в преступлениях, например, в сообщениях арбитражных судов [3] и разного рода уполномоченных гос-вом агентов.

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

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

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

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

Ссылки:
[1] https://www.rbc.ru/politics/13/11/2022/6370be7d9a79471426620f95
[2] https://begtin.tech/pdleaks-p3-govsys/
[3] https://www.asv.org.ru/news/612038

#privacy #security #data #personaldata

В рубрике "как это устроено у них" программа Pathways to Enable Open-Source Ecosystems (POSE) [1] от Национального научного фонда США по финансированию экосистемы открытого кода. Общая сумма фонда 8 миллионов долларов (около 480 миллионов рублей)

Полный список из 25 проектов включает проекты по гражданской науке, по развитию продуктов с открытым кодом для создания экосистемы открытых данных [2]․ Средний размер гранта на этой фазе (Phase 1) - это $300 тысяч, это порядка 18 миллионов рублей и все они выдаются именно научным командам которые исследуют то как устроены те или иные экосистемы открытого кода и также, привлекают к проектам в этих экосистемах дополнительные ресурсы.

Ссылки:
[1] https://beta.nsf.gov/funding/opportunities/pathways-enable-open-source-ecosystems-pose
[2] https://www.nsf.gov/awardsearch/advancedSearchResult?ProgEleCode=211Y&BooleanElement=Any&BooleanRef=Any&ActiveAwards=true#results

#opendata #openaccess #opensource

Mother Duck, компания созданная для развития СУБД DuckDB получили $47.5 миллионов инвестиций от Andreessen Horowitz [1]․ У них забавный лозунг Making analytics fun, frictionless and ducking awesome. Ducking awesome звучит особенно замечательно, невозможно перевести это с языка оригинала.

Для тех кто не помнит, DuckDB - это такая OLAP база данных, работающая полностью в памяти и внутри процесса из которого запускается. Её называют SQLite для аналитики и вокруг неё уже выстроилось большое сообщество, создан специальный фонд DuckDB Foundation [2] в который входят многие компании, включая Mother Duck, Mode, Posit и другие компании, в основном стартапы.

Как бы то ни было если Вы занимаетесь обсчётом больших данных в аналитических СУБД, то попробовать DuckDB стоит .

Ссылки:
[1] https://techcrunch.com/2022/11/15/motherduck-secures-investment-from-andreessen-horowitz-to-commercialize-duckdb/
[2] https://duckdb.org/foundation/

#startups #data #datatools

В рубрике больших открытых наборов данных The Stack [1] 3.1 терабайта 300 миллионов файлов исходного кода на 30 языках программирования с разрешающими лицензиями (permissive licenses) на его повторное использование. Опубликован на Hugging Face, кроме программных языков, охватывает около 20 естественных языков (английский, китайский, испанский, русский и др.)

Является результатом проекта BigCode [2], совместных усилий команд ServiceNow и Hugging Face․

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

А также большой тред в твиттере с рассказом об этом наборе данных [3]

Ссылки:
[1] https://huggingface.co/datasets/bigcode/the-stack
[2] https://www.bigcode-project.org/
[3] https://twitter.com/BigCodeProject/status/1585631176353796097

#opendata #opensource #datasets

Я регулярно рассказываю про работу над выявлением смысловых типов данных, это моя любимая тема в работе с данными - семантические типы данных. Я писал об этом большой текст на английском языке [1] и про проекты metacrafter [2] по идентификации типов данных и metacrafter-registry [3] реестр семантических типов данных.

В них пока небольшие, но обновления.
1. В реестр добавлены много типов персональных данных в реестр, например, идентификаторы паспортов [4] и водительских удостоверений. Везде где возможно приведены регулярные выражения для проверки этих типов данных.
2. Добавлены новые правила идентификации смысловых полей для русского и французского языка. Теперь можно использовать metacrafter на русскоязычных и франкоязычных наборах данных.

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

А я напомню что metacrafter сейчас используется в другом нашем проекте Datacrafter для идентификации типов данных в каталоге [7].

Ссылки:
[1] https://medium.com/@ibegtin/semantic-data-types-systematic-approach-and-types-registry-a2c2a60a467b
[2] https://github.com/apicrafter/metacrafter
[3] https://github.com/apicrafter/metacrafter-registry
[4] https://registry.apicrafter.io/datatype/aupassport
[5] https://registry.apicrafter.io/datatype/cadriverlic
[6] https://github.com/apicrafter/metacrafter/tree/main/rules
[7] https://datacrafter.ru/class

#opensource #datatools #data #dataengineering

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

Они недавно опубликовали результаты своего исследования [2], они полезны тем кто изучает экосистему открытости данных в мире. А я могу поделиться собственными ощущениями.

Начну с того что собирать обратную связь действительно сложно. Когда ты создаёшь продукт коммерческий то обратная связь начинается когда у него появляется лояльная аудитория. Спроси внешнего человека, он, скорее всего, проигнорирует и ещё и подумает "Зачем мне тратить на это время?". Спроси эксперта - он скажет "ребята, это консалтинг, моё время стоит денег". Продукт должен быть, либо феноменальным, либо ты им пользуешься уже много лет и есть что сказать, либо собирать надо так чтобы мотивировать пользователей. Опять же это с точки зрения пользователя, стороннего наблюдателя.

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

Поэтому какой-нибудь продукт вроде dbt, Meltano, Dagster (примеры из рынка данных) имеют какую-то невероятную обратную связь от пользователей и немало контрибьюторов в код даже при том что их создают и развивают стартапы эффективно их монетизирующие.

Всё вместе это и называется работа с сообществом. Я тут не могу не напомнить про отличную книгу от Nadia Engball под названием Working in Public: The Making and Maintenance of Open Source Software [3] о том как создаются и развиваются сообщества открытого кода и что делает их устойчивыми.

Ссылки:
[1] https://ckan.org
[2] https://ckan.org/blog/ckan-30-product-strategy-research-part-3
[3] https://www.amazon.com/gp/product/B08BDGXVK9/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=B08BDGXVK9&linkCode=as2&tag=begtintech-20&linkId=5df79c2a091bee55a08f60476f15ac33

#opensource #thoughts

Для тех кто любит программировать на Python и не любит Javascript не могу не рассказать о таком проекте как PyScript [1], код для исполнения кода Python'а на стороне браузера. Включает как простые, так и сложные примеры [2], а также по нему есть огромное руководство с кучей подробностей [3].

Признаюсь, я лично, никогда не любил разработку фронтэнда именно из-за Javascript'а, какое-то сильное чувство отторжение у меня вызывало его использование, так что не только Javascript'у проникать на сервер, но и Python'у в браузер.

А их свежего и любопытного - руководство по написанию расширений для Google Chrome с помощью PyScript [4].

Почему это важно? Многие продукты по обработке и визуализации данных не сервере написаны на Python. Если PyScript будет работать с хорошей производительностью, то часть задач обработки можно будет перенести в браузер и поддерживать единую кодовую базу.

Пока единственное ограничение в том что PyScript более-менее оттестирован в Chrome, но даже в Firefox'е его активно не проверяли.

Тем не менее, экспериментировать можно уже сейчас.

Ссылки:
[1] https://pyscript.net
[2] https://pyscript.net/examples/
[3] https://realpython.com/pyscript-python-in-browser/#modules-missing-from-the-python-standard-library
[4] https://medium.com/@petefison/write-chrome-extensions-in-python-6c6b0e2e1573

#opensource #python #programming