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

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

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

• 我讲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个报告：

• 关联数据和FOLIO的BIBFRAME世界 Linked Data and BIBFRAME World for FOLIO / Gloria Gonzalez, Vince Bareau, Anuar Nurmakanov. WOLFcon 2023, 2023-8-23. 31 slides.
• 数据解锁：让图书馆在FOLIO中拥有丰富的联系和见解 Data Unlocked: Empowering Libraries with Rich Connections and Insights in FOLIO / Gloria Gonzalez. BIBFRAME Workshop in Europe 2023, 2023-9-20. 39 slides.

• 关键关联数据功能将于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，两者相互链接。】

图书馆编目有两种，即所谓原编（原始编目）和套录（复制编目）。原编指对没有书目记录的资源进行编目；套录指复制已有书目记录，如有问题则修改。传统上，馆藏的所有书目记录都保存在本馆系统中（即使是云存储）。随着BIBFRAME的引入，这种模式可能会变化了。

LD4是美国始于2015年的图书馆关联数据系列项目，2023年为LD4P（Linked Data for Production）第4阶段，康奈尔、斯坦福、宾州大学和美国国会图书馆为在生产环境中推进BIBFRAME，提出了一个转变编目模式、停止套录数据的蓝色核心计划（Project Blue Core），数据将放在一个机构共享的中央数据池中，不下载到本地，如需修改、也只修改数据池中的记录。计划将分3个阶段实现：第一阶段—构想（2023年秋），第二阶段—最终计划（2024年）， 第三阶段—实施（2025年）。

目前只在2023欧洲BIBFRAME研讨会报告上看到介绍：

生产关联数据第4阶段：在机构中立的数据池中真正共享数据 Linked Data for Production Phase 4: Truly Shared Data in an Institutionally Neutral Data Pool / Philip E. Schreur, Tom Cramer, Jason Kovari, Simeon Warner. BIBFRAME Workshop in Europe 2023. 11 slides. https://www.bfwe.eu/attachments/bfwe23-schreur-cramer-kovari-warner.pdf

PPT比较简洁，详细了解需要结合47分钟音频（https://youtu.be/hoWk1vcvsi4）。互动从23分钟开始，内容：你认为真正共享和维护描述性元数据在政治上是可能的吗？元数据应该被锁定开放（locked open）吗？你认为这种方法最初会遇到什么问题？

【架构图】

BIBFRAME本体2.3版（http://id.loc.gov/ontologies/bibframe-2-3-0/）于2023-11-30发布。因为变化不大，美国国会图书馆（LC）网络开发和标准办公室主任Sally McCallum在BIBFRAME邮件组发布消息的标题是“BIBFFRAME/MARC转换新版发布”（New versions of BIBFRAME/MARC conversions release），在正文中才说明本体更新。

与2.2版（https://id.loc.gov/ontologies/bibframe-2-2-0.html）相比，有9处更新。可分为3组：

一、Hub相关更新

1、bf:Hub（一种抽象资源，充当两个作品之间的桥梁）：Hub在2.1版引入，大致对应LRM/RDA的WEMI四层实体中的最上层，但当时是作为bf:Work的子类。本次更新将Hub定义为基本模型类（Basic Model Class），不再是bf:Work子类。

2、bf:hasExpression / bf:ExpressionOf：定义域/值域原为bf:Work。由于Hub不再是Work子类，因此定义域/值域变为：bf:Work 或 bf:Hub

【从模型角度Hub在Work之上，原来定义为Work子类，总觉得有点奇怪，更新后显得正常了。不过还是与LRM/RDA不同，LRM/RDA的WEMI间属性各不相同，而BIBFRAME的 Hub / Work 都用 expression 连接】

二、新增由LC本地扩展BFLC转移到主词表

1、bf:PrimaryContribution：主要责任，bf:Contribution子类

2、bf:TransliteratedTitle：音译题名，bf:VariantTitle子类

3、bf:CaptureStorage：LC录音编目员根据MARC 007/13的要求，bf:SoundCharacteristic子类

4、bf:Relief 类 / bf:relief 属性：LC地图编目员根据MARC 008/18-21的要求

三、社区建议新增

bf:Microform：缩微品，作为bf:Instance的子类。GitHub讨论区有详细的建议理由 (GH101)。

参见：BIBFRAME本体2.1版发布（4层确认）（2021-6-25）

BIBFRAME 2 版本的修订内容，主要有两个来源：

• 其一，美国国会图书馆（LC），在 MARC/BIBFRAME 数据转换、BIBFRAME 编目试验等过程中发现；
• 其二，公开接受建议，可在github中提交发现的问题、发布修订建议，接受质疑与讨论，确定修订后关闭评论。（问题讨论链接issues）https://github.com/lcnetdev/bibframe-ontology/issues

之前写过BIBFRAME本体的2.1版和2.3版更新，下面补上2.2版。参见：

• BIBFRAME本体2.1版发布（4层确认）（2021-6-25）
• BIBFRAME本体2.3版发布（2023-12-2）

2.2版（https://id.loc.gov/ontologies/bibframe-2-2-0.html）于2022-10-3发布，共28个变化，涉及17个类、11个属性。大致可归为3类：

一、新增类及属性，增强互操作（转换、映射）

1、新增资源类型（bf:Work的子类）：（1）Integrating集成性[资源]（2）Kit套件（bf:MixedMaterial的子类、bf:MixedMaterial又为bf:Work的子类）（3）Monograph专著/单行资源（4）MusicAudio音乐音频（bf:Audio的子类，bf:Audio又为bf:Work的子类）（5）NonMusicAudio非音乐音频（同MusicAudio）（6）Serial连续性[资源]（7）Series丛编。

2、新增类DescriptionLevel / 属性descriptionLevel，对应MARC头标的编码等级（encodingLevel），但更改用词与DescriptionAuthentication、DescriptionConventions一致。

3、新增类Binding / 属性binding，合订方法，对应MARC/RDA结构化描述。

4、新增类Modification（bf:ProvisionActivity的子类），MODS映射时发现BIBFRAME缺少修改日期，本类可包括非日期修改如Agent。

5、新增属性validDate（bf:date的子属性），MODS映射时发现BIBFRAME缺少有效日期；同时也对应于MARC 046 特定编码日期。

二、扩大属性的定义域、值域，减少对应用的限制

1、取消值域：现期望值为rdfs:Resource（所有资源），减少对应用的限制（PCC认可）：（1）carrier（原期望值bf:Carrier），（2）content（原bf:Content），（3）intendedAudience（原bf:IntendedAudience），（4）language（原bf:Language），（5）media（原bf:Media）

2、扩大定义域：originPlace（原用于bf:Work），现注释-建议使用：bf:Work 或 bf:Instance（MARC转换，370字段地点适用于作品，257字段地点适用于实例）

三、更正与纠错

1、更改类的定义：MixedMaterial，Multimedia（均为多种类型资源，区别在于是否由软件驱动）

2、修改子类（subClassOf）：（1）Collection（添加子类bf:Work），（2）Manuscript（子类由bf:Instance改为bf:Work；对此修改尚有争议，见问题GH92：https://github.com/lcnetdev/bibframe-ontology/issues/92）

3、取消子类。描述/著录相关类，原误作AdminMetadata子类，现取消：（1）DescriptionAuthentication（描述验证）（2）DescriptionConventions（描述规则）（3）GenerationProcess（[描述]生成处理）

4、更改属性标签：replacedBy，replacementOf（原分别为：succeededBy，precededBy ）

【附：Work和Instance的子类（2.3版）】

• bf:Work的子类共18种，加下位子类3种共21种（不含2.3版取消的Hub），其中2.2版新增*7种，修改+2种

Text

Cartography

Audio（子类：MusicAudio*，NonMusicAudio*）

NotatedMusic

NotatedMovement

Dataset

StillImage

MovingImage

Object

Multimedia

MixedMaterial（子类：Kit*）

Manuscript+（由bf:Instance子类改）

Collection+（增加为子类）

Arrangement

Integrating*

Monograph*

Serial*

Series*

• Instance的子类共5种（其中2.3版新增*1种）

Print，Archival，Tactile，Electronic，Microform*

2023年11月底，美国国会图书馆（LC）发布了BIBFRAME词表（本体）2.3版和BIBFRAME/MARC双向转换2.4版。

via BIBFRAME Forum: New versions of BIBFRAME/MARC conversions released / Sally H. McCallum. 2023-12-1.

参见：BIBFRAME本体2.3版发布（2023-12-2）

按LC网络开发与标准办公室主任Sally McCallum在BIBFRAME邮件组发布信息的说法， 词表更新相对较少，双向转换的更新更为“实质性”。转换更新主要针对的是单条MARC记录中包含多个载体资源（多个007、300和3XX字段），先将其拆分为多条MARC记录，方便转换为一个作品、多个实例的BIBFRAME；相应地，从BIBFRAME转换、复合重建为对应的单条MARC记录。相对于原来各载体的描述混在一个BIBFRAME实例中无法区分，这确实是个非常重要的质量提升。

Jodi Williamschen和Kevin Ford在7月份的LD4在线会议上介绍了这项工作，可看油管视频和PPT：

Breaking news: Splitting MARC records to create better BIBFRAME data / Kevin Ford and Jodi Williamschen. 2023 LD4 Conference on Linked Data, July 12, 2023. 26 slides.

