Я довольно много писал про недокументированные API госорганов [1] и упоминал похожий гражданский проект в Германии [2].

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

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

Всех этих API великое, нет огромное количество.

Какое-то время назад я размещал на сервисе Postman коллекцию с документацией таких API [3]․ Там их немного, 6 государственных систем, около пары-тройки десятков точек подключения. Все они идут по 1-й или по 2-й категории API, а есть немало API которые просто являются частью продукта и вот их примеры.

Есть такой продукт DSpace используемый ВУЗами для создания репозиториев научных результатов. Он много где установлен в мире, в основном университетами, но даже открытые библиотека НАТО и Мирового банка тоже работают на DSpace. В России он используется, например, в СПбГУ.

У DSpace по умолчанию есть интерфейс раскрытия данных по стандарту OAI-PMH, это такой стандарт архивации научных и библиотечных знаний. Поэтому, к примеру, у инсталляции DSpace есть API интерфейс для доступа [4], подробнее о нём и как работать с протоколом OAI-PMH легко гуглится. Специалисты, как правило, о таких интерфейсах знают заранее. Неспециалисты очень удивляются когда неожиданно обнаруживают.

Другой пример, у Wordpress есть API, идущее практически по умолчанию в новых инсталляциях. Оно сводится к точке подключения /wp-json/ через который можно выкачать. Это полезно, например, для цифровой архивации. Я специально для такого сделал утилиту wparc [5] позволяющую архивировать данные из инсталляций Wordpress. В России, например, Wordpress, используется на сайте Госкомиссии по Арктике и, конечно, wp-json там активирован [6].

Таких примеров много, они не описываются на порталах открытых данных и инициативах вроде bund.dev или нашей коллекции госAPI.

Ссылки:
[1] https://t.me/begtin/3550
[2] https://t.me/begtin/4194
[3] https://www.postman.com/infoculture/workspace/infoculture-public/documentation/1428203-a769e0a6-0cc9-4de4-bdcc-5f8a0fa06e36
[4] https://dspace.spbu.ru/oai/
[5] https://github.com/ruarxive/wparc
[6] https://arctic.gov.ru/wp-json/

#api #openapi #government #undocumented

Рубрика "Циничное законописательство"
После вчерашней публикации Счетной палатой отчета по ЭАМ про ГИСы и Бюллетеня на ту же тему Минцифры решило хайпануть на теме и продемонстрировать, как быстро оно умеет отрабатывать рекомендации уважаемого Высшего органа государственного аудита.
Уже сегодня на Регулейшене появился проект внесения изменений в 149-ФЗ, в котором сделана очередная обреченная на провал попытка определения термина "государственная информационная система". Ссылку на Регулейшен и цитаты из "законопроекта" я не даю, потому что этот "законопроект" написан исключительно с целью ИБД (ИБД - имитация бурной деятельности, а не что-то про информационную безопасность). Шансов на то, что этот проект попадет в Госдуму, практически ноль - скорее всего, его зарубят на этапе антикоррупционной экспертизы еще на Регулейшене (там коррупциогенность не в терминологии, а в другом пункте - про приостановку финансирования ГИС).
В Минцифры не могут понять главного - любые попытки внесения в 149-ФЗ каких-либо изменений, относящихся к крайне немногочисленным в этом законе положениям про ИС и ГИС (если не считать статьи про ЕБС, которая вообще должна была стать отдельным законом, а не уродливым "горбом" у 149-ФЗ), являются ничем иным, как разновидностью гальванизации трупа. 149-ФЗ как субъект регулирования именно госИТ давно и бесповоротно убит Роскомнадзором, превратившим его в закон о запрете информации.
Сфера госИТ нуждается в своем отдельном федеральном законе - примерно таком в концептуальном смысле, каким был светлой памяти 24-ФЗ от 1995 года. И вот уже в рамках этого, отделенного от цензуры и надзора закона, нужно давать определения ГИС, ГИР (государственных информационных ресурсов), цифровых платформ, Гостеха и т.п.
Но для написания такого закона сейчас нет экспертного ресурса - ни среди юристов по информационному праву, ни среди ИТшников, способных генерировать правильные с технической и юридической точек зрения определения. Вот только я один и остался из экспертов - как три тополя на Плющихе.
А начать следовало бы вообще с узаконивания очень простой мысли - любая информационная система, созданная, развиваемая и эксплуатируемая за счет бюджета, является государственной информационной системой, независимо от целей ее создания, сферы применения, реализуемой функциональности и т.д. Все используемые сегодня определяющие критерии для ГИС должны определять не то, ГИС перед нами или не-ГИС, а конкретную категорию ГИС - ГИС госуслуг, ГИС полномочий, ГИС инфраструктуры, ГИС взаимодействия, ГИС поддержки процессов и т.п. Но это уже будет классификация второго рода. А классификация первого рода очень простая - "чьи деньги в системе?".
Вот и всё. Будет время, распишу эти мысли подробнее. А пока вот так

