2015年12月15日
第13卷，第9期

Schema.org：网络结构化数据的演变

大数据使得通用模式变得更加必要。

R.V. Guha，谷歌
Dan Brickley，谷歌
Steve Macbeth，微软

内容与表现形式的分离一直是Web的重要设计方面之一。然而，从历史上看，即使大多数网站都是由结构化数据库驱动的，它们也只是以HTML格式发布其内容。诸如Web搜索、价格比较、预订引擎等服务，它们对这些内容进行操作，但只能访问HTML。需要访问这些网页底层结构化数据的应用程序必须构建自定义的提取器，以将纯HTML转换为结构化数据。这些工作通常很费力，并且抓取器很脆弱且容易出错，每次网站更改其布局时都会崩溃。

近期，具有各种不同外形尺寸的设备激增，极大地增加了网站必须针对的不同呈现格式的数量。与此同时，许多新的个人助理应用程序，如Google App和微软的Cortana，已经开始为网站提供接触用户的新渠道。此外，成熟的Web应用程序（如Web搜索）正越来越多地寻求使用结构化内容（如果有的话），以增强更丰富和更具交互性的体验。这些发展最终使得Web和应用程序开发人员都必须能够以可互操作的方式交换其结构化数据。

本文追溯了为实现Web规模的结构化数据交换所做的努力的历史，并报告了Schema.org，这是一组基于现有标准语法的词汇表，如今已被Web上结构化数据的发布者和消费者广泛使用。示例说明了发布这些数据有多么容易，以及应用程序如何使用这些数据为用户和数据发布者交付价值的某些方式。

标准

早期，人们就清楚地认识到，领域独立的结构化数据标准将非常有用。一种方法是XML，它试图标准化语法。虽然XML最初被认为是基于浏览器的HTML的未来，但它在结构化数据方面发现了更多的用途，以及更传统的数据互操作性场景。

另一种方法，MCF¹⁸（元内容框架），将知识表示（框架和语义网络）的思想引入Web，并提出更进一步，使用通用数据模型——即，有向标记图。它的愿景是创建一个关于各种实体的单一图（或知识库），其中的不同部分将来自不同的站点。图1显示了该愿景的早期图示，其中关于Tori Amos的信息从那个时代的各个站点汇集到一个连贯的图中。

Schema.org: Evolution of Structured Data on the Web

当时的希望是使许多不同的应用程序能够轻松地处理来自许多不同站点的数据。随着时间的推移，这一愿景扩展到涵盖Web上数据的各种智能处理。蒂姆·伯纳斯-李等人于2001年在科学美国人杂志上发表的关于语义网的文章可能是对该计划最雄心勃勃和最乐观的展望。⁵

在1997年至2004年期间，开发了各种标准（RDF、RDFS和OWL）用于语法和数据模型。针对特定垂直领域提出了许多词汇表，其中一些被广泛采用。其中之一是RSS（丰富站点摘要），它允许用户使用他们最喜爱的新闻源自定义主页，例如Netscape的Netcenter和Yahoo的My Yahoo。另一个是vCard/hCard（即，IMC的vCard标准，使用微格式通过CSS类属性在HTML中表示），它用于在联系人管理器、电子邮件程序等之间交换联系人信息。稍后，hCalendar加入了它们，这是一种用于日历交换的格式，再次是现有IETF（互联网工程任务组）标准iCalendar的微格式HTML重新表示。FOAF（朋友的朋友）早于这些努力，但随着该行业的成熟，其用于社交网络数据的用法有所下降。¹¹ 它在RDF（资源描述框架）关联数据社区中找到了一个利基市场，作为一个常用的模式。⁶

在这些发布结构化数据的情况下，每一类广泛使用的应用程序都会消费它。由于目标是创建一个具有广泛覆盖范围的图，远远超出狭窄的垂直领域，因此挑战在于找到一个具有广泛覆盖范围的广泛使用的应用程序。这个应用程序被证明是文本搜索。

