W3C RDF工作组已将JSON-LD和JSON-LD 1.0处理算法与API标准推进到推荐状态。JSON-LD是一个标准，旨在向JSON中加入“链接数据（linked data）”语义。JSON-LD文档看上去是像下面这样：

{ "@context": "", "name": "Manu Sporny", "homepage": "", "image": "" }

　　如果还不熟悉W3C的标准化流程，可以先了解一下：一个规范可以处于三个成熟层次之中。推荐（Recommendation）状态是特定规范的最后一步。W3C的建议是，推荐状态可以“广泛实现”，也就是说，相应规范已经为广泛的公开使用做好准备，而且足够稳定。

　　人们投入了很多工作才使JSON-LD进入这一状态：在4年多的时间里，有着100次电话会议，281份议题纪要，2 000次代码提交，以及2 500封电子邮件。

进一步了解JSON-LD

　　下面是一个直接选自规范的例子：

{ "name": "Manu Sporny", "homepage": "", "image": "" }

　　这个JSON文档表示一个人。人们很容易推断这里的语义：“name”是人的名字，“homepage”是其主页，“image”是其某种照片。然而机器不理解“name”和“image”这样的术语。

　　为解决该问题，我们可以使用链接数据。下面使用JSON-LD表示上面的例子：

{ "": "Manu Sporny", "": { "@id": "" }, "": { "@id": "" } }

　　通过链接到schema.org上的定义，我们可以教给机器如何理解“name”、“url”和“image”的语义。不过有点复杂了。通过JSON-LD所谓的“上下文（context）”，我们可以兼顾第一个例子的简洁性和第二个例子的语义理解。基于第一个例子，我们引入一个context：

{ "@context": "", "name": "Manu Sporny", "homepage": "", "image": "" }

　　我们现在链接到了json-ld.org上的一个context。context文档看上去像下面这样：

{ "@context": { "name": "", "image": { "@id": "" "@type": "@id" }, "homepage": { "@id": "", "@type": "@id" } } }

　　这种方法的另一个优点是，多个文档可以使用同一个context。

为什么没有选择RDF

　　JSON-LD呈现出语义Web技术的风格，但是两者并不完全一样。它们有着类似的目标：围绕某类知识提供共享的上下文。例如，每个网站不应该围绕“name”重复发明概念。假设我们想研究几个不同的服务，以比较人们识别自身的方式。为了得到人们的名字，我们不得不针对每种API重新编写不同的代码，以确定如何取得其名字。

　　利用语义Web技术，每个服务都会暴露出“这是一个人（Person）”这一语义，我们只需要编写一次代码，理解人是什么。而且可以跨多种服务复用代码。

　　尽管JSON-LD和更为传统的语义Web技术（如RDF）有着同样的最终目标，但是二者没有使用同样的构建块，JSON-LD W3C社区组的主席Manu Sporny就两者之间的关系写了一篇博客：

　　这就是我实现JSON-LD时没有选择大部分语义Web技术栈（TURTLE/SPARQL/Quad Stores），而选择从头做起的原因。这一策略并不适合所有人，但却是唯一适合我们的，而且是我们所能想到的唯一能让更传统的语义Web技术从骄傲自满中醒悟过来的方式。

　　Manu还就规范简洁、清晰的文风做了详细说明：

　　我们尽最大努力剔除JSON-LD规范中复杂的技术行话。而且我特别注意在JSON-LD 1.0规范中完全不提RDF，因为读者不需要为了理解JSON-LD文档转而去读RDF相关资料。在这一点上我们推回了很多次，我后面还会讲，但是问题在于我们想以相对于典型的Internet和Web规范更具谈话风格的方式传达信息，因为在规范中太早进入学究式风格会定下错误的基调。

　　这两点都表明， JSON-LD尝试将语义Web技术相关的探讨向如下方向推进：简单、不复杂以及面向一般开发人员。

　　查看英文原文：JSON-LD Reaches W3C Recommendation Status

来自infoq

标签：JSON