Любопытный стандарт публикации продуктов на данных Open Data Product Specification [1] специально для тех компаний и не только компаний которые торгуют данными. Да, да, это не [Open Data] Product specification, а именно [Open] Data Product Specification. Слово Open тут про открытость стандарта, а не про открытые данные.

Что, впрочем, не делает стандарт менее любопытным. Идея любопытная как альтернатива спецификациям общедоступных данных для повышения находимости именно коммерческих данных. Хорошо бы дополнило стандарт Schema.org.


Ссылки։
[1] https://opendataproducts.org

#opendata #data #specifications #

Universal Tool Calling Protocol (UTCP) спецификация и SDK для тех кто думает об альтернативах MCP. Вместо специальной доработки инструментов они описываются в специальном файле utcp.json и вся взаимодействие с инструментом осуществляется через HTTP/gRPC/cli, с акцентом на то что нет накладных расходов на обращение к инструментам/сервисам.

Подробная документация на сайте utcp.io, но пока нет ни одного LLM провайдера который бы эту спецификацию поддерживал. Вот если будет хотя бы 1-2 то сможет (потенциально) потеснить MCP.

#ai #mcp #utcp #specifications

Я какое-то время назад писал про практики публикации данных и некоторые базовые стандарты описания наборов данных такие как DCAT, Schema.org и карточки CKAN, но, на самом деле их гораздо больше. Наборы данных описываются всё более разнообразно и имеют немало специфики, в последнее время привязанной к применению для ИИ.

- Croissant расширение спецификации Schema.org с метаданными привязанными к машинному обучению
- DSDL (Data Set Description Language) спецификация от китайской OpenDataLab для описания наборов данных для ML
- MRM3: Machine Readable ML Model Metadata свежая публикация с ещё одним стандартом метаданных для ML

А также:
- Data Package часть стандарта Frictionless Data, ориентирован на распространение данных в табличных форматах
- DDI (Data Documentation Initiative) спецификация для датасетов используемая в социологии, например. для данных опросов
- TEI (Text Encoding Initiative) спецификация из компьютерной лингвистики используемая для описания текстовых данных
- EML (Ecology Metadata Language) спецификация для описания наборов данных в экологии
- Dublin Core базовый стандарт для описания цифровых объектов, используется повсеместно в институциональных репозиториях в том числе для публикации данных
- CSV on Web стандарт для публикации CSV файлов онлайн, давно потерял в популярности, но всё еще используется
- geocore Format спецификация для публикации геоданных
- DataCite Metadata Schema спецификация сервиса DataCite для научных данных в целях научного цитирования и поиска
- FGDC Metadata Standards стандарты геослужбы США для публикации геоданных
- OGC® Catalogue стандарт публикации метаданных в сервисах Catalog Services for the Web (CSW) для геоданных

И это далеко не полный список.

#opendata #specifications #datasets #standards

TOON - свежий инструмент/спецификация/нотация для отправки структурированных данных LLM.

Переупаковывает JSON данные в упрощённый CSV подобный формат для отправки в запросе к LLM.

Сразу возникает запрос - зачем это нужно? И ответ в уменьшении числа токенов и экономии на использовании облачным LLM и LLM-как-сервиса.

#opensource #ai #llm #specifications

Ещё одна совсем-совсем свежая спецификация PLOON для отправки данных в ИИ агенты с максимальной экономией токенов. Экономит до 60% в сравнении с JSON и до 14.1% в сравнении с TOON. Автор написал бенчмарк показывающий что PLOON сильно экономнее других форматов. Уже прям любопытно что дальше, когда наступит момент что ИИ агенты смогут нормально употреблять бинарные данные и тогда все эти оптимизации будет очень легко заменить.

#ai #data #dataengineering #specifications

Еще немного размышлений вслух про дата продукты и открытые данные. Я поизучал спецификацию 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