Я регулярно писал о том что в России много открытых и общедоступных данных гос-ва через открытые 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

ТикТок анонсировали 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

В рубрике интересных проектов на данных, общественный проект OpenAQ (Open Air Quality) посвящённый, как вы догадались, качеству воздуха и инструментам его измерения. Они обновили свой навигатор по датчикам, теперь можно увидеть [1] их во многих странах, особенно в Евросоюзе и США. А также много датчиков в Чили, Австралии и в Таиланде.

Проект любопытный, с открытыми данными, интерфейсами для разработчиков и тд.

Ссылки:
[1] https://explore.openaq.org/

#opendata #datasets #API #airquality #lifequality

Элон Маск, по видимому, решил всё же разрушить экосистему Twitter'а и теперь Twitter API только за деньги [1]. Это повлияет на то что от соцсети отключаться очень многие сервисы, продукты и инструменты. Например, ранее Twitter был одной из самых лояльных к архивации социальных сетей и было несколько хороших инструментов по архивации контента. Теперь, похоже, как и Facebook, Instagram и другие в Twitter'е начнут ловить и блокировать разного рода ухищрения работать с их контентом через неофициальные API.

Не знаю из какой парадигмы в новой команде Twitter՛а исходили в этом решении, считали ли они бесплатных пользователей API нахлебниками, или просто то что надо монетизироваться любой ценой. К тому же есть примеры соц сетей вроде Facebook'а которая всегда была закрытой. Но по модели использования Twitter не Facebook и не Instagram. Его реально можно заменить на Mastodon, пусть и с неудобствами.

Ссылки։
[1] https://twitter.com/TwitterDev/status/1621026986784337922

#API #twitter #socialnetworks

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

- API.GOUV.FR - каталог API, стандарты и рекомендации Франции
- API.GOVERNMENT.AE - каталог API Объединённых Арабских эмиратов
- API.GOV.UK - каталог государственных API Великобритании
- API.GOV.AU - австралийский государственный стандарт предоставления API и каталог общедоступных API
- DEVELOPER.VIC.GOV.AU - портал для программистов (каталог API) правительства штата Виктория, Австралия
- DEVELOPER.TECH.GOV.SG - портал для разработчиков от Правительства Сингапура, API, документация и тд.

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

#opengov #government #api #opendata

В рубрике интересных наборов данных, сайт День сурка (Groundhog-Day.com) [1] где собрана база из 74 животных предсказателей длинной зимы или ранней весны, включая 43 сурка.

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

Ссылки:
[1] https://groundhog-day.com
[2] https://groundhog-day.com/api

#opendata #api

Подборка регулярного чтения про данные, технологии и не только:
- A Eulogy for Dark Sky, a Data Visualization Masterpiece [1] о визуализации данных в погодном приложении The Dark Sky для iOS и там же про наглядные решения контекстуализации данных. Я бы добавил этот термин в словарь "констектуализация данных" - это когда данные у Вас есть, но Вы подаёте их в том виде в каком они наиболее информативны и наглядны именно в том контексте/приложении/среде в которой их смотрят. А это приложение погоды отличный пример

- The Beginner's Guide to Databases [2] для новичков желающих разобраться в базах данных отличное руководство, оно не покрывает очень много чего, но одновременно даёт все нужные вводные для старта работы

- Meet Alpaca: Stanford University’s Instruction-Following Language Model that Matches GPT-3.5 Performance [3] новый интересный продукт как альтернатива GPT-3.5 под названием Альпака, главные отличия в открытости и меньших требованиях к железу. Открытый код главное преимущество [4]

- Finding Undocumented APIs [5] автор пишет про мою любимую тему, обнаружение недокументированных API. Я несколько выступлений и лекций проводил за эти годы про поиск и нахождение недокументированных API и ещё немало трюков могу рассказать о том как API находить, помимо перехвата запросов браузера к серверу. Так вот два самых очевидных способа часто срабатывающих:
* 1) Поискать API поиском Гугла на сайте явным образом вроде "REST API site:roskachestvo.gov.ru" и результат может удивить
* 2) Выяснить на каком программном продукте работает сайт и проверить не сохранилось ли в нём API идущее по умолчанию, у многих продуктов такое есть. Пример: Архив оцифрованных материалов Национальной электронной детской библиотеки РФ arch.rgdb.ru работает на движке DSpace, а у DSpace по умолчанию API доступно по ссылке /rest, проверяем, ага, вот и оно https://arch.rgdb.ru/rest/
Я могу не то что презентацию, а целый курс прочитать только по этой теме. Тем не менее ту статью рекомендую, часто информацию о API приходится выковыривать из сессий браузера.