Полезное чтение про данные, стартапы и технологии:
- Developer Experience Infrastructure (DXI) [1] о том как создавать продукты для разработчиков и что разработчики от них ждут. Похоже на подходы User Experience, только пользователи тут особые
- The Good Research Code Handbook [2] о том как реорганизовать код в при исследовательском проекте. Я бы сказал что это надо студентам прям преподавать, но полезно не только им
- StarTree подняли $47M инвестиций [3] и развивают свой продукт по облачной аналитике. Это та команда что создала Apache Pinot и делают теперь его корпоративный вариант.
- Data Governance Checklist [4] сильно связанный с регулированием, персональными данными и иными законами в США. Что не мешает ему быть актуальным не только в США

Ссылки:
[1] https://kenneth.io/post/developer-experience-infrastructure-dxi
[2] https://goodresearch.dev/index.html
[3] https://www.startree.ai/blog/a-new-phase-of-growth-for-startree-and-the-real-time-user-facing-analytics-movement
[4] https://medium.com/@corymaklin/data-governance-checklist-152a3a691002

#readings #data #startups

Периодическая таблица элементов открытых данных [1] от Open Data Policy Lab. В ней ничего про технологии и много про организацию процесса, ответственных, взаимодействие с пользователями, нормативное закрепление и так далее.

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

По ссылке кроме этой таблицы подробный опросник.

Ссылки:
[1] https://periodictable.opendatapolicylab.org/

#opendata #opengov #data #datamanagement

Полезное чтение про данные, технологии и не только:

Данные
- State of gender data [1] есть такая большая тема - учет гендерных особенностей в системах регистрации статистики, учетных системах или, как упоминают авторы, "data systems". Текст о том что учет гендерных данных недостаточен.
- One Data Point Can Beat Big Data [2] о том что не всё решается большими данными и понимание данных и тщательная их фильтрация, избавление от шума, могут дать больше чем просто расширение источников и объёмов данных
- Making Government Data Publicly Available: Guidance for Agencies on Releasing Data Responsibly [3] руководство о том почему и как публиковать открытые данные от Center for Democracy and Technology. Адресовано органам власти (агентствам) в США, но актуально для всех
- Closing the Data Divide for a More Equitable U.S. Digital Economy [4] о неравенстве в доступе к данным и что с этим делать на примере экономики США. В основном рекомендации для регуляторов. Акценты на том что есть многие сообщества (в нашем понимании муниципалитеты) качество данных по которым невелико и они выпадают из многих госпрограмм поддержки. Тема важная, подход системный, но, конечно, инфраструктура и экономика США от других стран существенно отличаются.

ИИ и умные города
- Why Japan is building smart cities from scratch [5] о том почему в Японии создают умные города с нуля. На самом деле в статье именно на этот вопрос ответа нет, есть рассказ про несколько городов в Японии построенных с нуля. Это интересно, хотя я подозреваю что в Китае в в этом направлении даже больший прогресс.

