Еще немного размышлений вслух про дата продукты и открытые данные. Я поизучал спецификацию ODPS (Open Data Product Specification) в её последней редакции версии 4.1. Её, кстати, правильно читать не как спецификацию про открытые дата продукты, а как открытую спецификацию на дата продукты. Это, конечно, неплохой документ и чуть ли не единственный описывающий данные именно к продукт и спецификация сама по себе имеет ценность не только для технического описания, но и как шаблона для внутреннего описания дата продуктов. Условно хороший документ спецификации для API к доступу к данным на этапе проектирования (скорее продуктового чем технического).

Но, при этом, со своими ограничениями:
1. Малая экосистема. У дата продукта может быть более одного интерфейса, это могут быть данные доступные через REST API, в формате для массовой выгрузки (bulk download), в формате специализированного API (WFC и OGC совместимые). Хотя в спецификации это всё предусмотрено, но каждый из этих интерфейсов, но нехватает инструментов тестирования этих множественных интерфейсов на основе спецификации.
2. Интеграция с ИИ агентами. Наличие ссылок на документацию - это важно, и, ИМХО, важно не просто наличие human-readable документации, но и документации для ИИ агента (в виде markdown похоже) для автоматизированного доступа к дата продукту.

Как я понимаю в части работы с общедоступными данными у ODPS есть реализация внутри X-Road, но при этом общедоступно действующих примеров нет и нет примеров её использования наиболее продвинутыми создателями открытых дата продуктов в госсекторе, к примеру, государственные API во Франции не описываются через ODPS хотя их описание и документация наиболее близки именно к описанию дата продуктов.

В принципе лично меня это смущает более всего, я знаю довольно много дата продуктов которые могли бы быть описаны с помощью ODPS, но не описываются по какой-то причине. Я подозреваю по той что за спецификацией не стоит кто-то достаточно крупный кто внедрил бы это в свой достаточно популярный каталог дата продуктов. К примеру достаточно крупных агрегатор сервисов API (но им спецификация не вполне подходит) или дата маркетплейс (таких крупных не так много). Кто-то вроде бывшего Quandl'а мог бы использовать подобную спецификацию.

#thoughts #data #specifications #dataengineering

Да, но... собрал наблюдения за происходящим:
- Github - это крупнейшая платформа для разработки, хранения кода и тд. Это большой плюс. Минус в растущем объёме технологического спама основанного на активности на ней. Например, ты лайкаешь какой-то репозиторий, а потом тебе приходят письма "Я знаю что тебе нравится такой-то продукт, а я делаю альтернативный. Посмотри на него пожалуйста". Или "Я обнаружил что ты активен в таком то репозитори, а мы делаем альтернативный проект вот такой. Попробуй его". Это не личные письма, а полностью автоматизированные рассылаемые массово. Со временем их число растет.
- когда open source проект набирает популярность - это повод к нему присмотреться, там часто нужный код, нужная функциональность и отзывчивые к запросам разработчики. Как только проект получает венчурные инвестиции - это повод начинать искать альтернативы, потому что инвестиции в 99% случаях идут на создание облачного сервиса и разработчики приоритетно начинают развивать именно его, забрасывая или искажая имеющиеся функции к KPI переданным инвесторами
- цифровая суверенизация по которой идут некоторые страны в мире - это не то чтобы однозначно плохо, те кто ратуют и продвигают её могут быть правы со своей колокольни. Но важно не забывать что это губительно для той быстрой гонки в разработке что сейчас есть в мире и исключают многие интересные продукты из глобальных экосистем. К примеру, как бы ни были хороши российские ИИ продукты, в мире они представлены минимально
- многие принципиально правильные идеи вроде стандартов описания данных на RDF маргинализируются несмотря на опору на многие внедрения и институциональную основу потому что разработка ИИ, дата инженерия, ИИ инженерия воспринимает их исключительно как жесткое легаси и все стандарты исходящие от практиков игнорируют институциональные стандарты везде где это возможно
- корпоративные каталоги данных выглядят хорошей идеей и очень логичной, но правильнее сказать что казались. После попыток заменить их на идею data discovery видно что и она не особенно приживается. А теперь вместе со снижением стоимости внутренней разработки ПО еще и возникает ситуация когда сделать с помощью ИИ свой внутренний каталог данных/конвееров и тд. быстрее, дешевле и проще чем внедрить внешний. Похоже этот рынок будет быстро меняться

#thoughts