2.4版有个预处理（Preprocess 0），就是在一个Work中创建不同载体的多个Instance：由原单条MARC记录创建多条精简MARC记录，以新建的MARC758字段（资源标识符）链接。另外：原来入Work的007位的声音内容、色彩内容和相应的34X字段/子字段跟着分拆到Instance。

由于MARC编目历史长且资源情况各异，单条MARC记录中包含多个载体资源会有不同做法。比如336-338字段的使用，重复300字段的做法，是在RDA实施后出现的，而MARC到BIBFRAME的转换需要针对所有遗留的MARC记录。 PPT以三个示例介绍不同做法：

• 例一、照片有对应电子资源：2个007、1个856（其中300/336-338仅各1，对应第1个007；第2个007对应856）
• 例二、音频盘有配套视频盘附件：2个007、300$e（336-338各2，分别配：第1个007+300$a$b$c，第2个007+300$e）
• 例三、3个电影胶卷的合集：007/300配对（各3条）

基本做法是：主MARC记录包含连接到第1个007字段，以及所有其余MARC字段；其他MARC记录包含连接到各自007字段、前述相应子段/子字段（如856、300$e、300等），保留共同的008、260/264字段，并新增758字段（形式如 758 \\ $4 http://id.loc.gov/ontologies/bibframe/instanceOf $1 http://example.org/22913073#Work）。

PPT也谈到了转换仍然存在的问题【括号中为本人点评】

• 无法保证007和300字段的顺序正确【如果完全依赖字段顺序，会有很大问题，应该辅以代码与描述的识别配对】
• 当两个007字段用于描述资源的同一部分时，会创建额外的MARC记录【简单的重复？问题似乎不太大】
• 实例标题的不确定性【本无单独著录，无解】

转换代码：

• https://github.com/lcnetdev/marc2bibframe2
• https://github.com/lcnetdev/bibframe2marc

转换规范：

• MARC-to-BF: https://www.loc.gov/bibframe/mtbf/
• BF-to-MARC: https://www.loc.gov/bibframe/bftm/

基础数据更新尚在进行中（毕竟MARC记录数量巨大），比较工具已是2.4版实时转换，记录实例：

• MARC-to-BF: https://id.loc.gov/tools/bibframe/compare-id/full-rdf?find=11950110【MARC 记录有3条007、300，无336-338；生成BIBFRAME的Work拆分3个Hub，3个Instance】
• BF-to-MARC: https://id.loc.gov/tools/bibframe/comparebf-id/11950110.txt【与上例同一记录，BIBFRAME生成的MARC记录除3条007、300外，还有1条336、3条337、4条338、3条340、9条344、1条353，结构化内容更丰富】

Share Family 由两家意大利公司 Casalini Libri（书商）和 @cult（软件公司）主导，始于2016年意大利多家大学图书馆的联合目录SHARE。参见：BIBFRAME 2.0实施注册新增项目（附：意大利SHARE目录）（2017-7-25）

SHARE原本是刻意选择的首字母缩略词 Scholarly Heritage and Access to Research，后来直接用作“共享”之意。2017年起公司与LD4P项目、若干北美大学图书馆共同开发Share-VDE，影响逐渐扩大。参见：Share-VDE在图书馆关联开放数据中的作用（2021-10-30）

2019年12月，不定期刊物 Share Family Bulletin 发刊，显示Share Family雏形初现。之后各期，可追踪这些年的进展。

2023年建立 Share Family网站：https://www.Share-Family.org

刊物最新为2023年12月第8期 Share Family Bulletin (2023.12 no.8)，总结2023年Share Family倡议的成就和挑战，实际也概述了整个发展史。

以下为第8期翻译摘编，含本人先前相关博文链接。文中的图似乎都是从之前各演讲PPT中取来，与文字不尽配套。

把原结语移到最前面，突显Share Family的背景与态度：

【结语】通过采用BIBFRAME作为与IFLA-LRM兼容的主要本体，Share Family利用关联开放数据的潜力，促进数据池之间的互操作性，与MARC共存。

图[1]：Share Family发展时间线（2016-2023）

• 2016 Share目录上线，开始Share-VDE原型；
• 2017-2019 Share-VDE成员和LD4P成员数据由MARC21到BIBFRAME；
• 2019-2021 Share-VDE 图书馆LOD环境；
• 2021 Share Family启动全LOD平台项目；PCC数据池开始；Share-VDE 2.0 新关联数据管理系统和实体发现门户；国家书目工作组开始；
• 2022 Share Family走向生产；
• 2023 英国国家书目（beta）走向生产；JCricket【参见：JCricket实体编辑器（2023-10-16）】

图[2]：Share Family 活跃租户和发现网站【图中没有LILLIT，有尚在开发中的3个项目Share ART艺术、Share MUSIC音乐、Share MIA手稿与古籍（LILLIT或归入此）】

• Share-VDE（虚拟发现环境）https://www.svde.org/
• SHARE目录-意大利大学图书馆网络 https://catalogo.share-cat.unina.it/sharecat/clusters?l=en
• PCC数据池-关联开放数据中的合作编目（PCC）目录计划 https://pcc-lod.org/ （2024初数据将重新索引）
• 关联开放数据中的国家书目 https://www.natbib-lod.org/（2023英国国家书目beta上线 https://bl.natbib-lod.org ）
• Parsifal-URBE联盟（罗马教会图书馆联盟）的LOD门户网站 https://parsifal.urbe.it/parsifal/?l=en
• LILLIT-意大利插图书籍门户网站，提供16至18世纪印刷的意大利版本的关联开放数据描述和插图 https://lillit.share-family.org/lillit/?l=en

图[3]：Share Family 租户基础架构【以 SVDE Sapientia CKB 中央知识库 为中心】

• Share Family索引 -> SVDE Sapientia CKB/实体注册 -> Share-VDE发现端口和机构皮肤/各租户门户
• Share Family索引 -> 各租户CKB -> 各租户网站
• Share-VDE图书馆的原记录 -> SVDE Sapientia CKB

【工作组/列举部分】Share-VDE和Share Family工作组，由咨询委员会指导：

• SEI–Sapientia实体识别工作组：致力于创建Share-VDE本体（BIBFRAME的扩展）https://doi.org/10.5281/zenodo.8332350【参见：Share-VDE本体：BIBFRAME扩展（2023-10-15） https://catwizard.net/posts/20231015091457.html】
• 用户体验–用户界面工作组：测试和使用Share-VDE 2.0测试版和国家书目门户网站
• 国家书目工作组

【第三方整合】

Share Family技术的发展包括将LOD平台产生的数据与外部系统相互集成的能力，尤其是与本地ILS和图书馆服务平台以及权威来源的集成。

• 关于与ILS和LSP整合，值得一提的是一些进步：

-由SVDE AIMS工作组设计并由斯坦福大学图书馆进一步投入的基于MARC的工作流程的新规范服务已经完成，可供愿意测试和使用它们的机构使用。此外，AIMS工作组将于2024年重新召开会议，分析和设计基于RDF/关联数据的工作流的规范控制功能；

-Alma流通API与地方图书馆服务的整合工作基本完成；

-与原生BIBFRAME编目编辑器Sinopia的集成正在进行中：来自Sinopia将由Share-VDE过程聚类的传入RDF数据的解析器正在开发中；

-已经分析了与FOLIO ILS的连接，以将FOLIO典藏数据与Share-VDE数据相关联，并将JCrick用户界面集成到FOLIO中。Share Family团队的Andrea Gazzarini和WOLFcon 2023的Index Data的Sebastian Hammer提出了一个通过FOLIO进行ILS/LSP交互的可能模型，以在相关数据社区内讨论如何寻求这种联系。

• 关于与规范系统整合，正在调查几个数据来源，在某些情况下，已经完成了初步整合步骤：

-LD4P提问规范（Questioning Authority）查询工具；

-用于相互丰富实体ID的Wikidata（最初的规范由SVDE工作组制定）；

-用于相互丰富实体ID的ISNI（初始规范由SVDE工作组制定）。

【UNIMARC-BIBFRAME转换】

SHARE目录倡议已经完成了UNIMARC-BIBFRAME直接映射和转换的工作（没有通过MARC的中间步骤），并将通过将得到丰富和记录的Wikibase实例与关联数据社区共享这项工作https://unimarc2bibframe.wikibase.cloud/。【2024/1/5内容为空】

【非拉丁文字丰富LOD平台】

• 2024年国立台湾大学图书馆将加入Share Family，由国立台湾大学图书馆提供的数据将由LD4P非拉丁文字资料亲和小组进行测试；
• 正在使用一个支持阿拉伯文字的测试门户进行实验

BIBFRAME发展到2024年，美国国会图书馆（LC）正式应用已近在眼前。业内前些年已经开始关注各家BIBFRAME应用的差异，某次会议多个报告人探讨以哪家应用为基点实现互操作，其中之一自然是LC。本次BIBFRAME更新论坛，LC关注“标准化”，罕见地只选择艾利贝斯（ExLibris）和OCLC两家报告，似乎是为推动以LC的BIBFRAME为“标准”以达成互操作。

BIBFRAME January 2024 Update Forum. 2024-1-22. https://www.loc.gov/bibframe/news/bibframe-update-jan2024.html

会议列出ExLibris报告2个、OCLC报告1个，但PPT只有两家各1个。

两家共同的态度是继续支持MARC。艾利贝斯比较隐讳，称“支持包括BIBFRAME在内的多种格式”；OCLC比较直接，称“在MARC和BIBFRAME之间无缝工作”。

一、Sally McCallum在开场中通报了LC的两个更新：