Web搜索领域的激烈竞争促使公司超越结果排名，以改进搜索结果。雅虎和后来的谷歌首先使用的一种技术是用来自结果页面的结构化数据来增强与每个搜索结果相关的摘要。

他们专注于少数垂直领域（最终大约十个，例如食谱、活动等），每个领域都有一个规定的词汇表，在适当的时候重用现有的词汇表，如hCard和FOAF。对于每个垂直领域，他们用一些结构化数据增强了摘要，以便优化用户和网站管理员的体验。这种方法导致了更大的采用率，很快就有数十万个网站使用结构化数据标记标记了他们的页面。然而，该计划有一个明显的缺点。不同垂直领域的词汇表完全独立，导致大量的重复和混淆。很明显，将其扩展到数百或数千个垂直领域/类别是不可能的。更糟糕的是，不同的搜索引擎推荐不同的词汇表。

由于由此产生的混乱，大多数网站管理员根本没有添加任何标记，而且他们添加的标记通常格式不正确。这种大量的不正确格式要求标记的使用者构建能够处理格式不正确的语法和词汇表的复杂解析器。这些复杂的解析器被证明与最初用于从HTML中提取结构化数据的系统一样脆弱，因此没有带来预期的进展。

Schema.org

2011年，主要的搜索引擎Bing、Google和Yahoo（后来加入了Yandex）创建了Schema.org，以改善这种情况。目标是提供一个跨越广泛主题的单一模式，包括人物、地点、事件、产品、报价等等。一个单一的集成模式涵盖了这些主题。其想法是为网站管理员提供一个单一的词汇表。不同的搜索引擎可能会以不同的方式使用标记，但网站管理员只需完成一次工作，就可以从标记的多个消费者那里获得好处。

Schema.org最初发布时包含297个类和187个关系，在过去的四年中，已增长到638个类和965个关系。这些类被组织成一个层次结构，其中每个类可以有一个或多个超类（尽管大多数只有一个）。关系是多态的，因为它们有一个或多个域和一个或多个范围。类层次结构更多的是作为一种组织工具，以帮助浏览词汇表，而不是作为常识的表示，类似于Cyc。

第一个使用此标记的应用程序是谷歌的丰富摘要，它在2011年切换到Schema.org词汇表。在过去的四年中，许多不同公司的许多不同应用程序已经开始使用Schema.org词汇表。其中一些更突出的包括以下内容

* 除了每个链接的丰富摘要之外，Schema.org中的注释还用作知识图谱的数据源，提供关于知名实体（例如，徽标、联系方式和社交信息）的背景信息。

* 基于Schema.org的结构化数据标记现在正用于电子邮件等地方。例如，确认预订（餐厅、酒店、航空公司等）、购买收据等的电子邮件都嵌入了Schema.org标记，其中包含交易的详细信息。这种方法使电子邮件助理工具能够提取结构化数据，并通过移动通知、地图、日历等使其可用。谷歌的Gmail和搜索产品使用这些数据来提供通知和提醒（图2）。例如，在Opentable.com上进行的晚餐预订将触发前往餐厅的提醒，提醒基于餐厅的位置、用户、交通状况等。

* 微软的Cortana（适用于Windows 10和Windows手机）利用了来自电子邮件消息的Schema.org，如图3所示。

* Yandex 使用 Schema.org的许多部分，包括食谱、汽车、评论、组织、服务和目录。它早期使用FOAF（对应于LiveJournal社交网络在俄罗斯的流行）证明了需要实用的词汇表扩展来支持面向消费者的产品功能。

* Pinterest 使用 Schema.org为食谱、电影、文章、产品或地点项目提供丰富Pin图。

* 苹果的iOS 9（Searchlight/Siri）使用Schema.org进行搜索功能，包括聚合评级、报价、产品、价格、互动计数、组织、图像、电话号码和潜在的网站搜索操作。苹果还在RSS中为新闻标记使用Schema.org。

采用统计

