电子资源的开放知识库:GOKb和KB+

这里的“知识库”特指电子资源数据库中包含的title list,含各title的基本信息(如起讫时间、访问网址)。title可以是期刊(不含刊载的论文),也可以是图书。由于数据库商可能在不同国家为不同机构提供定制(如英国的JISC、国内的DRAA),因而同一厂商的同一数据库,会有很多大同小异的包,甚至有可能title的访问网址也不相同。

知识库是电子资源一站式查询、跨库检索或发现系统的基础。为避免重复工作,英美有机构提供统一维护或开放的知识库。以下GOKb和KB+均以CC0许可提供数据库包信息下载,这意味着可以不加引用地任意使用。

GOKb : Global Open Knowledgebase 全球开放知识库
由社区维护的开放数据平台,持续更新中。目前收录title超过179万、442数据包,可通过API使用,或者免费注册后浏览与下载。下载格式 TSV 或 KBART。未来打算发布为关联数据,通过SPARQL使用。

KB+ : KnowledgeBase +
KB+向 UK Access Management Federation 成员提供在线服务。知识库由JISC员工集中维护,向机构提供订购电子资源管理相关的数据。KB+中很多数据以CC0许可提供公开下载。现有1445个收录资源不等的包,下载格式 CSV、XML、JSON 或 KBART II。

这两个项目的背后,都由Knowledge Integration Ltd(知识集成公司)提供软件开发支持。公司网站对GOKb的介绍称其2012年上线,由Kuali OLE 和 Jisc 共同承担,得到安德鲁梅隆基金部分资助,北卡州立大学领导。

附:中科院文献情报中心 联合目录集成服务系统:电子资源知识库(2009年)
电子资源知识库获中国科学院文献情报中心项目支持,2008年5月启动,2009年4月投入使用。联合目录数据库建立的电子资源知识库是基于联合目录,针对联盟图书馆和多分馆系统的知识库,支持成员馆电子资源的集成、动态更新和动态发布。由于电子资源知识库的支持,联合目录集成服务系统通过独特的情景敏感链接和印本资源、电子资源的集成揭示,可以使用户方便地获取许可电子资源的全文,同时了解中国科学院所属图书馆关于该资源印本和电子的收藏情况,及国内400余家图书馆关于该资源印本的收藏情况。
目前电子资源知识库存储着来自300余家出版社的9,000余种电子期刊的描述信息和链接信息,近60万条电子期刊馆藏信息(包括年卷期);150余个数据库(包括Elsevier、Springer、Wiley-Blackwell、IEL、ACS等重要的全文数据库和文摘数据库、工具型数据库、数值/事实/指标数据库、多媒体/数字音乐数据库等)的描述信息和链接信息;开放获取数据库和期刊的描述信息和链接信息。联合目录数据库将集成院外电子资源,电子资源知识库中存储的数据还将进一步增加。

BIBFLOW项目最终报告发布:BIBFLOW路标

2014年初ALA仲冬会议上,加州大学戴维斯分校 Michael Colby 介绍该馆刚得到IMLS资助为期两年的项目“编目再发明:未来图书馆运作模式”(Reinventing Cataloging: Models for the Future of Library Operations)(ALA 2014仲冬会议中的BIBFRAME,2014-2-5)。算一下的话,项目应该在2016年初完成。
当时没有BIBFLOW这个名称。在IMLS网站,无论是“BIBFLOW”还是“Reinventing Cataloging”都查不到。通过校名,查到2013财政年度的这个项目(金额$493,619) :LG-06-13-0201-13
Program: National Leadership Grants for Libraries
The University of California Davis University Library will investigate the future of academic research library technical services by assessing the current landscape and developing a roadmap for strategic planning and investments in the coming years. This roadmap can be continuously updated as new data models, standards, workflows, and practices emerge and evolve. Currently, complex workflows and interdependent systems have constrained academic libraries from fully leveraging the benefits and efficiencies of modern technological infrastructures. This research study will include acquisitions, licensing, cataloging, processing, digitization, and newly identified areas that will encourage using technological resources.

虽然并未提到BIBFRAME,但应该就是BIBFLOW项目了(研究性大学图书馆技术服务的未来)。而其中提到的Roadmap,也终于在2017年3月14日完成,并于日前在项目网站发布,悄悄地。一直关注此项目的 Jeff Edmunds 本月初在 BIBFRAME 邮件组发布了消息。
BIBFLOW: A Roadmap for Library Linked Data Transition (Prepared 14 March, 2017) / MacKenzie Smith, Carl G. Stahmer , Xiaoli Li, Gloria Gonzalez
I. 导论
II. 为什么关联数据
III. 转变基础
IV. 路标概述
V. 阶段一:MARC生态系统中的关联数据 。V.a 步骤一:关联数据查找MARC编目平台 ;V.b 步骤二:MARC 批插入 URI;V.c 步骤三:关联数据导入/导出 API;V.d 阶段一完成
VI. 阶段二:转变到原生关联数据生态系统 。VI.a 步骤一:发起转变到关联数据原生编目 ;VI.b 步骤二:批转换遗留MARC记录;VI.c 步骤三:迭代转换非目录图书馆系统
VII. 转变工作流程 。VII.a 套录 ;VII.b 原编;VII.c 连续出版物编目;VIII. 规范控制
IX. 厂商参与
X. 发现
XI. 当前图书馆关联数据实施调查
附录A:厂商参与态势
附录B:术语词汇