Технологии и программирование
- Building modern Python API backends in 2022 [6] о структуре и архитектуре современных бэкэндов приложений на Python. Конечно, на самом деле, альтернатив куда больше, но прикладной стек расписан хорошо.
- Ruff [7] очень быстрый проверятель (linter) исходного кода для Python, написанный на Rust. Показывают производительность выше в 10-100 раз чем другие аналогичные инструменты вроде flake8, pylint и т.д.
—
P.S. Я подумываю выделить рубрику чтение (#readings) в какой-то отдельный формат, например, еженедельную рассылку, в отличие от моей личной рассылки которую я веду не регулярно или же скорректировать личную рассылку (begtin.substack.com) и добавить туда еженедельной регулярности.

Ссылки:
[1] https://data2x.org/state-of-gender-data/
[2] https://behavioralscientist.org/gigerenzer-one-data-point-can-beat-big-data/
[3] https://cdt.org/insights/making-government-data-publicly-available-guidance-for-agencies-on-releasing-data-responsibly/
[4] https://datainnovation.org/2022/08/closing-the-data-divide-for-a-more-equitable-u-s-digital-economy/
[5] https://www.nature.com/articles/d41586-022-02218-5
[6] https://backfill.dev/blog/2022-08-21-modern-python-backends/
[7] https://github.com/charliermarsh/ruff

#opendata #data #government #policy #tech #programming #readings

Купище державное

Я чувствую уже что слишком часто пишу про инициативы Минцифры РФ, гораздо реже стал писать в последнее время про госзакупки или другие органы власти, а чаще про них и про технологии. Вот недавно на Regulation выложили свежий проект постановления Пр-ва РФ [1] с обновлённым положением ГосТех'а и положением о ФГИС "ГосМаркет".

Во первых, не могу не посетовать на неизобретательность авторов. Сплошные англицизмы, а могли бы назвать imperium foro (на латыни) или купище державное / державное купище (почти старославянский). Но это ирония, будем честными, ничего другого мы и не ждали.

Сама идея того что называют Госмаркетом в том чтобы у производителей ПО была бы возможность продажи своих продуктов госорганам в режиме магазина. Зашёл, кликнул, получил, начал работать.

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

В чём проблема с "ГосМаркетом" в России?

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

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

Например, Azure Government Marketplace [2] и AWS GovCloud с руководствами по публикации там приложений [3].

В чем особенность ГосМаркета?
1. Зависимость от ГосТех'а что довольно странно поскольку сам ГосТех выглядит "големимсто". В том смысле что НПА вокруг него уже принято больше чем видно реального результата.
2. Оторванность от ГосОблака - кто-то ещё помнит, а такой проект был и никуда не делся. Но с суетой вокруг ГосТех'а его куда-то задвинули на второй или третий план.
3. Отсутствие сертификации соответствия облачных решений. Вообще обычно вначале их разрабатывают и актуализируют и только потом уже создают платформы вроде Державного купища

Я на эту тему могу рассуждать и писать ещё долго, но пока ограничусь напоминанием что портал ГосУслуг в России запускали трижды. Сколько раз будут запускать ГосТех и ГосМаркет?

Денег в стране ещё много, я делаю
ставку что больше двух раз;)

Ссылки:
[1] https://regulation.gov.ru/projects#npa=131116
[2] https://docs.microsoft.com/ru-ru/azure/azure-government/documentation-government-manage-marketplace
[3] https://aws.amazon.com/ru/blogs/awsmarketplace/category/public-sector/government/

#government #digital

Просто таки замечательный текст [1] о том насколько уже сейчас можно использовать генераторы изображений с помощью ИИ такие как Stable Diffusion для создания видео. Краткий ответ - можно уже сейчас.

Приложенная картинка сгенерирована автором с помощью DeepNostalgia [2] движка от MyHeritage по оживлению фотографий.

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

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

Может уже пора делать стартапы по персонифицированной порнографии? Уже появились венчурные фонды со специализацией в этой теме?

Ссылки:
[1] https://metaphysic.ai/stable-diffusion-is-video-coming-soon/
[2] https://blog.myheritage.com/2021/02/deep-nostalgia-goes-viral/