- Data wrangling essentials: comparisons in JavaScript, Python, SQL, R, and Excel [6] сравнение функций преобразований данных в Excel, Python, R, SQL и Javascript. Полезно для тех кто вынужден пользоваться 2-3 языками/синтаксисами. Python там, правда, это не совсем Python, а конкретно Pandas, но текст от этого ценности не теряет.

Ссылки:
[1] https://nightingaledvs.com/dark-sky-weather-data-viz/
[2] https://technically.substack.com/p/the-beginners-guide-to-databases
[3] https://pub.towardsai.net/meet-alpaca-stanford-universitys-instruction-following-language-model-that-matches-gpt-3-5-490a38114a7e
[4] https://github.com/tatsu-lab/stanford_alpaca
[5] https://inspectelement.org/apis.html
[6] https://observablehq.com/@observablehq/data-wrangling-translations

#opensource #readings #api #data #guides

Про публикацию открытых государственных данных в России иногда, всё же, можно рассказать и что-то хорошее, хотя и нечасто. ФНС России обновило портал ФИАС [1] (Федеральной информационной адресной системы) в которой собраны сведения о более чем 32 миллионах зданий и сооружений и других связанных с ними объектов [2]. Система эта существует достаточно давно и доступ к ней есть через скачивание полных дампов, скачивание дельт изменений, API и СМЭВ. В общем это очень хороший пример того как правильно публиковать данные в открытом доступе если делать это на системной основе.

Я бы сказал что высокие оценки ФНС в части открытости [3] вполне оправданы, это редкое по нынешним временам системное раскрытие нужных бизнесу данных, причём данных референсных, составляющих базовую цифровую инфраструктуру. По сравнению с каким-нибудь Минэкономразвития России ФНС большие молодцы.

Особенно важно что в ведомстве понимают продолжают публиковать данные для массовой выгрузки в виде полных дампов, до 36GB в сжатом виде один дамп. К сравнению власти Санкт-Петербурга "похоронили" свой портал открытых данных ради портала API [4], что власти города конечно не красит.

Возвращаясь к ФИАС, конечно, даже подобная публикация данных неидеальна и её есть куда улучшить, особенно если смотреть не на форму, а на суть данных. А суть в том что это геоданные, без геоидентификаторов. Для того чтобы данные можно было применять в большой аналитической работе необходимо чтобы записи о муниципалитетах, улицах, зданиях и иных объектах содержали их геокоординаты, геоформу, включали Shape файлы, KML, GeoJSON, GML и все остальные геоформаты доступа к таким данным. Иначе говоря были бы интегрированы с данными Росреестра и доступны для выгрузки.

Другая важная сторона публикации данных в раскрытии их под свободными лицензиями. До сих пор на сайте ФИАС нет явно указанных, четких, не имеющих оговорок, условий использования этих данных. А чтобы использовать их в таких проектах как Wikidata или OSM лицензии имеют значение. Публикация данных под Creative Commons Zero выглядит наиболее логично.

Ссылки:
[1] https://fias.nalog.ru
[2] https://fias.nalog.ru/Statistics/
[3] https://t.me/ahminfin/568
[4] https://api.petersburg.ru

#opendata #geodata #russia #api #datasets

Я уже несколько раз писал о том что государства по всему миру продолжают создавать каталоги API, по аналогии с сайтами для разработчиков предлагаемыми в коммерческом секторе. Новые каталоги API в тот же список:
- Каталог административных API Японии http://api-catalog.e-gov.go.jp/ открыт 31 марта 2023 г., 39 API
- Государственные API в Малайзии https://www.mygdx.gov.my/en/landing-page/architecture?theme=first-theme 130 API
- Портал API налоговой службы Австралии https://apiportal.ato.gov.au, 6 API
- Портал госAPI ОАЭ https://api.government.ae 29 API
- Портал API налоговой службы Новой Зеландии https://portal.api.business.govt.nz 30 API
- Каталог API Литвы https://api.gov.lt около 40 API

