Instrumentorum minorum linguarum inopia magna sunt

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

Будь то национальные или региональные языки: армянский, казахский, татарский, камбоджийский и тд.

В лучшем случае если ты уже знаешь английский то можешь учить через него какие-то другие языки через Duolingo или аналогичные онлайн сервисы (ling-app и ещё с десяток).

Тут три наблюдения:
- как рыночные продукты для массовой аудитории есть несколько очень удачных продуктов, но для популярных языков в основном
- относительно небольшие страны мало инвестируют в платформы/стартапы/сервисы и в открытый код и данные
- страны с активной языковой политикой, вроде Испании, как раз наоборот инвестируют много

Такое ощущение что здесь есть какая-то бизнес модель упускаемая на этом рынке. Аналоги Duolingo on premise, когда не свой контент, чужой перепродаешь или даёшь платформу в аренду. Может быть курсера для языков.

Или, возможно, более структурированный и адаптированный "усилитель работы репетиторов" которыми сейчас де-факто являются карточки в Memrise к примеру.

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

#startups #ideas #thoughts

Белый дом (США) опубликовал меморандум об обязательном оперативном раскрытии результатов научных исследователей финансируемых из федерального бюджета США [1] [2].

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

От себя добавлю что портал открытых данных в США data.gov - это, во многом, портал раскрытия научных данных такими ведомствами как НАСА, геологической службой США и ещё рядом органов власти, но он не был приспособлен к раскрытию именно научных данных, например, он не присваивает DOI, не даёт публиковать данные под эмбарго и тд.

Поэтому этот меморандум имеет большое значение и интересно будут ли в США создавать отдельный национальный портал открытого доступа или обновят data.gov.


Ссылки:
[1] https://www.whitehouse.gov/ostp/news-updates/2022/08/25/ostp-issues-guidance-to-make-federally-funded-research-freely-available-without-delay/
[2] https://www.whitehouse.gov/wp-content/uploads/2022/08/08-2022-OSTP-Public-Access-Memo.pdf

#opendata #openaccess #datasharing #usa

Подборка свежего чтения про работу с данными и не только:
- The Rise of Data Contracts [1] текст о важности контрактов по работе с данными (контракт - это договоренность поставщиков и потребителей данных о существенных условиях вроде обратной совместимости, итеративности изменений и тд.)․ Можно было бы поиронизировать что молодежь открыла для себя contract programming, но хорошо что открыли и пишут и нужная вещь. Полезно для тех кто не в курсе того как это работает и полезно обновить знания тем кто уже знает.
- Qloo [2] интересный стартап обещающий что могут предсказывать культурные предпочтения пользователей. Называют себя "Cultural AI". Недавно они подняли инвестиций на $15M
- Ziliz [3] стартап по созданию Cloud-native service for Milvus я про Milvus писал ранее - это такая интересная облачная база данных удобная для рекомендательных сервисов и нечёткого поиска. Подняли $60M инвестиций [4] вдогонку к предыдущим $53.
- Apache Hudi vs Delta Lake vs Apache Iceberg - Lakehouse Feature Comparison [5] сравнение трёх платформ для озер данных от стартапа Onehouse. Читать надо с осторожностью, они делают свой сервис на Hudi, так что не стоит доверять без оглядки.
- Why Apache Iceberg will rule data in the cloud [6] чтобы иметь другую картину в сравнениях озер данных, альтернативный взгляд с позиции преимуществ Iceberg. Но лучше выберите любое и пробуйте, пробуйте, пробуйте пока не набьёте шишек.
- Professional Pandas: The Pandas Assign Method and Chaining [7] для тех кто уже всё про pandas знаете и хочет поизучать более сложные техники на базе pandas. Конкретно здесь про пользу метода assign и итоговые результаты.

Ссылки:
[1] https://dataproducts.substack.com/p/the-rise-of-data-contracts
[2] https://qloo.com/
[3] https://zilliz.com
[4] https://zilliz.com/news/vector-database-company-zilliz-series-b-extension
[5] https://www.onehouse.ai/blog/apache-hudi-vs-delta-lake-vs-apache-iceberg-lakehouse-feature-comparison
[6] https://www.infoworld.com/article/3669848/why-apache-iceberg-will-rule-data-in-the-cloud.html
[7] https://ponder.io/professional-pandas-the-pandas-assign-method-and-chaining/