当然，衡量成功的关键指标是网站管理员的采用水平。来自谷歌索引和Web Data Commons的100亿页样本提供了一些关键指标。在这个样本中，31.3%的页面具有Schema.org标记，高于一年前的22%。平均而言，每个包含此标记的页面引用了六个实体，并在它们之间进行了26个逻辑断言。图4a列出了Schema.org涵盖的一些主要垂直领域中的知名网站，显示了涵盖主题的广泛范围以及这些主题中最受欢迎的网站的采用情况。图4b和图4c列出了一些最常用的类型和关系。从该样本中的数字推断，我们估计至少有1200万个网站使用Schema.org标记。需要注意的重要一点是，结构化数据标记现在与Web本身的规模处于同一数量级。

虽然本文没有提供完整的分析和比较，但我们应该强调，各种其他格式也在Web上广泛使用。特别是，OGP（开放图谱协议）和微格式方法可以在与Schema.org大致相同数量的网站上找到，但考虑到它们小得多的词汇表，它们出现在不到一半的页面上，并且包含不到四分之一的逻辑断言。在这一点上，Schema.org是唯一被主要搜索索引中超过四分之一的页面使用的广泛词汇表。

这种采用水平的一个关键驱动因素是来自第三方工具（如Drupal和Wordpress扩展）的广泛支持。在垂直领域（如活动），来自垂直特定内容管理系统（如Bandsintown和Ticketmaster）的支持产生了重大影响。在RSS的采用中也观察到了类似的现象，一旦Blogger等工具开始自动输出RSS，RSS feed的数量就会急剧增加。

Schema.org的成功很大程度上归功于搜索引擎和工具对它的支持。然而，并非每个大公司推动的标准都取得了成功。Schema.org成功的部分原因在于其底层的设计决策。

设计决策

Schema.org设计的驱动因素是使网站管理员能够轻松发布其数据。总的来说，设计决策将更多的负担放在标记的消费者身上。本节讨论一些更重要的设计决策。

语法

从一开始，Schema.org就试图在务实地接受多种语法与向网站管理员提出明确而简单的建议之间找到平衡。随着时间的推移，人们清楚地认识到，多种语法将是最佳方法。其中包括RDFa（属性中的资源描述框架）和JSON-LD（用于关联数据的JavaScript对象表示法），发布者有他们自己偏好其中一种语法的理由。

事实上，为了处理RDFa 1.0的复杂性，Schema.org推广了一种更新的语法Microdata，它是作为HTML5的一部分开发的。Microdata的设计选择是通过对网站管理员进行严格的可用性测试而做出的。从那时起，部分受到Microdata的推动，RDFa的修订使其变得不那么复杂，特别是对于发布者而言。

不同的语法适用于不同的工具和创作模型。例如，Schema.org最近认可了JSON-LD，其中结构化数据表示为一组JavaScript风格的对象。这对于使用客户端JavaScript生成的站点以及个性化电子邮件非常有效，在个性化电子邮件中，数据结构可能更加冗长。有少数用于活动（如音乐会）的内容管理系统提供嵌入到其他站点中的小部件。JSON-LD允许这些嵌入式小部件在Schema.org中携带结构化数据。相比之下，Microdata和RDFa通常更适用于使用服务器端模板生成的站点。

有时可以将这种情况理想化为机器友好格式和人类友好格式之间的权衡，尽管在实践中这种关系更加微妙。诸如RDF和XML之类的格式主要是在考虑到机器消费的情况下设计的，而微格式则明确偏向于首先考虑人类。Schema.org正在探索中间地带，其中牺牲了一些机器消费的便利性来换取发布者的可用性。

多态性

许多基于框架的KR（知识表示）系统，包括RDF Schema、OWL（Web本体语言）等，每个关系都有一个域和一个范围。不幸的是，这导致了许多不直观的类，它们的唯一作用是成为某些关系的域或范围。这也使得在不显着更改类层次结构的情况下重用现有关系变得更加困难。允许多个域和范围的决定似乎显着缓解了这个问题。例如，尽管Schema.org中有各种类型（事件、预订、报价），它们的实例可以采用startDate属性，但多态性使我们能够避免拥有一个通用超类型（例如，时间上可开始的活动）来对这些类型进行分组。