А также предыдущий список из 6 каталогов API.

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

#openapi #opendata #api #government

В рубрике интересных продуктов по работе с API Metatype [1], платформа для декларативной разработки API, как сами создатели его позиционируют, продукт позволяющий проектировать API не будучи программистом. Внутри всё построено вокруг Typegraph [2], одновременно идеи и одноимённого пакета для Python с помощью которого описывается спецификация API. У продукта своя система типов, своя система управления доступа к ресурсам, интеграция с Prism, Deno и другими инструментами и ещё много чего.

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

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

Ссылки:
[1] https://metatype.dev
[2] https://metatype.dev/docs/concepts/typegraph
[3] https://metatype.dev/docs/guides/importing-openapi-definitions

#opensource #api #datatools

Открытые данные в России о которых многие не знают,

- Открытые данные ГУАП [1] ГУАП - это Санкт-Петербургский государственный университет аэрокосмического приборостроения, а на сайте у них есть раздел с API с информацией о ВУЗе. Есть внятное API, для полной открытости нехватает условий использования.
- Открытые API для сервисов Санкт-Петербурга [2] категорически малоизвестный портал Санкт-Петербурга с их официальными API к городским информационным системам. Развивают они его, почему-то, параллельно порталу открытых данных, а не совместно. Как и во многих других случаях, "забывают" написать про условия использования, но сами данные есть.
- Геопортал СВКНИИ ДВО РАН [3] и другие их ГИС сервисы [4] с картами и слоями карт по Дальнему востоку. Включает доступ к данным через открытое API сервера ArcGIS

Ссылки:
[1] https://api.guap.ru/data/
[2] https://api.petersburg.ru
[3] http://hags.north-east.ru:8080/geoportal/catalog/main/home.page
[4] http://www2.neisri.ru/index.php/ru/%D0%B3%D0%B8%D1%81-%D1%81%D0%B5%D1%80%D0%B2%D0%B8%D1%81%D1%8B.html

#opendata #datasets #api #russia #geodata

Подборка полезных ссылок про данные, технологии и не только:
- drawdb [1] визуальное проектирование баз данных и SQL генератор на базе draw.io. Открытый код на JS, лицензия MIT. Выглядит очень даже неплохо
- quickwit [2] альтернатива Datadog и подобным сервисам, но с открытым кодом. Реализует поисковую систему для наблюдаемости процессов. Лицензия AGPL или коммерческая, для бизнеса. Выглядит как минимум интересно, очередной пример YAML программирования, огромного числа файлов для настройки.
- paradedb [3] альтернатива Elasticsearch на базе Postgres, обещают что внутри файлы parquet и многократно выше скорость аналитических запросов. Обещают облачный сервис, пока доступен open source продукт. Лицензия AGPL для всех и коммерческая для бизнеса.
- traefik [4] реверсный прокси для HTTP для развертывания микросервисов и API, похож на альтернативу Kong и Tyk. Открытый код под MIT лицензией

Ссылки:
[1] https://github.com/drawdb-io/drawdb
[2] https://github.com/quickwit-oss/quickwit
[3] https://github.com/paradedb/paradedb
[4] https://github.com/traefik/traefik

#opensource #data #datatools #api #dataviz

В рубрике *как это устроено в России* о том что должно было бы быть открытыми данными, но ими не является. У почти всех российских регионов есть инвестиционные карты. Это, либо отдельные геопорталы, либо разделы на инвестиционных порталах которые точно есть у всех. Например, инвестиционная карта Курганской области [1] или инвестиционная карта Волгоградской области [2]. Можно убедиться что на них есть слои карт и их от десятков до полутора сотен. Другие подобные инвестиционные карты легко находятся по ссылкам с портала инвестпроектов Минэка РФ [3].

