编目精灵III

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）/posts/2020/1215/5579

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) 与顾问分享假设的测试和验证。