实体引用

许多模型（如关联数据）都将每个实体的全局唯一URI作为核心架构原则。⁴ 不幸的是，对于大多数站点来说，协调实体引用与可能拥有关于数万个实体信息的其他站点过于困难。相反，Schema.org仅坚持要求Schema.org提供的极少量术语使用唯一URI。鼓励发布者为每个实体添加尽可能多的额外描述，以便数据的消费者可以使用此描述来进行实体协调。虽然这给从多个网站消费数据的应用程序带来了大量的额外负担，但它显着减轻了网站管理员的负担。在图1所示的示例中，网站管理员不必为实体（例如，Tori Amos；Newton，NC；和Crucify）要求通用URI，其中有数亿个（任何特定站点可能使用数十万个），而只需为诸如country、musician、date of birth等术语使用标准词汇表，其中只有几千个（任何特定站点最多使用几十个）。然而，Schema.org还提供了一个sameAs属性，可用于将实体与知名页面（主页、维基百科等）关联起来，以帮助协调，但这尚未得到广泛采用。

增量复杂性

通常，使表示过于简单会使构建一些更复杂的应用程序变得困难。在这种情况下，我们从一些简单的东西开始，这对于网站管理员来说很容易实现，但具有足够的数据来构建一个激励性的应用程序。通常，一旦简单的应用程序构建完成，并且词汇表获得了最低限度的采用水平，应用程序构建者和网站管理员就会要求更具表现力的词汇表——如果我们一开始就使用它，这种词汇表可能会被认为过于复杂。

在这一点上，可以添加更具表现力的词汇表的复杂性。通常，这相当于相对简单地添加一些更具描述性的属性或子类型。例如，添加新型的操作或事件是扩展Schema.org表现力的一种强大方式。然而，在许多情况下，更仔细的检查揭示了概念化中的细微差异。例如，创意作品有许多不同的框架用于分析看似简单的概念，例如book，将其分解为类型化的、相互关联的实体（例如，在图书馆界，FRBR [书目记录的功能需求]）；或者对于电子商务报价，某些系统将制造商保修与供应商保修区分开来。在这种情况下，很少有正确的答案。Schema.org的方法是由实用性驱动的——更广泛的Web中可用的数据字段以及可以激励大规模发布的应用程序的信息需求。Schema.org的定义永远不会为了追求完美的模型而更改，而是为了响应发布者和消费者的反馈而更改。

Schema.org的增量复杂性方法可以在模式不断发展的领域之间的相互作用中看到。该项目试图在两个极端之间找到平衡：具有重叠范围的模式的非协调添加与所有主题的过度协调。作为一个我们已从强制协调中退后一步的领域的示例，创意作品（书籍等）和电子商务（产品描述）都在努力应对描述各种大规模生产项目的版本和实例的挑战。在专业书目中，重要的是在各个级别描述项目（例如，特定平装本的特定作者签名副本与作品本身，或该版本的特征，例如出版商详细信息）。在描述非书目项目（如激光打印机）时，电子商务中也需要做出惊人地相似的区分。虽然寻求捕获“大规模生产项目及其共同属性的宏大理论”的模式在智力上很有吸引力，但Schema.org采取了务实的路线，并为书目¹²和电子商务⁸采用了不同的建模习惯用法。

相比之下，令人惊喜的是，当有人指出Schema.org的报价概念可以应用于电子商务以外的非营利领域，例如图书馆借阅时，在这些相同领域之间发现了意想不到的共同点。需要对我们的定义进行一些社区提出的务实调整，以澄清报价通常是在不期望付款的情况下提出的。这在我们方法中很典型，即在充分了解它们需要改进的情况下尽早发布模式，而不是试图在发布之前完善一切。与Schema.org的许多方面一样，这也是一种平衡行为：在消费者的强烈激励下，术语可以在几个月内从无到有地在数百万个网站上使用。这为继续调整定义的愿望提供了自然的纠正力；一旦模式定义开始被采用，就对其进行太多更改是不切实际的（也许是不礼貌的）。

