Свежий любопытный BI(?) проект MotherDuck Data App Generator [1] который позволяет на основе датасета в DuckDB генерировать дата приложение. Приложение с открытым кодом, но зависит от инфраструктуры MotherDuck.

Хотя они и называют его Data App Generator, тут надо быть честными, это такой недо-BI, по крайней мере в текущей форме и примерах по генерации дашбордов.

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

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

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

Ссылки:
[1] https://motherduck.com/blog/data-app-generator/

#opensource #duckdb #data #dataapps #startups

Неплохая подборка примеров проектов в том что называют Rewrite Bigdata in Rust (RBiR) [1], а то есть по переписыванию функциональности и отдельных продуктов с открытым кодом на Rust, вместо Python или Java.

Подборка хорошая и примеры там все как один вполне применимые к инфраструктуре практически любого дата-продукта.

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

Ссылки:
[1] https://xuanwo.io/2024/07-rewrite-bigdata-in-rust/

#opensource #rust #bigdata #datatools #data

Симпатичный продукт для тетрадок работы с данными Briefer [1], обещают поддержку Python и SQL, генерацию Data apps, ИИ помощника и построение дашбордов.

Поддерживаются Y Combinator и даже с открытым кодом и ещё интереснее их рассказ о том почему они с открытым кодом и каково это открывать код когда тебя финансируют венчурный фонд [3]. Ожидаемо там про выбор AGPL лицензии.

Ссылки:
[1] https://briefer.cloud/
[2] https://github.com/briefercloud
[3] https://briefer.cloud/blog/posts/launching-briefer-oss/

#opensource #datatools #data

А помните я писал о том что хорошо бы многим продуктам иметь SQL интерфейс для продвинутых пользователей? Вместо API, в дополнение API Так вот всё больше такого появляется. К примеру? Hugging Face совсем недавно добавили SQL консоль.

Внутри там всё на базе DuckDB WASM и выглядит как весьма полезная фича.

К каким сервисам ещё бы очень хотелось иметь SQL консоли?
1. Всё что касается веб аналитики. Чтобы не тягать всё время из API и чтобы не испытывать мучения с их веб интерфейсами.
2. К почте, вот просто к корпоративной почте.
3. К любым другим массовым онлайн сервисам (?)


#sql #datatools #data

Полезное чтение про данные, технологии и не только:
- The Modern CLI Renaissance [1] о том как инструменты командной строки переживают ренессанс будучи переписанными, в основном, на Rust. Тоже наблюдаю эту картину и что тут скажешь, хорошо что это происходит.
- Nvidia and Oracle team up for Zettascale cluster: Available with up to 131,072 Blackwell GPUs [2] полным ходом гонка ИИ кластеров. Oracle и NVIDIA запускают в начале 2025 г. кластер на 2.4 зетафлопса, сравнивать сложно, это просто много
- Android apps are blocking sideloading and forcing Google Play versions instead [3] Google начали внедрять в андроид функцию установки приложения через Google Play если ты пытаешься поставить его из другого источника. То есть если ты из внешнего магазина загружаешь приложение которое есть в Google Play то тебя обязывают ставить то что в Google Play.
- Google will now link to The Internet Archive to add more context to Search results [4] Google теперь даёт ссылки в результатах поиска на Интернет Архив вместо их собственного кэша, на который они ранее ссылки удалили. Надеюсь они при этом дали денег Интернет Архиву, потому что как бы их не за ддосили.

Ссылки:
[1] https://gabevenberg.com/posts/cli-renaissance/
[2] https://www.tomshardware.com/tech-industry/artificial-intelligence/nvidia-and-oracle-team-up-for-zettascale-cluster-available-with-up-to-131072-blackwell-gpus
[3] https://arstechnica.com/gadgets/2024/09/android-now-allows-apps-to-block-sideloading-and-push-a-google-play-version/
[4] https://9to5google.com/2024/09/11/google-search-internet-archive-wayback-machine/

#software #data #google #android #readings

Полезные ссылки про данные, технологии и не только:
- Governing data products using fitness functions [1] полезная статья с определением того что такое Data Product и как ими управлять, в первую очередь с архитектурной точки зрения.
- UIS Data Browser [2] новый каталог данных (статистики) ЮНЕСКО, данных немного, но есть API и массовая выгрузка.
- Why is language documentation still so terrible? [3] гневная статья где автор ругает все языки программирования кроме Rust. Претензий много и я с ним согласен и не только в отношении языков. Хорошую документацию на SDK или open source продукты встретишь нечасто.
- How We Made PostgreSQL Upserts 300x Faster on Compressed Data [4] про оптимизацию загрузки данных в PostgreSQL с помощью TimescaleDB, лично я не видел этот движок в работе, но для каких-то задач он может быть именно тем что нужно
- ImHex [5] шестнадцатеричный редактор с открытым кодом для реверс инжиниринга. На мой взгляд мало что заменит IDA Pro, но для задач не требующих хардкора и когда нет денег вполне себе полезный инструмент.