#ai #video #stablediffusion

Хороший обзор прослеживаемости данных (data lineage) [1] от Borja Vazquez из Monzo Bank

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

Автор делает акцент на картографии данных в разных разрезах - пользовательского использования, качества данных, производительности и тд. в разных формах картографии данных, в основном вокруг DAG (directed acyclic graph) и потоков обработки данных.

Текст короткий, постановка проблем и подходов вполне понятные.

Когда-то я также активно занимался картированием данных, в основном для задач, обнаружения данных (data discovery).

Это другой подход, его задача идентифицировать основные источники данных в целях:
а) Внутреннего аудита
б) Создания дата-продукта

В итоге вместо того чтобы многие карты данных мы собрали общедоступные источники данных в datacatalogs.ru [2]

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

В работе с открытыми источниками ключевые вопросы: "Как найти источник? Как получить к нему доступы?"

Ссылки:
[1] https://medium.com/data-monzo/the-many-layers-of-data-lineage-2eb898709ad3
[2] https://datacatalogs.ru

#data #dataquality #datamaps #opendata #datalineage

В рубрике что почитать и посмотреть, о том как устроены индексы в базах NoSQL от команды ByteByteGo [1] и, от них же, о том почему Redis работает быстро [2] и о том почему Kafka работает быстро [3].

У них отличный канал и про другие общеупотребимые технологии [4], рассылка [5] и онлайн курс [6]․

По многим вопросам стандартной современной архитектуры софтверных продуктов и проектов - это замечательный источник.

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

Ссылки:
[1] https://www.youtube.com/watch?v=I6jB0nM9SKU
[2] https://www.youtube.com/watch?v=5TRFpFBccQM
[3] https://www.youtube.com/watch?v=UNUz1-msbOM
[4] https://www.youtube.com/c/ByteByteGo/videos
[5] https://bit.ly/3tfAlYD
[6] https://bit.ly/3mlDSk9

#systemarchitecture #data #designpatterns

В рубрике интересных наборов данных о России вне России, открытые данные и каталоги данных о нефтегазовом рынке:

Resource Projects [1]
Проект NRGI с данными нефтяных проектов, нефтяных компаний и их профилей. Профиль ряда постсоветскихстран: Россия [2], Азербайджан [3], Казахстан [4], Украина [5], Грузия [6], Армения [7]. Из любопытного - почему-то ничего нет по Саудовской Аравии.
Там же профили компаний и их проектов.

National Oil Company Data [8]
База показателей по нефтегазовым компаниям. Ещё один проект NRGI, данных там много, последние данные за 2021 год.

JodiData [9]

Совместный проект нескольких международных агентств по отчетности по добыче и другим показателям по нефти и газу. Данные довольно актуальные, последние данные по России за июнь 2022 г.

Resource Data [10]

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

IEA Data [11]

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

Ссылки:
[1] https://resourceprojects.org
[2] https://resourceprojects.org/country/RU
[3] https://resourceprojects.org/country/AZ
[4] https://resourceprojects.org/country/KZ
[5] https://resourceprojects.org/country/UA
[6] https://resourceprojects.org/country/GE
[7] https://resourceprojects.org/country/AM
[8] https://www.nationaloilcompanydata.org/
[9] https://www.jodidata.org
[10] https://www.resourcedata.org/
[11] https://www.iea.org/data-and-statistics

#opendata #datasets #oil #gas #energy

В рубрике интересных наборов данных COYO-700M: Image-Text Pair Dataset [1] набор данные в виде пар изображение-текст собранный из базы Common Crawl, крупнейшего открытого поискового индекса в мире.

В наборе данных более 700 миллионов изображений полученных после анализа 10 миллиардов ссылок с упоминанием изображений.

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

Набор данных можно скачать по ссылке [2].

Ссылки:
[1] https://github.com/kakaobrain/coyo-dataset
[2] https://huggingface.co/datasets/kakaobrain/coyo-700m

#opendata #datasets

