Использование параметра профиля для запросов JSON-LD

Question

В документации JSON-LD упоминается, что клиенты могут предоставить параметр профиля заголовку Accept, для управления представлением. Он определяет три значения по умолчанию для запроса compacted, расширенный или flattened JSON-LD документы. Он также сказал, что

Если параметр профиля задан, сервер should возвращает документ, который чтит профили в списке, которые распознаются сервером.

Это, однако, не объясняет, существуют ли какие-либо конкретные правила, которым должен следовать сервер. Является ли это полностью до сервера, чтобы решить, что такое поведение для пользовательских URI профиля? Есть ли какие-либо обсуждения по этому вопросу?

Будут ли приведенные ниже примеры правильными?

Пример 1

Клиент запрашивает с

Accept: application/ld+json; 
     profile="http://www.w3.org/ns/json-ld#compacted http://schema.org" 

И сервер возвращает документ уплотняется с http://schema.org как @context?

Пример 2

Клиент запрашивает с

Accept: application/ld+json; profile="http://schema.org" 

И сервер возвращает документ уплотняется с http://schema.org как @context?

Answer 1

JSON-LD 1.0 Spec определяет profile в IANA Condierations. Это определяет идентификаторы профиля, такие как compacted, которые вы указали выше. Он не дает способа указать конкретный контекст для использования, а семантика profile затруднит понимание того, что подразумевается под другим URI профиля, поскольку нет способа (AFAIK) зарегистрировать это значение в другом месте.

Сказанное, я думаю, было бы полезно указать контекст для использования для compacted или expanded, и если/когда мы поддерживаем кадрирование, используем рамку. Я думаю, что это может принять форму параметра Accept-типа context и/или frame, который будет использоваться для указания запрашиваемого контекста или фрейма, которые будут использоваться при сериализации документа. Однако, как и для других профилей, это ДОЛЖЕН, а не ДОЛЖЕН; клиент должен иметь возможность справиться с возвратом документа, не так сериализованным, возможно, используя локальный экземпляр jsonld.js для повторного кодирования возвращаемого документа. Также может быть полезно рекомендовать использовать те же параметры в ответе с Content-Type для передачи сервером profile/context/frame, используемого как часть ответа.

Просьба рассмотреть вопрос о выпуске проблемы на уровне https://github.com/json-ld/json-ld.org/issues, так как мы начинаем рассматривать новые рекомендации групп сообщества (т. Е. Не W3C), для того чтобы устранить длительные нерешенные запросы функций сообщества.