关联数据注意事项

2015年11月,约翰霍普金斯大学图书馆系统馆员Jonathan Rochkind在离职前2天,发表长篇博文《关联数据注意事项》(Linked Data Caution),表明他对关联数据的认识【参见:知识图谱、语义网、关联数据】。虽然他在总体上对图书馆应用关联数据现状持否定态度,但文章写得相当客观。他并不反对关联数据,他担心的是图书馆界把关联数据本身作为一个目标,并且“基于关联数据、重建围绕数据格式的基础设施(infrastructure)”,而不是以用户为中心的考虑。他认为所有这些问题,很大程度上是受到关联数据倡导者误导,以为更广泛的IT世界都在应用——或许曾经是事实,只是时过境迁?
文章从关联数据入门开始,内容丰富。摘译部分如下。(说明:“我”指原博文作者,【本人标注说明】)

– 什么是关联数据?
一个抽象数据模型——如何建模数据的模型。该模型说,所有元数据将列作一个“三元组”,(1)主体,(2)谓词(或关系),(3)客体。对这些数据元素,尽可能首选使用标识符,尤其是URI形式的标识符。URI作为标识符很好,因为基于域名,有很好“命名空间”途径以避免冲突,是全域标识符。
如同任何数据建模,仍然需要“领域模型”——你关心实体的正式清单(图书、人物),这些实体有什么特性、属性及相互关系。在图书馆世界,甚至在有计算机前,我们一直在创建这些正式的领域模型。我们称之为“词表控制”或“规范控制”。在关联数据中,领域模型采用形式为实体、属性和关系的标准共享URI标识符。为属性或关系建立有某种含义的标准共享URI,是基本的“词表控制”,而为实体建立标准共享URI,则是基本的“规范控制”。仍然需要通用词表,让关联数据可互操作。

– 语义网vs关联数据?vs RDF?【基本上是同义词】
RDF代表“资源描述框架”,实际上是“三元组”的抽象数据模型的官方名称。然后“关联数据”可理解为使用RDF和URI的数据,“语义网”是由很多人使用形成的生态系统。

– 实际上想做什么?用户在哪里? 【略】

– 其他人真的做吗?也许没有
【1】谷歌在检索结果的丰富片断(rich snippets)和侧栏事实即知识图谱中使用。但谷歌为其知识图谱收割的大部分数据源实际上不是关联数据,而是谷歌收割、内部转为关联数据——然后实际上曝光关联数据化(三元组化)数据到更广泛的世界。
【2】Talis【图书馆2.0时代的著名英国公司】在2000年代中战略中心开始转向语义网/关联数据。2011年,他们实际上售出其图书馆管理部门,主要专注语义网技术。但很快在2012年,他们宣布“语义网和数据市场领域投资将停止。现在所有工作集中在教育行业。”【主导者Richard Wallis在2012年4月去OCLC,2015年7月离开】
【3】2009年《纽约时报》兴奋宣布一项计划,曝光其内部主题词表为关联数据。虽然数据仍在,但在我看来已在2010年放弃。
【4】在语义网/关联数据全盛期的一对大关联数据的数据库:Freebase始于2007年,在2010年被谷歌获得…2014年关闭;DBPedia开始更早、仍然存在…但不再引起激动与buzz。较新的WikiData(2012)仍然存在,被视为Freebase的后继者。人们普遍承认,这些项目都没有达到最初的希望,即导致实际有用的面向用户的产品或服务,仍然是实验。
我的感觉是:一般业内理解,关联数据不像人们在2007-2012年全盛期所想那样,事实上采用已减缓且逆转(谷歌趋势图)。 【 参见:语义网还是个事儿吗?
事实上,图书馆及其同盟文化遗产部门,以及来自政府机构(尤其是英国)及学术出版(主要是Nature)的有限参与,是当前关联数据研究与实施的主要驱动者。我们是关联数据研究的某些领导者,我们不是跟随私营部门。在“信息检索”领域,图书馆作为研究与实施感兴趣及有用技术的驱动者,并没有什么错误——40-80年前,本行业在信息检索技术中是领导者,它将再次如此,当然高兴!但是我们不应该以“其他人都在做”作为我们活动的动机或理由——并非因为主要web参与者正重度投资于此(他们没有),这一定是个好主意;并非如果我们转换所有我们的基础结构到关联数据,因为所有人都这将这么做(他们不一定,并且大家都使用关联数据并不足以互操作,还需要在词表上协调,只是开始),我们就能以我们想要的方式与其他人互操作。