其一，B2M/M2B转换2.5版：LC前一周发布新版BIBFRAME-MARC和MARC-BIBFRAME转换【网站上没看到2.5版更新情况说明】

其二，示例：正逐步添加到BIBFRAME本体规范的属性和类中【List View可以看到已添加不少示例，应该也为展示LC在本次论坛介绍中所提出的“标准BIBFRAME”】

二、ExLibris报告：解锁连接：关联开放数据和BIBFRAME如何为图书馆用户带来好处 Unlocking Connections: How Linked Open Data and BIBFRAME can Benefits Library Users / Chani Yehuda, Itai Veltzman. 22 slides.

支持互操作：

• [1]发布：导出为BIBFRAME；发布到OCLC。
• [2] API：BIBFRAME作品和实例；与Sinopia集成。
• [3]全球来源：LC，WIkidata，ORCID，更多……。
• [4] 知识图谱：由Alma导出目录到机构知识图谱。

2024-2025年关联数据路标：

• 2024上半年，测试托管自己的Sinopia实例（2024年5月，SINOPIA编目接入Alma系统）
• 2024年下半年，在Primo和Alma中，基于LC和Wikidata，添加新的信息卡(Info Card)和个人页(Person page)；扩展关联数据强化处理，由现有规范到编目工作流程。添加外部查找功能到元数据编辑器(Meadata Editor)中的编目工作流程。
• 2025年，集成本地目录到外部知识图谱系统；能够搜索作品及其实例。

三、OCLC报告：OCLC为BIBFRAME所做的准备 OCLC’s preparation forBIBFRAME / Jeff Mixter. 9 slides.

• [1]标识符：将WorldCat实体URI添加到WorldCat记录中：个人、地点和事件2023年12月，作品2024年1月底起（创建将在工作流程中使用的全局标识符）
• [2]工具：2024年1月底，WorldShare Record Manager集成WorldCat实体查找和URI插入编目工作流程（弥合传统记录和关联数据框架之间的差距，实现数据的无缝创建和管理）
• [3]导入/导出：已发布向OCLC提供BIBFRAME 2.0数据的文档（Prepare your BIBFRAME）https://help.oclc.org/Metadata_Services/WorldShare_Collection_Manager【希望采用美国国会图书馆在其编辑器 MARVA 中使用的序列化方式Concise Bounded Description (CBD)】
• [4] BIBFRAME风格：评估了LC、Share-VDE和瑞典国家图书馆的BIBFRAME，适应BIBFRAME 2.0模型的不同风格（图书馆员可以以尽可能高的保真度共享和交换数据）

另参见：2024年1月30日OCLC新闻，关于OCLC 将 WorldCat 实体标识符添加到 WorldCat 记录中，并将关联数据功能集成到图书馆已使用的编目服务中

• OCLC linked data services transform metadata management and connect library resources to wider knowledge streams. https://www.oclc.org/en/news/releases/2024/20240130-linked-data.html

不知道什么时候看到2021年的文章《BIBFRAME作品实体描述的半自动化方法》：

Jim Hahn (2021) Semi-Automated Methods for BIBFRAME Work Entity Description, Cataloging & Classification Quarterly, 59:8, 853-867, DOI: 10.1080/01639374.2021.2014011

摘要：本文报告了在RDF关联数据编辑器Sinopia（https://Sinopia.io）中半自动创建BIBFRAME作品实体描述的机器学习方法的研究。自动主题标引软件Annif配置了美国国会图书馆主题标题（LCSH）词表，该词表来自关联数据服务https://id.loc.gov/。培训语料库由来自IvyPlus POD项目 (https://pod.stanford.edu/) 和Share-VDE (https://wiki.share-vde.org) 的930万个题名和LCSH关联数据参引组成。探索了半自动化流程，以支持和扩展而不是取代专业知识。

内容涉及BIBFRAME、机器学习、语料库、自动主题标引……就编目领域而言，很潮。不过下载到电脑桌面后就忘了，前几天看到，打开仔细看过：文章篇名称“作品实体描述”，实际只是提供“主题”；“半自动化方法”，指根据文献题名，由自动主题标引软件Annif给出建议的主题，编目员决定是否采用。其实主题标引建议，对MARC编目也同样适用。

本文围绕两个工具：一、Annif，根据文献题名建议主题；二，BIBFRAME编辑器Sinopia，通过API选择或不选择建议的主题，需要解决编辑器功能问题。以下结合本文了解Annif使用方法。

Annif（https://annif.org/）是芬兰国家图书馆开发的自动主题标引和分类工具。最新版本Annif 1.0.2（2024年2月2日）。

实际使用有3种途径：1、命令行界面，2、简洁的Web UI（网站主页有试用），3、微服务风格的REST API。

使用方法（四步骤）

1、选择主题词表

Annif结合使用现有的自然语言处理和机器学习工具，包括TensorFlow、Omikuji、fastText和Gensim。它是多语言的（网站演示3种语言即芬兰语、瑞典语、英语），可以支持任何主题词表（SKOS或简单的TSV格式）。

本文使用LCSH，下载自 https://id.loc.gov/。由于LCSH文件格式没有Annif支持的TTL语法，作者使用RDF语法库进行转换，并在GitHub上公开SKOS LCSH TTL转换的输出。

2、根据训练数据准备语料库。本文使用两个训练语料库：

（1）宾夕法尼亚大学图书馆的130万条带有题名 (245 $a) 和相关的关联数据主题 (650 $0 uri) 的记录的元数据集，数据由Share-VDE作过URI增强处理。

（2）IvyPlus开放数据平台（POD）和Share-VDE的930万题名和主题关联数据。Share-VDE数据来源于合作编目计划（PCC）数据池项目。

3、加载词表并训练模型

首先使用预先标记的测试集评估训练模型。通过使用预先标记的测试，软件将系统地确定基于机器学习的标题[主题]与人工指定的标题的比较方式。PCC成员馆中单独的SDVE强化MARC元数据集提供了测试训练的目标。

通过Scikit学习模型评估，生成归一化折损累计增益（NDCG）分数，前述两个语料库分别得分0.401和0.487。文章称，对于依赖完全自动化机器学习系统的行业来说，预测精度通常接近百分之九十。

4、为新文档建议主题

Annif网站 Web UI 试用可选择显示10、15、20个建议主题。

【话外】第3步预测精度不足，是语料库的问题，不是Annif的问题。由题名预测主题，其不靠谱是可以预料的，最著名的例子是《钢铁是怎样炼成的》。这也就是本文只能“半自动”的主要原因了。

用本文摘要试用Annif网站 Web UI，词表选择YSO Omikuji Bonsai English，建议的10个主题如下：

• lists of subject headings
• subject indexing
• subject cataloging
• semantic web
• linking
• thesauri
• linked open data
• metadata
• machine learning
• computer programmes

提到Annif的相关博文：

• 荷兰国家图书馆白皮书《探索自动生成元数据的可能性》（2019-9-16）（根据受控词表自动分配关键词的实例之一）
• SWIB19：语义网在图书馆会议（报告概要）（2019-11-20）（SWIB19培训的5个语义网/关联数据工具之一）

2023年10月，Jeff Edmunds发布文章“BIBFRAME必须死”，参见：BIBFRAME必须死（2023-10-25）

11月他将文章引入BIBFRAME论坛，先后引发多个话题：

• 11.2-8 Jeff Edmunds [BIBFRAME] BIBFRAME Must DieBIBFRAME必须死
• 11.8 Karen Coyle [BIBFRAME] Does BIBFRAME improve on MARC?BIBFRAME改进了MARC吗？（介绍2007年她为LC写的报告《MARC记录的未来》）
• 11.8-9 Timothy Thompson（耶鲁）[BIBFRAME] MARC Must (Still) Die [Was: BIBFRAME Must Die]MARC（仍然）必须 死（数据验证支持差，以规范为例说明数据质量不行[同意]）
• 11.9 Jeff Edmunds [BIBFRAME] If MARC Must (Still) Die, Who’s Going to Kill It, When, and How?如果MARC（仍然）必须死，谁会杀死它，何时以及如何杀死？（BIBFRAME不可行的部分原因是，图书馆缺乏资源来对元数据质量和编目实践进行如此广泛的改进，而这些改进完全基于过去所称的规范控制，现在通常被称为实体管理）
• 11.9- Johnathon Redmon [BIBFRAME] Marc vs BIBFRAME（美国某公共馆编目助理求入门知识；KC：不是在MARC和BIBFRAME之间做出选择）

2024年2月底，书目概念模型兴趣小组（BCMIG）宣布将在ALA核心的兴趣小组周（https://www.ala.org/core/continuing-education/interest-group-week）召开网会讨论此问题，再度在BIBFRAME论坛引发热议，Jeffrey Edmunds对报告人之一Gloria Gonzalez的EBSCO销售人员身份的质疑更是引发争议。

日前，2024年3月7日书目概念模型兴趣小组会场（Bibliographic Conceptual Models IG session）的会议录像（3个报告50分钟）+聊天记录（共65分钟）已经上网：

• BCMIG Winter IG Week 2024

会议标题：薛定谔的目录：BibFrame是活是死？（Schrödinger’s Catalog: Is BibFrame Alive or Dead?）

一、“BIBFRAME必须死”：主要论点概要 “BIBFRAME must die”: a synopsis of the primary arguments / Thomas M. Dousa（视频0-14分钟）概述BIBFRAME论坛围绕“BIBFRAME必须死”的讨论。

二、BIBFRAME必须进化-继续：BibFrame需要进行可用性改造 (Continue to bibframe must evolve) BibFrame need a usability makeover (and it’s as easy as abc) / Robert Sanderson（视频14-28分钟）认为BIBFRAME需要降低进入壁垒，平衡可用性和完备性。

三、给BIBFRAME的情书 A Love Letter to BIBFRAME / Gloria Gonzalez（视频28-50分钟）强调图书馆需要BIBFRAME的理由，关于BIBFRAME的5个预测，费用问题；另外也推介了EBSCO产品，包括BiblioGraph和folio。

• Gloria认为需要BF的理由：[1] 图书馆需要带新用户到图书馆目录，不需要他们先走进目录；[2] 图书馆元数据需要走出目录，在任何应用中可重用；[3] MARC正阻止用户访问图书馆。【对前二者我很认同。不过，对于用户可能不知道“走进目录”的问题主要针对公共图书馆，对学术图书馆不应该是问题（如之前讨论指出的，学术图书馆的很多资源在收费墙后）】
• 关于BIBFRAME的5个预测：1、将会有Bibframe数据网络集成到一个工具中，帮助人们以新的方式发现图书馆有什么。2、将看到集中化和去中心化服务的混合。3、Bibframe发展到超越基本书目描述来描述其他领域。4、知识图谱将被集成到个性化的发现服务中。5、图书馆将有很多选择，需要图书馆提需求。
• 对吐槽众多的费用问题：[1]费用和价格在下降；[2]大机构正付费添加此功能；[3]在BF系统与工具上的投资正取得成功（Sinopia, Marva, Libris, FOLIO）；[4]开源投资对使BF可支付、可获取关键；[5]必须问自己：不从MARC转到BF会是什么费用？

— RDA躺枪 —

聊天区简直成了新RDA吐槽专场。RSC前主席Gordon Dunsire也在网会，频频为RDA作解释。

摘录若干如下：

• 对BIBFRAME的质疑/恶意（无论你怎么想）在多大程度上实际上是对新RDA的失望
• 我对新RDA的看法肯定比BIBFRAME要悲观得多
• 负担不起RDA工具包……为了可疑的利益，我们/他们将如何负担得起用无法理解的词表进行训练，获得我们负担不起的新系统
• RDA以最愚蠢的方式推出。他们本可以专注于专著的应用纲要，但没有…他们给了我们…一个本体，并期望人类阅读它…
• “res”和“nomen”让我觉得非常非常努力地在语言上做到令人难以置信的精确，但却以普遍熟悉为代价

有同行想找使用bf:Archival的例子，但没有找到，在BIBFRAME邮件组寻求帮助。

美国国会图书馆（LC）负责BIBFRAME的网络开发与MARC标准办公室的Nate Trail首先给出的解答是：档案（bf:Archival）是实例（bf:Instance）的一个类型（rdftype），因此在id.loc.gov上查实例会看到更多。

按Nate给出的实例检索式（https://id.loc.gov/search/?q=cs:http://id.loc.gov/resources/instances），侧栏细化检索有类型分面，目前Archival有1025条。【此法对查找不同类型记录特别方便，如修改为作品检索式（https://id.loc.gov/search/?q=cs:http://id.loc.gov/resources/works），再由侧栏分面细化限定】

然而，实例中并未使用bf:Archival。BIBFRAME词表网站的Archival类（https://id.loc.gov/ontologies/bibframe.html#c_Archival）的示例，也没有直接使用bf:Archival。

Nate后来解释：对作品和实例类型，LC不使用子类作为资源的名称（如bf:Archival），而是保留bf:Instance，用一个rdf:type属性进一步定义它。如BIBFRAME词表网站中的示例片断【特别是第2行】：

<bf:Instance rdf:about=http://id.loc.gov/resources/instances/5811340>【bf:Instance类】
    <rdf:type rdf:resource=http://id.loc.gov/ontologies/bibframe/Archival/>【子类Archival】
    <bf:title >
      <bf:Title >
        <bf:mainTitle >Benjamin Silliman correspondence</bf:mainTitle>
      </bf:Title>
    </bf:title>
…
</bf:Instance>

写上篇博文“如何查各类BIBFRAME记录（及作品和实例子类的表示）”https://catwizard.net/posts/20240611153107.html】时得知在BIBFRAME中档案是实例的子类。印象中RDA没有“档案”这一类。

查RDA，“档案”使用术语 archival resource（档案资源），是一个文献（类型），但不属内容类型或媒介类型。于是想给RDA与BIBFRAME的文献类型作个对照。

RDA遵循FRBR/LRM模型，资源的四层实体为“作品W-内容表达E-载体表现M-单件I”。BIBFRAME（以下简称BF）只有三层实体“作品W-实例I-单件I”，其中BF作品对应RDA的作品和内容表达。

从本体（词表）看，BF类（实体）多、几乎与属性的数量相当。而RDA类（实体）很少，但有内容类型对应于内容表达，有媒介类型对应于载体表现。因此直觉BF作品子类可对应RDA内容类型，BF实例子类可对应RDA媒介类型。但初步对比表明，事实并非如此。我甚至找出AACR2章节和MARC21头标和008、007字段来做对照，试图找出BF作品/实例子类的依据或来源。

首先，BF实例子类与RDA媒介类型差别很大，只有缩微和电子（计算机）2个相同：

仔细想想，BF实例的5个子类，都可能包含多种内容类型，如印刷品，可能含文字、地图、图像、乐谱、舞谱、手稿等等（缩微同）；档案还能包含音视频、电子资源等更多内容类型。也就是说，我当初认为的其与RDA媒介类型对应的想法根本不对路。

其次，RDA的内容类型是多种内容类型的组合，如cartographic tactile image（含地图、触觉、图像）。而BF的作品子类包含2个方面：内容类型和组织形式（RDA术语“扩展计划”extension plan）。作为MARC21的替代，BF作品子类与MARC21头标06位记录类型（内容类型）和07位书目级别（RDA扩展计划）的对应更好（下表BF作品子类后的标记=MARC21头标取值）。

与RDA相关的备注：

• 1）archival resource 档案资源，是一个文献（类型）。多个元素有档案相关规定，如：作品属性：system of organization；载体表现属性：date of production，title of manifestation。
• 2）manuscript 手稿：RDA术语表中没有“手稿”，但在一些作品、内容表达或单件元素中有相关规定
• 3）series丛编：RDA有多个丛编相关元素，为载体表现元素
• 4）print 印画：print特指印刷图片如版画，而不是BM实例子类所指广义的印刷品——RDA术语常很特别（比如unmediated 无中介）。

今夏BIBFRAME更新论坛于2024-7-1举行，视频及PPT已上线。与1月论坛一样，这次也只有2个报告，其中一个还是美国国会图书馆（LC）自己的。

参见：2024冬BIBFRAME更新论坛（2024-2-8）

BIBFRAME July 2024 Update Forum. https://www.loc.gov/bibframe/news/bibframe-update-jul2024.html

• 开场中Sally McCallum首先介绍了LC的最近活动：

[1] 发布MARC到BIBFRAME和BIBFRAME到MARC转换的更新（2.6版）。包含改进的标题和管理元数据的$1URI转换。【规范检索点加$1……见：说明文件】

[2] 在接下来的几个月里，一些LC编目员将开始在我们的BIBFRAME系统中编目，他们创建的记录将由系统转换为MARC，而不是在MARC中对记录进行双重键入【终于正式开始了】。这些记录的一些特征将通过从BIBFRAME转换进入我们的MARC 文件……。将在下周发布对它们的描述——但没有什么太大的惊喜：更多URI在$1、更多使用3XX字段等。我们随意地称其为“现代 MARC”(Modern MARC)，因为我们更多地利用了自2008年以来建立的MARC字段，主要是为了适应RDA。

• LC的报告：ScriptShifter：增强图书馆元数据和发现（ScriptShifter: Enhancing Library Metadata and Discovery / Paul Frank and Matt Miller）

ScriptShifter是LC新开发的、开源的罗马化音译工具——多种文字与拉丁字母间相互转换。【以往编目时，对非拉丁文字需要音译成拉丁字母……（将另写博文）】

在线使用：https://bibframe.org/scriptshifter。

也可本地运行、本机运行、通过API集成到其他软件中使用：

[1]在GitHub上运行基于Python的开源工具，源代码：https://github.com/lcnetdev/scriptshifter/；

[2]运行在Docker hub上找到的工具的打包Docker镜像：https://hub.docker.com/r/lcnetdev/scriptshifter/tags；

[3]使用内置web应用程序或查阅API文档：https://github.com/lcnetdev/scriptshifter/blob/main/doc/rest_api.md。

• 外部机构的报告，来自Share Family（Share-VDE），Sally McCallum称是“第一个对BIBFRAME做出重大承诺的系统”：促进BIBFRAME协作：与Share Family的互操作性和数据管理（Fostering BIBFRAME collaboration: interoperability and data curation with the Share Family / Tizianna Possemato, Casalini Libri – @Cult）

报告以多种图示介绍Share Family背景：包含的项目，2016-2024发展时间线。

Share Family的数据处理和输出，特别是Sapientia集群知识库（CKB）和 JCricket实体编辑器；CKB中深度粒度化，包括数据分组。

最后是LC最关注的互操作——强调在Share-VDE本体中包含bf:Hub，保证互操作。

Share Family（Share-VDE）近年在图书馆关联数据领域很活跃，部分相关博文可参见：

