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

在MARC中记录URI的核心词表(《NACO 024最佳实践指引》)

合作编目项目(PCC)在2019-2021年开展了两项以MARC记录URI的试验,意在由名称的规范控制走向实体的身份管理。在2023年3月的“URI指导小组最终报告”中,列出了正式开展此项工作的6个核心文档,其中一个核心文档曾在2018年博文中写过其早期版本:[5] Formulating and Obtaining URIs: A Guide to Commonly Used 由Vocabularies and Reference Sources. (2020)。参见:

本文围绕另一个核心文档的最新版本,关于在LC名称规范档(NACO)的MARC 024字段中记录URI的指引:[2] NACO 024 Best Practices Guidelines. (2019-2023)

024字段:其他标准标识符,除ISBN、ISSN等以外的标准号或代码或URI(书目与规范格式相同)

鉴于一条记录中出现过多024字段对用户与本地系统维护造成的麻烦,提出本最佳实践。简单地说,就是规定一般限制每条规范记录最多5个024字段。为此提出“核心词表”,当已有5个或更多时,只有出自“核心词表”的才能添加。

本指引中的核心词表,以表格示例方式,分别列举不同类型实体的来源。概要如下:

  • 个人名称:Wikidata, ISNI, ORCID, VIAF, ULAN, WorldCat Entities
  • 家族名称:VIAF, Wikidata, CERL, ULAN
  • 团体名称:Wikidata, ISNI, VIAF
  • 地理名称:Wikidata, GeoNames, TGN, WorldCat Entities
  • 作品和内容表达:Wikidata, VIAF, MusicBrainz, BBC Things, DBpedia, FAST, WorldCat Entities

虽然这是个要求遵守的政策文件,但此“核心”词表不是强制性的(并且会维护更新)。可以根据机构与馆藏的需要使用任何词表,包括前述[5]中所列词表,需要注意只有前述5个024字段的数量限制。

指引还指出,OCLC Connexion(编目软件)中的Authority Toolkit可用于搜索外部词表,并根据这些词表正确构建URI。

在MARC中使用URI:URI指导小组最终报告

虽然MARC本身不能直接用于关联数据,但图书馆界所用元数据多由MARC转换,在MARC编目中记录URI,有助于后续的关联数据应用。因此多年前已开始尝试在MARC中使用URI。

MARC书目格式于2007年新增子字段$0规范记录控制号,2016年$0扩大到包括各种标准号,并且在不标注时默认为URI。2017年新增子字段$1真实世界对象URI,区别于作为其描述的$0。当年还新增字段758资源标识符,记录书目记录中描述的资源或与其相关的资源,如FRBR作品、内容表达、载体表现和单件,以$i/$4记录关系,$0/$1记录标识符。

2015年美国合作编目项目PCC开始寻求在MARC中记录URI的最佳实践,其后开展了2项试验:

  • 2019-2021:PCC URIs in MARC Pilot
  • 2020-2021:PCC Wikidata Pilot(在MARC中记录维基数据的URI)

URI指导小组(URI Guidance Subgroup, UGS)属于PCC的关联数据咨询委员会(LDAC)和身份管理咨询委员会(IMAC),应PCC政策委员会(PoCo)要求撰写报告,就如何在书目和规范记录中使用MARC中的URI提供指导,以下是其最终报告:

关联数据咨询委员会/身份管理咨询委员会的URI指导小组给合作编目项目政策委员会的报告 LDAC/IMAC URIs Guidance Subgroup Report to PCC PoCo (March 17, 2023)