По поводу свежего распоряжение Правительства РФ об использовании соцсетей Вконтакте и Одноклассники где органы власти должны заводить свои аккаунты [1] мне есть что сказать.

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

Поэтому пишу кратко и тезисно:
1. В России государственных и муниципальных организаций около 200 тысяч, это означает что в соцсети пойдет много контента который ранее там не оказывался потому что никому не был нужен.
2. Правительство РФ - это орган федеральной исполнительной власти, но выпускает распоряжение затрагивающее региональные, муниципальные власти, а также суды.
3. Главные кто будут в выигрыше от этого решения - это соцсети и пиар агентства. Первые получат поток контента (хоть и так себе), вторые начнут, уже начали, продавать свои услуги.
4. Обязательно найдутся псевдообщественники которые начнут накатывать жалобы на то что какой-нибудь детский сад или поликлиника г. Резиножопска не завела аккаунт в соц сетях.

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

P.S. Просто не могу не отметить деградацию нормотворчества. В распоряжении Правительства поленились даже правильно написать реквизиты закона которые должны быть Федерального закона "Об обеспечении доступа к информации о деятельности государственных органов и органов местного самоуправления" от 09.02.2009 N 8-ФЗ вместо этого написано просто Федерального закона "Об обеспечении доступа к информации о деятельности государственных органов и органов местного самоуправления".

Поленились указать дату и номер закона. Всё это очень печалит

Ссылки:
[1] http://government.ru/news/46448/

#openness #government #social #transparency

7 Best Practices for Data Ingestion

Полезная заметка для тех кто занимается сбором и обработкой данных [1]. Автор собрал несколько практик используемых при загрузке данных.

Если кратко их пересказать:
1. Отслеживайте ошибки в первоисточнике (настраивайте предупреждения).
2. Сохраняйте копию первичных данных до преобразования.
3. Заранее устанавливайте сроки и ожидания пользователей. Загрузка данных не так уж проста.
4. Автоматизируйте трубы данных, устанавливайте SLA используйте системы оркестрации.
5. Трубы загрузки данных должны быть идемпотентны (результат их работы должен повторяться)
6. Создавайте шаблоны, используйте их повторно
7. Документируйте Ваши трубы данных.

Всё кажется очень очевидным и ни с чем не поспоришь. Я бы только добавил что 7-й пункт документируйте Ваши трубы данных должен быть 1-м пунктом. Сколько я не сталкиваюсь с продуктами на данных, вокруг данных, связанных с работой с данными и др. все формы data product недостаток документации есть у всех.

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

Ссылки:
[1] https://medium.com/codex/7-best-practices-for-data-ingestion-f336c6b5128c

#data #datapipelines

Может ли ИИ лишить работы журналистов и писателей? Может быть, когда-нибудь. А вот что он может уже сейчас - это выступить соавтором текста.

ИИ мой соавтор [1] в рассылке Stories by AI о сервисе Sudowrite использующем языковую модель GPT-3 для сонаписания текстов.

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

Страшная штука, если задуматься, но, пока ещё, поддерживает только английский язык.

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

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

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

Ссылки:
[1] https://storiesby.ai/p/ai-is-my-co-writer
[2] https://www.sudowrite.com

#ai #tools #writing

Свежий интересный проект с открытым кодом по мониторингу качества данных Elementary Data [1] изначально собранный через интеграцию с dbt и возможность мониторинга данных в хранилищах данных.

Формирует отчеты по наблюдению за данными (data observability report) на основе проведенных тестов.

Как я понимаю, собираются монетизироваться через облачный сервис, который сейчас готовится к бета тестированию.

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

Впрочем инструмент интересный, надо пробовать.

Ссылки:
[1] https://www.elementary-data.com/

#opensource #datatools #dataquality

