标签： LD4

蓝色核心计划：转变编目模式、停止套录

图书馆编目有两种，即所谓原编（原始编目）和套录（复制编目）。原编指对没有书目记录的资源进行编目；套录指复制已有书目记录，如有问题则修改。传统上，馆藏的所有书目记录都保存在本馆系统中（即使是云存储）。随着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转换简化MARC格式

美国国会图书馆（LC）实施BIBFRAME已是箭在弦上，届时它将不再以MARC进行编目，代之以提供由BIBFRAME转换生成的MARC记录。为此，合作编目项目（PCC）于2022年初成立“BIBFRAME转换之MARC简化专责组”，其职责是检查LC的BIBFRAME2.0到MARC21转换程序和相关规范，据此开发一套简化的MARC字段，以准确有效支持BIBFRAME转换。年中和年末，中期报告和最终报告如期完成发布。见：

这套简化字段，在职责文件中称“瘦MARC”（Skinny MARC）。出于词义褒贬原因，小组先后考虑过一些其他术语，包括：简化MARC（simplified MARC）、基本MARC（essential MARC）、BF2MARC、用于BIBFRAME的MARC改编（MARC adaptation for BIBFRAME）、链接MARC（linky MARC）。特别说明的是，需要与先前的“轻量级MARC”（MARC 21 LITE, 2008版）区别开来。小组称不推崇任何上述名称，但或许是出于表述简单的考虑，在最终报告中多用“BF2MARC”。

小组提出的BF到MARC字段表，称为“来自BIBFRAME的MARC描述性字段的初步曲目”（Preliminary Repertoire of MARC Descriptive Fields from BIBFRAME）。所谓“初步”，是因为提供的2个表格中，主表“MARC<-BF”只有90多个变长字段子字段（如020$a）或定长字段位置段（如008/07-10），其中还包括12个无对应的008字段位置段，实际有对应的只有80多对。副表“MARC not included”列出没有对应BIBFRAME元素的近130个子字段等（如130/240$a）。可以想见这离成品有多大距离，LC的BF/MARC转换已历多年，我原本以为据此提出一套简化MARC格式是件并不复杂的任务，如此结果真是出乎意料。

为此，最终报告概述首先指出：“我们团队认识到，当前的BIBFRAME环境还不够成熟，无法建立稳定可靠的MARC字段集以作为永久‘简化’集”。之后列举了小组工作的复杂性（摘录）【本人理解】：

  • LC 转换记录的可得性缺乏【LC没提供】
  • 同行示例的通行性缺乏【于是从开发Sinopia的[LD4]获取，但数据滞后于LC目前用的BF2.2，也没有用LC本地扩展bflc:】
  • 书目记录中罗马化的未来不确定性【LC4调查显示罗马化对图书馆运行与服务很重要，但LC更倾向于使用有限罗马化文字；亲历LC的BF到MARC转换在使用/不使用880字段间摇摆】
  • LC的BIBFRAME扩展(bflc) 的状态【主要款目在BF中没有对应物，只在扩展bflc:；BF新类Hub与240字段的关系】
  • 序列化MARC数据的不确定性【检索点1XX/6XX/7XX/8XX中不同子字段，对规范维护的影响】
  • 小组对专业格式的专业知识的限制

接着提出了9个希望PCC未来讨论的开放主题【略】

附录2，BIBFRAME到MARC 21(BF2MARC)转换原则和量规（摘录）：

1、BF2MARC记录看起来将不像原生MARC【包括只带最少的ISBD标点；淡化主要款目，但包含关系代码；可能用040或884字段中的代码标识转换生成的记录】

2、BF2MARC记录虽然不一定复制惯用的MARC技术或惯例，但仍应像传统MARC记录一样发挥作用，支持以下领域的基本机器和人类操作：a.提供所描述资源的明确标识；b.提供所描述资源的必要描述性细节；c.启用对书目检索点的受控检索；d.为书目检索点的存在提供合理的理由【附注】；e.启用对主题检索点的受控主题检索；f.提供足够的元数据出处以实现信任和管理。【这是小组的意见，更从涉及编目规则，LC是否认可？】

3、转换必然是一个有损的过程。BF2MARC数据的功能要求不是可以通过算法将其转换回BIBFRAME。

4、应允许并鼓励对BF2MARC记录进行后续的下游修改。

Sinolio=集成FOLIO和Sinoipa编辑器

在2021年第5届欧洲BIBFRAME研讨会（BIBFRAME Workshop in Europe 2021）上，有2个关于FOLIO和Sinoipa编辑器的报告：

Sinopia是LD4P项目的RDF编辑器，可以BIBFRAME和其他本体进行编目，最初基于美国国会图书馆BIBFRAME编辑器。有关这两个编辑器，可参见本次会议的另一个报告：两个编辑器的故事（A tale of two editors）

关于Sinolio的报告在会议网站上仅有简介：开源关联数据编辑器Sinopia正在探索2021年秋季的FOLIO集成。这项工作非正式地称为 Sinolio（Sinopia 和 FOLIO 的组合），重点将放在API级与像BIBFRAME这样的Sinopia资源集成在FOLIO Inventory的馆藏、实例和单件中具有代表性的作品、实例和单件。

关于Sinopia和FOLIO的报告也包含Sinolio的一些信息，摘译如下：

作为安德鲁W.梅隆基金支持的LD4P3（闭环） 项目的一部分，康奈尔大学和斯坦福大学正在探索将Sinopia RDF编辑器与FOLIO开源图书馆服务平台集成的工作。概念整合证明将允许实施FOLIO的图书馆使用Sinopia为其部分馆藏提供丰富的书目描述，同时继续将MARC用于其他项目。RDF数据将存储在Sinopia中，同时也在FOLIO Inventory中存储足够的数据，以允许Sinopia中描述的资料的收集管理和流通。这种集成将是使RDF成为图书馆编目主流部分的重要一步，有助于将关联数据编织到日常图书馆工作流程中，并弥合MARC和LOD（关联开放数据）世界之间的差距。
康奈尔大学2021年7月全面实施 FOLIO。FOLIO本身没有RDF编目工具，FOLIO+Sinopia=用 BIBFRAME维护其目录部分的路径，无需单独的系统或额外的操作记录。Sinopia将提供BIBFRAME存储与编辑。Sinopia+FOLIO=Sinolio。Sinolio ETL（抽取、转换、加载）工作流程：i. 从Sinopia中提取RDF，ii. 转换为FOLIO典藏记录，iii. 通过Okapi API加载。

Sinopia编辑器可注册试用：stage.sinopia.io

参见：2021欧洲BIBFRAME研讨会信息（2021-10-17）