Schema.org: Web上结构化数据的演变(笔记)

来自谷歌和微软的三位Schema.org开发者,2015年底发表了一篇介绍四年来Schema.org演变的文章,在追求“结构化数据”的大背景下,详述开发的前因后果,以及与关联数据的关系:

R.V. Guha, Dan Brickley, Steve Macbeth. Schema.org: Evolution of Structured Data on the Web. Queue vol. 13, no. 9 (December 15, 2015)

文章小标题:Big data makes common schemas even more necessary.
体现在文章结论的最后:“对大数据的增长兴趣使得对共同schema的需求比以往更相关。当数据科学家探索数据驱动分析的价值,需要从不同来源把数据抓在一起,因此对共享词表的需求正在增长。我们希望schema.org将对此有所贡献。”

【结构化数据标准的发展】
早期(1997年前?)有XML和MCF (Meta Content Framework)。
1997-2004年间针对语法和数据模型开发了不同的标准(RDF、RDFS和OWL)。针对具体行业提出许多词表,某些得到广泛采用,如hCard、FOAF。不同垂直领域的词表完全独立,导致大量重复和混乱。更糟的是,不同搜索引擎推荐不同的词表。
针对此问题,2011年主要搜索引擎公司Bing, Google, Yahoo(及后来加入的Yandex)创建Schema.org,目的是提供跨领域的单一词表。最初是三个公司关起门来做决定,后来逐步开放,先是在W3C公共论坛讨论,后来改变模式为所有决定都公开做出[在GitHub上],有一个来自资助公司、学界及W3C的指导委员会。
Schema.org发布时297个类、187个关系,四年后增加至638个类、965个关系。

愿景图“来自多个网站的知识库样例”比以前看到过的图更具说明性

【Schema.org应用】
– 首个应用是谷歌搜索结果的丰富片断(Rich Snippets)在2011年转用Schema.org词表。[snippet最早由雅虎采用、谷歌跟进,当时依据垂直领域词表]
– 用作谷歌知识图谱(Knowledge Graph)的数据源,显示在检索结果侧栏的事实面板。
– 电子邮件。预订饭店、旅馆、航班等电邮嵌入Schema.org标记,电邮辅助工具可抽取结构化数据,通过手机通知、地图、日历等使用。Gmail和Google搜索产品使用此数据提供提醒,如订餐会基于饭店位置、用户、交通状况等,触发提醒去饭店。
微软小娜(Cortana)通过电邮讯息利用schema.org
Pinterest利用Schema.org提供针对菜谱、电影、文章、产品或地点的丰富钉板(rich pins)。
苹果的Searchlight/Siri使用Schema.org提供搜索特性,包括集成评分、供应者、产品、价格、互动计数、机构、图像、电话号码及潜在的网站搜索行动。还用于新闻RSS。

【采用统计及原因分析】
在100亿网页的样本中,31.3%网页有Schema.org标记,1年前是22%。含有标记的网页平均参引6个实体、作出26个逻辑断言。估计至少1200万网站使用Schema.org标记。结构化数据标记现在与Web本身是一个数量级的了。
快速增长的原因是第三方工具的扩展支持,如Drupal和Wordpress,以及垂直内容管理系统(如Bandsintown和Ticketmaster)。

【设计决策:成功原因分析】
设计Schema.org的驱动因素是方便站长发布其数据。总体上,设计决策把更多负担放在标识的消费者。
– 支持多种语法:RDFa、JSON-LD、Microdata
– 多态性:关系/属性可以有多个定义域、多个值域(减少不必要的类)
– 实体参引:只有非常少的部分要求唯一URI
– 增量复杂性:从简单开始,逐步增加表达性。受实用性引导,定义从不为追求完美模型而改变,但回应来自发布者和消费者的反馈。
– 清理:清除无有意义使用的术语[类似文献保障原则]

【扩展】
保持最通用为核心,其他作为扩展。
参见:Schema.org扩展机制(及汽车&书目扩展)

