FOLIO的BIBFRAME功能

月初去合肥,参加全国图书馆知识组织与新一代信息服务系统数据管理专题研讨会(好长的会名)。

  • 我讲BIBFRAME,包括最新进展,有今年9月欧洲BIBFRAME研讨会(BFWE 2023)EBSCO的Gloria Gonzalez关于FOLIO将如何用BIBFRAME,Maurits van der Graaf 对国际应用RDA和BIBFRAME的预测,以及Marshall Breeding去年的预测【参见:用BIBFRAME成本更高?(2023-5-23)】

会上EBSCO中国创新服务总监周奇有报告“FOLIO项目进展及案例分享”,其中两点我特别感兴趣:

  • 其一,folio的Poppy版本将有MARC编目(2023 R2第2次发布)。回来查Poppy(罂粟花)计划2023-11-20公开发布,在典藏app中新增quickMARC选项,可创建新的MARC书目记录(而不仅仅是导入记录)【见:Poppy (R2 2023) Release Notes. https://wiki.folio.org/display/REL/Poppy+%28R2+2023%29+Release+Notes
  • 其二,2023年世界开放图书馆基金会大会(WOLFCon 2023)Gloria有个FOLIO与BIBFRAME的报告。回来查8月会议的这个报告,与她在BFWE 2023的报告风格、侧重各有不同。

——FOLIO的BIBFRAME相关功能——

以下概述自2个报告:

  • 关键关联数据功能将于2024年进入FOLIO:

[1]BIBFRAME编辑器【Marva,关联数据编辑器;可在FOLIO内部或外部使用】

[2]基于图谱的存储【关联数据DB】

[3]连接到其他FOLIO图书馆的网络

[4]一键从MARC移到BIBFRAME【ETL引擎,即提取、转换、加载,将多个来源的数据组合到中央存储库】

[5]通过API和联合提要[syndication feeds]将关联数据发送到任何用户界面【同步推送功能】

[6]可选加入BiblioGraph的更大数据网络【使用BIBFRAME Lite;关于BiblioGraph,参见:EBSCO推出BiblioGraph(Library.Link改名?)(2023-2-6)】/posts/2023/0206/6028

  • FOLIO将如何使用BIBFRAME:

BIBFRAME转换(关联数据转入/转出)

BIBFRAME编辑(书目、规范、管理数据)

BIBFRAME共享(API、同步、互操作)

BIBFRAME报告(追踪、测量、评估…)

  • FOLIO的关联数据核心变化:新增2个app、新增关联数据存储

[1]Marva编辑器app->关联数据模块

[2]图谱浏览器app->数据浏览模块

[3]关联数据DB(BIBFRAME存储)【FOLIO原来将MARC或其他格式书目记录导入简单记录库SRS DB保存,实际使用的是典藏DB,两个库相互链接。新增的关联数据DB将存入2个新增app生成的数据,并复制SRS DB中的数据。典藏模块将有2个存储即:1)典藏DB,2)关联数据DB,两者相互链接。】

FOLIO关联数据存储(BIBFRAME存储)

BIBFRAME必须死

2002年,Roy Tennant在Library Journal上发表著名文章“MARC必须死”。

在该文发表21周年之际,Jeff Edmunds在其任职的宾州州立大学图书馆机构库上发布文章“BIBFRAME必须死”,向MARC21致敬,认为BIBFRAME不是书目描述的前进方向,并提出五个理由:

BIBFRAME Must Die / Jeff Edmunds. 2023-10-14. https://dx.doi.org/10.26207/v18m-0g05

早在2017年,Jeff Edmunds就曾在BIBFRAME邮件组中发出“BIBFRAME will fail”唱衰,引发热烈讨论。参见:邮件组大讨论:BIBFRAME将会失败?(2017-2-5)