#data #readings #datatools #startups

Продолжая тему приватности мобильных приложений. Есть стартапы создающие мобильные приложения, а есть стартапы помогающие отслеживать нарушения приватности в этих приложениях. Например, Privado [1] предоставляют сервис отслеживания обработки чувствительных данных в приложениях для Android'а через сканирование исходного кода. Проверить код можно скачав их open source сканер [2] и запустив с параметром 'privado scan <folder name>'.

Я его проверял на швейцарском государственном приложении отслеживания COVID-19 swisscovid-app-android [3].

Из плюсов - он работает
Из минусов - только с Java кодом, не поддерживается приложения на Javascript или Kotlin не говоря уже о Flutter и тд.
Из странностей - ложные срабатывания. Например, срабатывает на обработку высоты изображения как рост человека height, хотя в коде видно что срабатывание неверное.

Приложение хотя и open source, но будьте осторожны, результаты оно постит сразу на сайт community.privado.ai, то есть открытый код, но с зависимостью от облачного сервиса.

Главная фишка - генерация Data Safety манифеста для Google Play. Иначе говоря, автоматизация комплаенс процедуры для приложений Android.

Продукт интересный, буду наблюдать за его развитием. Может быть он сможет работать и с декомпилированным кодом или сам научится декомпилировать DEX файлы? А может у него появятся конкуренты.

Ссылки:
[1] https://www.privado.ai/
[2] https://github.com/Privado-Inc/privado
[3] https://github.com/SwissCovid/swisscovid-app-android

#mobileapps #privacy #android #security

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

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

Реестр вырос уже до 284 типов данных сгруппированных по 26 категориям и в привязке к 11 странам. Более всего страновых идентификаторов по России - более 70 (ИНН, СНИЛС, КЛАДР и все остальные), но по мере обработки порталов данных и других источников растет список и по другим странам.

Самые главные изменения в том что многие типы данных теперь имеют привязку к Wikidata и Schema.org. Какие-то ещё можно привязать, но, к сожалению не все. Wikidata почти не покрывает персональные идентификаторы, зато включает сотни идентификаторов литературных источников почти нигде "в диком виде" не встречающиеся.

Реестр всё лучше перелинкован, синхронизован с используемыми инструментами и понемногу включает и регулярные выражения для идентификации типов данных. Часть их уже перенесена в утилиту metacrafter [4] для идентификации семантических типов данных, а часть будет перенесена постепенно позже.

Ссылки:
[1] https://registry.apicrafter.io/
[2] https://github.com/apicrafter/metacrafter-registry
[3] https://medium.com/@ibegtin/semantic-data-types-systematic-approach-and-types-registry-a2c2a60a467b
[4] https://github.com/apicrafter/metacrafter

#opensource #data #datatools #metadata #semanticdatatypes

В рубрике как это работает у них the Global Open Science Cloud Initiative (GOSC) [1] проект CODATA (Комитета по данным Международного научного совета).

Идея его простая - создать стандарты и инфраструктуру для интеграции больших национальных и международных проектов открытой научной инфраструктуры. Я об этих проектах многих писал: EOSC, ARDC, NFDI, NRDIO и многих других. В мире идёт активное развитие таких платформ, например, развивается La Refencia в Латинской Америке и African Open Science Platform, как вы догадываетесь, в Африке.

Все они на разных стандартах, идентификаторах, протоколах, и вот CODATA организуют инициативы по их обзору и интеграции. Что любопытно, оплачивает это CNIC CAS (Компьютерный сетевой информационный центр Китайской академии наук). И вот организаторы обещают уже 12 октября представить первые результаты в рамках GOSC IPO [3]. Ждать недолго и даже если это будет только результат анализа существующих проектов - это уже будет интересно.

Почему это важно? Существенная часть открытой научной инфраструктуры - это доступность научных данных, инструментов их обработки и облачных сервисов. Лично я сомневаюсь появления глобальной [некоммерческой] научной инфраструктуры как digital commons в ближайшие годы, но сама идея интеграции национальных инициатив выглядит актуально.

Ссылки:
[1] https://codata.org/initiatives/decadal-programme2/global-open-science-cloud/
[2] https://codata.org
[3] https://codata.org/launch-of-the-gosc-international-programme-office/

#openaccess #openscience #opendata

Онтология типов данных

Когда я только-только начинал возиться с семантическими типами данных то столкнулся с тем что онтологического моделирования типов данных очень мало. Есть исследование и онтология OntoDT [1] ещё 2016 года, но сайт с ним уже недоступен, и сама онтология кое-где ещё доступна как RDF/OWL [2]. Основной автор Panče Panov явно переключился на более прикладные исследования [3]

В качестве других примеров։
- онтология EDAM [4] в биоинформатике, с акцентом на особенности анализа и майнинга данных в этой области
- CDM (Common Data Model) [5] не-формальная онтологии от Microsoft привязанная с акцентом на продажах, пользователях, маркетинге и тд.
- онтология типов данных при ответах на вопросы по геоаналитике [6] прошлогоднее исследование с акцентом на геоданные.

Есть, также, какое-то количество других научных и не только научных публикаций на эту тему, но в целом их довольно мало. Они чаще всего происходят в контексте задач по анализу данных и его автоматизации. Самое развитое идёт в сторону автоматизации создания и аннотирование моделей для ИИ. Проект D3M (Data-Driven Discovery of Models) [7] от DARPA в США. Я не так давно писал о нём и порождённых им стартапах. [8]

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

Ещё какое-то время назад в СУБД на родном уровне поддерживались только самые базовые типы данных։ INT, FLOAT, STRING/VARCHAR, BLOB и тд. с небольшими вариациями. Сейчас, современные СУБД, поддерживают многочисленные дополнительные типы данных, перешедших из смысловых (семантических) в базовые типы. Пример: ip-адреса и mac-адреса уже достаточно давно имеющиеся в некоторых СУБД [9] и недавно добавляемые в другие [10].

Ранее всего это произошло с датами и временем в разных вариациях, с геоданными для которых есть сейчас много отдельных функций и индексов внутри СУБД. Также происходит с сетевыми наиболее популярными данными.

Мои ощущения что на этом процесс не остановится. Например, меня удивляет что всё ещё нет СУБД общего типа с отдельными типами данных под хэши (SHA1, SHA256 и др.).

Многие составные идентификаторы и коды классификаторов сейчас в СУБД хранятся как строки, при том что часто они нужны в декомпозированной форме и, в итоге, создаётся избыточность разбирая этот код на части. Пример в России: Вы можете хранить код КЛАДР как есть, а можете разделить его на подэлементы и осуществлять поиск по ним когда это необходимо.

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

Ссылки:
[1] https://fairsharing.org/FAIRsharing.ydnwd9
[2] https://kt.ijs.si/panovp/OntoDM/archive/OntoDT.owl
[3] https://orcid.org/0000-0002-7685-9140
[4] http://edamontology.org/page
[5] https://docs.microsoft.com/en-us/common-data-model/
[6] https://digitalcommons.library.umaine.edu/josis/vol2020/iss20/2/
[7] https://datadrivendiscovery.org
[8] https://yangx.top/begtin/3926
[9] https://www.postgresql.org/docs/current/datatype-net-types.html
[10] https://mariadb.com/kb/en/inet4/

#data #rdbms #research #metadata #semanticdatatypes

Если медицинская организация имеет личный кабинет и использует сервис CDN для раздачи контента и данные в личном кабинете тоже через него отдаются, то это в чистом виде трансграничная передача данных. Ведь данные проходят пользователю через сервера в США и/или Европе. Пожалуйся на них в Роскомнадзор и те прибегут и наштрафуют. Но есть ли ущерб потребителю? Честно говоря, я сомневаюсь. Называть компанию не буду, более того, их много.

А если ВК раздают пользователям приложения в котором 90% приложений отдаёт данные Гуглу, Facebook'у и тд. или если некоторые, не будем показывать пальцами, органы власти то Роскомнадзор даже не почешется.

Как это правильно назвать по-русски?

#privacy