Что можно о них сказать? Они все содержат то или иное недокументированное API. Там всего несколько вендоров геоинформационных систем и у них всё довольно стандартизировано. При очень небольших усилиях то же Минэкономразвития могло бы добавить на нацпортал открытых данных более 1000 датасетов и/или стандартизированных API по стандарту WFS. Очень небольшие расходы на всё это нужно, я бы даже сказал мизерные, а вероятность что эти данные были бы небесполезны, конечно, есть.

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

Кстати, к примеру в Казахстане национальный геопортал [4] сделан довольно прилично и там публикуют открытые данные. Не со всех региональных геопорталов они их агрегируют, но и 571 слой карт - это неплохо.

Возвращаясь к ситуации в РФ. Мне бы вот, например, хотелось агрегировать данные с российских геопорталов в Dateno и даже недокументированность их API решается. У типовых систем, типовые API. Но тут уже другое ограничение, российские госсайты в большинстве своём недоступны с зарубежных IP адресов. Краулер работающий не изнутри страны не сможет достучасться до большого числа сайтов. Это, конечно, тоже решается, но требует больше времени и усилий.

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

Ссылки:
[1] https://invest45.ru/investmap
[2] https://investmap.volgograd.ru
[3] https://invest.economy.gov.ru
[4] https://map.gov.kz

#opendata #data #geodata #russia #api

Нашёл презентацию Paul Bradshaw о недокументированных API веб-сайтов и как их искать [1]. Рецепты у него довольно простые:
- используйте Chrome Developers Tools и аналог в Firefox
- изучайте структуру ссылок и XHR типы запросов
- учитесь декодировать параметры

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

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

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

Второй значимый инструмент - это "типовые", но недокументированные API многих программных продуктов. В первую очередь типовые API CMS.

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

Но, опять же, это всё полезно, в первую очередь журналистам, OSINT'щикам и хакерам. Для других задач нужно куда реже.

Ссылки:
[1] https://github.com/paulbradshaw/undocumentedapis/blob/main/Undocumented%20APIs.pdf

#api #readings #datajournalism

Подборка ссылок на продукты публикации датасетов для API и аналитики:

С открытым кодом:
- SQLite Studio [1] быстро первращает базы SQLite в веб интерфейс. Можно смотреть структуру таблиц и делать запросы. А также есть демо [2]. По ощущениям очень простой и удобный для этой небольшой задачи.
- Datasette [3] хорошо известный в узких кругах продукт, очень быстро превращающий датасеты в веб интерфейс. Умеет в разные данные, разные API, разные интерфейсы и куча расширений. Когда хочется конструктор и разного
- CSVBase [4] простой до безобразия для превращения CSV файлов в API. Внутри всё Python, одновременно и сервис для публикации данных онлайн для тех кто очень хочет делать это за деньги
- APIReady [5] написанный мной 11 лет назад очень простой движок по превращению CSV файлов в API. Честно говоря с той поры я его даже не развивал, просто как демонстрация самой идеи.
- APICrafter [6] тоже написанная мной утилита по публикации API к базам MongoDB. Развитие APIReady и необходимость поскольку MongoDB по умолчанию не давало и не даёт приемлимое API в их Community Server. Только в облачном сервисе есть уже что-то удобное. Всё на Python, управляется развесистыми YAML конфигами которые строятся автоматически на основе просканированных баз данных [7]

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

А я через какое-то время напишу про то какие есть бесплатные и коммерческие, не open source, онлайн инструменты делиться датасетами.

Ссылки:
[1] https://github.com/frectonz/sqlite-studio
[2] https://sqlite-studio.frectonz.io/
[3] https://datasette.io/
[4] https://github.com/calpaterson/csvbase
[5] https://github.com/ivbeg/apiready
[6] https://github.com/apicrafter/apicrafter
[7] https://github.com/apicrafter/apicrafter/blob/main/examples/rusregions/apicrafter.yml


#opensource #datatools #data #api