实际上,本文不仅抨击BIBFRAME,也抨击FRBR/LRM和RDA,认为它们是“过时”和“脱离现实”的

  • BIBFRAME运动起源于20世纪90年代中期出现的关于书目数据建模的思想。不幸的是,由此产生的关于人们如何寻找和查找图书馆材料的许多概念是在谷歌、脸书、智能手机、5G网络、Alexa和物联网、ChatGPT和生成人工智能之前,以及在一系列其他技术之前发展起来的,这些技术彻底改变了人们搜索、查找和思考信息的方式。
  • 未来在别处,有全文索引、大数据和越来越令人印象深刻的人工智能系统,这些系统可以在缺乏干净、一致打包的数据的情况下解析数据并得出准确的推断,而不是BIBFRAME和RDA试图“烘焙”的实体之间脆弱且永远不稳定的关系,这给编目员、供应商和图书馆带来了巨大的成本。

这延续他在2017年讨论中提出的第5个要点中的观点:

  • 图书馆(和档案馆等)资料的发现已不再主要运行于书目元数据(metadata),而是运行于巨大数据(megadata)(我定义为一个复杂的元数据混乱)、全文和大数据(包括个性化数据)。其结果是,不怎么需要与欣赏高质量元数据

本文引用Roy Tennant前文曾引2001年David J. Flander的文章,不过是另一句,以此对BIBFRAME大加讽刺:

  • “现在计算能力已经足够便宜了,不再需要以人作为代价来简化计算机”。 2001年的事实在2023年依然如此。“以人作为代价来简化计算机”完美地传达了BIBFRAME运动的指导原则

对于BIBFRAME应用效果,本文引用2019年瑞典国家图书馆的一篇会议论文:

  • 在为数不多的“完全”过渡到BIBFRAME的图书馆中,只有瑞典国家图书馆发表了对结果的评估:……结论:“关联数据的优势还没有立即显现。”

文章最后的结论是:

  • 美国国会图书馆和其他机构正在制定和倡导的道路——放弃MARC、采用不可用的官方RDA工具包和BIBFRAME——是昂贵、不可行和不公平的,对编目员、图书馆、发现供应商或我们共同服务的公众没有提供重大改进。

—–BIBFRAME必须死的5个理由(摘译/原无编号)—–

[1] BIBFRAME会让图书馆付出高昂的代价

正如Marshall Breeding在2022年11月的一次演讲中指出的那样,“向BIBFRAME的过渡将涉及大量投资:技术开发、员工培训、文档等。在最初的过渡之后的许多年里,图书馆预计BIBFRAME的编目成本将大大高于MARC。随着时间的推移,效率可能会提高。”

【参见Marshall Breeding的报告介绍:用BIBFRAME成本更高?(2023-5-23)】

[2] BIBFRAME不可行

BIBFRAME要想以任何名义上有意义的方式工作,就必须有成千上万块多米诺骨牌就位。举几个例子:

  • 图书馆、供应商和出版商将不得不放弃MARC,转而使用BIBFRAME。
  • 必须协调BIBFRAME本体的各种本地实现中的不一致性。
  • 必须商定并采用BIBFRAME的标准互换口味。
  • 允许使用BIBFRAME进行本地编目的编辑器必须进行协调,以便一个编辑器输出的数据与另一个编辑器的数据无法区分,或者至少兼容。
  • 必须设计、部署、测试和采用实体管理系统,以实现对关联数据的共享管理,从而无需数千个单独的竖井。
  • 所有主要和次要的图书馆供应商(Clarivate、EBSCO、SirsiDynix等)都必须将其ILS和发现系统转换为基于BIBFRAME和关联数据,而不是基于MARC。
  • 专门创建MARC数据的供应商,如SkyRiver、Cassidy编目和书目数据服务(BDS),将不得不被诱骗完全重组其运营,以生成BIBFRAME数据而不是MARC记录。
  • OCLC必须将WorldCat或其中的很大一部分从基于MARC的书目和规范记录数据库转换为基于BIBFRAME的实体和这些实体之间关系的三元组存储。
  • OCLC必须设计和部署编辑器和API,以允许在WorldCat中为所有格式的资料(包括CONSER的系列)原生创建BIBFRAME数据,并与其成员和客户交换该BIBFRAME数据。
  • 官方RDA必须映射到BIBFRAME,并由所有利益相关者商定和采用。
  • 官方RDA必须得到普遍培训、采用和实施。
  • 美国117000多家图书馆中的许多或大多数图书馆以及世界各地数十万家图书馆的编目员和技术人员都必须接受使用BIBFRAME编目的培训,或者至少了解其原理和表达数据。
  • 所有(或大多数)图书馆目录和发现系统都必须重新设计,以按照BIBFRAME关联数据的原则运行,而不是以文档为中心的MARC记录。
  • 必须设计、创建和维护中央三元组存储,因为关联数据精神的基本原则之一不是在本地复制数据,而是集中存储数据。