– 我在数据与服务互操作挑战上的经验 【9方面的例子】
过去7年多,我的主要工作是在图书馆环境中,参与集成来自不同系统、厂商和来源的服务与数据。……有些问题很适合关联数据。
但是,在我的经验中,几乎没有问题只需简单转换基础架构到关联数据,就能提供解决方案或基础进步。障碍经常在其根的商务模型(实体有你要互操作的数据,但不想共享它们的数据,因为保持封闭对他们具有商业价值;或者只是没有商业兴趣投资于需要更好分享数据的技术);或者缺少共享的领域模型(词表控制);或缺少人力创建/记录机读格式所需的数据。
关联数据既非必须也不足以解决我碰到的大多数实际障碍。简单转换到基于关联数据的基础设施,而不处理商业或领域模型问题完全没有帮助;不需要关联数据来解决商业或领域模型问题,也不清楚对此的帮助:主要的关联数据运动可能不是解决这些问题最有效、最具费用效益或最快速的方法。
以下是一些例子。
【1】我们有什么连续出版物馆藏?【需要机器可操作的馆藏记录格式】
【2】记录中缺少OCLC号或其他标识符【有共同的标识符,无需LD就可以做很多事】
【3】数据陈旧/准确性
【4】难以由数据获取格式/形式信息,表达用户所关注的【识别资源的格式/体裁】
【5】工作集分组和关系【FRBR化】
【6】馆藏/许可信息的多来源馆藏/许可信息的多来源
【7】谷歌图书不链出
【8】OpenURL,被时光冻结的标准【不再有人维护了?】
【9】从开放Web链接到图书馆复本

– 为什么人们对关联数据如此兴奋?
【从众心理】没人会因为买了IBM被开除
【真实信徒】尽管在图书馆界有关联数据咨询者,说服你全力投入关联数据而获利(自有所指)
我认为,图书馆决策者知道我们“需要把我们的东西放在谷歌中”,并被告知“关联数据”是这么做的一种途径,但对“在谷歌中”意味着什么没有清晰的图景。如我已经说的,我认为谷歌在关联数据上的投资或投入被夸大了,但确实schema.org标记可被谷歌用于丰富片断或知识图谱事实盒。我实际上同意,我们图书馆网页应该使用schema.org标记,以机器可读标记曝光其信息。对图书馆信息网页,现在这会有比目录页还强大的结果(丰富片断)。并且对目录书目页这么做也不难,不需要重建我们整个基础设施,我们的MARC数据就这么能相当简单地对照到schema.org,如Dan Scott已经用VuFind、Evergreen和Koha有效证明了How discovery layers have closed off access to library resources, and other tales of schema.org)。是的,所有我们的“发现”网页应该这么做。Dan Scott报告说,那没有很大效果,但如果每个人都这么做会(有效果)。

– 我们应当做什么?
【1】保持怀疑。当然,对我也是。
【2】自学有关元数据技术【不被忽悠】
【3】把图书馆当作IT组织(至少大学图书馆是)。
【4】保持用户中心。“关联数据”不能成为你的目标。
【5】包含schema.org标记在你的网页和目录/发现页。为了曝光给谷歌,或其他人。
【6】避免以“是否支持关联数据”作为评估问题。
【7】在数据中放置标识符。我不在意它是不是作为URI,但是的,确保每条记录有一个OCLC号。是的,每条书目应该记录LCCN或其他标识符,关联到创作者规范记录,不只是标目。这是我无保留支持的“关联数据”建议。
【8】你应该信任谁?不信任任何人,呵呵。不过如果你要我的个人建议,注意Diane Hillmann,看她的博客
【9】要求关联数据计划产生迭代增量【即一开始就有成果并逐步增加,而不是到遥远的未来才能显现效果】