Поработав в избытке с данными и со смыслом публикации разной статистики, в какой-то момент напишу лонгрид на тему того как хорошо и как плохо публикуют статистику в разных странах и территориях, а пока в виде выжимки накопленные мысли. Поскольку я на эту тему несколько раз уже писал в таком формате, то где-то могу и повторяться:
1. Унификация. Хорошо опубликованные статистические данные практически всегда хорошо унифицированы. У них есть так называется code lists, стандартизированные справочники территорий, видов деятельности и тд. Они унифицированы в единые форматы и с ними можно работать унифицированным образом с любым индикатором. Можно сказать что почти во всех развитых странах базы индикаторов доступны таким вот унифицированным образом. В современных национальных системах управления статпоказателями такая унификация почти всегда увязана на внедрение стандарта SMDX от 2 до 3 версии.
2. Массовая выгрузка. На английском языке она звучит как bulk download, возможность выкачать базу индикаторов целиком с минимальным объёмом усилий. Может выглядеть как 1-2 zip файла со всем содержимым, так делают в FAO, или тысячи csv/csv.gz файлов по одному по каждому индикатору, со всем содержимым индикатора и каталогом ссылок на все файлы. Так делают в Евростате и ILO.
3. Универсальный поиск. Статистические продукты бывают разные, иногда в разных информационных системах, в разных форматах, включая архивные статсборники. Универсальный поиск позволяет искать по ним всем. Начиная с интерактивных таблиц и заканчивая архивными материалами и даёт возможность найти нужные данные в нужном формате за заданный период.
4. Открытые данные по умолчанию. Практика альтернативная возможности массовой выгрузки когда статистические показатели с самого начала публикуются на стандартизированном портале открытых данных с уже имеющимся API этого портала и доступны для выгрузки через это стандартное API. Например, так делают в ЦБ Бразилии с дата порталом на базе CKAN и в Катаре с их госпорталом открытых данных на базе OpenDataSoft
5. Экспорт данных и доступ через API. Не просто экспорт в Excel, а как минимум выбор из 5-6 форматов начиная от самых простых вроде csv, продолжая форматами для Stata и других продуктов, автогенерацией кода для Python или R и наличию SDK к хотя бы паре популярных языков разработки для доступа к данным. У многих европейских порталов статданных есть неофициальные SDK, в других вроде статданных Гонконга автоматически генерируется код на Python на страницах интерактивных таблиц.
6. Технологичность. Тут можно было бы добавить и соответствие лучшим дата-инженерным практикам. Это включает: доступность данных в форматах parquet, документация к API по стандарту OpenAPI, общедоступные примеры работы через Postman или аналоги, общая документация в стиле технологических проектов с интерактивными примерами, а не в форме отчетности подрядчика по контракту в PDF. Технологичность - это про доступ и про документацию, как ни странно, но это самое актуальное для статданных.

#opendata #api #statistics #thoughts

Полезная статья о которой хочется написать отдельно Deliver Your Data as a Product, But Not as an Application [1], она требует авторизации на Medium. но почитать её стоит.

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

Собственно в статье отсылка к хорошо известной книге Principles of Data-Oriented Programming [2] и следующим принципам:
- Отделяйте код (поведение) от данных;
- Рассматривайте данные как неизменные (immutable)
- Отделяйте схемы/структуры данных от их представления
- Представляйте данные с помощью простых структур данных

Статья написана с прицелом на OOP разработчиков которые хотели бы понять отличия программирования с данными и без.

Идея отделения данных от кода, в принципе, не нова. Лично я при проектировании разных ИТ продуктов за последние годы придерживался принципа API-first, то есть вначале у тебя появляется API, а потом уже разные интерфейсы поверх него.

В случае с данными оно разделяется на 2+ сервиса API. Первый сервис API для бизнес логики/кода, второй для данных, как правило Data API отдающее JSON или Protocol Buffers. Реальные системы могут иметь больше вариаций по разделению и компонентам, но бизнес логика и доступ к данным разделять стоит всегда.

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

И это, конечно, относится не только к данным статистики.

Ссылки:
[1] https://towardsdatascience.com/deliver-your-data-as-a-product-but-not-as-an-application-99c4af23c0fb
[2] https://blog.klipse.tech/dop/2022/06/22/principles-of-dop.html

#itarchitecture #datasaproduct #data #api