用于JSON-LD请求的配置文件参数

Question

JSON-LD的文档提到客户端可以为Accept标头提供配置文件参数，可用于控制表示。它定义了请求的三个默认值压缩了,扩展了或压扁 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，并且如果/当我们支持成帧时，使用一个框架将是有用的。我认为这可能采取特定于类型的接受参数context和/或frame的形式，它将用于指定在序列化文档时要使用的请求上下文或帧。但是，与其他配置文件一样，这些是应该，而不是必须;客户端需要能够处理得到的文档没有如此序列化，可能使用本地jsonld.js实例重新编码返回的文档。建议在Content-Type响应中使用相同的参数以便服务器传递用作响应的一部分的profile/context/frame可能也很有用。

请考虑在https://github.com/json-ld/json-ld.org/issues提出问题，因为我们正在开始查看新的社区组（即非W3C建议书）规范草案，以解决长期出色的社区功能请求。