———-关联数据的分割线———-
【对关联数据现状的基本判断】
自2006年,“关联数据”口号重定向W3C的RDF社区,从强调语义网本体和规则语言,到开放数据活动和实践数据共享。
关联数据宣传已经成功地从各种公共部门和开放数据源引起了大量以RDF表达的公开数据(如图书馆、生命科学和政府)。但是,强调标识符调和、复杂的最佳实践规则(包括HTTP的高级使用)、使用任意数量的部分重叠词表(schema),限制了关联数据实践在专业信息管理者以外领域的成长。关联RDF数据发布实践没有在广泛的Web得到采用。
(与“从语义网到知识图谱——语义技术工程化的回顾与反思”文章的认识一致。参见:知识图谱、语义网、关联数据;另见:关联数据注意事项

【与关联数据的异同】
Schema.org分享很多关联数据社区方法:使用相同的数据模型和标记语言(RDFS)和语法(如JSON-LD和RDFa),分享很多相同的目标。也分享了关联数据社区对语义网旗下实施的很多学术工作中发现的对过早成熟的形式主义的怀疑(规则系统、描述逻辑等)。尽管Schema.org也避免假定这类基于规则的处理会是普通的,但它不同于典型的关联数据指引,假定来自Web的结构化数据能在应用中利用前,通常会需要不同类型的清理、调和及后处理。【换言之,对Schema.org,数据清洗不是必要的——想起情报检索语言的前控和后控】

关联数据的目标更高,并因此带到Web的数据源数量很小、然而其质量往往很高。这两种方法相结合提供了很多的机会——例如,专业发布关联数据常能规范描述来自更广泛主流Web的schema.org描述中提及的实体。【公共部门继续承担需要更多费用的专业工作】

知识图谱、语义网、关联数据

2014年时,约翰霍普金斯大学图书馆系统馆员Jonathan Rochkind写了篇博文:语义网还是个事儿吗?当时我作了译介(2014-11-8)。一年后他离开了已经工作9年并且热爱着的图书馆,去了一家软件公司就职。发消息前两天他写了长篇博文《关联数据注意事项》(Linked Data Caution),用众多事实佐证自己先前的看法。在离开博文中,他说自己身心俱疲(Career change, 2015-11-25),不是因为关联数据而离开,但那篇博文可作为他的临别赠言。可以看出他对图书馆前景的深度失望,以及对图书馆界在关联数据上投入巨大的深度担忧。

今天看到鲍捷的《从语义网到知识图谱——语义技术工程化的回顾与反思》,让我又想起Jonathan Rochkind和他对关联数据的看法。计算机领域变化太快,不同观点太多(或者说共识少,要不然也不会有那么多死在沙滩上的前浪),鲍文的观点有待验证。无论如何,作笔记如下。

———从语义网到知识图谱——语义技术工程化的回顾与反思(笔记)———
– 基本观点:“语义网”这两年改名“知识图谱”;工程优于科学【逻辑】。
关于关联开放数据:Tim Berners-Lee(就是我们的神)呼吁:语义网 -> (因为感觉走偏)2006年提出关联数据 -> 2009年公开数据(用RDF结构化)。
关于元数据和知识图谱:元数据 -> 演变成RDF -> 然后演变成一堆奇奇怪怪的语言 -> 然后是schema.org【一统天下?】 -> 最后演变到了今天的知识图谱。
关于RDF:RDF不适合作为存储语言。
RDF的发展:知识的交换语言 -> 数据建模语言 -> 数据存储语言。作为存储语言,由于要完全从头开发,高成本低性能而失败。
2013年Google推目前知识图谱用的Microdata,后来JSON-LD,充分利用现有工具。
存储语言:RDF数据 -> 图数据库(键值数据库?)。图数据库比三元组库和SPARQL更主流。
【乱弹:如此则RDF与MARC倒是很类似,是交换语言而非存储语言。ILS内部并不按MARC格式保存】
关于本体语言OWL和RDF1.1:弱语义的语义网,优于强语义的OWL。
OWL2语言很失败、没人用。
2004的RDF语义是怪胎,2014年RDF1.1是厄运的开始。【在计算机界,常见不同版本并用,并非未及升级,如当年的RSS】
逻辑或推理非常需要成本,在实践中很少使用。大多数时间有数据就够了,有一个结构化的东西就好。
Dublin Core等没能发展起来,因为都是面向机器的,它考虑的是怎么提高机器的效率。RSS想的是我怎么提高人的效率,这样就火起来了。【图书馆界在说要让机器能够用数据,他说要让人用得高效】
构造知识图谱,需要知识工程的技术,需要自然语言处理的技术,需要规则系统,需要正则表达式。有效的才是最好的。

——— Google趋势:知识图谱vs语义网vs关联数据———
在先前博文中语义网(SW)和关联数据(LD)搜索对比基础上,增加知识图谱(KG)做对比。Google搜索趋势显示,在SW下降与LD上升趋势交汇后的2012年5月,KG异军突起超出SW和LD,2012年12月出现第2个超出SW和LD的峰值,其他时间均在两者之下,搜索量起伏不大。SW仍持续下跌,LD则平稳起伏。

Google Trends: KG,SW,LD

另看国家趋势
KG前五:印度100、美国60、德国50、英国47、法国39(没有其他国家)
SW前五:韩国100、巴基斯坦98、印度87、奥地利85、爱尔兰/伊朗74,(英国37、美国30)
LD前五:印度100、巴基斯坦68、菲律宾28、英国/美国均21

FRBR、RDA和BIBFRAME词表的RDF推理测试

有关新兴的书目RDF词表的正式论文不多见。因此当看到远洋老师在书社会Keven日志的评论中推荐此文时,马上下载,然后花了几个晚上阅读、消化此文,对RDF词表有了与先前不同的理解。

《语义网中资源描述的多实体模型:FRBR、RDA和BIBFRAME比较》
Baker, T., Coyle, K., & Petiya, S. (2014). Multi-entity models of resource description in the Semantic Web: A comparison of FRBR, RDA, and BIBFRAME. Library Hi Tech, 32(4), 562-582. doi:10.1108/LHT-08-2014-0081 (Preprint)

原文摘要:新兴图书馆标准中,书目描述正采用多实体模型,描述从概念性作品到物理单件的不同抽象层。其中三个已发布为使用语义网标准RDF的词表:FRBR、RDA和BIBFRAME。作者使用通用的语义网可用软件,测试了基于这三个词表的RDF数据。分析证明,这些模型意图的数据结构不被RDF词表支持。在某些情况下,这导致词表间不受欢迎的不兼容,在Web的开放数据环境中对互操作是一种损害。

文章含脚注及参考文献共18页(期刊版20页),读完后对文章概要、一些基本概念及作者的观点备注如下(有时很难分清是作者观点还是基本概念):
1、文章概要
文章分别使用FRBR、RDA和BIBFRAME词表,设计若干非正统数据样例,用RDF推理机测试,结果表明(FRBR词表)类的互斥会造成问题,而(RDA和BIBFRAME词表)属性与类的非一对一“错误”并未被检测出来(换言之虽不符合词表定义及其校验目的,但未影响到实际使用)。文章没有直接做三种词表的比较。
2、关于RDF词表
(1)RDF类不定义属性;RDF属性独立于类,原则上可用于描述任何类的实例。
(2)基于推导的RDF语义在本质上是提供(增加)信息的。RDF定义域声明允许推理机简单推导:以一个属性描述的资源,也是该定义域类的成员。
(3)OWL公理(类成员、基数、互斥)不是数据检验约束。RDF类不支持数据结构校验。新兴的RDF检验方法会在RDF词表本身之外表达这些约束。
3、关于书目RDF词表
(1)目前的多实体书目模型的RDF词表,概念化书目事物(thing)为属于不同RDF类的资源集。
(2)FRBR定义类互斥。当描述类的实例的数据必须与描述完全不同类的实例的数据集成时,互斥会造成问题。
(3)定义的约束越少,RDF词表越可重用。从质量控制需求,对书目数据的校验约束应该采用应用纲要等方法,独立于词表表达。