BIBFRMAE应用进展:LD4P实施之路

BIBFRAME正迈向应用阶段,似乎离成为现实已经不远了。最近的两大进展:
一是LC的BIBFRAME第2阶段测试,直接以BIBFRAME编辑器进行编目,已进行了一年,并于上月发布了包括LC的MARC规范记录和书目记录转换的全部BIBFRAME描述数据集,供其他机构下载测试使用。参见:LC提供BIBFRAME描述数据集批量下载(2018-6-20)。
二是斯坦福等高校的LD4L系列项目(http://www.ld4l.org/),致力于由MARC过渡到关联数据,在2014-2016年的LD4L、2016-2018年的LD4L-Labs和LD4P之后,又争取到了梅隆基金为期2年LD4P第2阶段项目,名为“实施之路”(Linked Data for Production: Pathway to Implementation,没有查到直接信息)。
作为项目的一部分,LD4P正建立沙盒,与合作编目项目(PCC)合作,为所有PCC成员创建基于云的沙盒,以实验创建基于BIBFRAME的元数据。项目希望在原核心成员哥伦比亚大学、康奈尔大学、哈佛大学、LC、普林斯顿大学、斯坦福大学、爱荷华大学之外,征求更多PCC成员深度参与(称为LD4P Cohort,合伙人),将某些基于MARC的工作流程转换到以关联数据为基础的工作流程。申请需符合项目提出的最低要求,获准后可得到最高5万美元的子项目资助。

在上月ALA年会上ALCTS举办的“在真实世界中实施关联开放数据”(Implementing Linked Open Data in the Real World)会场,斯坦福大学的Philip E. Schreur介绍了本项目。
在BIBFRAME邮件组(论坛)的本项目邀请参与的附件(Proposal Request to Join the LD4P Cohort)中,有本项目的7个目标
1. 创建连续馈送的关联数据池,以基于BIBFRAME的应用纲要表达。
2. 开发扩展的图书馆合伙人(LD4P合伙人),能够通过创建基于云的沙盒编辑环境来创建和重用关联数据。
3. 开发用于以标识符自动增强MARC数据的政策、技术和工作流程,以使其尽可能清晰地转换为关联数据。【在前述最低要求中,最后一条是:在可行的情况下,将URI合并到MARC记录子字段$ 0s和$ 1s中】
4. 开发用于创建和重用关联数据及其支持标识符作为图书馆核心元数据的策略、技术和工作流程。
5. 通过与Wikidata的协作,更好地将图书馆元数据和标识符与Web集成。
6. 使用基于关联数据的发现技术,增强广泛采用的图书馆现环境(Blacklight)。
7. 通过开发一个名为LD4的组织框架,协调持续的社区协作。

via [BIBFRAME] Invitation to Join the LD4P Cohort / Philip E. Schreur (2018-7-5)
关于LD4L系列项目,参见:
重量级图书馆关联数据项目LD4P获得资助(2016-5-10)
BIBFRAME扩展:bibliotek-o(及ArtFrame和RareMat)(2018-5-1)

另:作为LD4P项目成果,“艺术和珍本资料BIBFRAME本体扩展”向BIBFRAME提出了很多修订建议,提交在BIBFRAME本体开发的Github网站“问题”部分,并统一标注:”This recommendation was made on behalf of the LD4P Art & Rare Materials BIBFRAME Ontology Extension (https://github.com/LD4P/arm).”。简单说明见:[BIBFRAME] Art & Rare Materials BIBFRAME feedback – GitHub Issues / Jason Kovari (2018-7-5)

2018年国际关联数据实施者调查

OCLC研究部在2014和2015年进行了2次关联数据实施者调查,调查结果都曾公布,原始数据(除联系信息)也在网站提供(Results of Linked Data Surveys for Implementers, 2014 & 2015)。
参见:
OCLC 关联数据项目调查结果:机构、成果、消费、发布、技术、建议(2014-9-25)
关联数据应用现状:2015国际关联数据实施者调查的分析(2016-9-4)

目前,OCLC研究部正进行2018年国际关联数据实施者调查(International Linked Data Survey for Implementers 2018),调查对象是已经实施或正在实施关联数据项目或服务的工作人员,可以是将数据发布为关联数据、也可以是将关联数据资源摄入自己的数据或应用程序中。项目可以是未参加过先前调查的、也可以报告先前实施项目的变化。截止日期为2018年5月25日
调查内容略多,虽然不是所有问题都必填,还是需要对项目各方面有比较全面深入的了解。好在填写时不需要一次性完成,也不限当天,只要是同一台电脑、同一个浏览器,在点击最后的“Done”提交前,都可以用“Prev”“Next”修改填写内容。
希望这次能够看到国内的关联数据项目参与调查

酷URI、内容协商与解引

BIBFRAME还没开发完成,关联数据/语义网中的URI有可能在MARC记录中率先使用?至少美国合作编目计划(PCC)已经开始实质性行动。参见:
创制和获取URI的常用词表和参考源指南(2018-3-2)
编目常见URI问题:什么时候开始用?RWO又是什么?(2018-3-7)

在PCC的《URI常见问题》(URI FAQs, 2018-2-6)中,几次提到W3C文件《语义网的酷URI》。为更清楚地理解URI,找来仔细阅读。然后发现此文件中其实并没有解释《URI常见问题》中提到的dereference,因此又找到另一个W3C文件(见后)作为补充。以下为若干摘译(括号中数字为《语义网的酷URI》小节号)。

Cool URIs for the Semantic Web (W3C Interest Group Note, 03 December 2008)
摘要:资源描述框架RDF允许用户以计算机可处理的方式描述Web文档真实世界中的概念——人物、组织、论题和事物。在Web上发布这样的描述会创建语义Web。URI(统一资源标识符)非常重要,既提供了框架本身的核心,又提供了RDF和Web之间的链接。本文件提供了其有效使用的指南;讨论了两种策略,称为303 URI和散列URI;给出了使用这些解决方案的几个网站的指针,并简要讨论了为什么其他几个方案有问题。

URI】(1)
在语义网上,所有的信息必须表达为关于“资源”的陈述资源由“统一资源标识符”(URI)标识。这种建模方法是“资源描述框架”(RDF)的核心。

内容协商】(2.1)
Web客户端和服务器使用HTTP协议请求Web文档的表示并发回响应,HTTP具有强大的称为“内容协商”的机制来提供相同Web文档的不同格式和语言版本
当用户代理(如浏览器)发出HTTP请求时,会随某些HTTP标头发送,以指示它喜欢的数据格式和语言。服务器然后从其文件系统中选择最佳匹配或按需生成所需内容,然后将其发送回客户端。
内容协商往往是一种扭曲的实现:服务器不是直接回答,而是重定向到找到适当表示的另一个URL。重定向由一个特殊的“状态代码”[响应码]表示。

酷URI】要求(3)
1、在网上:给一个URI,使用标准Web传输协议HTTP,机器应该获得RDF数据,人类应该获得可读的表示如HTML。
2、无歧义:Web文档的标识符与其他资源的标识符之间不应混淆,一个URI不能同时代表一个Web文档和一个真实世界对象。

Web文档 vs 真实世界对象】(3)
Web文档 = 信息资源】根据《万维网的体系结构》第一卷,如果其所有基本特征都可以在消息中传达,则我们有一个Web文档(称为“信息资源”),如网页、图像或产品目录。
真实世界对象 RWO = 事物 Thing】如人和汽车,甚至抽象的想法和不存在的事物,如神话中的独角兽。

酷URI】设计要求(4.5)
1、简单性:简短助记。
2、稳定性:尽可能持久不变。
3、可管理性:如URI路径包含年份、可以每年更改URI模式而不影响旧URI;再如保留所有303 URI在专用子域上以简化未来迁移。

真实世界对象URI的2种解决方案】(4):
1、Hash URI(#):如 http://www.example.com/about#alice
适用于相当小而稳定的资源集合,如RDF Schema词表和OWL本体。只需简单上传静态RDF文件到Web服务器、无需任何特殊配置,适合快速发布RDF。
2、303 URI(303 See Other 重定向):
转发到通用文档,如:http://www.example.com/id/alice
重定向到:http://www.example.com/doc/alice,再经内容协商,
向机器提供:http://www.example.com/doc/alice.rdf
向人提供:http://www.example.com/doc/alice.html
转发到不同文档,如:http://www.example.com/id/alice(Alice这个人的标识符),重定向经内容协商,
向机器提供:http://www.example.com/data/alice(描述Alisce的RDF文档)
向人提供:http://www.example.com/people/alice(Alice的主页,Web文档)
以上3个文档在内容中当提供互相链接、揭示文档间关系(4.6)

内容协商 Content negotiation vs 解引 dereference】(译自:Best Practice Recipes for Publishing RDF Vocabularies, W3C Working Group Note 28 August 2008)
[按PCC的URI FAQ 5:解引,即检索由URI标识的资源的一种表示] 当一个HTTP客户端尝试解引一个URI时,可以指定优先接收响应哪类内容,通过在请求讯息标头中包含Accept:字段……。当服务器接收一个请求,它能使用Accept:字段的值,选择最合适的可用响应,尝试尽可能满足客户端的首选。这个过程即内容协商的一个实例

——— 附:响应码(response code)、Cool URI ———
关于HTTP URI消除歧义的简单规则,转引本文件之参考文献中的建议:
[httpRange-14] Resolved, Roy Fielding. 18 June 2005. http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039.html.
a)如果一个“http”资源对一个GET请求的响应码是2xx,那么被那个URI标识的资源是一个信息资源;【Web文档】
b)如果一个“http”资源对一个GET请求的响应码是303(See Other),那么被那个URI标识的资源可以是任何资源
c)如果一个“http”资源对一个GET请求的响应码是4xx(错误),那么这个资源性质未知

为什么称“酷URI”?源自Tim Berners-Lee的文章:
Cool URIs does not change Cool URIs don’t change, Tim Berners-Lee, 1998. http://www.w3.org/Provider/Style/URI.
什么让URI很酷?
酷的URI是不变的URI
什么样的URI会变?
URI本身不变:是人改变了它们。

via Cool URIs in a RESTful World / by Thomas Bandholtz on Apr 08, 2008
中译版:RESTful世界里的Cool URI / 译者 王锐 发布于 2008年4月16日【上述译文略有修改】