此次发布的报告是网页形式,数十个页面链接,看起来很是不便;其中有不少图示,分辨率更是低到完全看不清。Roy Tennant 自告奋勇转换成了PDF文件,并放在他自己的网站上供下载,但对看不清的图示就无能为力了。其中二阶段各三步骤的转换路标(conversion roadmap)还勉强能够看清:

Figure 6: Transition process overview

摘录报告部分段落:
“本报告的主要发现是,图书馆转变到关联数据,处在比大多数人相信的更好位置。更广的关联数据生态系统和语义网,总体上建立在对实体(人物、地点等)和行动(写作、获取等)的共享唯一标识符的基石上。图书馆具有很长的共享数据治理和标准的历史,因此图书馆文化很适合转变到关联数据,图书馆的结构化数据(MARC)处在很好的数据转换位置。鉴于上述情况,我们的结论是,关联数据代表着机会而非挑战,本路标意在作为希望抓住这一机会的图书馆的指引。”(I. 引言)
“MARC和关联数据编目框架的关键差异是,MARC基于记录,而关联数据基于图谱 (graph)。不同于理论上无限的知识图谱,记录有着固定数量的字段和子字段。……扩展框架的唯一途径是,通过一个复杂的、自上而下的驱动过程,由许多机构与治理团体参与讨论与采用,接着重新编程处理这些记录的所有软件系统。 ”“基于图谱的知识系统则不受制于任何以上局限。它们可强化使用信誉良好的受控词表描述对象的能力,同时提供可扩展性,让用户增加新知识节点(字段)到其描述图谱。”(II. 为什么关联数据)
转变到关联数据并非数据转换活动……转变到关联数据要求增加新数据到每一条记录,数据常会难以由机器消歧。特别是,成功的转变到关联数据生态系统,要求在转换时增加大量共享的公开承认的唯一标识符(URI)到每条记录。基本概念是,在一个图谱中为所有实体提供一个唯一的、机器可操作标识符。”“从数据角度,转变到关联数据的主要障碍,是将MARC记录中实体的文字表达,与机器可操作URI联系起来。这种联系必须反向实施到所有遗留记录(艰巨任务),必须更新图书馆系统,在处理新记录或编辑已有记录时创建这种联系……”(III. 转变基础)

MARC到BIBFRAME转换:并列比较工具

上月美国国会图书馆(LC)公布了BIBFRAME2.0词表更新、相关组件,其中包括MARC字段到BIBFRAME2.0的转换对照表(MARC 21 to BIBFRAME 2.0 Conversion Specifications)。近日,LC以提供了MARC到BIBFRAME转换的并列比较工具,可以直观浏览一条MARC记录转换为BIBFRAME记录后是什么样子的:

BIBFRAME Comparison Tool — Compare MARCXML to BIBFRAME2
提供2种查询记录的途径:书目记录ID(001字段)或LCCN控制号(010字段)
BIBFRAME2的序列化方式2种可选:Turtle 或 RDF/XML(默认前者)

该工具副标题“从MARCXML到BIBFRAME2”,但目前展示的是MARC编辑界面,并非MARCXML。这是由于实际转换工具是由MARCXML转为BIBFRAME的,即需要先经过早年的转换工具将MARC转换为MARCXML。选择显示MARC而非MARCXML,应该是由于对编目员来说,其可读性和简洁性上更高。

默认样例为BIB ID=5226/LCCN=82060878,非RDA记录。看BIBFRAME记录,大致区块为以下6大类:
1 作品 ,包含:
– 题名(首选题名)
– 管理元数据(头标/0XX部分)
– 分类号(050/082)
– 008部分代码
– 贡献(1XX/7XX,连接“施事者”)
– 连接“实例”
– 连接“主题”
2 实例 ,包含:
– 著录(2XX-5XX)
– 008部分代码
– 连接“馆藏”
– 连接“作品”
3 馆藏(050LC索书号)
4 主题(6XX)
5 施事者(1XX/7XX)
6 各类代码值,定义所属“类”,用于以上各类的属性取值,多为头标/0XX的代码。

样例中可以看到几处bflc: 命名空间(BIBFRAME的LC扩展)的使用,应该都是为转换处理而临时设置的:
编目级别(管理元数据):bflc:encodingLevel a bflc:EncodingLevel ;【头标17,#=f/full】
贡献(作品):bf:contribution a bflc:PrimaryContribution【主要责任者1XX】
题名(作品/实例):bflc:titleSortKey “Snoopy on wheels /” ;【去不排序字符?含子字段末“/”】
施事者
bflc:name00MarcKey “1001 $aFlanagan, Terry.” ;【含MARC子字段名】
bflc:name00MatchKey “Flanagan, Terry.” ;【不含子字段名的字符串】
bflc:primaryContributorName00MatchKey “Flanagan, Terry.” .【主要责任者1XX】

BIBFRAME2.0不以元素区分创作者、贡献者,所有责任者都是“贡献”contribution,再加上不同的“职能”role 。或许是在处理上还不能一步到位地提供具体的职能,LC扩展了表明主要责任(创作者)的类 bflc:PrimaryContribution 和3个属性 bflc:primaryContributorName00MatchKey,bflc:primaryContributorName10MatchKey,bflc:primaryContributorName11MatchKey(应该分别对应100/700、110/710、111/711)。为什么7XX?因为7XX也可能是创作者。