[3] BIBFRAME对探索生态系统没有任何价值

[4] BIBFRAME对用户不友好,不管这些用户是谁

[5] BIBFRAME充满了不公平

BIBFRAME实施和官方RDA工具包成本高昂,超出了大多数图书馆的能力范围,因此是精英主义的,以牺牲大多数图书馆的利益为代价为极少数图书馆服务。

Karen Coyle这样的权威人士指出了一个小团体是如何推动FRBR的发展的,FRBR是LRM/RDA/BIBFRAME运动的基础:“最终,FRBR是由一个非常小的群体开发和审查的,无论以何种标准衡量,这个群体都不能代表推动其发展的图书馆社区。[…]我们必须承认这样一个事实,即这样一个过程的最终结果可能实际上并不能为更大的图书馆社区服务。”

换言之,极少数图书馆思想家将编目世界推向了一条昂贵的无关紧要的道路

JCricket实体编辑器

2023年欧洲BIBFRAME研讨会(BIBFRAME Workshop in Europe 2023)上,Share-VDE(以下简称SVDE)有2个报告,其一介绍Share-VDE本体(可参见博文:Share-VDE本体:BIBFRAME扩展 ),另一介绍其在生产方面的进展,后半部分演示新推出的实体编辑器JCricket,即规范数据编辑工具。

JCricket用于人工编辑SVDE知识库中的实体(包括其属性、关系、链接等),可用操作包括:

  • 编辑:属性添加、升级、删除
  • 合并:多个棱镜[实体]合并为一个。如“Mark Twain”[笔名]和“Samuel Clemens”[原名]
  • 分拆:一个棱镜[实体]分拆为多个。当一个棱镜错误地包含属于多个实体的信息。如“Wallace David”和“David Wallace”

JCricket是什么

  • 一个关联数据实体/规范编辑器;
  • 适用于在Share家族(svde.orgpcc-lod.orgnatbib-lod.org)的所有租户内创建的关联数据实体;
  • 一个手动应用程序,用于管理CKB集群知识库中实体的属性(特性、关系和链接);
  • 一个跨成员机构共享的协作工具;
  • 可以成为关联开放数据中实体共享的新工具。

JCricket不是什么

  • 不是传统的书目数据编辑器;
  • 不是原始编目工具;
  • 不与Sinopia或Marva对比;
  • 不影响成员馆系统中的原始数据(除非图书馆希望在SVDE及其系统中使用特殊API进行实体更新)

附相关/专有名词:

  • JCricket(曾称 J. Cricket):SVDE的实体编辑器
  • Sapientia(智慧):Share-VDE的知识库(CKB, Cluster Knowledge Base)
  • Tenant(租户):代表一组为同一知识库做出贡献的机构。
  • Provenance(出处):为CKB贡献的具体机构(图书馆)
  • Prism(棱镜):CKB中的实体,(如同多棱镜) 每个面(face)代表数据来自一个给定出处。

来自: