The Open Banking Standard - свежий стандарт предоставления API британскими банками. Его активно продвигает ODI в последнее время и похоже что успешно продвинут #opendata #openapi

Это даже не новость, а непрерывный развивающийся тренд о котором нельзя не написать. Спецификация стандарта для публикации API - Swagger [1] в январе этого года вошла полностью в инициативу OpenAPI [2] и теперь развивается в при поддержке большого числа крупнейших ИТ игроков вошедших в консорциум.

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

Сссылки:
[1] https://swagger.io
[2] https://www.openapis.org

#opendata #opengov #openapi

Talend [1], разработчики ETL продуктов по работе с данными, покупают стартап Restlet [2] ориентированный на создание удобной документации и описания API по стандарту Swagger (Open API).

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

Ссылки:
[1] https://www.talend.com
[2] https://restlet.com/company/blog/2017/11/27/restlet-is-now-part-of-talend/

#opendata #opengov #openapi

В рубрике интересные наборы данных, большой набор данных по распознаванию еды [1] в рамках конкурса Food Recognition Challenge [2]. Конкурс тоже интересный, 10 тысяч швейцарских фунтов команде сделавшей алгоритм с точностью > 0.70.

А в наборе данных 1.16ГБ из 24,119 изображений с 39,325 сегментами для 273 различных классов. Всё под лицензией CC-BY 4.0

Проект делается по инициативе Digital Epidemiology Lab [3] и у них же огромный проект по краудсорсингу сведений о еде, The Open Food Repo [4] с охватом 374,104 продуктов из 5-х стран США, Швейцария, Италия, Германия, Франция. У проекта нет наборов данных, но есть общедоступное API, активно применяемое пользователями.

Ссылки:
[1] https://www.aicrowd.com/challenges/food-recognition-challenge/dataset_files
[2] https://www.aicrowd.com/challenges/food-recognition-challenge
[3] https://www.digitalepidemiologylab.org
[4] https://www.foodrepo.org/

#opendata #food #datasets #openapi

OpenAI, разработчики языковой модели GPT-3 о которой так много писали и пишут и которую активно используют в многочисленных демо проектах и экспериментах основанных на понимании языка, убрали лист ожидания к своему API [1] для списка поддерживаемых или стран. Это хорошая новость. Плохая новость в том что России в этом списке стран нет [2]. Вернее даже что из всего постсоветского пространства там нет России, Украины, Киргизстана, Таджикистана, Туркменистана и Беларуси, но есть Казахстан и Армения, к примеру. Китая, кстати, тоже нет в списке.

Чем вызван такой выбор стран непонятно.

Ссылки:
[1] https://openai.com/blog/api-no-waitlist/
[2] https://beta.openai.com/docs/supported-countries

#ai #openapi #openai

Я регулярно пишу о том что у многих информационных систем и иных публичных ресурсов государства есть много недокументированных API. Причём эти API имеют, как правило, две истории происхождения:
a) API сделанные разработчиками для работы каких-то компонентов и ни разу не документированные, например, если сайт сделан с использованим Ajax технологии.
б) API предусмотренное изначально создателем платформы выбранной разработчиками. Например, API использованной CMS.

Приведу примеры того в какой форме такое API бывает.

Сайт Финансового университета fa.ru сделан на Sharepoint, CMS от Microsoft чаще используемой для внутри-корпоративных сайтов и реже для сайтов в Интернете. У последних версий Sharepoint доступ к данным осуществляется через API по ссылке "/_api". Для Финуниверситета это www.fa.ru/_api/ и по этой ссылке можно далее, особенно если почитать документацию на Sharepoint, осуществлять навигацию по сайту. Обычно это начинается со ссылки www.fa.ru/_api/web где по расширенному протоколу Atom отдаётся описание хранящихся в списках сайта материалов.

Сайт Рособрнадзора obrnadzor.gov.ru сделан на CMS Wordpress. Wordpress - это одна из наиболее популярных CMS в мире, скорее всего наиболее популярная. Вот уже несколько версий в этой CMS есть специальная ссылка "/wp-json/" позволяющая получать данные содержимого сайта (не вёрстки, а контента!) в машиночитаемом виде. Поэтому и содержание сайта Рособрнадзора можно выкачать специальным краулером по адресу obrnadzor.gov.ru/wp-json/ . Кроме Рособрнадзора на Wordpress созданы сайты ещё многих сайтов.

У Санкт-Петербургского государствнного университета есть система Архива публичного доступа dspace.spbu.ru как кто-то уже догадался, сделанный на платформе DSPace используемой тысячами научных и иных организаций по всему миру. У DSPace есть API, вполне документированное, но не выносимое на главные страницы инсталляции платформы, доступное по ссылке "/rest/". В случае СПбГУ это ссылка на API dspace.spbu.ru/rest/.

DSPace используется не только ВУЗами, но и межгосударственными организациями такими как Всемирная организация здравоохранения. ВОЗ публикует свои материалы в системе IRIS, Институциональное хранилище для обмена информацией. IRIS, также, создано на базе DSPace и открыто его API apps.who.int/iris/rest/

Недокументированные API оставленные разработчиками присутствуют, например, на сайтах Мэра и Правительства Москвы www.mos.ru и портала Электронный бюджет budget.gov.ru из-за чего они плохо индексируются поисковыми системами. Сами API можно выявить просматривая запросы браузера к страницам сайтов.

Федеральная пробирная палата отдаёт все страницы на своём официальном сайте probpalata.ru из-за использования в качестве CMS движка для документооборота. Об этом я писал отдельно https://t.iss.one/begtin/3283, до сих пор удивляюсь этой истории.

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

Из всего этого я обращаю внимание на следующее:
1) Фактическая доступность данных часто выше чем наблюдаемая (документированная) доступность.
2) Системной работы над доступностью данных и програмнных интерфейсов из госсистем у нас в стране всё ещё нет. Нет аналогов платформ API как в других странах.
3) Конечно, API, не заменяет возможно массовой выгрузки (bulk download) данных. Иногда, даже при доступности такого API, чтобы выгрузить данные надо делать миллионы запросов к системе, что может занимать долгое время при медленном отклике от системы.

#openapi #api #data #govwebsites

В рубрике больших наборов данных архив Github в некоммерческом проекте Github Archive[1]. Ежедневно, ежечасно там собирается слепок данных о 20+ событиях по репозиториям в Github. Я писал о нём ранее и всегда актуально напомнить о нём потому что данные из этого архива присутствуют уже на нескольких крупных платформах.

Их слепок на декабрь 2020 года есть на Clickhouse [2] (проект Яндекса) и с ними можно работать онлайн через веб интерфейс [3] или API. Там же у них есть есть полный слепок этих данных в виде архива на 83GB, хороший тестовый набор живых данных для тех кто хочет работать с Clickhouse с большим статическим объёмом данных.

Доступ к данным из этого архива есть и через Google BigQuery [4], он появился ещ в 2016 году если не раньше, но, судя по описанию в каталоге BigQuery не обновлялся с 2019 года. Интересно обновляется ли набор Яндекса? Кстати, надо бы проверить.

Всё это возможно потому что Github предоставляет открытое API для доступа к данным. Его я использовал когда-то для анализа открытого кода органов власти [5]. Я этот анализ в первый раз проводил 5 лет назад и повторял потом несколько раз, но со временем делать несколько сотен тысяч запросов к API для получения статистики стало утомительно и планировал перейти на работу через API поверх GH архива, но для этого нужно чтобы данные там были актуальны.

А также не могу не напомнить презентацию исследователей [6] ещё с 2012 года о том как можно анализировать данные Github'а для расчёта разных метрик в привязке к языкам разработки, лицензиям, организациям и тд.

А также напомню что в России немного государственного кода на Github есть в репозитории [7] который я давно поддерживаю.

Ссылки:
[1] https://gharchive.org
[2] https://ghe.clickhouse.tech/
[3] https://gh-api.clickhouse.tech/play?user=play
[4] https://console.cloud.google.com/bigquery?p=bigquery-public-data&d=github_repos&page=dataset&project=test1-162811
[5] https://data.world/ibegtin/open-source-government-project
[6] https://www.igvita.com/slides/2012/bigquery-github-strata.pdf
[7] https://github.com/infoculture/awesome-gov-opensource-russia

#opensource #opendata #openapi #datasets

В рубрике интересных наборов данных OpenSanctions [1] проект о котором я уже писал в сентябре 2021 года [2] добавил интеграцию с Wikidata [3], одним из проектов фонда Викимедиа. В Wikidata собраны многие профили политиков и теперь эти профили импортируются в OpenSanctions. В пример, ожидаемо, приводят профиль Владимира Путина [4] и Дональда Трампа [5].

Проект активно развивается, раскрывает исходный код и данные в виде наборов данных и API. У него ограничивающая лицензия CC-BY 4.0 NC и коммерческое лицензирование для бизнес пользователей. С оговоркой что для журналистов и активистов лицензия CC BY 4.0 [6]. Это не вполне открытая лицензия, но учитывая плотный рынок due diligence и того что эти правила заданы на старте проекта, вполне приемлемая.

А то что теперь подгружаются данные из Wikidata даёт шанс что проект со временем превратится в большую базу PEPs (персон с политическим влиянием) по аналогии с LittleSis.org [7], но если LittleSis был с самого начала проектом ориентированным на США, то OpenSanctions довольно универсален.

Ссылки:
[1] https://www.opensanctions.org
[2] https://t.iss.one/begtin/3074
[3] https://www.opensanctions.org/articles/2022-01-25-wikidata/
[4] https://www.opensanctions.org/entities/Q7747/
[5] https://www.opensanctions.org/entities/Q22686/
[6] https://www.opensanctions.org/licensing/
[7] https://littlesis.org

#opendata #opengov #sanctions #datasets #openapi