Кратко

  • Документ SPARQL 1.2 Graph Store Protocol от 24 сентября 2026 года — очередной рабочий проект W3C, а не первый публичный проект и не окончательная Рекомендация.
  • По сравнению с декабрём 2024 года GET без Accept допускает любую RDF-сериализацию; октеты после процентного декодирования параметра ?graph= теперь явно трактуются как UTF-8.
  • При переходе стоит отдельно проверить согласование формата, точность имени графа и право выполнять запись. Это редакционная рекомендация, а не новая обязательная процедура W3C.

У автоматического клиента редко спрашивают, почему он ничего не написал в заголовке запроса. Пока сервер возвращает привычный Turtle, отсутствие Accept выглядит безобидным. Но декабрьский рабочий проект 2024 года ограничивал ответ на такой GET тремя вариантами: RDF/XML, Turtle либо N-Triples. Версия от 24 сентября 2026 года разрешает любую RDF-сериализацию, называя JSON-LD среди примеров. Это не сообщение о том, что конкретный сервер уже перешёл на JSON-LD, и не прогноз поведения всех реализаций. Изменился текст границы, на которую мог полагаться клиент с узким набором парсеров.

Если приложение понимает только один формат, его следует явно запросить и затем сверить фактический Content-Type с возможностями парсера. Сериализованный документ переносит содержимое графа по HTTP; сам выбор формата не подтверждает истинность записанных утверждений. Он также не означает разрешение на изменение графа. Одно успешное чтение слишком часто превращается в мнимое доказательство всех трёх вещей — чтения, правильного выбора цели и полномочия на действие.

Вторая правка касается цели запроса. Протокол и раньше позволял указать граф не прямым обращением к его IRI, а параметром ?graph= в адресе Graph Store. В тексте 2024 года говорилось о процентном декодировании значения. В тексте 2026 года дополнительно сказано, что полученные октеты интерпретируются как UTF-8-строка IRI. IRI должен быть абсолютным, иначе сервер возвращает 400. Проверка имени с символами за пределами ASCII позволяет увидеть, совпало ли понимание адреса у клиента и сервера. Источники не описывают ни обнаруженной коллизии, ни использованной уязвимости.

Рядом с этими уточнениями находятся операции, последствия которых значительно серьёзнее. GET получает представление графа; PUT заменяет его содержимое; POST добавляет данные слиянием; DELETE удаляет граф. Их нельзя объявлять сентябрьским изобретением: управление графами через HTTP описывала ещё Рекомендация SPARQL 1.1 2013 года. Действующий проект оставляет политику доступа реализации и допускает отказы при отсутствии удостоверения или прав. Узнать IRI и прочитать граф — не значит получить возможность его стереть. Даже уполномоченному клиенту важно не перепутать замену всей совокупности с добавлением данных.

Поэтому журнал приёмки новой версии мог бы фиксировать отправленный Accept, полученный тип содержимого, закодированное значение graph, итоговый абсолютный IRI, учётную запись с правом на каждый метод и результат безопасной пробы на тестовом графе. Это предложение автора о рабочем контроле, а не установленный W3C бланк соответствия. Его задача — сделать видимыми три независимых решения, которые нельзя вывести из единственного ответа «200 OK».

По истории публикаций W3C первая публичная рабочая версия SPARQL 1.2 вышла в мае 2023 года. Сентябрьский текст остаётся проектом, который может измениться, и не содержит отчёта о работе конкретных продуктов. Достоверный масштаб новости невелик, но существенен: два неявных допущения клиента теперь требуют явной проверки. Реальное влияние на систему установит испытание именно этой системы.

Источники