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)】https://catwizard.net/posts/20230206172241.html

  • 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是由一个非常小的群体开发和审查的,无论以何种标准衡量,这个群体都不能代表推动其发展的图书馆社区。[…]我们必须承认这样一个事实,即这样一个过程的最终结果可能实际上并不能为更大的图书馆社区服务。”

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

Share-VDE本体:BIBFRAME扩展

Share虚拟发现环境(Share-VDE,亦简称SVDE),是意大利厂商 Casalini Libri 和 @Cult 与多个北美研究图书馆合作的BIBFRAME项目。目前为 Share-VDE 2.0(https://svde.org/)。发展过程可参见:Share-VDE在图书馆关联开放数据中的作用(2021-10-31)

Share-VDE使用BIBFRAME词表描述书目实体。作为关联数据搜索系统、联邦搜索环境,考虑聚集作品的需求,要求扩展BIBFRAME。

众所周知,FRBR/LRM书目有4层(Work—Expression—Manifestation—Item),而BIBFRAME模型只有3层(Work—Instance—Item),bf:Work合并了LRM的前2层。后来BIBFRAME增加了对应于LRM模型Work的bf:Hub、作为bf:Work的子类【为什么是子类?】,而SVDE则相应增加了Opus类。

上月结束的今年欧洲BIBFRAME研讨会(BIBFRAME Workshop in Europe 2023, BFWE 2023),有Share-VDE本体介绍,对BIBFRAME有更多扩展。PPT中并有本体网页链接,以OWL描述SVDE本体(由Share-VDE Sapientia Entity Identification (SEI)工作组完成),其中还多有与LRM/RDA的对应关系。

SVDE本体尚未正式发布,开发者希望托管到LC网站。以下来自概述PPT及本体网页。

——Share-VDE本体——

  • 概念图+核心模型

svde:Opus -> svde:hasExpression -> svde:Work

svde:Opus -> svde:hasOpusType -> svde:OpusType(Opus类型未定)

svde:Work -> svde:inHub -> bf:Hub

  • 类与属性

svde:Opus:艺术或智力活动的一个独特的概念结果。作为SVDE中的最高抽象级别,Opus是一个允许对被视为功能性或近似等效的作品进行分组的实体。与bf:Hub相关但不等同,它们分别通过bf:hasExpression / svde:hasExpression收集bf:Work实体(备注6:LRM作品和RDA作品的平行类,包含svde:Opus的属性集平行于LRM作品和RDA作品中的那些属性)【核心类】

svde:Work:由一组元素定义的、代表Opus每次“实现”时所采取的特定智力或艺术形式(备注7:bf:Work的子类;组成svde:Work的一组属性,平行于LRM内容表达和RDA内容表达中的那些属性)

svde:hasExpression:关联Opus[定义域]到Work[值域],近似LRM=is realized through/RDA=has expression of work。

svde:inHub:关联到1个或多个svde:Work[定义域]到一个bf:Hub[值域];bf:relatedTo子属性(备注5:利用bf:Hub对同一svde:Work的译本进行分组;计划未来用例:对同一svde:Work的不同版本或改编进行分组)

svde:OpusType:支持识别Opus类别【猜想用于搜索结果分面】

svde:hasType:可由实体专门化的中间属性。RDA has category of entity子属性。

svde:hasOpusType:关联Opus[定义域]到OpusType[值域];svde:hasType子属性。

svde:closeMatch:另一个本体或方案中语义相似的实体(通常是类或属性);dct:relation子属性【定义用】

见: