Wir dokumentieren Deutschland
В рубрике как это работает у них проект bund.de [1] и его основательница Лилит Виттманн. Лилит с волонтерами занимается тем что находит недокументированные государственные API, документируют их и выкладывают документацию на сайт bund.de помогая повторному использованию данных. Фактически выполняют за правительство Германии ту работу которую они должны делать сами. Например, во Франции этим занимается государственная компания Etalab создавшая каталог api.gouv.fr
Из свежих работ Лилит и её команды - это превращение торгового реестра Германии (аналога российского ЕГРЮЛа) в машиночитаемую форму. С 1 августа в Германии он стал "открытым", но лишь частично, не в виде открытых данных. Она пишет у себя в блоге о том как они обрабатывают эти данные и собирают набор данных [2]. В общий доступ они его не выкладывают, но можно заполнить форму и получить их для исследовательских целей (это около 100ГБ).
То что делает Лилит и команда волонтеров - это то что волонтеры в Германии, Великобритании, России и т.д. делали ещё 10 лет назад. До появления национальных порталов открытых данных мы устраивали хакатоны и конкурсы по извлечению данных из открытых источников и превращению их в открытые данные.
Потом стали появлятся госинициативы, но не все из них были достаточно системы чтобы решить вопросы с доступом к данным, поэтому история ходит по кругу.
В прошлом году наша команда собрала более 100 открытых точек подключения к открытым недокументированным API информационных систем в России и сделать аналог bund.de или api.gouv.fr это несложно и быстро. Но время ещё, видимо, не пришло.
Кстати, Лилит Виттманн известна тем что когда-то вычислила секретное германское ведомство с помощью Airtag [3]. Так что боевая девушка, думаю что ещё станет депутатом Бундестага когда-нибудь или сделает политическую карьеру.
Ссылки:
[1] https://bund.de
[2] https://lilithwittmann.medium.com/bund-dev-wir-befreien-das-handelsregister-8168ad46b4e
[3] https://t.me/begtin/3473
#opendata #germany #opengov #api
В рубрике как это работает у них проект bund.de [1] и его основательница Лилит Виттманн. Лилит с волонтерами занимается тем что находит недокументированные государственные API, документируют их и выкладывают документацию на сайт bund.de помогая повторному использованию данных. Фактически выполняют за правительство Германии ту работу которую они должны делать сами. Например, во Франции этим занимается государственная компания Etalab создавшая каталог api.gouv.fr
Из свежих работ Лилит и её команды - это превращение торгового реестра Германии (аналога российского ЕГРЮЛа) в машиночитаемую форму. С 1 августа в Германии он стал "открытым", но лишь частично, не в виде открытых данных. Она пишет у себя в блоге о том как они обрабатывают эти данные и собирают набор данных [2]. В общий доступ они его не выкладывают, но можно заполнить форму и получить их для исследовательских целей (это около 100ГБ).
То что делает Лилит и команда волонтеров - это то что волонтеры в Германии, Великобритании, России и т.д. делали ещё 10 лет назад. До появления национальных порталов открытых данных мы устраивали хакатоны и конкурсы по извлечению данных из открытых источников и превращению их в открытые данные.
Потом стали появлятся госинициативы, но не все из них были достаточно системы чтобы решить вопросы с доступом к данным, поэтому история ходит по кругу.
В прошлом году наша команда собрала более 100 открытых точек подключения к открытым недокументированным API информационных систем в России и сделать аналог bund.de или api.gouv.fr это несложно и быстро. Но время ещё, видимо, не пришло.
Кстати, Лилит Виттманн известна тем что когда-то вычислила секретное германское ведомство с помощью Airtag [3]. Так что боевая девушка, думаю что ещё станет депутатом Бундестага когда-нибудь или сделает политическую карьеру.
Ссылки:
[1] https://bund.de
[2] https://lilithwittmann.medium.com/bund-dev-wir-befreien-das-handelsregister-8168ad46b4e
[3] https://t.me/begtin/3473
#opendata #germany #opengov #api
У Postman вышел их ежегодный обзор 2022 State of the API Report [1] составленный через опрос разработчиков пользующихся их платформой и схожий с исследованиями JetBrains.
Исследование полезное, много графиков, большая выборка, много чего любопытного. Конечно, с оговоркой что они делают акценты там где их собственный продукт посильнее, а некоторые темы вроде предпочтений по корпоративной интеграции или языки разработки охватывают мало или недостаточно.
Полезно будет, в первую очередь, тем кто выбирает приоритеты в изучении новых технологий.
Ссылки:
[1] https://www.postman.com/state-of-api/how-to-share-the-report/
#api #studies #research #postman
Исследование полезное, много графиков, большая выборка, много чего любопытного. Конечно, с оговоркой что они делают акценты там где их собственный продукт посильнее, а некоторые темы вроде предпочтений по корпоративной интеграции или языки разработки охватывают мало или недостаточно.
Полезно будет, в первую очередь, тем кто выбирает приоритеты в изучении новых технологий.
Ссылки:
[1] https://www.postman.com/state-of-api/how-to-share-the-report/
#api #studies #research #postman
Я довольно много писал про недокументированные 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
Так вот скажу что этих самых недокументированных 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
Telegram
Ivan Begtin
Продолжая тему недокументированных государственных API приведу ещё один живой пример с некоторыми техническими подробностями.
Вот, в Санкт-Петербурге есть портал бюджетных инициатив граждан [1]. В целом неплохой, современно выглядящий и с примерно 29 тысячами…
Вот, в Санкт-Петербурге есть портал бюджетных инициатив граждан [1]. В целом неплохой, современно выглядящий и с примерно 29 тысячами…
Конгресс США официально открыл API к базе законопроектов [1], а также опубликовал исходный код с примерами работы с этим API [2].
Важно что данных там отдаётся много, фактически не просто законопроекты и законы, а весь их цифровой след, со всеми поправками, голосованиями и тд.
Удивительно скорее то что у них это заняло так много времени, поскольку общественные базы данных и API к данным конгресса существуют давно [3]. Но, как бы то ни было, значит число общественных проектов на этих данных только вырастет.
Ссылки:
[1] https://blogs.loc.gov/law/2022/09/introducing-the-congress-gov-api/
[2] https://github.com/LibraryOfCongress/api.congress.gov/
[3] https://projects.propublica.org/api-docs/congress-api/
#opendata #us #congress #api #legislation
Важно что данных там отдаётся много, фактически не просто законопроекты и законы, а весь их цифровой след, со всеми поправками, голосованиями и тд.
Удивительно скорее то что у них это заняло так много времени, поскольку общественные базы данных и API к данным конгресса существуют давно [3]. Но, как бы то ни было, значит число общественных проектов на этих данных только вырастет.
Ссылки:
[1] https://blogs.loc.gov/law/2022/09/introducing-the-congress-gov-api/
[2] https://github.com/LibraryOfCongress/api.congress.gov/
[3] https://projects.propublica.org/api-docs/congress-api/
#opendata #us #congress #api #legislation
Library of Congress Blogs
Introducing the Congress.gov API
The beta Congress.gov API launched in September 2022.
В рубрике интересных наборов данных открытое API проекта Metaculus [1] по краудсорсингу предсказаний.
Проект позволяет регистрировать предсказания, собирать оценки от пользователей и измерять точность предсказаний.
Все эти сведения доступны в формате JSON через API проекта [2].
Всего в проекте более 1 миллиона предсказаний [3] что очень даже немало.
Для полного счастья нехватает только дампов данных, но может быть авторы добавят их в будущем.
Ссылки:
[1] https://www.metaculus.com
[2] https://www.metaculus.com/api2/
[3] https://twitter.com/fianxu/status/1569537658103431168
#opendata #predictions #datasets #API
Проект позволяет регистрировать предсказания, собирать оценки от пользователей и измерять точность предсказаний.
Все эти сведения доступны в формате JSON через API проекта [2].
Всего в проекте более 1 миллиона предсказаний [3] что очень даже немало.
Для полного счастья нехватает только дампов данных, но может быть авторы добавят их в будущем.
Ссылки:
[1] https://www.metaculus.com
[2] https://www.metaculus.com/api2/
[3] https://twitter.com/fianxu/status/1569537658103431168
#opendata #predictions #datasets #API
В рубрике полезных инструментов для публикации данных roapi [1] фреймворк по публикации статических наборов данных, написан на Rust, а внутри использует Apache Arrow и Datafusion. Автор описывает его как то что не надо написать ни строчки кода что, не совсем так, вместо кода надо писать конфиг на YAML, но даже при этом возможности весьма немалые. Фактически, из коробки, получаем REST API, GraphQL и SQL (через HTTPS и протокол Postgres Wire) для доступа к выбранному набору данных.
Можно делать API на основе файлов CSV, JSON, NDJSON (JSON lines), Parquet, баз SQLite и MySQL.
Пока это лучший движок для таких задач, по крайней мере по описанию, конечно, ещё надо интенсивно тестировать.
Я помню как ещё 10 лет назад командой data.gov публиковался простой PHP скрипт csv-to-api [2], а я лет 9 назад писал простой движок apiready [3] генерировавший чуть более продвинутое API выделяя отдельно справочные значения.
Через много лет лично я пришёл к архитектуре:
1) Положи все данные в СУБД
2) Используй обертку вокруг данных в СУБД
и написал и опубликовал движок apicrafter [4] позволяющий такую обёртку делать вокруг базы в MongoDB.
Но, возможно, roapi - это лучший выбор из имеющихся для табличных данных. Потому что поддержка сразу многих протоколов для доступа к данным имеет значение и упрощает доступ из разных приложений и в разных сценариях использования.
Ссылки:
[1] https://github.com/roapi/roapi
[2] https://github.com/project-open-data/csv-to-api
[3] https://github.com/ivbeg/apiready
[4] https://github.com/apicrafter/apicrafter
#datatools #api #openapi
Можно делать API на основе файлов CSV, JSON, NDJSON (JSON lines), Parquet, баз SQLite и MySQL.
Пока это лучший движок для таких задач, по крайней мере по описанию, конечно, ещё надо интенсивно тестировать.
Я помню как ещё 10 лет назад командой data.gov публиковался простой PHP скрипт csv-to-api [2], а я лет 9 назад писал простой движок apiready [3] генерировавший чуть более продвинутое API выделяя отдельно справочные значения.
Через много лет лично я пришёл к архитектуре:
1) Положи все данные в СУБД
2) Используй обертку вокруг данных в СУБД
и написал и опубликовал движок apicrafter [4] позволяющий такую обёртку делать вокруг базы в MongoDB.
Но, возможно, roapi - это лучший выбор из имеющихся для табличных данных. Потому что поддержка сразу многих протоколов для доступа к данным имеет значение и упрощает доступ из разных приложений и в разных сценариях использования.
Ссылки:
[1] https://github.com/roapi/roapi
[2] https://github.com/project-open-data/csv-to-api
[3] https://github.com/ivbeg/apiready
[4] https://github.com/apicrafter/apicrafter
#datatools #api #openapi
GitHub
GitHub - roapi/roapi: Create full-fledged APIs for slowly moving datasets without writing a single line of code.
Create full-fledged APIs for slowly moving datasets without writing a single line of code. - roapi/roapi
В рубрике регулярных напоминаний не могу не рассказать про сервис оценки простоты языка Простой язык (plainrussian.ru) [1] который я много лет назад сделал и передал в Инфокультуру при её создании.
Это очень простой сервис который на вход получает текст на русском языке и на выходе выдает его сложность в баллах где баллы - это число лет учёбы которые необходимо пройти чтобы понимать этот текст. Например, 11.97 баллов - это, примерно, 1-3 курс ВУЗа, а то есть около 12 лет учебы.
При том что анализ текстов - это, довольно сложная задача в общем понимании, но в данном случае было целью сделать как можно более доходчивый сервис для всех и каждого.
У сервиса есть API [2] и открытый код [3]. Код не обновлялся примерно лет 10, во всяком случае та его часть которая использовалась для расчета формул.
И вот в формулах и было самое сложное и интересное. Алгоритмы сервиса работают на тех же принципах что формулы читабельности текста созданные изначально для английского языка: Flesch-Kincaid, SMOG, Automatic Readability Index и другие. В их основе подсчет числа слов на предложение, среднее число слогов на слово, среднее число букв на слово, число редких слов и так далее.
Когда я задумал впервые сделать такой же алгоритм для русского языка, то столкнулся что для него формул нет. Их надо было, или придумать с нуля, или адаптировать коэффициенты английского языка для русского. В итоге я пошёл вторым путем, но составление собственного языкового корпуса с нужной мне статистикой тогда казалось длительной и неэффективной задачей, поэтому коэффициенты были подобраны грубым перебором за несколько недель-месяцев (?) нескольких десятков миллиардов вариантов коэффициентов на обучающей предразмеченной выборке из пары десятков текстов литературы для внеклассного чтения.
Сейчас всё это можно было бы решить гораздо быстрее, с современными ML инструментами расчеты были бы быстрее чем их проектирование.
Особенность итогового результата в том что тексты простые/бытовые он идентифицирует хорошо, а вот тексты юридические или нормативно-государственные оценивает всегда как особо сложные.
По прежнему сайт остаётся одним из тех проектов которым регулярно пользуются несмотря на его неизменность в последние годы.
Ссылки:
[1] https://plainrussian.ru/
[2] https://github.com/ivbeg/readability.io/wiki/API
[3] https://github.com/infoculture/plainrussian/tree/master/textmetric
#plainrussian #russian #language #api #tools
Это очень простой сервис который на вход получает текст на русском языке и на выходе выдает его сложность в баллах где баллы - это число лет учёбы которые необходимо пройти чтобы понимать этот текст. Например, 11.97 баллов - это, примерно, 1-3 курс ВУЗа, а то есть около 12 лет учебы.
При том что анализ текстов - это, довольно сложная задача в общем понимании, но в данном случае было целью сделать как можно более доходчивый сервис для всех и каждого.
У сервиса есть API [2] и открытый код [3]. Код не обновлялся примерно лет 10, во всяком случае та его часть которая использовалась для расчета формул.
И вот в формулах и было самое сложное и интересное. Алгоритмы сервиса работают на тех же принципах что формулы читабельности текста созданные изначально для английского языка: Flesch-Kincaid, SMOG, Automatic Readability Index и другие. В их основе подсчет числа слов на предложение, среднее число слогов на слово, среднее число букв на слово, число редких слов и так далее.
Когда я задумал впервые сделать такой же алгоритм для русского языка, то столкнулся что для него формул нет. Их надо было, или придумать с нуля, или адаптировать коэффициенты английского языка для русского. В итоге я пошёл вторым путем, но составление собственного языкового корпуса с нужной мне статистикой тогда казалось длительной и неэффективной задачей, поэтому коэффициенты были подобраны грубым перебором за несколько недель-месяцев (?) нескольких десятков миллиардов вариантов коэффициентов на обучающей предразмеченной выборке из пары десятков текстов литературы для внеклассного чтения.
Сейчас всё это можно было бы решить гораздо быстрее, с современными ML инструментами расчеты были бы быстрее чем их проектирование.
Особенность итогового результата в том что тексты простые/бытовые он идентифицирует хорошо, а вот тексты юридические или нормативно-государственные оценивает всегда как особо сложные.
По прежнему сайт остаётся одним из тех проектов которым регулярно пользуются несмотря на его неизменность в последние годы.
Ссылки:
[1] https://plainrussian.ru/
[2] https://github.com/ivbeg/readability.io/wiki/API
[3] https://github.com/infoculture/plainrussian/tree/master/textmetric
#plainrussian #russian #language #api #tools
Telegram
Инфокультура
Новости Информационной культуры. https://infoculture.ru
Я регулярно писал о том что в России много открытых и общедоступных данных гос-ва через открытые API, нигде не документированные, но существующие [1]. Но это, конечно же, не только российская специфика и очень многие сайты создаются по архитектуре Jamstack [2] и данные подгружаются через вызовы REST API или запросы GraphQL.
Такой подход имеет много преимуществ при доступе с мобильных устройств и для ускорения настольных браузеров, но имеет один важнейший недостаток - контент сайтов выпадает из архивации. Поэтому, к примеру, многие данные с сайта Мэрии Москвы (mos.ru) не архивируются, они доступны только через API и не присутствуют в форме HTML кода.
А вот выдался и наглядный пример из другой страны. Относительно недавно обновился официальный сайт органов власти Республики Казахстан (www.gov.kz) [3]. Выглядит он сейчас весьма прилично, быстро грузится и обладает многими полезными характеристиками: удобным поиском, чёткой структурой и быстрым откликом.
И, как Вы уже догадались новый сайт Правительства Казахстана сделан именно таким. Почти весь контент отдаётся через GraphQL или REST API. Например, документы Министерства цифрового развития, инноваций и аэрокосмической промышленности Республики Казахстан [4] возвращаются именно через такое API [5]. Аналогично новости, события, вакансии, госуслуги, жизненные ситуации и тд. по всем организациям на этом портале.
Казалось бы почему бы не публиковать их сразу как открытые данные? Но это другой вопрос. Сейчас ничто не мешает желающим превращать данные из API с этого сайта/этой госсистемы в общедоступные наборы данных.
Но, конечно, это никак не поможет тому что сайт gov.kz будет хуже индексироваться поисковыми системами, что архивы материалов в Интернет-архиве (archive.org) будут не полны и что если теперь делать архивную копию этого сайта, то надо учитывать ещё и его API.
Ссылки:
[1] https://t.me/begtin/3303
[2] https://jamstack.org/
[3] https://www.gov.kz
[4] https://www.gov.kz/memleket/entities/mdai?lang=ru
[5] https://www.gov.kz/api/v1/public/content-manager/documents?sort-by=created_date:DESC&projects=eq:mdai&page=1&size=10
#opendata #opengov #digitalpreservation #webarchives #api #government #kazakhstan
Такой подход имеет много преимуществ при доступе с мобильных устройств и для ускорения настольных браузеров, но имеет один важнейший недостаток - контент сайтов выпадает из архивации. Поэтому, к примеру, многие данные с сайта Мэрии Москвы (mos.ru) не архивируются, они доступны только через API и не присутствуют в форме HTML кода.
А вот выдался и наглядный пример из другой страны. Относительно недавно обновился официальный сайт органов власти Республики Казахстан (www.gov.kz) [3]. Выглядит он сейчас весьма прилично, быстро грузится и обладает многими полезными характеристиками: удобным поиском, чёткой структурой и быстрым откликом.
И, как Вы уже догадались новый сайт Правительства Казахстана сделан именно таким. Почти весь контент отдаётся через GraphQL или REST API. Например, документы Министерства цифрового развития, инноваций и аэрокосмической промышленности Республики Казахстан [4] возвращаются именно через такое API [5]. Аналогично новости, события, вакансии, госуслуги, жизненные ситуации и тд. по всем организациям на этом портале.
Казалось бы почему бы не публиковать их сразу как открытые данные? Но это другой вопрос. Сейчас ничто не мешает желающим превращать данные из API с этого сайта/этой госсистемы в общедоступные наборы данных.
Но, конечно, это никак не поможет тому что сайт gov.kz будет хуже индексироваться поисковыми системами, что архивы материалов в Интернет-архиве (archive.org) будут не полны и что если теперь делать архивную копию этого сайта, то надо учитывать ещё и его API.
Ссылки:
[1] https://t.me/begtin/3303
[2] https://jamstack.org/
[3] https://www.gov.kz
[4] https://www.gov.kz/memleket/entities/mdai?lang=ru
[5] https://www.gov.kz/api/v1/public/content-manager/documents?sort-by=created_date:DESC&projects=eq:mdai&page=1&size=10
#opendata #opengov #digitalpreservation #webarchives #api #government #kazakhstan
Telegram
Ivan Begtin
Я регулярно пишу о том что у многих информационных систем и иных публичных ресурсов государства есть много недокументированных API. Причём эти API имеют, как правило, две истории происхождения:
a) API сделанные разработчиками для работы каких-то компонентов…
a) API сделанные разработчиками для работы каких-то компонентов…
ТикТок анонсировали API для доступа к их аналитике исследователям/учёным [1]. Сами ссылки на API и форма запроса доступа, видимо, появятся позже, а сейчас с ними работают представители их Content and Safety Advisory Councils (общественных советов по контенту).
Ссылки:
[1] https://newsroom.tiktok.com/en-us/an-update-on-our-platform-api-for-researchers
#api #tiktok #transparency #data
Ссылки:
[1] https://newsroom.tiktok.com/en-us/an-update-on-our-platform-api-for-researchers
#api #tiktok #transparency #data
Newsroom | TikTok
An update on our platform API for researchers
Earlier this year we announced the development of research APIs as part of our commitment to bring transparency to how our platform operates. We support independent research and have spent the last fe
В рубрике интересных проектов на данных, общественный проект OpenAQ (Open Air Quality) посвящённый, как вы догадались, качеству воздуха и инструментам его измерения. Они обновили свой навигатор по датчикам, теперь можно увидеть [1] их во многих странах, особенно в Евросоюзе и США. А также много датчиков в Чили, Австралии и в Таиланде.
Проект любопытный, с открытыми данными, интерфейсами для разработчиков и тд.
Ссылки:
[1] https://explore.openaq.org/
#opendata #datasets #API #airquality #lifequality
Проект любопытный, с открытыми данными, интерфейсами для разработчиков и тд.
Ссылки:
[1] https://explore.openaq.org/
#opendata #datasets #API #airquality #lifequality