分类： 若有所思

Share-VDE本体：BIBFRAME扩展

Share虚拟发现环境（Share-VDE，亦简称SVDE），是意大利厂商 Casalini Libri 和 @Cult 与多个北美研究图书馆合作的BIBFRAME项目。目前为 Share-VDE 2.0（https://svde.org/）。发展过程可参见：Share-VDE在图书馆关联开放数据中的作用（2021-10-31）

Share-VDE使用BIBFRAME词表描述书目实体。作为关联数据搜索系统、联邦搜索环境，考虑聚集作品的需求，要求扩展BIBFRAME。

众所周知，FRBR/LRM书目有4层（Work—Expression—Manifestation—Item），而BIBFRAME模型只有3层（Work—Instance—Item），bf:Work合并了LRM的前2层。后来BIBFRAME增加了对应于LRM模型Work的bf:Hub、作为bf:Work的子类【为什么是子类？】，而SVDE则相应增加了Opus类。

上月结束的今年欧洲BIBFRAME研讨会（BIBFRAME Workshop in Europe 2023, BFWE 2023），有Share-VDE本体介绍，对BIBFRAME有更多扩展。PPT中并有本体网页链接，以OWL描述SVDE本体（由Share-VDE Sapientia Entity Identification (SEI)工作组完成），其中还多有与LRM/RDA的对应关系。

SVDE本体尚未正式发布，开发者希望托管到LC网站。以下来自概述PPT及本体网页。

——Share-VDE本体——

  • 概念图+核心模型

svde:Opus -> svde:hasExpression -> svde:Work

svde:Opus -> svde:hasOpusType -> svde:OpusType（Opus类型未定）

svde:Work -> svde:inHub -> bf:Hub

  • 类与属性

svde:Opus：艺术或智力活动的一个独特的概念结果。作为SVDE中的最高抽象级别，Opus是一个允许对被视为功能性或近似等效的作品进行分组的实体。与bf:Hub相关但不等同，它们分别通过bf:hasExpression / svde:hasExpression收集bf:Work实体（备注6：LRM作品和RDA作品的平行类，包含svde:Opus的属性集平行于LRM作品和RDA作品中的那些属性）【核心类】

svde:Work：由一组元素定义的、代表Opus每次“实现”时所采取的特定智力或艺术形式（备注7：bf:Work的子类；组成svde:Work的一组属性，平行于LRM内容表达和RDA内容表达中的那些属性）

svde:hasExpression：关联Opus[定义域]到Work[值域]，近似LRM=is realized through/RDA=has expression of work。

svde:inHub：关联到1个或多个svde:Work[定义域]到一个bf:Hub[值域]；bf:relatedTo子属性（备注5：利用bf:Hub对同一svde:Work的译本进行分组；计划未来用例：对同一svde:Work的不同版本或改编进行分组）

svde:OpusType：支持识别Opus类别【猜想用于搜索结果分面】

svde:hasType：可由实体专门化的中间属性。RDA has category of entity子属性。

svde:hasOpusType：关联Opus[定义域]到OpusType[值域]；svde:hasType子属性。

svde:closeMatch：另一个本体或方案中语义相似的实体（通常是类或属性）；dct:relation子属性【定义用】

见：

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

增强MARC书目记录中元数据（SCA工作组最终报告）

最近十多年，针对关联数据在图书馆中的应用，MARC21标准经过多轮扫描更新，其中最重要的变化就是在越来越多的字段中加入控制子字段、记录可解引到RDF的URI，用于增强MARC记录：

  • 2016年重新描述$0规范记录控制号或标准号，取消可解引URI的前缀代码(URI)（其他号码仍需前缀）；
  • 2017年新增$1真实世界对象URI。

字段加入URI子字段$0$1，从检索点及代码开始，现在进入到描述性字段。近日合作编目项目（PCC）上线新的报告：