• Share Family发展概要及2023年总结（2024-1-5）
• JCricket实体编辑器（2023-10-16）
• Share-VDE本体：BIBFRAME扩展（2023-10-15）
• Share-VDE在图书馆关联开放数据中的作用（2021-10-30）
• BIBFRAME 2.0实施注册新增项目（附：意大利SHARE目录）（2017-7-25）

2024年下半年起，美国国会图书馆（LC）部分编目员开始直接用BIBFRAME编目，然后转换为MARC格式记录供使用（应该不久就可以在LC目录中看到转换记录）。2025年3月LC实施FOLIO和BIBFRAME，7月完全切换到FOLIO，现在的图书馆集成系统Voyager退休，意味着届时所有出自LC的MARC记录都由BIBFRAME转换生成。

之前LC的MARC数据的字符集为marc-8，只支持部分语言文字，随着更换到FOLIO，将使用unicode字符集，支持所有语言文字。加之元数据格式由MARC转为BIBFRAME，非拉丁文字编目政策因之而变。2024年4月，LC发布消息（Cataloging, Acquisitions News, 04/25/2024. https://www.loc.gov/aba/news/），为准备2025年春季在LC实施BIBFRAME，作为LCAP（图书馆馆藏访问平台）FOLIO实施的一部分，采访和书目检索局（ABA）将采用[新的]非拉丁文字输入书目描述的最佳实践，并附3个文件，分别是通告、建议报告和政策问题文件：

• 通告（2024-4-15）Announcement(PDF : 159 KB) 分阶段实现BIBFRAME和LCAP/FOLIO中输入非拉丁文字（2025年内，分季度实现不同语种的非拉丁文字的原文录入，使用LC开发的开放获取的罗马化工具ScriptShifter：参见：2024夏BIBFRAME更新论坛. https://catwizard.net/posts/20240712092615.html）
• 政策问题文件（2023-11-3）Policy Issue Document(PDF : 174 KB)FOLIO BIBFRAME中非拉丁文字输入的政策问题 （LC遵循《PCC多字符集书目记录创建指南》，使用MARC模式A，即非拉丁文字信息记录在880字段中，音译记录在常规MARC字段中。但自2017年开始的BIBFRAME编辑器试验中，非拉丁文字输入一直遵循MARC模式B（对应于MARC就是直接使用常规字段），书目描述是在实例中用原始文字，在作品中提供拉丁音译的检索点。/ 应考虑恢复实施MARC前在旧目录卡上描述非拉丁文字条目的方法，条目包含原始文字中的信息，检索点和正题名以音译形式呈现。以此简化书目描述的创建和结构，节省键入音译数据的资源，满足日益全球化的图书馆生态系统中非拉丁文字用户的需求。此外，以音译提供适当的检索点和正题名，确保图书馆资料的组织和安排，以及规范检索点的维护。）
• 建议报告（2024-5-8）Recommendation Report(PDF : 980 KB) 关于在BIBFRAME和FOLIO中非拉丁文字输入的建议（最佳实践草案，解决2023年“政策问题文件”中提出的2个问题：1）制定一项关于BIBFRAME描述中包含的音译数据范围的政策，2）确定生成音译数据的解决方案，促进BIBFRAME-MARC转换。/ 音译数据范围：实例：对应MARC字段245/264的信息，作品：检索点如首选题名[MARC字段130/240]。/ BIBFRAME输入采用MARC模式B，但为满足编目服务发行部（CDS）客户[购买LC书目记录的图书馆]的需求，需要为BIBFRAME-MARC转换的描述性元数据生成成对的音译字段。建议采用两种方法提供音译数据：ScriptShifter自动音译；没有自动化工具时字段空白、使用<>作为占位符。/ 附录为示例：多语种BIBFRAME格式；MARC音译占位方式）

由于是在2025年内实施到位，对其他图书馆来说，LC的三阶段实施细节不太重要，主要是了解建议的书目数据细节（还不是最后决定）。后附一条记录，直观感受变化。

尽管国内大量套录源自LC的书目记录，但小语种记录来自LC的不多，估计不会有太大影响。只是现在开始LC记录将逐步过渡到BF转换成的MARC，也需要关注下载记录的变化，确定应对方法。随着明年中Voyager的退休，数据套录方式肯定也会变动，同样需要关注。

— 找一条中文文献记录对比看变化 —

目前由BIBFRAME转换的MARC记录，是考虑其他图书馆需求的折中方案，但结果并非MARC模式A——不是所有原文字都使用880字段：只有规范检索点用音译，不用音译时直接使用相应字段。可以看到转换后的记录880字段少了很多。曾亲眼见证转换程序的变化，如2021年6月的 bibframe2marc v1.1.0 转换结果是BIBFRAME采用的MARC模式B，完全不用880字段，可参见：BIBFRAME/MARC数据双向转换程序更新（880字段消失）. https://catwizard.net/posts/20210620124221.html。

1、LC目录（https://catalog.loc.gov/）查中文文献记录（输入汉字，如：上海），找一条看MARC记录（申報自由谈）。记录010字段LCCN号=82185853 或 001字段书目号=4232950（用于查找Bibframe2Marc对比记录）

• 130 0_ |6 880-01 |a Zi you tan.
• 880 0_ |6 130-01/$1 |a 自由谈.【BF转换记录无：1XX检索点不做原文】
• 245 00 |6 880-02 |a Shen bao Zi you tan.
• 880 00 |6 245-02/$1 |a 申報自由谈.
• 246 30 |6 880-03 |a Zi you tan【BF转换记录无：2XX描述仅照录、不做罗马化（尽管通常246/247也是检索点）】
• 880 30 |6 246-03/$1 |a 自由谈
• 260 __ |6 880-04 |a [Shanghai] : |b Shanghai tu shu guan ying yin, |c 1981.
• 880 __ |6 260-04/$1 |a [上海] : |b 上海圖書館影印, |c 1981.
• 500 __ |6 880-05 |a Incomplete reprint of the literary section, zi you tan , of the daily shen bao . Originally published: shang hai, 1911-1949. Reprint ed., with new pref., includes only issues for Dec. 1, 1932 – Oct. 31, 1935 and Oct. 10-31, 1938.【BF转换记录无：5XX描述仅照录、不做罗马化】
• 880 __ |6 500-05/$1 |a Incomplete reprint of the literary section, 自由談，of the daily 申報．Originally published: 上海, 1911-1949. Reprint ed., with new pref., includes only issues for Dec. 1, 1932 – Oct. 31, 1935 and Oct. 10-31, 1938.
• 505 0_ |6 880-06 |a Shang. 1932nian 12yue 1ri-1934nian 4yue 25ri–xia. 1934nian 4yue 26ri-1935nian 10yue 31ri, 1938nian 10yue 10ri-1938nian 10yue 31ri.【BF转换记录无：5XX描述仅照录、不做罗马化】
• 880 0_ |6 505-06/$1 |a 上. 1932年12月1日-1934年4月25日–下. 1934年4月26日-1935年10月31日, 1938年10月10日-1938年10月31日.
• 630 00 |6 880-07 |a Shen pao.
• 880 00 |6 630-07/$1 |a 申報.【转换无，6XX检索点不做原文】

2、BIBFRAME工具：BIBFRAME2MARC转换工具（https://id.loc.gov/tools/bibframe/comparebf-lccn）v2.6【调整顺序880字段到配套字段下】

• 130 0 $aZi you tan.$0http://id.loc.gov/resources/hubs/36aebe4e-1991-3a2b-d7fe-f6387a551327【检索点，罗马化+$0规范，不做880】
• 245 00 $6880-01$aShen bao Zi you tan
• 880 00 $6245-01/$1$a申報自由谈
• 246 10 $a自由谈【不做880】
• 264  1 $6880-11$a[Shanghai]$bShanghai tu shu guan ying yin$c1981
• 880  1 $6264-11/$1$a[上海]$b上海圖書館影印$c1981
• 500  $aIncomplete reprint of the literary section, 自由談，of the daily 申報．Originally published: 上海, 1911-1949. Reprint ed., with new pref., includes only issues for Dec. 1, 1932 – Oct. 31, 1935 and Oct. 10-31, 1938.【不做880】
• 505 0 $a上. 1932年12月1日-1934年4月25日–下. 1934年4月26日-1935年10月31日, 1938年10月10日-1938年10月31日.【不做880】
• 630 4 $aShen pao.$1http://id.loc.gov/resources/hubs/39380c58-e2da-603d-076c-441b383c6718【检索点，罗马化+$1实体URI，不做880】
• 884  $aDLC bibframe2marc v2.6.0 (MarkLogic Corporation) $g20240714211322.0 $qDLC $uhttps://github.com/lcnetdev/bibframe2marc【转换信息】

今天去上图采编中心参加讲座：RDA的发展和更新。小会议室里挤满了人，很感慨时代的变化。几年前如有外来专家讲座，一定是市学会活动，公开发布消息，高校馆公共馆同仁济济一堂，而今却只是一个内部活动。很感谢几位让我得到了这样一个机会，姓名不表。

主讲人周小玲（Charlene Chou）现任纽约大学图书馆知识检索部门主任，目前正在上海纽约大学访学。她做报告的身份是RDA指导委员会的更广泛社区参与专员（RSC / Wider Community Engagement Officer，2022-2023, 2024-2025），据她说因北美、欧洲和澳洲三洲已有各自的地区机构，这个职位负责在其他三洲即南美、非洲和亚洲推广RDA，她从东亚开始。她说台湾的馆长在推动采用新RDA。另外，日本的国会馆有兴趣但不确定实施时间【确定不是敷衍？日本为对标原RDA已更新本国编目规则】，韩国感兴趣西文部分【和吾国类似】，新加坡积极【新加坡国家图书馆局的Haliza Jailani是2021-2023年RDA理事会亚洲代表】。

提问阶段我问了RDA实施情况。比如说，美国PCC于2024.5.1-2027.4.30滚动式实施，现在有图书馆开始实施了吗？并没有，因为第一，培训才做第一阶段，均在期待更实用的第二阶段；第二，等待应用纲要完成；第三，LC-PCC PS和MGD更新，今年完成【实施至少2025年了】。

其他已经实施的国家有：大英图书馆【工具包有BLPS】，德语联盟【有RDA DACH】；新西兰【工具包有NLNZ PS】，澳大利亚；以色列，希腊——我问：没看到有这2个语种翻译啊？答曰：可能版权比较复杂，没上网【原RDA中译本非电子版，也说明有中文翻译的】，或者直接用英语【德国也没翻译原文，RDA DACH是对应的手册】。

最近有ALA活动“RDA Around the world”【未查到资料】，西班牙文翻译已完成，但南美并无实施。

关于翻译，她特意介绍RDA registery（RDA注册）已由顾犇翻译成简体中文，初稿很快会上传征询意见；台湾正在翻译繁体中文。

看提问不踊跃，我又就她报告中提及的RDA各种映射，问了与BIBFRAME映射问题。不意她理解为BIBFRAME与MARC映射，说到了BIBFRAME实施的问题（真是意外收获）——由于b2m转换不似m2b成功，因而LC想只做BIBFRAME记录（再转换成MARC）一直没有执行【就是那个关注很久却找不到实例的BIBFRAME 100】，而比如她们馆用Share-VDE把MARC转换为BIBFRAME，觉得很好，因之没觉得有必要用BIBFRAME【大致此意】。

之前查RDA近期PPT时，发现RSC网站（www.rda-rsc.org）不知何时并入了RDA工具包网站（https://www.rdatoolkit.org/rsc），大概是为了降低维护成本，但更新不及时了，半年过去，还没有2024年的报告。2023年有在台湾和香港的报告，今天的内容大致同在香港JULAC的报告，可见 2023 Presentations | ALA RDA Toolkit：

Introduction to Official RDA Toolkit. Bibliographic Services Committee, Joint University Libraries Advisory Committee, Hong Kong. 2023-12-15.

以上相关内容可参见部分博文：

• 美国2024年5月起实施新RDA（2023-7-17）https://catwizard.net/posts/20230717095729.html
• PCC RDA入门培训：第1阶段（2024）（2024-3-21）https://catwizard.net/posts/20240321154544.html
• RDA元数据指导文档（MGD）：掌握新RDA（2022-9-10）https://catwizard.net/posts/20220910165058.html
• 德语国家标准RDA DACH（2024-3-16）https://catwizard.net/posts/20240316110201.html
• 《日本目录规则》2018年版（暂名）（2017-11-19）https://catwizard.net/posts/20171119223024.html

昨天在上海图书馆采编中心做了一个讲座，标题《美国国会图书馆(LC)实施BIBFRAME》（PPT链接附后）。

此事源于年初，采编中心纪主任说在做年度学术计划，想请我做堂讲座，主题为编目发展趋势或者大语言模型相关新技术发展等都可以。我答应了，但坦言还没什么想法。之后一直关注两方面进展。

人工智能很热（也写了几篇介绍博文 https://catwizard.net/posts/tag/ai），但刚起步，没有太多实际应用，基本上还处在设想与规划阶段，比如《PCC人工智能和机器学习战略规划任务组最终报告》（2024-4-15）。编目工作或标准方面则没有什么方向性的变化，最大的期待应该就是美国国会图书馆（LC）明年更换图书馆自动化系统FOLIO后实施BIBFRAME了。

7月1日的BIBFRAME更新论坛透露了一些重要信息，顺藤摸瓜看了些资料，也写了些博文。那天去上图听周小玲讲座（听周小玲讲座：RDA的发展和更新（实施与翻译），2024-7-17），和纪主任沟通后，确定了讲座主题。

— 历年PPT分享 —

2008年时注册了Slideshare.net，自己的PPT基本上都上传到那里。2018年时忽然要架梯才能访问了，感觉太不方便，就找了academia.edu作为替代。上传了当年的3个文档，主要给博文做链接。之后好像不是每次有PPT都会写博文，有时主办方也会分享PPT，因此没再上传过文档。

昨天讲座后，想着还是可以分享下PPT。于是今天回到academia.edu，索性把2018年以来的PPT大致都上传了。

再说Slideshare.net在2020年被LinkedIn卖给了scribd.com，目前架梯后仍可访问、上传的PPT也都在，但不知道为什么在搜索框中输入题名基本上查不到。直接访问个人主页还是可以看到。

• 2008-2017：https://www.slideshare.net/catwizard/presentations
• 2018-：https://ecnu.academia.edu/catwizard

BIBFRAME词表中，Hub的定义是：作为两部作品之间桥梁的抽象资源。

BIBFRAME 2.0最初是三层模型，即“作品 Work—实例 Instance—单件 Item”。相对于《书目记录的功能需求》（FRBR）的四层模型WEMI（作品W—内容表达E—载体表现M—单件I），bf:Work对应于WEMI前两层“作品W”和“内容表达E”。BIBFRAME词表后续更新，2.1版引入bf:Hub，大致对应WEMI最上层的“作品W”，但当时bf:Hub被定义为bf:Work的子类；2.3版将bf:Hub定义为基本模型类（Basic Model Class），可以认为真正与FRBR的“作品”对应，即BIBFRAME 2模型与WEMI模型基本达成一致。参见：

• Hub：BIBFRAME模型下的超级作品（2020-6-28）https://catwizard.net/posts/20200628160934.html
• BIBFRAME本体2.1版发布（4层确认）（2021-6-25）https://catwizard.net/posts/20210625164233.html
• BIBFRAME本体2.3版发布（2023-12-2）https://catwizard.net/posts/20231202170956.html

模型如此，数据则是另一回事。因为当初编目时并没有这样一个模型，数据没有相应的标识，现在要运用此一模型，需要通过算法对现有数据进行聚类处理，而算法如果没有适当的数据支撑，也是无法完成正确聚类的。就美国国会图书馆（LC）目前发布的BIBFRAME数据来看，bf:Work（=内容表达E）聚类还有差距，比如一些显然多次出版的作品的相同内容表达却都只有1个实例；bf:Hub（=作品W）差得更远，比如作品的不同语言翻译目前都视为不同bf:Hub。

日前有人在BIBFRAME邮件组提问，说自己原以为在BIBFRAME 2.0中，同一作品的多个翻译会放在一个Hub下，但从LC的BIBFRAME数据看并非如此（如作品《哈利·波特与阿兹卡班的囚徒》）。

LC网络开发和MARC标准办公室的Nate Trail回复，认可她的观点，并举《哈利·波特与阿兹卡班的囚徒》的Hub（Harry Potter and the prisoner of Azkaban，https://id.loc.gov/resources/hubs/7571ef89-f950-64a5-9a78-608b1bfdce54.html），说明bf:Hub数据来自LC相应的名称-题名规范记录（Rowling, J. K. Harry Potter and the prisoner of Azkaban，https://id.loc.gov/authorities/names/no2013059078.html），其中Hub侧栏的分面“related work” 来自规范记录（字段“Additional Related Forms”），其余分面的链接则由记录相关信息动态生成。Nate Trail认为LC需要“调整sparql查询中的一些内容，以优化事物之间的关联方式”。

相信随着算法改进，Bibframe Hub和Bibframe Work会有更好的聚集作用。

以下以罗琳“哈利·波特”系列作品（清单附后）第3部《哈利·波特与阿兹卡班的囚徒》为例，记录Bibframe Hub在2024-9-15的聚类现状。

— Bibframe Hub：Harry Potter and the prisoner of Azkaban —

《哈利·波特与阿兹卡班的囚徒》的Bibframe Hub，侧栏分面有6种，记录了改编电影，以及和“哈利·波特”系列中的前后作品，比系列中其他几种书揭示的内容更丰富：

• [1] Has Expression（有内容表达，取值为 bf:Work）

Rowling, J. K. Harry Potter and the prisoner of Azkaban

…… [名称相同的其他5条，略]

（说明）名称相同的6条是不同的Bibframe Work。

第1条，是相应的Bibframe Work，https://id.loc.gov/resources/works/21268504.html，有分面“Translation”（其他5条没有此分面），下列数十条翻译，如：Rowling, J. K. Harry Potter and the prisoner of Azkaban. Slovak（斯洛伐克语），链接的是Bibframe Hub——也就是说，不同语言翻译是不同Hub（即前引邮件组中提出的问题）。

上述6条Bibframe Work记录的侧栏分面详简各不相同，共同的是必有的“Has Instance”（有实例，取值为 bf:Instance），但其下均只有1条Bibframe Instance（如前述不合理之点）。

• [2] Related To（相关，取值为 bf:Work）

Rowling, J. K. Harry Potter and the Chamber of Secrets

Rowling, J. K. Harry Potter and the goblet of fire

Harry Potter and the prisoner of Azkaban

（说明）信息当来自[3]，不同的是链接到相应的Bibframe Work。

• [3] related work（相关作品，取值为 bf:Hub）

Rowling, J. K. Harry Potter and the Chamber of Secrets

