web系统中的结构化数据标记
共 4132字，需浏览 9分钟
·
2021-11-18 00:27
Web 系统的设计要点之一是内容和表示的分离，网站以HTML发布内容，对内容进行操作的服务也只能访问 HTML。随着表现形式各异的设备在大量地增加，也大大增加了网站针对不同表示格式的数量。同时，一些新的个人助理应用，例如google assitant，amazon的Alexa，已经开始为web提供接触用户的新渠道。
此外，成熟的网络应用程序，正越来越多地寻求使用结构化内容，以提供更丰富和更具交互性的体验。这最终使得 Web 系统和开发人员能够以可互操作的方式交换结构化数据变得至关重要。Schema.org 是一套基于现有标准语法的词汇表，目前被 Web 系统上使用上的结构化数据所广泛使用。
关于结构化数据标记的标准
在早期，结构化数据的标准在独立的领域非常有用。一种方法是XML，试图标准化语法。虽然 XML 最初只被认为是HTML的未来，但它为结构化数据找到了更多的实用工具，具有更丰富的数据互操作性场景。另一种方法是元内容框架 ，它将知识表示的思想引入到 Web 系统，并提出进一步使用一种通用的数据模型，即有向标记图。元内容框架的愿景是创建关于实体的广泛知识库，其中不同的部分来自不同的网站。随着时间的推移，这一愿景逐渐涵盖了网络上的各种智能数据处理。
在1997年和2004年之间，产生了结构化数据标记的各种标准(RDF、 RDFS 和 OWL)。许多词汇都用于特定的垂直领域，其中一个被广泛采用的就是 RSS ，它允许用户用自己喜欢的新闻来源定制主页。另一个是 vCard/hCard (通过 CSS class 属性以 HTML 的微格式表示) ，用于在地址簿、电子邮件等程序之间交换信息。后来，hCalendar 也加入了这个项目，它同样是一种微格式的 HTML，重新表达了现有 IETF的标准—— iCalendar。
在发布每一种结构化数据标准的时候，都会有一些应用程序会广泛地使用它。那如果要创建一个跨越垂直领域的结构化数据标准，就要找到一个覆盖面广的应用程序，这个应用程序可能就是文本搜索。
网络搜索不局限于搜索结果的排名，而是要提高搜索结果的质量。用一些结构化数据来标记网页内容，可以优化用户和网站站长的体验。但是，大多数网站根本没有为网站添加任何标记，另外，即使是添加了标记，仍然往往格式不正确。这种大量的不正确格式要求构建复杂的解析器，这些解析器能够处理格式不正确的语法和词汇表。
结构化数据的标记标准：schema.org
2011年，主要的搜索引擎 Bing、 Google 和 Yahoo 创建了 schema. org 来改善这种状况。目标是提供一个涵盖广泛主题的模式，主题包括人、地点、事件、产品、提供等等，一个单一的模式涵盖了这些主题，主要是为站长提供一个统一的词汇表。
2011年后，许多不同公司的不同应用已经开始使用 schema.org 的词汇表。其中包括:
google将schema. org 中的注释用作知识图谱的数据源，提供关于知识实体的背景信息(例如 logo、 contact 和社会信息)。
基于 schema.org 的结构化数据标记正在电子邮件等地方使用。例如，确认酒店预订的电子邮件、购买收据等都嵌入了带有交易细节的 Schema.org 标记。这种方法使电子邮件的辅助工具能够提取结构化数据，并通过移动通知、地图、日历等使其可用。
Pinterest 使用 schema. org 为菜谱、电影、文章、产品或摆放物品提供丰富的依据。
苹果的Siri使用 Schema.org 进行搜索功能，包括聚合评级、优惠、产品、价格、交互次数、组织、图片、电话号码和潜在的网站搜索操作，还在 RSS 中使用 Schema.org 进行新闻标记。
当然，衡量是否成功的一个关键是站长的采用程度。从 Google 索引中可知，大约31.3% 的页面使用了 schema. org 标记。平均而言，每个包含这个标记的页面都会引用多个实体，其中包含数十个逻辑判断。需要注意的是，结构化的数据标记与 Web系统本身具有相同的数量级。在主要搜索引擎中，有超过四分之一的页面使用了Schema.org 的广义词汇表。Schema.org 的成功很大原因在于它背后的设计决策。
schema.org中的一些设计
Schema.org 的驱动因素是让站长可以轻松地发布他们的数据，设计决策将更多的努力放在了标记的使用者身上。
表达的语法
从一开始，schema. org 就在多种语法和向站长提供简洁说明之间寻找平衡。随着时间的推移，多重语法显然是个好方法，包括 RDFa 和 JSON-LD ，数据的发布者可以自行选择。
不同的语法适用于不同的工具和数据模型， JSON-LD是将其中的结构化数据表示为一组 javascript 风格的对象。这对于使用JavaScript 生成的站点以及个性化的电子邮件非常有用，因为在这些电子邮件中，数据结构可能更加冗长。JSON-LD 允许嵌入式的成员在 Schema.org 中携带结构化数据。有时候，可以将这种情况理想化为机器友好格式和人机友好格式之间的权衡。RDF 和 XML 等格式的设计主要为了机器使用，而微格式则明确表示人类优先。
领域的多态
许多知识表示的系统，对每个关系都有一个域和范围。这导致了许多不直观的表达，一个关系的唯一作用可能是某种关系的域或范围，这也使得重用现有关系而不改变类层次结构变得更加困难。允许多个域和范围的决定可能会改善这一问题。例如，schema. org 中有各种类型(Events，reservation，Offers) ，它们的实例都可以接受 startDate 属性，但是多态性使我们避免使用通用的超类型来对它们进行分组。
实体的引用
对于大多数站点来说，协调数以万计的实体与其他站点之间的实体引用太困难了。schema. org 坚持使用惟一的 uri，鼓励数据的发布者向每个实体添加尽可能多的额外描述，以便数据的消费者可以使用此描述进行实体协调。虽然这给来自多个 Web 数据的应用程序带来了额外成本，但它极大地减轻了站长的负担。。
增量的复杂性
通常，如果表示过于简单，会使构建一些更复杂的应用程序变得困难。通常情况下，一旦构建了简单的应用，词汇表也获得了低程度的采用，应用的开发者和站长就会要求使用更具表现力的词汇表，这相当于添加一些更多的描述性属性或子类型。添加新类型的操作或事件是扩展 Schema.org 表达能力的一种强大方法。然而，在许多情况下，很少有正确的答案，Schema. org 的方法不会因为追求完美模式而改变。
清除与扩展
每隔一段时间，可能会引入一些没有意义的词汇，尽管可能会很容易处理，但最好还是把它们清除掉。
Web 底层的结构化数据是多样的，schema. org 最多只能为最常见的主题提供核心词表。即使是对于一个相对常见的主题，比如汽车，也可能需要数百个属性才能从各种网站上找到各种汽车规格的详细信息。schema. org的策略是为这样的主题提供一个小的核心词汇表，并依靠扩展来覆盖长尾问题。
扩展主要有两大类， 一类是由 Schema.org 社区创建的，另一类是仅在“民间”实现。2015年的时候，引入了托管扩展的概念，然而，分层机制的设计是为了让专家和专业组织有更大的自主权。另外是外部扩展的概念，它们是参考 Schema.org 的核心词汇表设计的，期望在核心词汇表的基础上进行构建。
结构化数据标记的其他发展
2006年以来，“链接数据（linked data）”将 W3C RDF 社区的重点从语义网本体论和规则语言转向开放数据和实用数据共享。关联数据联盟已经成功地从各种公共部门和开放数据来源获得了大量RDF表示的开放数据，但RDF 的数据发布做法在网络中还没有被采用。
链接数据的目标更高，网上数据来源的数量很少，但质量往往很高。这为结合这两种方法提供了许多机会，例如，专业团队发布的关联数据往往可以权威地描述来自 schema. org 描述中提到的实体。
使用标识 uri 和独立模式的无约束组合，链接数据可以被视为一个设计极限，另一端的极限可能是知识图谱。在2012年由谷歌提出了知识图谱的概念，作为一个统一的图数据集，用于搜索和相关应用。这个基本思想建立在与链接数据和 schema. org 共享的公共元素之上: 一个具有命名属性类型化实体的图数据模型。知识图谱特别强调前期的实体管理，以确保新数据被整合，且与现有记录相联系。基于共享，用 Schema.org 表示的结构化数据是集成到知识图的自然信息来源。没有人愿意阅读冗长的规范，大多数开发人员倾向于复制和编辑示例。随着时间的推移，复杂性逐步增加，平台/标准中的每一层复杂性只有在采用了更基本的层之后才能添加。
小结
网络基础设施需要结构化的数据机制来描述实体和现实世界中的关系，这个想法一直存在。与其寻求创建“智能代理的语言”，不如从网络搜索中解决具体的场景，人工辅助的结构化数据标记可能是最佳的实用途径。
schema.org 已经开发了更多的词汇，并以更加分布的方式进行。从汽车到产品细节等一系列的主题扩展，提供了一个统一的词汇表和必要的讨论空间。在web系统中，大数据的应用越来越广泛，使得对通用模式的需求越来越重要，探索数据驱动的价值，从不同来源收集数据的需求，对共享词汇的需求在增加，或许这是 schema.org 的价值之一。
【关联阅读】