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