清理

偶尔，我们会被冲昏头脑，引入永远不会得到有意义使用的词汇表。虽然很容易让这些术语闲置，但最好将它们清理掉。到目前为止，这种情况仅发生在没有强大的激励性应用程序的大型词汇表中。

扩展

鉴于Web底层结构化数据的多样性，Schema.org充其量只能希望为最常见的主题提供核心。即使对于像汽车这样相对常见的主题，也可能需要数百个属性来捕获汽车制造商网站上找到的汽车规格的详细信息。Schema.org的策略是为每个此类主题提供一个小的核心词汇表，并依靠扩展来覆盖规范的尾部。

从一开始，扩展就有两大类：由Schema.org社区创建并旨在被吸收到核心中的扩展，以及仅仅在“野外”部署而没有任何中心协调的扩展。在2015年，扩展机制得到了增强，以更好地支持这两种想法。首先，引入了托管扩展的概念；这些术语与Schema.org的核心紧密集成，但被视为附加的（在某种意义上是可选的）层。这些术语仍然需要与更广泛的社区进行协调讨论，以确保命名一致并确定适当的集成点。然而，分层机制旨在允许更大程度地分散到专家和专业社区。

其次是外部扩展的概念。这些是独立管理的词汇表，在设计时特别参考了Schema.org的核心词汇表，期望在核心词汇表的基础上构建，而不是重复核心词汇表。外部扩展的范围可能从特定于产品/服务的小型词汇表（例如，用于特定公司的消费），特定于地理位置的词汇表（例如，美国医疗保健），一直到规模与Schema.org相似的大型模式。

我们从Schema.org的跨领域数据模型中受益匪浅。它允许一种松散耦合的协作形式，其中主题专家可以在专门的论坛（例如，体育、健康、书目）中进行协作，同时在可预测的框架内进行协作，以将其工作与其他Schema.org领域集成。

更重要的添加来自在某个领域具有特定兴趣和专业知识的外部团体。最初，此类合作是以项目到项目的风格进行的，但最近它们已通过W3C的社区组机制和GitHub提供的协作平台进行个人参与。

最早的合作是与IPTC的rNews计划进行的，该计划的贡献导致了许多术语的添加（例如，NewsArticle）以及对支持新闻描述的改进。其他早期的添加包括医疗保健相关的模式，通过包含GoodRelations项目实现的电子商务，以及LRMI（学习资源元数据倡议），这是与Creative Commons和教育出版商协会的合作。

关于电视和广播标记的案例说明了一个典型的流程，以及我们协作工具的演变。⁹ Schema.org最初使用一些粗略的术语来描述电视内容。W3C的讨论确定了可以改进它的几种方式，使其更符合行业惯例和国际术语，并增加了描述广播内容的能力。随着越来越普遍，来自更广泛社区的专家（BBC、EBU等）带头开发这些改进（当时通过W3C的wiki和共享文件系统），这反过来又激发了改进我们的协作框架的努力。随后在2014年迁移到GitHub上托管的开源工具使得迭代速度更快，这可以从项目的发布日志中看出，该日志显示了更广泛的社区对细节的关注是如何反映在模式细节的细微改进中的。¹⁰

Schema.org没有规定更广泛的社区成员应该如何分享和辩论想法——除了普遍偏好公共论坛和文明讨论之外。一些团体更喜欢wiki和IRC（互联网中继聊天）；另一些团体更喜欢Office风格的文档协作创作、电话和面对面会议。最终，所有这些努力都需要汇集到项目的公共GitHub存储库中。大量贡献者通过问题跟踪器报告问题或分享提案。少数希望更多参与技术细节的贡献者为模式、示例和文档贡献具体更改。

经验教训

以下是我们迄今为止学到的一些最重要的经验教训，其中一些可能适用于 Web 上的其他标准制定工作。大多数都是完全显而易见的，但有趣的是，在许多场合都被忽略了。

1. 让发布者/开发者更容易参与。更一般地说，当发布者数量和消费者数量不对称时，将复杂性放在数量较少的一方。他们必须能够继续使用他们现有的工具和工作流程。