Полезное чтение про данные и не только:
- WSJ пишет что метеорологическая служба США начала закупать данные у двух частных компаний чтобы заполнить пробелы в покрытии их спутников [1]. Статья о том что государство действует очень медленно в таких случаях, закупать данные у частного сектора госорганам непросто.
- научная статья о том как регулируется (ограничивается) ИИ в разных странах [2] статья под пэйволом, но весьма полезна и по сути построена на сравнении предпочтении граждан.
- критическая статья в Politico о том что предполагалось что ИИ изменит систему здравоохранения и о том почему этого не происходит [3]. Если коротко то - завышенные обещания, несовместимые системы и тд. Самое плотное применение ИИ в США сейчас в радиологии.

Ссылки:
[1] https://www.wsj.com/articles/u-s-government-effort-to-tap-private-weather-data-moves-along-slowly-11661335203
[2] https://www.tandfonline.com/doi/full/10.1080/13501763.2022.2094988?src=
[3] https://www.politico.com/news/2022/08/15/artificial-intelligence-health-care-00051828

#data #readings

Счетная палата РФ выпустила бюллетень N30 посвящённый государственным информационным системам [1], о нем уже написали TAdviser, РБК и много других изданий. РБК, например, делают акцент на критике Гостеха [2] в бюллетене, другие издания другие акценты, а я могу посоветовать почитать сразу весь бюллетень.

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

1. Число государственных информационных систем в России несопоставимо с [не]доступностью данных из этих же информационных систем. Иначе говоря огромное число информационных систем существуют в полностью закрытом режиме и, в лучшем случае, по ним доступны только сведения перечисленные в их ТЗ размещённом на сайте госзакупок.

2. Архитектура многих информационных систем - это продолжение госполитики по сверхконцентрации полномочий в Москве и подмосковье. Георезервирования данных нет не только потому что на этом экономят или не умеют, но и по причине трансформации федеративного государства в техноунитарное. А то есть там где нельзя забрать полномочия у субъектов федерации вместо этого на стыке полномочий создается федеральная информационная система от которой региональной власти оказываются в критической зависимости (не могут без неё работать). Это не только про электронные учебники, это ещё и про системы Росреестра, ГИС Торги, портал госзакупок и ещё многие другие системы.

3. Лично мне не хватило в бюллетене отражение "успехов" Гостех в правительстве Москвы и в Казахстане. Но даже упоминание критичности зависимости платформы от воли Сбербанка - это достаточно существенная критика.

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

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

Ссылки:
[1] https://ach.gov.ru/statements/bulletin-sp-8-2022
[2] https://www.rbc.ru/technology_and_media/30/08/2022/630cc2709a7947836b2ef7c4

#government #it #digital #opengov

Дождались! Минэк расторг контракт на портал открытых данных.

Правда возникает вопрос, почему это не было сделано еще, например, в конце 2020 года, когда подрядчик в декабре 2020 года не провел хакатон, а Минэк в августе 2021 (!) его отменил доп. соглашением.

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

Напомню, что подрядчиком была петербургская компания, у которой было 3-4 клона с одинаковыми названиями, учредителями, адресами. И одну из этих компаний Минэк внес в РНП по предыдущему госконтракту на портал ОД.

Я довольно много писал про недокументированные 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://yangx.top/begtin/3550
[2] https://yangx.top/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 года. И вот уже в рамках этого, отделенного от цензуры и надзора закона, нужно давать определения ГИС, ГИР (государственных информационных ресурсов), цифровых платформ, Гостеха и т.п.
Но для написания такого закона сейчас нет экспертного ресурса - ни среди юристов по информационному праву, ни среди ИТшников, способных генерировать правильные с технической и юридической точек зрения определения. Вот только я один и остался из экспертов - как три тополя на Плющихе.
А начать следовало бы вообще с узаконивания очень простой мысли - любая информационная система, созданная, развиваемая и эксплуатируемая за счет бюджета, является государственной информационной системой, независимо от целей ее создания, сферы применения, реализуемой функциональности и т.д. Все используемые сегодня определяющие критерии для ГИС должны определять не то, ГИС перед нами или не-ГИС, а конкретную категорию ГИС - ГИС госуслуг, ГИС полномочий, ГИС инфраструктуры, ГИС взаимодействия, ГИС поддержки процессов и т.п. Но это уже будет классификация второго рода. А классификация первого рода очень простая - "чьи деньги в системе?".
Вот и всё. Будет время, распишу эти мысли подробнее. А пока вот так