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子属性【定义用】

见:

BIBFRAME互操作小组

BIG——BIBFRAME互操作小组(BIBFRAME Interoperability Group),关注很久,一直没专门写博文。

上月结束的今年欧洲BIBFRAME研讨会(BIBFRAME Workshop in Europe 2023),BIG现任主席Ian Bigelow有个报告,从背景开始全面介绍BIG,包括目前关注或进行中内容。

BIBFRAME Interoperability Group (BIG): Update / Ian Bigelow (University of Alberta), Nancy Lorimer (Stanford University). 27 slides. https://www.bfwe.eu/attachments/bfwe23-lorimer-bigelow.pdf

其中有2022年中的BIBFRAME实施调查,分析了11家实施者在模型、版本、MARC转换上的区别(年初BIBFRAME更新论坛也有报告)。目前的主要工作是定义数据交换所需的标准BIBFRAME“形状”,以及定义交换数据应遵守的“BIBFRAME中间语”(从专著文献类型开始)。PPT摘编译如下。

[1] 背景。2021年9月合作编目项目(PCC)组织了一次BIBFRAME数据交换的虚拟会议,代表国家图书馆、PCC委员会、LD4社区、供应商社区、欧洲BIBFRAME小组等与会,确定的主要挑战是:由于在原始数据创建中表达BIBFRAME本体的不同选择以及MARC数据转换的不同结果,导致BIBFRAME数据的交换问题。因此PCC政策委员会(PoCo)2022年1月批准成立BIBFRAME互操作小组(BIG)。BIG维基:https://wiki.lyrasis.org/pages/viewpage.action?pageId=249135298

[2] 成员。3种机构,每机构1位。

1) 标准团体(PCC)

2) 实施BF的图书馆(国家馆=LC、瑞典国家图书馆、芬兰国家图书馆,高校/Alberta、UC Davis、Penn、Stanford、Cornell)

3) BF数据托管组织(Share-VDE、Sinopia、Index Data、OCLC)

[3] 顾问机构。参与审查、协助测试(EBSCO,Ex Libris,MODS编辑委员会,国家医学图书馆,NISO,伊利诺伊大学芝加哥图书馆)

[4] 职责。合作开发和维护可互操作的BIBFRAME数据指南:支持生产级别的实施;解决限制互操作性的问题;为相关工具和基础设施的开发提供信息。

【以上可另见职责文件:Terms of Reference (BIBFRAME Interoperability Group). April 15, 2022. https://www.loc.gov/aba/pcc/bibframe/TaskGroups/BIG/BIG-TOR.pdf

[5] 初步成果

1) 合并了其他几个工作组所做的工作,如Strawperson工作组、通信工作组和用例工作组;

2) 审查了几个BIG成员的BIBFRAME实施,并讨论了他们对互操作性的要求和遇到的问题;

3) 对BIG成员目前使用的编目标准进行了调查;

4) 开展了BIBFRAME实施情况调查【见下】;

5) 与LD4、Share-VDE、OCLC在LC举行了一次由LC政策、培训和合作项目部(PTCP)主办的发现会议;

6) 纳入了在LC举行的2022年关联数据峰会的反馈和行动;

7) 制定工作计划【见下】。

[6] 实施调查:问题与分析。11个实施机构参与调查【2022年7-8月】

与bf2.0明显不同的模型?50%(svde:Opus/svde:Work;bflc;本地扩展词表;BIBFRAME lite)

BIBFRAME版本基础?(多数2.0;1个2.1;1个正在移到2.1)

MARC到BIBFRAME的处理和版本?(RDFizer工具/SVDE;本地转换逻辑/瑞典、芬兰;LC MARC2IBFRAME转换器)

BIBFRAME到MARC的处理和版本?(基于LC转换的逻辑,本地转换逻辑/瑞典)

[7] 2023年工作计划

1) 定义数据交换所需的标准BIBFRAME“形状”,a. 利用PCC数据和标准作为测试案例和起点;b. 从专著开始,但尽可能或稍后再包括其他;c. 基于原生BIBFRAME描述对应于转换(来自MARC)的审查需求。

2) 确保技术人员和图书馆员可读建议,但更新最好只在一个地方进行:

a. 研究如何生成表格格式,可能使用DC TAP,并生成SHACL

【见下/子组工作1。参见:TAP规范:表格式应用配置文件(DCMI开发中)(2020-12-15)https://catwizard.net/posts/20201215114312.html

Dublin Core Tabular Application Profiles (DCTAP). https://www.dublincore.org/specifications/dctap/

Shapes Constraint Language (SHACL). https://www.w3.org/TR/shacl/. 形状约束语言,一种用于描述和验证 RDF 图的语言】

b. 编码互操作性范围(格式/扩展/旧版或新版等)

c. 记录由小组工作识别的BIBFRAME互换技术方面的最佳实践。

3) 与顾问分享假设的测试和验证。

[8]  下属小组工作

1) SHACL/DCTap子组【标准BIBFRAME形状】。目标:第1部分:设置电子表格的结构和实践,以便能够一致地获取决策并支持相应的SHACL。第2部分:测试过程和迭代(待定)

2) BIBFRAME Interlingua子组。目标:定义专著的BIBFRAME中间语。

定义BIBFRAME Interlingua(中间语)。BIBFRAME中间语遵守水平。交换BIBFRAME数据的机构应考虑以下遵守水平:1级(如果不存在则违规):级别1中包含的数据元素被认为是BIBFRAME数据功能交换所必需的数据元素。任何在生产中使用BIBFRAME数据的机构都应遵守这一级别,并能够发布和接收保留这一信息的数据。同样,那些致力于BIBFRAME开发的人应该非常小心地处理这些元素的任何更改,与BIG合作和沟通,以确保本地系统做好任何更新的准备。2级(如果不存在则警告):严重性=~必需减少歧义*(还需更多定义)。这些数据元素对于识别和交换不那么重要,但对于BIG的许多实践社区来说,它们被认为是数据重用和发现的关键。为了遵守第2级,不需要这些元素,但如果存在这些元素,则应遵守所示的方法来构建和呈现数据以供重复使用。

[9] 正在讨论的其他问题

1) MARC转换:MARC到BF的转换限制应该在多大程度上影响我们的需求?将BF转换为MARC的需求应该在多大程度上影响我们的需求(属性,词表?)是否存在仅用于转换目的的属性,或者它们是否具有其他用途?(引用,开源文章中的通讯作者)。

2) 内容标准:只在BF还是在BF+RDA工作?如果某个东西是RDA核心,那么BF的交换是否需要它?(如果是,如何处理转换为BF的AACR2记录,因为BF缺少许多RDA字段?如果否,如何与内容标准交互?)

[3) 取值词表:当不是每个人都使用相同的词表时,这是一个挑战;值域的使用通常是可选的(当使用非图书馆词表,如《艺术与建筑叙词表》时,声称一个术语是BF类的实例是不合适的,这很好;如果唯一现有词表是文字的,就不太好了)

4) 语言和文字标签tag:需要文字语言标签吗?文字标签使用不多,但很有用。

5) BF扩展:应当考虑什么BF扩展(BFLC,SVDE,arm艺术与珍稀资料本体,PMO表演音乐本体)?如何评估它们的通用性?是否需要(即请求)映射到通用BF?

[10] 接下来步骤

1) 基于样本数据确定bf:Work属性的形状(数据模型)/进行中;

2) 确定bf:Instance的最小交换要求和属性形状/进行中;

3) 创建表格数据并生成SHACL/进行中;

4) 编码互操作性范围(格式/扩展/旧版或新版等);

5) 记录BIBFRAME交换技术方面的最佳实践;

6) 与顾问分享假设的测试和验证。