Ссылки:
[1] https://martinfowler.com/articles/fitness-functions-data-products.html#ArchitecturalCharacteristicsOfADataProduct
[2] https://databrowser.uis.unesco.org/
[3] https://walnut356.github.io/posts/language-documentation/
[4] https://www.timescale.com/blog/how-we-made-postgresql-upserts-300x-faster-on-compressed-data/
[5] https://github.com/WerWolv/ImHex

#opensource #data #datacatalogs #documentation #dbs

В рубрике интересных наборов и каталогов данных, источники данных по блокчейну, Web 3
- Blockсhair datasets [1] дампы всех основных криптовалют: Bitcoin, Bitcoin Cash, Zcash, ERC-20, Ethereum, Dogecoin, Litecoin в виде коллекции сжатых TSV файлов
- Bitcoin Blockchain Historical Data [2] датасет на Kaggle адаптированный под data science прямо на платформе, только Bitcoin
- AWS Public Blockchain Data [3] дампы блокчейнов Bitcoin и Ethereum сразу в формате parquet
- Google Cloud Blockchain Analytics [4] данные и интерфейс работы с ними для 24 разных криптовалют на платформе Google Cloud

Ссылки:
[1] https://blockchair.com/dumps
[2] https://www.kaggle.com/datasets/bigquery/bitcoin-blockchain
[3] https://registry.opendata.aws/aws-public-blockchain/
[4] https://cloud.google.com/blockchain-analytics/docs/supported-datasets

#opendata #datasets #data #datacatalogs

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

Самый простой пример - это всегда ли данные машиночитаемы? К примеру, данные в виде файлов csv, json, xml и тд. всегда можно рассматривать как машиночитаемые, а, к примеру, тексты, видео и изображения нет. Но если собрать тысячи, сотни тысяч текстов или фотографий, то вот, пожалуйста, датасет для обучения в data science. То есть данные не всегда машиночитаемы?

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

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

А как рассматривать API? К примеру, в геоданных массово данные доступны не в виде файлов, а в виде API по стандартам OGC или ряду проприетарных. Их принято относить к наборам данных. Но там разные API, к примеру, WFS, WMS без сомнений можно относить к data api (API для доступа к данным), а какие-нибудь WPS уже точно не data api, а процессные API для обработки данных, а WCS что ближе к не API для данных, с помогающих в работе с геоинструментами. Для аудитории специалистов по геоанализу они нужны, но как бы не данные.

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

Ещё пример, опять же про не машиночитаемость. С точки зрения архивации данных важно хранить данные в любой форме за условно любой период времени. К примеру, статистический сборник 19го века. Формально не машиночитаем, по факту исследователям статистикам может быть нужен? Безусловно. На многих порталах открытых данных опубликованы тысячи таких сборников как открытые данные. Но они не машиночитаемые. В такой логике к, примеру, Библиотека конгресса США или Национальная электронная библиотека в РФ это тоже каталоги данных? Или источники данных? Даже если они не машиночитаемы?

Всё это возвращает к размышлениям о том что наборы данных - это то о чём можно говорить как об опубликованным со смыслом (publish with the purpose), с пониманием аудитории и хотя бы одного сценария их применения.

В практическом применении это напрямую затрагивает, например, то какие данные индексируют и не индексируют поисковые системы. К примеру, Google Dataset Search не индексирует геоданные, они медленно, то уверенно склоняются к поисковику для исследователей. Научные поисковики вроде OpenAIRE, DataCite или BASE с самого начала декларируют что это не только поиск по данным, а по любым результатам научной деятельности до которых просто дотянутся. Для data science поисковика нет поскольку всего два основных ресурса, Hugging Face и Kaggle.

В Dateno индексируются геоданные (гео API) и порталы индикаторов причём с расширенной трактовкой индикаторов как то что датасетом является индикатор + страна во всех случаях когда можно сделать постоянную ссылку на файл или API. Так делают многие создатели этих порталов с индикаторами уже давно. Но это тоже некая форма интерпретации исходя из потребности и поиска пользователей.

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

#thoughts #data #datasets

Для тех кто любит применять правильные термины, оказывается ещё в июле 2024 г. вышел словарь CODATA Research Data Management Terminology [1] с подборкой англоязычных терминов по управлению исследовательскими данными.

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

Например, определение открытых данных звучит как:

Data that are accessible, machine-readable, usable, intelligible, and freely shared. Open data can be freely used, re-used, built on, and redistributed by anyone – subject only, at most, to the requirement to attribute and sharealike.[2]

Этот словарь доступен через портал Research Vocabularies Australia [3] агрегатор и поисковик по всем словарям используемым в исследовательских целях в Австралии.

Ссылки:
[1] https://vocabs.ardc.edu.au/viewById/685
[2] http://vocabs.ardc.edu.au/repository/api/lda/codata/codata-research-data-management-terminology/v001/resource?uri=https%3A%2F%2Fterms.codata.org%2Frdmt%2Fopen-data
[3] https://vocabs.ardc.edu.au

#opendata #semanticweb #data #datacatalogs #terms

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

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

...
Значительная часть открытых данных связанных с медицинскими исследованиями в мире публикуется благодаря политике Национального института здравоохранения США (NIH). И связано это с тем что у NIH есть последовательная политика:
1. Вначале предпочтительности, а далее обязательности открытого доступа для всех финансируемых им исследований.
2. Последовательная политика поощрения создания и создания собственных репозиториев данных и иных результатов научной деятельности.
3. Прямые инвестиции в инфраструктуру создания, обработки, визуализации и систематизации данных научных исследований.

Примеры реализации этих политик в виде каталога репозиториев данных поддерживаемых NIH [1] причём эти репозитории разделяются на Generalist и Domain Specific. Первые - это репозитории данных как датасетов, такие как Zenodo или OSF. Вторые - это специализированные репозитории данных где единицей измерения/учёта/записи являются, как правило, не датасеты, а объекты научной деятельности к которым привязаны данные. Это могут быть репозитории исследований (studies), репозитории геномов (genomes) и так далее. Как правило эти репозитории содержат существенное число метаданных связанных с медициной/биоинформатикой/генетикой и перевязаны между собой кросс ссылками.

По мере нарастания критической массы разных проектов, а там реально очень много проектов на данных у NIH есть Common Fund Data Ecosystem (CFDE) [2] по интеграции существующих дата порталов и иных дата проектов общими правилами и конвейерами обработки данных. А сама эта инициатива существует в рамках The Common Fund в рамках которого как раз финансируется общая инфраструктура, важная для всех направлений исследований [3].

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

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

Ссылки:
[1] https://www.nlm.nih.gov/NIHbmic/domain_specific_repositories.html
[2] https://commonfund.nih.gov/dataecosystem
[3] https://commonfund.nih.gov/current-programs

#opendata #medicine #openaccess #health #data

В рубрике интересных поисковиков по данным Datacite Commons [1] это поисковик по научным данным, другим научным работам, научным организациям и репозиториям данных. Создан и развивается компанией DataCite, выдающей DOI для работ связанным с данными и собирающей единый индекс научных работ с метаданными объектов которые получили эти DOI.

Выглядит достаточно большим, 61 миллион работ включая 19 миллионов наборов данных [2].

Но, если присмотреться, то не всё так там с этим просто.
1) Значительная часть датасетов, около 2 миллионов, находятся на сервисе Data Planet [3] и публично недоступны, даже каталог посмотреть нельзя, только метаданные в DataCite.
2) Как минимум два источника - это GBIF и The Cambridge Structural Database это базы со структурированным описанием встречаемости видов и химических элементов. Это не датасеты, а как бы единые базы нарезанные на большое число записей. На эти записи по отдельности выдаются DOI, но называть их датасетами скорее неправильно.
3) Особенность метаданных в DataCite в отсутствии ссылок на файлы/ресурсы, поэтому те карточки датасетов что там есть не дают информации по реальному содержанию, только говорят о факте существования набора данных.

На фоне DataCite Commons у нас в Dateno реализовано гораздо больше, и с точки зрения объёмов проиндексированного, и с точки зрения удобства поиска.

Но не все источники данных из DataCite сейчас есть в Dateno и их ещё предстоит добавить. Ключевой вопрос в том рассматривать источники данных такие как GBIF как множество датасетов или не считать такое дробление обоснованным?

Ссылки:
[1] https://commons.datacite.org
[2] https://commons.datacite.org/statistics
[3] https://data.sagepub.com

#opendata #data #datasearch

Я как раз собирался составить очередную подборку интересного чтения про данные и понял что один из текстов стоит упомянуть отдельно и поговорить про него. Это заметка Is Excel immortal? [1] от Benn Stancil. Бэн регулярно пишет интересно про данные, венчурный рынок, стартапы, аналитику и про Excel он пишет очень правильные слова.

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

Причём тут важна сильная сторона Excel, это сочетание гибкой манипуляции табличными данными, внутреннего языка и формул и (самое главное!) гибкой визуализации.

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

Бэн упоминает замену в виде Tableau, но Tableau не поставляется по умолчанию на почти все десктопы и у него отсутствует (?) сильный инструмент по операциями с данными. Странно что при этом он не упоминает PowerBI от MS.

Но в, самом деле, какой может быть замена Excel к 2075 году?

Лично я много что перепробовал в своей жизни:
- Airtable для ведения таблиц онлайн. Скорее онлайн замена MS Access, непомерно дорогая при коммерческом использовании, удобная при личном, но
- OpenRefine для того что называют data wrangling. Он заменяет Excel в задачах визуальной чистки данных.
- PowerBI для визуализации данных, но, признаюсь, в простых задачах Excel удобнее

Что печально, продуктов с открытым кодом для таких задач маловато. Но и коммерческие продукты пока не тянут что-то кроме ограниченных задач.

Обратите внимание, что обычно Excel'ю противопоставляют LibreOffice/OpenOffice, но я лично считаю что времена такого сравнения давно прошли. LibreOffice/OpenOffice обладает очень ограниченными функциями визуализации и манипуляции с данными.

Каким может быть Excel будущего?

1) Разделение данных и представления. Таблицы с данными в embedded базе, а ля DuckDB или SQlite, а разметка в гипертексте, может быть на основе одного из существующих стандартов.
2) Разделение визуализации и представления. Звучит странно, но это как с данными. Визуализация строится на основе одного из будущих стандартов описания дашбордов, а разметка это как накладываемые на неё стили.
3) Облачная синхронизация, но local-first.
4) Отсутствие ограничений на объёмы хранимых данных
5) Типизация вкладок. Сейчас когда в Excel готовят данные некоторые вкладки - это таблицы, а другие это тексты с пояснениями к ним и третьи - это формы. Нужны вкладки которые останутся дата таблицами, вкладки заметок, вкладки форм и вкладки аля markdown notebooks

Что можно добавить?

Ссылки:
[1] https://benn.substack.com/p/is-excel-immortal

#thoughts #excel #data #datatools

Подборка ссылок про данные, технологии и не только:
- The Open Data Editor is now ready for the pilot phase [1] обновлённый редактор для подготовки датасетов готов для тестирования, полезный инструмент для всех кто публикует данные с помощью CKAN
- To Be Born in a Bag [2] о исследованиях в разработки искусственной матки и возможностью создавать живых существ искусственным образом. Напоминает воплощение научной фантастики из серии книг Лоис Буджолд. А заодно и там же про создание мамонтов искусственным образом
- DuckDB foundation [3] один из успехов DuckDB в том что это фонд успешно взаимодействующий с несколькими компаниями контрибьюторами. Полезное чтение про успешную модель существования открытого кода.
- The Disappearance of an Internet Domain [4] Великобритания отказывается от суверенитета над островами Чагос и передаёт их Маврикию. Что такое острова Чагос? Это доменная зона .io. Автор рассуждает о его судьбе.
- The Prosopography of Anglo-Saxon England (PASE) [5] онлайн база данных всех британцев как-либо упомянутых в литературных источниках с 6 по 11 века нашей эры. Почти 20 тысяч персон
- Bots, so many Bots [6] боты составляют более 60% из 1 миллиона пользователей ProductHunt. А если говорить о других социальных площадках, то и там ботов всё больше. В какой-то момент должен будет возникнуть перелом когда такие площадки станут бесполезными.
- DatAasee - A Metadata-Lake for Libraries [7] научная статья и открытый код [8] каталога метаданных и озера данных для библиотек.

Ссылки:
[1] https://blog.okfn.org/2024/10/02/the-open-data-editor-is-now-ready-for-the-pilot-phase/
[2] https://press.asimov.com/articles/artificial-wombs
[3] https://davidsj.substack.com/p/foundation
[4] https://every.to/p/the-disappearance-of-an-internet-domain
[5] https://pase.ac.uk/pase/
[6] https://wakatime.com/blog/67-bots-so-many-bots
[7] https://www.semanticscholar.org/reader/7166be7af2fd4bc9cf73d19f076180d9ca83b029
[8] https://github.com/ulbmuenster/dataasee

#opendata #data #tech #dataengineering

Полезное чтение про данные, технологии и не только:
- Unlocking AI for All: The Case for Public Data Banks [1] о том что для развития экосистемы ИИ нужны public AI data banks (PAIDs), каталоги данных доступных для исследователей и среднего/малого бизнеса. Мысли здравые и даже примеры близкие, но автор явно далёк от некоторых областей работы с данными иначе знал бы более релевантные примеры. В любом случае идея актуальная ещё надолго.
- China: Autocracy 2.0 [2] структуризация экономической и политической политики Китая с оглядкой на его автократическую модель. Что-то кажется очевидным, что-то не так очевидным, но всё вместе неплохо описано.
- Climate and Health Outcomes Research Data Systems (CHORDS) [3] проект и каталог данных о влиянии окружающей среды на здоровье человека. Каталог данных скорее выглядит как агрегатор ссылок на академические репозитории, но всё неплохо организовано. Подробный рассказ про инициативу [4] и, что любопытно, внутри него ранее не встречавшийся мне продукт каталога данных Gen3 Data Commons [5]
- Need for Co-creating Urban Data Collaborative [6] про инициативы по открытости данных в Индии на уровне городов и вовлечение граждан в создание данных. Много интересного о том что там происходит, из любопытного, у них есть DMAF (Data Maturity Assessment Framework) [7] для оценки зрелости работы с данными в индийских городах и результаты оценки и дашборд по 100 городам [8]
- Report – Improving Governance Outcomes Through AI Documentation: Bridging Theory and Practice [9] доклад о необходимости и влиянии документированности AI моделей на их управляемость


Ссылки:
[1] https://www.lawfaremedia.org/article/unlocking-ai-for-all--the-case-for-public-data-banks
[2] https://www.nber.org/papers/w32993
[3] https://niehs.github.io/chords_landing/index.html
[4] https://factor.niehs.nih.gov/2024/8/science-highlights/climate-health-data
[5] https://gen3.org/products/data-commons/
[6] https://medium.com/civicdatalab/need-for-co-creating-urban-data-collaboratives-1ab9bc2c0776
[7] https://dmaf.mohua.gov.in/
[8] https://amplifi.mohua.gov.in/dmaf-dashboard
[9] https://cdt.org/insights/report-improving-governance-outcomes-through-ai-documentation-bridging-theory-and-practice/

#data #opendata #ai #india #china #healthcare #openaccess #datapolicy

Пишут что PostgreSQL 17 может заменить NoSQL базы данных [1] потому что умеет грузить безсхемные JSON документы и обзавёлся несколькими функциями для работы с JSON документами. Новости прекрасная, если там всё так хорошо как описано, то это есть на чём проверить, очень хочется качественного сравнения с MongoDB и другими NoSQL СУБД построенными по модели хранения документов (MongoDB, ArangoDB и др), а также поисковые СУБД вроде Elastic, Meilisearch и тд.

Во многих СУБД есть поддержка JSON, но они оказываются весьма придирчивы к содержанию загружаемых документов. Потому и интересно как это сейчас в PostgreSQL.

И, в дополнение, полезный текст Postgres is eating the database world [2] о том как PostgreSQL вырос в мощную экосистему за последние годы.

Ссылки:
[1] https://www.linkedin.com/posts/mehd-io_the-last-release-of-postgresql-17-silently-activity-7250122811581640706-RLBD
[2] https://medium.com/@fengruohang/postgres-is-eating-the-database-world-157c204dcfc4

#data #opensource #postgresql

Еврокомиссия 24 сентября запустила Public Procurement Data Space (PPDS) [1] инициативу по интеграции данных о государственных закупках в странах Евросоюза. Инициатива эта является продолжением и развитием Европейской стратегии данных (European strategy for data) [2] от 2020 года где тематика доступности данных о закупках была явно обозначена.

Из любопытного:
1. В основе технологий PPDS лежит онтология eProcurement Ontology (ePO) [3] и технологии Knowledge Graphs с реализацией аналитической базы данных с интерфейсом SPARQL
2. У проекта есть открытые репозитории, в основном с проверка
ми качества данных и индикаторами [4]
3. А также они в открытый доступ отдают дашборды с оценками качества данных [5], реализованы дашборды на Superset

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

Ссылки:
[1] https://www.public-procurement-data-space.europa.eu/en
[2] https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A52020DC0066
[3] https://docs.ted.europa.eu/EPO/latest/index.html
[4] https://eproc.pages.code.europa.eu/ppds/pages/
[5] https://www.public-procurement-data-space.europa.eu/en/dashboards

#opendata #europe #procurement #data #datasets