Полезное чтение про данные, технологии и не только:
- 6 простых шагов для дата-стартапа [1] - если коротко то всё так: цели и ключевые результаты, потоки пользователей, модель заработка, инструменты и каталог событий, каталог метрик, отчеты. С одной стороны разумно, а с другой, достаточно ли? Вот что для Вас важнейший шаг для дата-стартапа?
- О том как работает diffstatic [2] - это такой умный инструмент сравнения знающий 20 языков программирования и делающий сравнение с учётом их синтаксиса. Автор рассказывает как он его разрабатывал.
- Github Copilot делает разработчиков пушистее и шелковистее продуктивнее и счастливее [3] как показывает исследование самого Github'а. Кто бы сомневался что результат будет таким если исследование не независимое. Технология всё ещё имеет свои юридические и этические изъяны.
- Ducks: Поисковик по объектам в Python [4] довольное неожиданная реализация аналога NoSQL а ля MongoDB через словари для Python'а. С похожим языком запросов, но всё только в памяти. Когда надо много чего обрабатывать в памяти, а возможности включать СУБД нет может быть полезно.
- FAIR vs Open Data [5] научная статья в MIT Press Direct со сравнением инициативы FAIR по открытости научных исследований и движений за открытые данные. Это не синонимы и не антиподы, две близкие и пересекающиеся темы.
- Alexa TM 20B [6] научная статья про крупнейшую языковую модель по архитектуре seq2seq [7]. Как минимум полезно тем кто разрабатывает языковые модели.

Ссылки:
[1] https://thedatastrategist.medium.com/6-easy-steps-to-a-data-driven-startup-on-day-1-4e4f900c2667
[2] https://www.wilfred.me.uk/blog/2022/09/06/difftastic-the-fantastic-diff/
[3] https://github.blog/2022-09-07-research-quantifying-github-copilots-impact-on-developer-productivity-and-happiness/
[4] https://ducks.readthedocs.io/en/latest/index.html
[5] https://direct.mit.edu/dint/article/doi/10.1162/dint_a_00176/112737/FAIR-Versus-Open-Data-A-Comparison-of-Objectives
[6] https://www.amazon.science/publications/alexatm-20b-few-shot-learning-using-a-large-scale-multilingual-seq2seq-model
[7] https://en.wikipedia.org/wiki/Seq2seq

#opendata #data #github #ai #datatools #readings

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

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

Так вот в России сотни тысяч поставщиков, доступ к данным можно получить и через них, да и просто пройдя аккредитацию на портале. Это означает что целевые расследования сохранятся, усложнится лишь анализ данных, усложнится аналитика и будет уничтожен почти на корню весь легальный бизнес проверки контрагентов. Почему? Потому без запрета и штрафов на использование этих данных сервисы проверки контрагентов будут искать возможность их получить. Они и так сильно пострадали от закрытия данных по контрактам госкомпаний по 223-ФЗ в 2018 году, а теперь станет ещё хуже.

Хорошо ли это для страны? Не думаю. Хорошо ли это для конкуренции ? Точно нет. Кто выиграет ? Конечно те кому было неудобно пилить бюджет.

Но дело не только в этом. Кроме госзакупок российское государство создает и раскрывает много артефактов своей деятельности. Торги по госимуществу, лицензии, данные о городской инфраструктуре и тд. Их тоже могут использовать в блогосфере для критических публикаций. Ждём уже их закрытия для профессиональных участников или ещё нет?

И, наконец, самое главное. Ключевой источник знаний о субсидиях, многих госконтрактах с ед. исполнителями и иных решениях - это нормативно-правовые документы. Ну что, когда ждём что их тоже закроют? Будет доступ к законам только за деньги и только для юристов. Чем отличается от госзакупок? Разве что только объёмами данных.

Тренд на закрытость государства есть уже давно, но сейчас он значительно усиливается. Лично я вижу по слишком многим темам деятельности государства подмену раскрытия данных продуктами жизнедеятельности пиарщиков. Вместо реальных показателей по нац. проектам, медийные государственные проекты. Вместо раскрытия данных, внедрение каптчей на доступ к сайтам. Вместо раскрытия данных для широкой публики, публикация их только для самих госорганов в режиме авторизации через ЕСИА и тд.

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

Ссылки:
[1] https://www.kp.ru/online/news/4911844/

#opendata #opengov #transparency #government #procurement