报告提出7个建议,以下为摘译【本人注】

  • 建议1【正式做】:正式终止MARC中URI试验,并采取适当措施使编目员能够在MARC记录中插入URI【试验早已结束,现在应该真正做了!】。这将包括审查相关文件以进行任何必要的编辑:政策声明、元数据指导文档、描述性编目手册、LC指南补充、参与者的手册和其他文档。此外,核心的MARC中URI文档应由PCC发布和维护,PCC应就在MARC中插入URI提供指导。…建议的核心汇编在下面的附录C中。
  • 建议2【总则】:公布在MARC中插入URI的项目以及提供指导的PCC小组的总则。…附录G汇编了一些总则。…
  • 建议3【核心文档】:组织关于在MARC中添加URI的核心文档(见附录C),并将其作为集合发布。这可能需要成立一个小组来处理文件以供发布…。流程可能包括…。进一步建议,指导在职编目员的信息应尽可能汇编在一份文件中,可能是按照NACO 024最佳实践指南的最佳实践文件【附录C核心文档 [2]】。
  • 建议4【用例】:在上面提到的同一集合中,记录MARC中URI的用例。关注将URI添加到MARC的用例范围可以帮助我们了解添加这些数据可以实现的各种目标以及它可能产生的影响。此外,培训计划(如以下建议5中所建议的)——如果制定了这些计划——可以包括为什么这项工作很重要,如何使用最终结果,以及它如何影响用户。(下面的附录E是记录用例的开始。)
  • 建议5【培训】:责成培训常设委员会制定培训计划,以便在书目和规范记录的MARC中添加URI。
  • 建议6【政策指导】:要求新的或现有的机构提供政策和实践指导,以回应PCC参与者的问题。……
  • 建议7【调查】:在PCC成员的适当时间进行调查,以衡量MARC中URI用户的进展、发展和态度,并评估未来需要支持的领域。

收录相关资料的8个附录

附录A:小组职责【为MARC书目和规范记录中URI的使用提供指导】

附录B:相关PCC和其他报告、指南和资源【2页】

附录C:核心文档【PCC指导文件6种】

  • [1] MARC object table: a field-by-field analysis of the bibliographic format. (2019)
  • [2] NACO 024 Best Practices Guidelines. (2019-2023)
  • [3] PCC Task Group on Linked Data Best Practices Final Report. (2019)
  • [4] URI FAQs. (2018)
  • [5] Formulating and Obtaining URIs: A Guide to Commonly Used Vocabularies and Reference Sources. (2020)
  • [6] URIs in MARC Cheat Sheet. (2023)

附录D:PoCo对3个PCC试验进展中描述的调查中确定的需求,2021年11月5日,幻灯片10-27页。【调查结果,URI指导小组的意见】

附录E:用例,衍生自:Use Cases for URIs in MARC: Toward Native Linked Data. (2018)【4方面用例:发现,ILS,规范[数据]供应商,走向原生关联数据】

附录F:格式化和获取URI【附录C核心文档 [6]】

附录G:总则

  • 主要来源于PCC MARC中URI工作组(PCC Task Group on URIs in MARC)和PCC应用常设委员会MARC书目记录元数据和实践工作组(PCC Standing Committee on Applications Task Group on Enhancing Metadata and Practices in MARC Bibliographic Records)的报告。
  • 编目员在MARC中输入URI的总则:
  • – 在MARC中嵌入URI的建议/指南必须符合现有MARC环境的成本效益
  • – MARC中的文字值有时很容易在没有$0或$1的情况下转换为URI,因此,在这些情况下,不需要在MARC记录中输入这些URI。
  • – 避免在任务易于自动化的地方手动添加URI。例如,一些软件,如Authority Toolkit,提供了简化URI输入的服务。协调工具(Reconciliation tools),如OpenRefine,允许查找外部数据库中的URI,并将其与数据中存在的实体进行匹配。另一方面,有时使用频率较低的词表,或使用可能不稳定或不唯一标签的来源,被排除在服务之外或难以协调,从而证明使用手动输入是合理的。
  • – 应该注意使用规范的和可解引的URI,而不是简单地使用任何呈现自己的http链接。
  • – MARC本身并不是一种关联数据格式。将URI插入MARC记录主要是为了提高MARC到RDF转换的输出
  • – 注意编目员的时间。
  • PCC小组在MARC中提供URI指导的一般原则:【略】

附录H:时间表,2007-2022【$0、$1、758字段加入MARC及调整;PCC成立工作组/委员会,包括MARC中URI/身份管理/关联数据/为BIBFRAME转换简化MARC/增强MARC书目元数据;试验MARC中URI、Wikidata;等】