2. 没有人会阅读冗长的规范。大多数开发者倾向于复制和编辑示例。因此，文档更像是一组食谱，而不是规范。

3. 复杂性必须随着时间的推移逐步增加。今天，平均网页相当复杂，包含 HTML、CSS、JavaScript 等。然而，它最初非常简单，并且复杂性主要是根据需要添加的。平台/标准中的每一层复杂性都只能在更基本层被采纳之后添加。

结论

Web 基础设施需要结构化数据机制来描述真实世界中的实体和关系的想法，与 Web 本身一样古老。^1,2,13 使用类型化关系网络描述世界的想法在 1970 年代就已经广为人知，而使用关于世界的逻辑陈述的历史甚至早于计算机的出现。令人惊讶的是，如此看似显而易见的想法如此难以融入 Web 作为一个信息平台。Schema.org 的历史表明，与其直接寻求创建“智能代理的语言”，不如从 Web 搜索中解决极其简单的场景，这已被证明是实现面向人工智能个人助理的结构化数据的最佳实践途径。

在过去的四年中，Schema.org 在许多方面都得到了发展，包括组织结构和实际模式方面。它最初是由几个人创建的，他们组成了最初三家赞助公司的非正式联盟。在第一年，这些赞助公司在闭门造车的情况下做出了大部分决定。它逐步开放，首先将大多数讨论转移到 W3C 公共论坛，然后转变为一种模式，所有讨论和决策都在公开场合进行，并设立了一个指导委员会，其中包括来自赞助公司、学术界和 W3C 的成员。

在发布四年后，Schema.org 正在进入下一个阶段，更多的词汇开发以更分散的方式进行。从汽车到产品详情等主题的许多扩展已经在进行中。在这种模式下，Schema.org 本身只是核心，在必要时提供统一的词汇和聚集论坛。

对大数据日益增长的兴趣使得对通用模式的需求更加迫切。随着数据科学家探索数据驱动分析的价值，对从不同来源提取数据以及对共享词汇的需求也在增加。我们希望 Schema.org 将为此做出贡献。

致谢

Schema.org 是来自广泛组织和背景的大量人员共同努力的成果。如果没有 Google、Microsoft、Yahoo 和 Yandex 团队的合作努力，它就不会有今天的成就，而这些团队本可以选择单独工作会更容易。如果没有通过 W3C 聚集在一起的更广泛社区成员的贡献，它也将是面目全非的。

参考文献

1. Berners-Lee, T. 1989. Information management: a proposal; http://www.w3.org/History/1989/proposal.html.

2. Berners-Lee, T. 1994. W3 future directions; http://www.w3.org/Talks/WWW94Tim/.

3. Berners-Lee, T. 2006. Linked Data; http://www.w3.org/DesignIssues/LinkedData.html.

4. Berners-Lee, T. 2010. Is your linked open data 5 star? http://www.w3.org/DesignIssues/LinkedData#fivestar.

5. Berners-Lee, T., Hendler, J., Lassila, O. 2001. The semantic web. Scientific American (May): 29-37; https://sciam.cn/article/the-semantic-web/.

6. Friend of a Friend vocabulary (foaf); http://lov.okfn.org/dataset/lov/vocabs/foaf.

7. Google Developers. 2015. Customizing your Knowledge Graph; https://developers.google.com/structured-data/customize/overview.

8. Guha, R.V. 2012. Good Relations and Schema.org. Schema Blog; http://blog.schema.org/2012/11/good-relations-and-schemaorg.html.

9. Raimond, Y. 2013. Schema.org for TV and radio markup. Schema Blog; http://blog.schema.org/2013/12/schemaorg-for-tv-and-radio-markup.html.

10. Schema.org. Release log; http://schema.org/docs/releases.html.

11. Schofield, J. 2004. Let's be Friendsters. The Guardian (February 19); https://www.theguardian.com/technology/2004/feb/19/newmedia.media.