Rowling, J. K. Harry Potter and the goblet of fire

Harry Potter and the prisoner of Azkaban (Motion picture)

（说明）如前引Nate Trail所述，来自规范记录，链接到相应的Bibframe Hub。

• [4]Sequel to（续前，取值为 bf:Hub）

Rowling, J. K. Harry Potter and the Chamber of Secrets

（说明）“哈利·波特”系列系列第2部

• [5] Sequel（后续，取值为 bf:Hub）

Rowling, J. K. Harry Potter and the goblet of fire

（说明）“哈利·波特”系列系列第4部

• [6] Adapted as motion picture（改编为电影，取值为 bf:Hub）

Harry Potter and the prisoner of Azkaban (Motion picture )

（说明）小说改编为电影，是不同作品，有不同bf:Hub（与WEMI模型一致）

— 附：JK 罗琳的“哈利·波特”系列 —

• 1哈利·波特与魔法石 Harry Potter and the philosopher’s stone
• 2哈利·波特与密室 Rowling, J. K. Harry Potter and the Chamber of Secrets
• 3哈利·波特与阿兹卡班的囚徒 Harry Potter and the prisoner of Azkaban
• 4哈利·波特与火焰杯 Harry Potter and the goblet of fire
• 5哈利·波特与凤凰社 Harry Potter and the Order of the Phoenix
• 6哈利·波特与“混血王子” Harry Potter and the Half-Blood Prince
• 7哈利·波特与死亡圣器 Harry Potter and the Deathly Hallows

近日LC网络开发与标准办公室主任Sally McCallum在BIBFRAME邮件组发布信息，BIBFRAME词表2.4及BIBFRAME-MARC双向转换2.7发布。奇怪的是，邮件标题只提转换不提词表（BIBFRAME/MARC conversion update 2.7. https://listserv.loc.gov/cgi-bin/wa?A2=BIBFRAME;a5601218.2409）。找出新版词表和转换的更新内容对照着看，理解到，词表是为MARC字段转换为BIBFRAME而更新，另外还有一些转换更新不涉及词表变化；而BIBFRAME到MARC反向转换主要是相应变化。

2024年7月初BIBFRAME更新论坛，介绍的是BIBFRAME-MARC双向转换2.6。7月中我准备上海图书馆采编中心讲座PPT时，无意发现已更新到2.7（增加758字段作品和实例URI）。但当时不知道词表（本体）也已更新到2.4。目前BIBFRAME网站的新闻也还没有相关信息。

参见：上图讲座：美国国会图书馆实施BIBFRAME（附历年PPT分享）（2024-8-29）https://catwizard.net/posts/20240829105435.html

BIBFRAME 2 Ontology——BIBFRAME 2 List View. https://id.loc.gov/ontologies/bibframe.html

词表/本体2.4版更新于 2024-07-10，共16处变化（新增11、其中8之前为bflc，修改5），可归为4组（新增3，修改1）：

注：GH为更新问题讨论，链接网址构成方式类似，如GH119，网址为 https://github.com/lcnetdev/bibframe-ontology/issues/119

一、分类号、标识号（类，新增）

• bf:ClassificationNal，美国国家农业图书馆分类法，bf:Classification子类。(GH119)【MARC 070】
• bf:OclcNumber，OCLC号，bf:Identifier子类。(GH120)【MARC 035，OCLC号原定义域：bf:Local】

二、关系（类与属性，新增 (GH116)）【代替BIBFRAME的LC扩展 bflc:】

• bf:Relation，关系（关联资源及其与所描述资源的关系）【代替bflc:Relationship】
• bf:relation，关系【代替bflc:relationship】
• bf:Relationship，关系类型（资源之间的关系类型）【代替bflc:Relation】
• bf:relationship，关系类型【代替bflc:relation】
• bf:associatedResource，关联资源【新增，GH116中为：bf:relatedResource？】

三、出版相关（属性，新增(GH124)）【代替BIBFRAME相应的LC扩展 bflc:】

• bf:distributionStatement，发行说明（通常转录）
• bf:manufactureStatement，生产说明（通常转录）
• bf:productionStatement，制造说明（通常转录）
• bf:publicationStatement，出版说明（通常转录）

四、丛编（属性，更新定义或定义域）【进一步改进由490字段创建丛编Hub】

• bf:hasSeries，有丛编（资源与其发布所在的较大资源之间的关系；组成部分上含较大资源的题名）
• bf:seriesOf，丛编（较大资源与其包含的资源之间的关系，形成一个丛编，较大资源的题名出现在组成部分上）
• bf:hasSubseries，有子丛编（资源与其发布所在的较大丛编资源之间的关系；较大的丛编资源是另一个总体丛编资源的一部分）
• bf:subseriesOf，子丛编（丛编资源与其包含的资源之间的关系，形成子丛编；丛编资源本身与更大的资源有关系，它是其中的组成部分）
• bf:seriesEnumeration，丛编数量（通常转录）。更新定义域 (GH100)【由Instance扩大为：Work或Instance】

上述“关系”的变化，被称为“新的关系构造”，（以间接关系）反映现有的[RDA]行为者的贡献角色建模，影响到众多MARC字段转换，如7XX$i，760-788关联款目。另外，记录中如果没有240，7XX$t等将作为240创建Hub；对041字段中的语言资源，根据每个子字段中的信息创建特定语言的注释或特定语言的伴随资源。这些信息的揭示及丛编相关属性的更新，应该能有效地改善BIBFRAME对作品和Hub的聚类。

参见：Bibframe Hub 聚类现状（2024-9-16）https://catwizard.net/posts/20240916094541.html

— 附：BIBFRAME词表及转换相关博文 —

目前的BIBFRAME 2词表，发布于2016年，自2021年起每年更新一版，是为2.0（2016-04-21）2.1（2021-06-09）2.2（2022-10-03）2.3（2023-11-30）和2.4（2024-7-10）。

• BIBFRAME词表2.0发布（2016-4-23）https://catwizard.net/posts/20160423153919.html
• BIBFRAME本体2.1版发布（4层确认）（2021-6-25）https://catwizard.net/posts/20210625164233.html
• BIBFRAME本体2.2版修订【2022年发布】（2023-12-2）https://catwizard.net/posts/20231202221222.html
• BIBFRAME本体2.3版发布（2023-12-2）https://catwizard.net/posts/20231202170956.html

MARC到BIBFRAME转换发布于2017年，BIBFRAME到MARC转换发布于2020年。更新频率高于词表，目前大致一年2版（2024年为2.6和2.7版）。

• MARC到BIBFRAME转换：并列比较工具（2017-4-7）https://catwizard.net/posts/20170407212635.html
• LC发布BIBFRAME到MARC转换（2020-5-6）https://catwizard.net/posts/20200506234309.htm
• BIBFRAME/MARC数据双向转换程序更新（880字段消失）【1.1.0版】（2021-6-20）https://catwizard.net/posts/20210620124221.html
• BIBFRAME/MARC双向转换2.4版发布：拆分多载体资源（2023-12-3）https://catwizard.net/posts/20231203155347.html

BIBFRAME 2.0采用“作品Work—实例Instance—单件Item”三层模型，bf:Work 对应于FRBR的“作品Work”和“内容表达Expression”。BIBFRAME更新到2.X后，或许应该是 bf:Hub 对应“作品W”，bf:Work 对应“内容表达E”。

无论怎么说，一个内容表达有多个实例/载体表现Manifestation是很常见的情况，比如《红楼梦》有不同出版社出版。但在美国国会图书馆（LC）的BIBFRAME数据中，却很难找到例子。目前Bibframe Work记录，右栏“Has Instance”基本上都只下挂一条实例记录（如：https://id.loc.gov/resources/works/7375470.html）。

最近有人在BIBFRAME邮件组询问这个问题，LC的 Nate Trail 回复，说明通过LC关联数据服务（id.loc.gov）的BIBFRAME Instances查询（https://id.loc.gov/search/?q=cs:http://id.loc.gov/resources/instances），[左栏]有分面“Secondary Instance”，由此可查到“次要实例”，他认为次要实例可能是印刷文本的电子版。

按上述指点，确实查到不少“Has Instance”有2条实例的Bibframe Work记录，看到的都是印刷品及其电子版。

是不是说，LC目前仅将确定为同一文本的多种媒介作为相同的内容表达（如印刷品及数字化的电子版）？毕竟不同出版社出版的版本，是否为相同的内容表达，在书目数据中没有可作出判断的依据时（如是否重印），如此处理才是严谨的。

至于同一本书的不同版本（如第1版、第2版），显然是不同的内容表达，不应该出现在Bibframe Work记录的“Has Instance”，而是在Bibframe Hub（或Bibframe Work？）记录的“Has Expression”。

CALIS（中国高等教育文献保障系统）的RDA培训，有一小节专门讲如何判断手头文献是新的载体表现、新的内容表达还是新的作品，如何制作具有不同特征的书目记录。但实施RDA之前的记录可能没有这样的特征。最近新西兰实施官方RDA，MARC引入758字段“资源标识符”，记录作品/内容表达的标识符，将有助于未来的书目数据聚类。LC最新BIBFRAME/MARC转换v2.7也已增加758字段资源标识符。参见：

• 新西兰实施官方RDA并更新MARC（2024-8-12）https://catwizard.net/posts/20240812144558.html
• BIBFRAME本体2.4版及MARC转换2.7版发布（2024-9-19）https://catwizard.net/posts/20240919135432.html

— 附：如何查看“次要实例” —

由于LC关联数据服务（id.loc.gov）查询结果显示问题，目前要查看“次要实例”记录，还需要一点小技巧：

• 【第1步】BIBFRAME Instances

网址：https://id.loc.gov/search/?q=cs:http://id.loc.gov/resources/instances

点左栏分面：Secondary Instance

此时结果栏 {Label} 内容为空，不知道是什么记录，也无法点击跳转（下行是第1个查询结果）

1. {Label}   {Dataset} BIBFRAME Instances {Type} Instance ; SecondaryInstance {Identifier} 22234936-85X-1

• 【第2步】试着取 {Identifier} 构成以下访问网址：

https://id.loc.gov/resources/instances/22234936-85X-1.html

Bibframe Instance

Title：digital file from b&w film copy neg.

右栏：Instance Of：[Captain Charles Ludlow]

• 【第3步】点击右栏链接跳转到对应作品：Bibframe Work

网址：https://id.loc.gov/resources/works/22234936.html

Title：[Captain Charles Ludlow]

右栏：Has Instance [有2个实例]

[1891]

digital file from b&w film copy neg. [经由照相负片数字化的文档]

• 【第4步】点击右栏2个链接跳转到对应实例：Bibframe Instance

经查看，是1891年某刊的图片复制品，以及其数字化版本（https://loc.gov/pictures/resource/cph.3a04452/）

想知道BIBFRAME的类Hub（bf:Hub）究竟是什么？博文比较长，先说个人结论：bf:Hub是内容表达（或内容表达组）。间接佐证：bf:Hub在2021年发布时定义为bf:Work的子类，现在bf:hasExpression属性仍同时用于bf:Hub和bf:Work类。

• 背景

1997年国际图联（IFLA）《书目记录的功能需求》（FRBR）提出书目资源四层实体“作品—内容表达—载体表现—单件”（后常简称WEMI），2017年取代FRBR系列的《IFLA图书馆参考模型》（IFLA LRM）继承此模型。本文中不加限定说明的WEMI均为LRM概念（为方便以lrm:标识），如标题中的“作品”即指lrm:Work。

美国国会图书馆（LC）的BIBFRAME 2.0模型是三层核心类“作品—实例—单件”，bf:Work对应lrm:Work+lrm:Expression。当BIBFRAME 2.1和2.3词表新增bf:Hub（作为两部作品之间桥梁的抽象资源），形成“Hub—作品—实例—单件”四层基本模型类（Basic Model Class），似乎正对应LRM的四层，但BIBFRAME 模型图现在仍是2.0版，没有Hub类。

这2个四层实体/类真是一一对应吗？bf:Hub相当于lrm:Work吗？尽管有人这么并列，我之前也这么认为，但每每看到bf:Hub记录，总有点怀疑。上月博文“Bibframe Hub 聚类现状”（2024-9-16，https://catwizard.net/posts/20240916094541.html），着重于单条bf:Hub记录，看其侧栏关联的记录。这次希望更详细了解bf:Hub本身，选择原语种为英语的《哈姆雷特》及其中译、《红楼梦》及其英译，略做探究。由于上文所引Nate Trail，bf:Hub数据来自LC相应的规范记录，因此与规范库 （authorities.loc.gov）对照。

• [1] 作品规范记录对应lrm:expression？

BIBFRAME 2.0 模型只有三层Work—Instance—Item。规范记录对应Bf:Work，书目记录对应bf:Instance，感觉很完美。

如果bf:Hub数据来自LC相应的规范记录。难道规范记录对应bf:Hub？

LC规范库，作品的规范记录大多通过名称-题名查找，少数（如匿名作品）通过题名查找。以莎士比亚《哈姆雷特》为例，查：Shakespeare, William, 1564-1616 hamlet，现有108条结果，约60条标记为规范标目，含中译3条。以下为其中4条：

Shakespeare, William, 1564-1616 hamlet（主记录，关联460条书目记录）

Shakespeare, William, 1564-1616. Hamlet. Chinese（中译，关联1条书目记录）

Shakespeare, William, 1564-1616. Hamlet. Chinese (Lin)（林同济中译，未关联书目记录）

Shakespeare, William, 1564-1616. Hamlet. Chinese (Zhu)（朱生豪中译，未关联书目记录）

LC的题名/名称-题名规范用于书目记录的130/240等字段，同一作品常有多条记录（如上，有不同语种、同一语种不同译本，以及不同选本、部分，等等）。因此作品规范记录显非lrm:Work，更接近lrm:expression。

按编目规则，文献原语种不加语种限定，因此仅有题名、无任何限定的那条记录（我暂称为“主记录”），可对应LRM的代表性内容表达，而非lrm:Work，在规范记录中应该也没有字段给予特别标识。

那么，是不是bf:Work对应lrm:expression，bf:Hub对应lrm:Work？

• [2] bf:Hub对应什么？

以前大致浏览过bf:Hub检索结果一览，感觉并没有合并相同作品。如前所引，bf:Hub数据来自LC相应的规范记录。从LC规范库与关联数据服务（id.loc.gov）的查询结果对比，两者大部分形式一致，但bf:Hub的结果数（82条）比规范记录数（约60条）还要多出不少。以下1条对应于规范库“主记录”：

Shakespeare, William, 1564-1616 hamlet（主记录）Identified By：Lccn: n80008522

由两者的名称-题名形式对比，推测多出来的那些bf:Hub，应该来自未使用规范形式的书目记录（这些bf:Hub记录中没有LCCN规范记录ID）。回顾先前博文“Hub：BIBFRAME模型下的超级作品”（2020-6-28）https://catwizard.net/posts/20200628160934.html，其中所引2019年欧洲BIBFRAME研讨会上Kevin Ford关于bf:Hub的MARC来源的介绍，正是这么说的。可是由于当初的博文误读，结论和标题完全错误。

换言之，目前bf:Hub不只对应原有的规范记录以及规范库结果，离lrm:Work距离更远。

• [3] 四层关系Hub—Work—Work—Instance

特别奇怪的是，从BIBFRAME各类记录侧栏的关系追溯，通常竟然有4层（如果加上Item的话就是5层模型了）：

Hub（has Expression）Work（has Expression）Work（has Instance）Instance

猜测在有bf:Hub前，bf:Work兼作品/内容表达，因此有两层？好奇前一层Work的数据何来。另外从数据看，bf:Hub像某种内容表达组。

• 以《哈姆雷特》主记录为例：

【Bibframe Hub】（有LCCN，对应规范记录）

https://id.loc.gov/resources/hubs/83e65f55-ac8f-fcb8-ea65-120fbbbaccec.html

Title = Hamlet

Identified By = Lccn: n80008522

侧栏：Has Expression = Shakespeare, William, 1564-1616 Hamlet（数十条/名称形式相同，此为第1条）

【Bibframe Work】（无ID，来源不明；与下条“分类号”不同）

https://id.loc.gov/resources/works/7624041.html

Title = Hamlet

Classification = LCC: PR2795.M3 H38

侧栏：Has Expression = Shakespeare, William, 1564-1616 Hamlet, 1751（数十条/名称形式各异，此为第1条）

【Bibframe Work】（无ID，URL标识同instance，对应书目记录）

https://id.loc.gov/resources/works/10026252.html

Title = Hamlet, 1751

Classification = LCC: PR2878.H3 K5 1751a

侧栏：Has Instance = Hamlet, 1751（一条）

【Bibframe Instance】（对应书目记录）

https://id.loc.gov/resources/instances/10026252.html

Title = Hamlet, 1751

Identified By = Lccn: unk84045293

• 仅偶尔遇3层，即：Hub—Work—Instance

如《哈姆雷特》规范标目中未注明中译者的那条Shakespeare, William, 1564-1616 Hamlet. Chinese（仅1条书目记录） 

【Bibframe Hub】（有LCCN，对应规范记录）

https://id.loc.gov/resources/hubs/35bf8775-775a-4808-8ba0-6d52396cf7a1（长标识）

Title = Hamlet. Chinese

Identified By = Lccn: no2016051867

Note = Data source: (hdg.: 哈姆雷 = Hamulei ; translator, Peng Jingxi)

侧栏：Has Expression = Shakespeare, William, 1564-1616 Hamuleite

【Bibframe Work】（无ID，URL标识同instance；译者与Hub不同）

https://id.loc.gov/resources/works/23394582.html

Title = Hamuleite

Contribution = Fu, Guangming, 1965- (Translator)（傅光明）

侧栏：Has Instance = Hamuleite

【Bibframe Instance】（对应书目记录）

https://id.loc.gov/resources/instances/23394582.html

Title = Hamuleite: Hamlet

Identified By = Lccn: 2023388166 = Isbn: 9787201123844

• [4] 遗留数据问题

大规模的数据往往经不起细察。曾说自己手黑，随便一查就会发现错误问题。当年关注OPAC 2.0，发现新功能常使一些原本隐藏的数据错误显现出来。这次也一样，上述《哈姆雷特》记录汉译者有问题；《红楼梦》（Cao, Xueqin, approximately 1717-1763，用姓名查可包含各种变异题名结果），看到各种版本混在一起，不同英译本被聚合在一个bf:Work下。

前述[2]中多出来的bf:Hub记录，凸显遗留数据未采用规范形式的问题。[3]中的聚合匹配错误，同样体现数据的各种问题，不一定是错误，也可能由于编目规则的逐步进化。如果通过细化不同时期MARC记录到BIBFRAME的转换规范，减少数据形式上的差异，或有助于降低聚合处理难度。