《增强MARC书目记录中元数据和实践的SCA(应用常务委员会)工作组最终报告》Final Report of the SCA Task Group on Enhancing Metadata and Practices in MARC Bibliographic Records. 2023-1-17

报告2023-1-17完成，2023-5-11政策委员会（PoCo）评审，2023-8-31批准了报告建议的10个字段中的8个，预计将体现在MARC标准的后续更新中。

报告审查了82个字段，在非结构化文本中识别出实体，对其中10个描述性字段提出建议。建议包括增加$0和$1子字段，以及对当前政策（即现行编目指导文件）的修订。当前政策引用的现行编目指导文件主要是：

  • 原RDA和官方RDA，主要讨论其中的LC-PCC PS（政策声明）
  • MGD（元数据指导文档）
  • 341字段还引用3种OLAC最佳实践：OLAC Best Practices for Cataloging Objects Using RDA and MARC21，OLAC Best Practices for Cataloging Streaming Media，OLAC Best Practices for Cataloging DVD-Video and Blu-Ray Discs
  • 506和540字段还引用：Provider Neutral E-Resource Guidelines

附录A对10个描述性字段的建议，概要如下（其中7个添加$0$1，5个得到批准/其中1个MARC标准已更新）

  • 024 – Other Standard Identifier (R) 其他标准标识符【添加$0$1，更新GMD】
  • 210 – Abbreviated Title (R) 缩略题名【添加$0$1，创建PS+更新MGD（建议未批准：PCC CONSER试点小组或美国ISSN中心不建议实施210字段）】
  • 300 – Physical Description (R) 物理描述【更新PS+创建MGD】
  • 341 – Accessibility Content (R) 可访问性/辅助内容【添加$0$1，添加$2+创建无障碍词表+来源代码，创建PS+更新MGD】
  • 504 – Bibliography, Etc. Note (R) 书目等附注【推荐使用353字段/辅助内容特征，更改PS+MGD/使用受控词表=补充内容代码】
  • 506 – Restrictions On Access Note (R) 访问限制附注【添加$0$1，更新术语来源代码，创建PS+更新MGD/鼓励使用856$l（建议未批准：出于相同目的已经存在856$l）】
  • 536 – Funding Information Note (R) 资助信息附注【确定各种资助号是否有可用URI；710记录资助者】
  • 540 – Terms Governing Use And Reproduction Note (R) 管理使用和复制条款附注【添加$0$1，更新访问限制条款来源代码表，创建PS+更新MGD/使用856r（与506近似但被接受）
  • 586 – Awards Note (R) 奖项附注【添加$0$1，结构化/添加$c奖项类别$d奖项日期，创建PS+更新MGD】
  • 658 – Index Term–Curriculum Objective (R) 索引词—课程目标【添加$0$1（文中所引MARC讨论稿已批准/MARC标准2023-6-21已更新）】

工作组的8条原则：

  • 1.尊重并肯定先前PCC工作组关于描述性字段的建议。
  • 2.在考虑是否以及如何将描述性字段适用于关联数据时，注意编目员时间和资源的投资回报。
  • 3.在评估拟议的实践变更时，考虑回溯协调(reconciliation)的必要性，以及此类协调所需的资源。
  • 4.评估MARC字段是否明确地传达了单个对象引用。
  • 5.请记住，并非所有URL/URI都可以用于关联数据；关联数据需要一个可以解引到RDF中的URI。
  • 6.保持在工作组根据职责确定的范围内。
  • 7.具有明确标识的词表的字段值可以机械地转换为关联数据，而不必要求编目员在MARC数据中嵌入子字段$0或$1 URI。
  • 8.当数据在记录中其他地方的机器可读字段中复制时，人类可读字段不需要适应关联数据，这些字段可以更容易地用于关联数据。

可以看到对工作效率的重视。而附录B（增强现有描述性字段的工具和策略）更是针对以上每个字段，提出各自使用软件工具识别或批量更新的建议。

参见：在MARC中使用URI：URI指导小组最终报告（2023-8-29）