写点什么

JSON-LD 进入 W3C 推荐状态

  • 2014-02-08
  • 本文字数:1711 字

    阅读完需:约 6 分钟

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

复制代码
{
"@context": "http://json-ld.org/contexts/person.jsonld",
"name": "Manu Sporny",
"homepage": "http://manu.sporny.org/",
"image": "http://manu.sporny.org/images/manu.png"
}

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

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

进一步了解 JSON-LD

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

复制代码
{
"name": "Manu Sporny",
"homepage": "http://manu.sporny.org/",
"image": "http://manu.sporny.org/images/manu.png"
}

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

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

复制代码
{
"http://schema.org/name": "Manu Sporny",
"http://schema.org/url": { "@id": "http://manu.sporny.org/" },
"http://schema.org/image": { "@id": "http://manu.sporny.org/images/manu.png" }
}

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

复制代码
{
"@context": "http://json-ld.org/contexts/person.jsonld",
"name": "Manu Sporny",
"homepage": "http://manu.sporny.org/",
"image": "http://manu.sporny.org/images/manu.png"
}

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

复制代码
{
"@context":
{
"name": "http://schema.org/name",
"image": {
"@id": "http://schema.org/image"
"@type": "@id"
},
"homepage": {
"@id": "http://schema.org/url",
"@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

2014-02-08 01:334871
用户头像
臧秀涛 略懂技术的运营同学。

发布了 300 篇内容, 共 136.3 次阅读, 收获喜欢 35 次。

关注

评论

发布
暂无评论
发现更多内容

学习路线

hasWhere

基于数组的有界阻塞队列 —— ArrayBlockingQueue

程序员小航

Java 源码 队列 源码阅读 JUC

如何避免option请求

hasWhere

阿里P8大牛力荐Java程序员进阶必读的书籍清单(附电子版)

Java架构之路

Java 程序员 面试 编程语言 书籍推荐

学习思路

hasWhere

form表单提交get请求

hasWhere

《转》Spring事务传播机制

hasWhere

java安全编码指南之:敏感类的拷贝

程序那些事

Java java安全编码 java安全 java安全编码指南

格式化报文输出

hasWhere

LeetCode题解:641. 设计循环双端队列,使用队列,JavaScript,详细注释

Lee Chen

大前端 LeetCode

揭秘App的财富密码,剖析算法工程师价值来源

峰池

人工智能 互联网 推荐算法 互联网公司

栈与队列简介

Java旅途

数据结构 队列

CICD实战——服务自动构建与部署

TARS基金会

DevOps 后端 jenkins CI/CD TARS

架构师训练营第 1 期 第 2 周作业

李循律

极客大学架构师训练营

鸿蒙系统究竟是PPT秀还是有真材实料?鸿蒙HarmonyOS开发环境搭建与运行Demo

软测小生

华为 鸿蒙 HarmonyOS

《转》POI的XWPFParagraph.getRuns分段问题

hasWhere

数据提交

hasWhere

解读华为云原生数据库设计原则,打破传统数据库上云瓶颈

华为云开发者联盟

数据库 数据

TensorFlow 篇 | TensorFlow 2.x 基于 HParams 的超参数调优

Alex

tensorflow keras hparams tensorboard 超参数调优

c++ 杂谈3

菜鸟小sailor 🐕

一文了解Zookeeper

Java旅途

kafka zookeeper 分布式

《我在你床下》观后感

徐说科技

Redis 缓存性能实践及总结

vivo互联网技术

redis redis集群 redis监控

ARChatRoom功能介绍手册

anyRTC开发者

音视频 WebRTC 语音 RTC 安卓

清华架构师整理分布式系统文档:从实现原理到系统实现,收藏吧

小Q

Java 程序员 架构 分布式 微服务

高难度对话读书笔记—求助的勇气

wo是一棵草

onblur调用alert导致的死循环

hasWhere

Http自定义请求头接收不正确

hasWhere

在多架构时代,英特尔扩展高性能计算边界

E科讯

实践案例丨利用小熊派开发板获取土壤湿度传感器的ADC值

华为云开发者联盟

物联网 IoT 传感

Java进阶教程、大厂面试真题、项目实战,GitHub上这14个开源项目屌炸天了!

Java架构之路

Java 程序员 面试 编程语言 项目实战

JSON-LD进入W3C推荐状态_语言 & 开发_Steve Klabnik_InfoQ精选文章