12. Wallis, R., Scott, D. 2014. Schema.org support for bibliographic relationships and periodicals. Schema Blog; http://blog.schema.org/2014/09/schemaorg-support-for-bibliographic_2.html.

13. W3C. 1996. Describing and linking Web resources. Unpublished note; http://www.w3.org/Architecture/NOTE-link.html.

14. W3C. 2011. Library Linked Data Incubator Group Final Report; http://w3.org/2005/Incubator/lld/XGR-lld-20111025/.

15. W3C. 2011. Linked Data Cookbook; http://www.w3.org/2011/gld/wiki/Linked_Data_Cookbook.

16. W3C. 2012. Health Care and Life Science Linked Data Guide; http://www.w3.org/2001/sw/hcls/notes/hcls-rdf-guide/.

17. W3C. 2014. RDF Schema 1.1; http://www.w3.org/TR/rdf-schema/

18. W3C. 1997. MCF Using XML, R.V.Guha, T.Bray, http://w3.org/TR/NOTE-MCF-XML

R.V. Guha 是 RSS 和 Schema.org 等广泛使用的 Web 标准的创建者。他还负责 Google Custom Search 等产品。他是 Epinions.com 和 Alpiri 的联合创始人。早些时候，他是 Cyc 项目的联合负责人。他目前是 Google Fellow 兼 Google 研究部门的副总裁。他拥有斯坦福大学计算机科学博士学位和印度理工学院钦奈分校机械工程学士学位。

Dan Brickley 以其在 W3C 社区中关于 Web 标准的工作而闻名，他在 W3C 社区帮助创建了语义网项目及其许多定义性技术。Brickley 在 Google 从事 Schema.org 倡议和结构化数据标准方面的工作。之前的工作包括围绕电视、农业、数字图书馆和教育的元数据项目。

Steve Macbeth 是 Microsoft 应用程序和服务组的合作伙伴架构师，他负责设计和构建移动、云和智能系统交叉领域的解决方案。这项工作包括构建平台技术，使所有平台上的所有应用程序都能更好地理解用户的行为和偏好，以便更智能地运行并随着时间的推移进行学习。在此职位之前，Macbeth 曾担任 Bing Core Search 的高级领导，专注于整体搜索质量、相关性和实验，以及位于中国北京的亚洲搜索技术中心的总经理兼联合创始人，他在那里生活和工作了三年。在加入 Microsoft 之前，他是加拿大温哥华的技术初创公司 Riptide Technologies 和 pcsupport.com 的创始人和 CTO。

最初发表于 Queue vol. 13, no. 9—
在数字图书馆中评论本文

更多相关文章

Qian Li, Peter Kraft - 事务和无服务器是天作之合
数据库支持的应用程序是无服务器计算的一个令人兴奋的新领域。通过紧密集成应用程序执行和数据管理，事务性无服务器平台实现了许多在现有无服务器平台或基于服务器的部署中不可能实现的新功能。

Pat Helland - 任何其他名称的身份
新兴的系统和协议都在收紧和放松我们对身份的概念，这很好！它们使完成工作变得更容易。REST、IoT、大数据和机器学习都围绕着有意保持灵活，有时甚至模棱两可的身份概念。身份的概念是我们分布式系统的基本机制的基础，包括互换性、幂等性和不变性。

Raymond Blum, Betsy Beyer - 实现数字永久性
当今的信息时代正在为世界所依赖的数据创造新的用途和新的管理方式。世界正在从熟悉的物理制品转向更接近信息本质的新型表示手段。我们需要流程来确保知识的完整性和可访问性，以保证历史将被知晓且真实。

Graham Cormode - 数据草图
您是否曾感到被源源不断的信息流淹没？看起来没完没了的新电子邮件和短信要求您不断关注，还有电话要接听、文章要阅读、敲门声要回应。将这些碎片拼凑在一起以跟踪重要的信息可能是一个真正的挑战。为了应对这一挑战，流数据处理模型越来越受欢迎。其目的不再是捕获、存储和索引每一分钟的事件，而是快速处理每个观察结果，以便创建当前状态的摘要。