【Share-VDE的前世今生】

Share-VDE始于2016年。

2017年，意大利@CULT公司在BIBFRAME 2.0实施注册（BIBFRAME 2.0 Implementation Register）中添加了其开发的7所大学的目录门户：SHARE — Scholarly Heritage and Access to Research，包含200万书目记录、34万规范记录，采用BIBFRAME词表的关联数据发布。以FRBR化目录界面，呈现作者的增强信息。参见：BFRAME 2.0实施注册新增项目（附：意大利SHARE目录）（2017-7-25）

2018年BIBFRAME更新论坛，Casalini Libri（书目和规范数据提供者，PCC成员）、@Cult（ILS、发现工具、语义网解决方案厂商）介绍其与16个北美研究图书馆合作的Share-VDE项目（https://share-vde.org），用URI强化MARC记录。目录界面与SHARE相同，只是收录内容不同吧。参见：2018年BIBFRAME更新论坛（2018-11-14）

2019年初BIBFRAME更新论坛，斯坦福大学介绍LD4P2项目使用SHARE-VDE转换记录为BIBFRAME。参见：ALA 2019仲冬会议的BIBFRAME更新论坛（2019-2-17）

2020年LD4P3项目，Share-VDE作为托管编目环境，成为项目重要的协作者。LD4系列项目至此“闭环”，意在关联数据环境下创建一个完整周期的工作模型，进行图书馆元数据的创建、共享和重用。参见：关联数据编目走向现实——新项目LD4P3及LD4社区（2020-12-10）

2021年9月第5慲欧洲BIBFRAME研讨会，公司介绍技术上重构的Share-VDE 2.0（https://svde.org/）。参见：2021欧洲BIBFRAME研讨会信息 （2021-10-17）

【Share-VDE声明】

与此同时，Share-VDE咨询委员发布了一个声明，描述该计划在图书馆关联开放数据的更广泛背景下的作用，内容包括SVDE概述、数据模型、LOD、PCC数据池、工具和发现（以下为谷歌翻译，仅少量人工干预，如链接数据->关联数据）

Share-VDE在图书馆关联开放数据中的作用（Share-VDE’s Role in Library Linked Open Data）

概述

Share-VDE（虚拟发现环境）项目自 2016 年最初的 Share-VDE 原型以来一直是图书馆关联开放数据和 BIBFRAME 使用的领导者。 通过汇集来自欧洲和北美许多图书馆的数据，Share-VDE在异构环境中展示了 BIBFRAME 的强大功能。 Share-VDE 植根于美国国会图书馆开发的 BIBFRAME 数据模型，但扩展到来自许多图书馆的图书馆数据，显示了合作的力量。成员图书馆与 Casalini 和 @Cult 的开发团队合作，贡献了他们的数据、时间和资源来开发 Share-VDE。

数据模型

作为图书馆生态系统中的 BIBFRAME 节点，Share-VDE 提供丰富的数据，可与其他 BIBFRAME 节点互操作。 Share-VDE 将来自成员图书馆的 MARC 规范和书目数据汇集在一起，用权威实体对其进行丰富，并将数据聚类到 BIBFRAME 实体中。 Share-VDE 工作组详细审查了聚类，并扩展了 BIBFRAME 模型以满足现实世界的需求并反映参与图书馆的数据。数据模型的这种发展产生了 Share-VDE Opus（一种 bf:Work），它将所有相关内容表达组合或聚集在一起并代表原始/创造性作品，从而促进与 IFLA LRM 的互操作性。

关联的开放数据

Share-VDE 基础设施基于 LOD 平台，该平台旨在能够自动化创建和发布关联开放数据的过程，而不管数据源格式如何。 Sapientia 集群知识库在 RDF（因此作为关联开放数据）中可用，并可通过 SPARQL 端点和 API 查询访问。

PCC数据池

基于这项开发工作，Share-VDE 被 LD4P3 基金选中来创建 PCC 数据池。 Share-VDE 与 LD4P、OCLC 和 PCC 合作，将所有 BIBCO 和 Conser MARC 编目整合在一起。 Share-VDE 数据模型和聚类算法被应用于创建 PCC 质量 BIBFRAME 数据的开放池。 PCC 数据池将作为编目员使用 Sinopia 创建本地生产的 BIBFRAME 的可信数据源，以及任何用户都可以使用的关联开放数据。

工具

除了其他开发工作之外，Share-VDE 团队还在创建工具来处理数据。 Share-VDE 数据模型预计，在大量自动化实体集群中，某些集群或关系链接将不准确。 J.Cricket 编辑器提供了一种将直接用户专业知识应用于维护 Sapientia 集群知识库的方法。成员图书馆与开发团队也一直在探索和推荐外部数据源，以将其合并到为集群知识库提供数据的规范数据流中。此外，他们正在研究新的规范工具和服务，以与 BIBFRAME 模型保持一致并扩大规范数据的使用。

发现

最后，Share-VDE 带来了许多其他 BIBFRAME 项目所缺少的关键元素——发现。正如 Share-VDE 名称所示，Discovery 从一开始就是该项目的重点。 Share-VDE 发现基于 BIBFRAME，使用实体模型。与基于记录的目录不同，Share-VDE 侧重于作品和作者元素。这种新模型通过专注于原始作品而不是单个图书馆中的特定实例，避免了基于 MARC 的目录中存在明显重复记录的长期问题。这种方法超越了关联数据的丰富（例如数据卡），成为了一种新的发现方法。这是对 BIBFRAME 生态系统的一个巨大补充，展示了关联数据改善用户体验的力量。

总结

Share-VDE 是一个 BIBFRAME 节点，在新兴的书目生态系统中提供可与图书馆和其他 BIBFRAME 节点交换的权威数据。数据模型和工具是由一个强大的合作社区开发的。 Share-VDE 计划是该生态系统的领导者，并支持最终目标：促进丰富和结构化数据的重用，并为研究社区提供新一代获取知识的工具。

今年年中看到BIBFRAME更新论坛又讲到“BIBFRAME 100”，即美国国会图书馆（LC）去年有100名编目员、每周2天、以BIBFRAME编目，2021年起改为全部350名编目员、每周5天、以BIBFRAME编目，并且不再做MARC记录，此100仍100%之意。

计算一下：350人*5天*25周/半年=43750人天

假定每人每天做3种，就会有13万条BIBFRAME记录，即使少至1种、也该有4万条以上。

由于LC并未更换系统，因此其目录中的新增记录应该都是由BIBFRAME转换而来的MARC记录。这些记录长什么样？是不是和BIBFRAME到MARC转换界面看到的一样？于是想查一下。

在BIBFRAME到MARC转换中，转换而成的MARC记录中有884字段（2015年新增），形如：

884 $aDLC bibframe2marc v1.1.0-SNAPSHOT $g20210619231058.0 $qDLC $uhttps://github.com/lcnetdev/bibframe2marc

用LC目录的专家搜索查这个特征，是不是可以找出来由BIBFRAME转换而来的记录呢？
于是到LC目录：

一、关键词搜索（专家搜索）Keyword Search (Expert) https://catalog.loc.gov/vwebv/searchKeyword

• 884A bibframe2marc（Your search could not be processed as entered.）
• K884 bibframe2marc（Your search could not be processed as entered.）
• 说明884不可查。

二、再看搜索帮助：Search/Browse Help — Keyword Bibliographic Index Configurations https://catalog.loc.gov/vwebv/ui/en_US/htdocs/help/index_keyword.html

• 页内搜索884，查到884$u使用KURL – Electronic Access，高级检索查Advanced Search https://catalog.loc.gov/vwebv/searchAdvanced，选择途径（within）Electronic Access (KURL)，查找：
• https://github.com/lcnetdev/bibframe2marc 或 bibframe2marc（Your search found no results.）

三、是真没有，还是查不到？再试着查2021年或2020年编制的记录（LCCN以2021或2020起始）。

• 高级搜索，选择途径LCCN：
• 2021（Your search found no results.）
• 2020：2条（分别是010=2020，显然有误；010=2020938908）
• 查其他年份，没有结果——结论：LCCN只能完全一致检索（2020年那条能搜索到的原因不明）

四、再查2021或2020年出版文献（008字段第1出版年），专家搜索：

• 008D 2021（大多在版编目记录，有263字段计划出版日期）
• 008D 2020（大多在版编目记录，有263字段计划出版日期；今天查在版编目记录明显减少）
• 记录005或008字段显示2021年的，均未看到884转换字段。
• 放弃。

今天与同行讨论此事，想起当初（2021-7-8）所写上述内容，放出。

个人猜测，LC当前的自动化系统在导入由BIBFRAME转换而成的MARC记录时，屏蔽了884字段，导致字段信息丢失？

参见：

LC联机目录的“专家搜索”（2015-10-6）

BIBFRAME/MARC数据双向转换程序更新（880字段消失）（2021-6-20）

884字段：描述转换信息（2015新增）https://www.loc.gov/marc/bibliographic/bd884.html

• $a – Conversion process (NR) 转换处理（如： DLC bibframe2marc v1.1.0-SNAPSHOT）
• $g – Conversion date (NR) 转换日期（yyyymmddhhmmss.X，如：20210619231058.0）
• $k – Identifier of source metadata (NR) 来源元数据标识符
• $q – Conversion agency (NR) 转换机构
• $u – Uniform Resource Identifier (R) [转换程序]URI（如：https://github.com/lcnetdev/bibframe2marc）

四月的上海，可以说整月都是愚人节【COVID-19】。所以，现在发这个愚人节故事似乎也不算太晚。

4月1日那天，Jeffrey Edmunds在BIBFRAME邮件组发帖“MARC转换到BIBFRAME”。文中可见对此一趋势的不满，对小型图书馆被抛弃的无奈。也提到相关的重要机构LC和OCLC，在MARC及其转向关联数据过程中有重要影响的人物Terry Reese、Roy Tennant和Lorcan Dempsey，重要的编目软件Connexion、MarcEdit和Sinopia。

MARC –> BIBFRAME transition（全文翻译如下）

即时发布

美国国会图书馆今天宣布，自2022年7月1日起，所有LC系统将从MARC转换为BIBFRAME。

• MARC记录将不再由LC创建或从LC获得
• 现有的书目记录将以RDF三元组被原子化、存储及提供
• 所有LC发现工具的搜索结果都将呈现为知识图谱而不是列表

在LC宣布的同时，OCLC公布了将WorldCat从基于MARC的数据库转变为基于BIBFRAME的三元组存储的计划。OCLC的编目客户端Connexion将于2022年7月1日停用，并由Sinopia取代，以允许OCLC成员以BIBFRAME本地创建和管理书目元数据。

BIBFRAME和关联数据倡导者称赞该公告是十多年发展的顶峰。高级图书馆管理者April Fisch说：“通过这一公告，我们看到了数千小时工作和数百万美元投资的成果。现在，当用户搜索我们系统之一时，他们将看到的不是一个无聊的可用资源列表，而是一些漂亮的东西，比如知识卡和指向其他事物的链接，以及更多指向其他事物的其他事物的链接，以及更多指向其他链接的链接带有更多链接的信息和链接。旨在将用户与资源联系起来的传统图书馆发现系统已经过时。这些新系统将把用户与一切联系起来，我相信我们会同意，这更酷。”

Roy Tennant，二十年前他的心声：“MARC必须死！”终于被听到了，大喜过望。 “终于！”据报道，他明显松了一口气。 “我开始以为MARC可能永远不会死！” （另一方面，MarcEdit的创建者和ALCTS编目和元数据管理部门颁发的2019年Margaret Mann奖获得者Terry Reese沮丧地在俄亥俄州立大学校园内蹒跚而行，喃喃自语“现在怎么办？” )

Lorcan Dempsey著名地观察到“发现发生在别处”。由于BIBFRAME完全放弃了MARC，发现现在将无处不在，即使用户无法判断它正在发生。

BIBFRAME 和关联数据长期承诺的极大改善的用户体验现在将成为现实。新系统不再回答诸如“我在哪里可以买到这本书？”之类的无聊问题，而是允许用户形成诸如“向我展示生活在18世纪并在莱比锡出版的名叫玛丽亚的德国女作家的所有资料”之类的查询。或者柏林、还有谁有红头发、或棕色、还有一只名叫基普的腊肠犬。”

当被问及资源较少且现场技术专业知识较少的小型图书馆如何应对巨变时，LC政策和标准部的一位发言人发表了以下声明：

“嗯，不确定。”

《图书馆技术通讯》第1卷第4期，有篇关于把MARC格式记录转换为BIBFRAME，生成关联数据，形成多样化的网络服务：

EBSCO和Novelist使用BIBFRAME来促进可发现性（EBSCO and Novelist use BIBFRAME to facilitate discoverability）

EBSCO旗下NoveList的“关联图书馆服务”产品（Linked Library Service），利用关联数据启用多种途径，使图书馆及其馆藏在网络上更加可见。途径之一是EBSCO与Google合作，提供从Google搜索中的知识面板借书的选项。

“关联图书馆服务”作为Novelist的订阅服务提供。大多数订阅者是公共图书馆，但也有其他图书馆类型。SirsiDynix还提供名为BLUEcloud Visibility+的服务，据称有10个国家/地区的6,000多家图书馆参与“关联图书馆服务”。
Novelist Linked Library Servicehttps://librarytechnology.org/images-bib/27302-lls.jpg图1说明了与“关联图书馆服务”相关的数据流及其启用的用户路径：

• 订阅该服务的图书馆以MARC格式导出其馆藏数据。
• 这些记录被转换成BIBFRAME并并入Library.Link网络。
• 图书馆可以访问管理界面和仪表板，以查看其关联数据结构以及通过该服务促进的使用事务的统计信息。
• Library.Link中的数据流入多个目的地，包括
  • 用于在搜索结果中启用“借阅”操作的Google知识图谱，
  • 谷歌图书，
  • 互联网档案（Internet Archive）以启用开放图书馆（Open Library）中的选项，以便从附近的图书馆借阅馆藏，并为参与此服务的图书馆启用受控数字借阅。
• 图书馆的关联数据还可用于生成与指定列表或主题选择相对应的书流（book rivers）或其他小部件（widget），然后可以将其集成到图书馆的网站、目录或任何其他资源中。
• 搜索结果中显示的Google知识面板中的借阅操作根据JSON提要中指定的语法将用户连接到图书馆的目录。“关联图书馆服务”启用的借阅操作适用于任何图书馆集成系统（ILS）产品的联机目录。

以上为摘译。另查本项目始于2015年，可谓历史悠久：

EBSCO Information Services and NoveList Show Commitment to BIBFRAME and Linked Data through Sponsorship Agreement with Zepheira ~ Development Initiatives and Support for Libhub Initiative Seen as Natural Outgrowth of Continuing Efforts to Provide More Visibility for Library Collections ~

当时是EBSCO与Zepheira合作、应用Libhub。2020年初Zepheira被EBSCO收购。

Zepheira在2012年受美国国会图书馆（LC）委托开发BIBFRAME 1.0的公司。开发合约完成后，Zepheira在2014年推出Libhub，2015年将其使用的BIBFRAME称为bibfra.me，2016年Libhub演变为Library.Link。2017年LC提供2500万书目记录免费批下载，曾被导入Library.Link（目前页面无法访问）。Library.Link通过关联数据公开图书馆馆藏，当2019年秋Google在其图书知识面板中启动Borrow Action，Zepheira调整策略以利用这种更优雅的方法（目前仅在美国、加拿大和澳大利亚提供）。

参见：

• LC正式启动以关联数据取代MARC（2012-5-26）https://catwizard.net/posts/20120526120016.html
• BIBFRAME和BIBFRA.ME（就差一个点）（2015-5-10）https://catwizard.net/posts/20150510093451.html
• 2016 ALA年会BIBFRAME更新论坛（2016-8-27）https://catwizard.net/posts/20160827171205.html
• LC提供2500万书目记录免费批下载（附LC在Library.Link）（2017-7-21）https://catwizard.net/posts/20170721153805.html
• EBSCO收购关联数据公司Zepheira（2020-3-4）https://catwizard.net/posts/20200304153638.html

美国国会图书馆（LC）开发BIBFRAME，如果从2011年“书目框架转变行动”开始算，已超过十年。

今年ALA年会期间，LC照例举办BIBFRAME更新论坛。此次论坛，可以认为宣告LC即将正式实施BIBFRAME。

先前历次BIBFRAME更新论坛，除作为主持方的LC外，还会有来自厂商和高校等机构的多个报告。此次论坛，报告人除了1位都来自LC，而这一位报告针对的是OCLC使用LC的BIBFRAME数据。

Library of Congress June 2022 BIBFRAME Update Forum（Zoom网会，2022-6-27，1:00 PM ET – 2:00 PM EDTMeeting ID: 160 327 6570，Passcode: 576692）

“随着美国国会图书馆（LC）BIBFRAME 100的目标日期将于今年秋季到来，当LC的大多数编目人员将在LC的BIBFRAME系统中创建描述，并通过转换为MARC创建MARC记录时，我们希望利用这个更新论坛来突出可能影响LC数据用户的一些发展。Beacher Wiggins将首先介绍LC采购和书目访问部的现状和期望。LC专家将深入非拉丁领域，讨论更多的文字、多少音译、音译表审查、Marva（BIBFRAME编辑器）中的非拉丁文字输入以及可共享的音译实用程序。LC将报告通过新的发行软件来共享BIBFRAME数据，包括作品、实例、hub、名称、主题和许多标准列表。会议结束时，OCLC将提交一份报告，介绍他们对使用LC的BIBFRAME记录和/或由BIBFRAME数据创建的MARC记录的初步想法。”

【本人总结的几个关键点：BIBFRAME 100；BIBFRAME转换创建MARC记录；Marva（LC的BIBFRAME编辑器）；非拉丁文字输入及音译；BIBFRAME数据发行】

【报告一览（会后在BIBFRAME主页发布）】

• Introduction / Sally McCallum, Library of Congress
• BIBFRAME 100 Expectations / Beacher Wiggins, Library of Congress
• Non-Latin Scripts in LC’s BIBFRAME / Paul Frank and Jessalyn Zoom, Library of Congress
• Transliteration Utilities / Matt Miller, Library of Congress
• LC’s BIBFRAME Data Distribution / Kevin Ford, Library of Congress
• LC’s BIBFRAME Data in OCLC / Nathan Putnam, OCLC

或许是因为美国国会图书馆（LC）还没有正式实施BIBFRAME，目前网站上没有任何与BIBFRAME翻译有关的信息。

【韩国的BIBFRAME计划】上月底，韩国国家图书馆（NLK）元数据与可持续访问部Yoonkyung Choi在BIBFRAME邮件组询问BIBFRAME翻译事宜。据TA说，“NLK的目标是在2030年之前将书目语言从KORMARC（Korean MARC）转换为BIBFRAME。作为该计划的准备工作，我们计划将BIBFRAME规范翻译成韩语，并与韩国的图书馆和研究人员共享。”TA发送电子邮件到BIBFRAME官方邮箱，询问是否可以在线共享翻译版本，需要以什么形式标记版权。由于未收到回复，因此在邮件组询问。

【BIBFRAME翻译政策】负责BIBFRAME开发的LC网络开发和标准办公室主任Sally McCallum回复表示高兴并期待翻译完成，同时表述BIBFRAME的翻译政策：

• BIBFRAME规范可以自由翻译，由翻译者发布和分发成果。
• 不授予翻译成某种语言的专有权利，因此同一语种可能并存其他翻译。
• 鼓励免费分发BIBFRAME规范，但翻译版本也可以拥有版权并出售。
• 要求在文档或简介中引用BIBFRAME规范的来源，以便其他人知道它是源自LC的翻译。
• 出于分享目的，LC希望收到翻译的URL，以便向其他人推荐；希望引用翻译、URL 和联系人，以便在LC的BIBFRAME网站上发布。

【BIBFRAME西班牙语翻译】耶鲁大学图书馆的Tim A. Thompson表达了开发一个框架促进BIBFRAME本地化和翻译的愿望，并介绍了其与墨西哥国立自治大学的图书馆员合作，翻译BIBFRAME 2.1的西班牙语版本。它的Google表格版本包括术语、标签和定义等<https://docs.google.com/spreadsheets/d/1KgpWmMSyAEVVkfQgBPB0tdf6jk9cJ81z8S_Z9k4mH-8/edit?usp=sharing>。【共401个元素，不懂西班牙语，只看到Instance译为Manifestacion，看上去是英语的Manifestation——对应于LRM/RDA用语】

《IFLA图书馆参考模型》（LRM）规定，虚构的或非真实的实体不属于通常所属的类型。包括：

• 虚构人物和非真实人类实体不属于“个人”（Person），见LRM-E7的范围注释：“个人实体仅限于有生命或认为有过生命的真实个人”。“一般认为是虚构的（如科米蛙）、文学性的（如简·马普尔小姐）或纯粹传说性质的（如巫师梅林）人物不是实体个人的实例”。
• 非真实的地点不属于“地点”（Place），见LRM-E10的范围注释：“想象的、传说中的或虚构的地点不是地点实体的实例”。

这些实体被归入最宽泛的类型“资源”（Resource），非人类实体（如动物）也如此。见LRM-E1的范围注释：“资源是明确定义的所有其他实体的超类，以及没有明确标记的任何其他实体的超类”。样例：

• {Miss Jane Marple} [阿加莎·克里斯蒂（Agatha Christie）多部小说和故事中的人物]
• {Earthsea} [一个虚拟的世界，厄修拉·K·勒古恩（Ursula K. Le Guin）创作的《地海三部曲》（Earthsea trilogy）的背景]
• {Pal} [1940年6月4日-1958年6月在世，一只雄性粗毛牧羊犬，1943年至1954年在电影中出演灵犬莱西（有几只帕尔的后代在后来的影视作品中也扮演了灵犬莱西）]

《资源描述与检索》（RDA）遵循LRM，作品的责任只能归于真实的人类或集体行为者。在新RDA的指南部分有“Fictitious and non-human appellations”（虚构和非人类称谓），在载体表现中作为责任说明出现时：对虚构实体，其称谓被假定是行为者、集体行为者、团体、家族或个人的化名称谓[假名、笔名等]；对非人类实体，则视为RDA外部的实体。指南介绍了不同条件与选项下使用的RDA元素，但如果落实到MARC记录中会怎么样？

参见：RDA元数据指导文档（MGD）：掌握新RDA（2022-9-10）

Official RDA Toolkit LC-PCC Metadata Guidance Document: Fictitious and Real Non-Human Entities [PDF, 233KB, 5页]
RDA元数据指导文档（MGD）的《虚构和真实非人类实体》，提供了LC-PCC的新RDA做法（2022年9月尚未实施），包括MARC和BIBFRAME示例。

• 简单地说，MARC做法基本照旧：

规范记录照旧：“将继续在NAF [名称规范档] 中建立虚构人物和真实的非人类实体的名称规范记录（NAR）”。特别强调提供“实体类型名称”，放在原就有且常用的100$c（头衔和其他相关词）：“PCC正在开发用于这些非RDA行为者的实体类型词表”。

书目记录照旧：“根据需要，虚构人物和真实的非人类实体可以在书目记录中创作作品”。

看上去主要变化是：规范和书目记录的040$e（编目来源之描述规则）采用新代码pccrda，而不是rda。“表明这些记录符合PCC对RDA的实施”（换言之，这些是非RDA记录）。本MGD在概述中说，书目记录的描述规则代码未定，但示例中采用了相同新代码。

• 至于BIBFRAME，似乎完全不涉及这个问题：“将Nomen实例的IRI记录为真实世界对象[RWO]”。换言之，不区分虚构、真实非人类实体，和人类一样，都是RWO。

与LC-PCC PS配套使用的“元数据指导文档”（Metadata Guidance Documentation, MGD），分为叙述性MGD和一对一MGD两种。参见：

• RDA元数据指导文档（MGD）：掌握新RDA（2022-9-10）
• RDA元数据指导文档（MGD）：虚构和真实非人类实体（2022-9-13）
• RDA元数据指导文档（MGD）：合集（2022-9-14）

仔细看了上述2个叙述性MGD，接下来再看看一对一MGD。

一对一MGD共有200多个文档，据称映射到500多个新RDA的政策声明，内容与新RDA中的元素（原关系说明语也变为元素）或其特定选项相关联。因此有的一个MGD文档对应一个元素，如载体类型（MG: Manifestation: Carrier type），或是一个元素的特定方面，如政府出版物的制作日期（MG: Manifestation: Date of manufacture: GPO publications）；有的则有多个MGD文档对应一个元素的不同方面，可能是不同方面或不同条件下的选项，如生产日期（MG: Manifestation: Date of production）分为3个文档[目前显示4个、有一条重复]：记录（Recording）、在版编目（CIP cataloging）、出版日期不确定（Date of publication not identified）。

一对一MGD包含内容为：

• 指导（Guidance）
• MARC示例
• BIBFRAME示例
• 参考与附注：即映射，提供原LC-PCC PS编号等（新RDA没有编号）
• 更新历史

随意找了个最常用的正题名（title proper），正巧除LC/PCC实践外，还有大英图书馆实践。全部内容如下：

正题名：Official RDA Toolkit LC-PCC Metadata Guidance Document: Entities > Manifestation > title proper [PDF, 115 KB; 2页]

• 指导：记录正题名——不排序字符——LC实践/PCC实践：一般设置MARC字段245的第2个指示符位置（不排序字符）以忽略定冠词和不定冠词，以用于排序和归档目的。但是，不要排除某些冠词：
  • 1、当正题名以冠词起首，该冠词作为个人、家族、地理或团体名称的一部分出现并保留在该名称中；
  • 2、当正题名以冠词起首，并且上下文或编目员判断需要保留它时，例如，这样的题名：
• MARC示例——
  • 例1：245 00 $a “The” as an introductory element of generic nouns
  • 例2：245 00 $a “El Cid” in literary criticism of the 20th century
• BIBFRAME示例——不使用不排序指示符

• 指导：大英图书馆实践：交替题名被视为正题名的一部分。由编目员判断决定是否给交替题名一个检索点。【按传统，LC-PCC也认为交替题名是正题名的一部分，但未提供相应指导】
• MARC示例——例3
  • 245 14 $a The rail and the rod, or, Tourist-angler’s guide to waters and quarters thirty miles around London
  • 246 13 $a Tourist-angler’s guide to waters and quarters thirty miles around London
• BIBFRAME示例……（略，上述246内容作为变异题名 bf:VariantTitle 的主题名 bf:mainTitle）

• 参考与附注：LC-PCC PS 2.3.2.7 【记录正题名，包括：[1]不排序字符；[2]专著丛编/多部分专著：缺少题名或从属题名，见PS2.3.1.7】
• 更新历史：2022-01-31

到RDA工具包去对照看政策声明及元数据指导文档链接：

正题名元素页（Entities > Manifestation > title proper）侧栏政策声明，目前有3家：

• BLPS（22条）：大英图书馆PS只有简单说明：采用、不采用、合适则用、编目员判断等。没有MGD链接。
• LC-PCC PS（24条）：有较详细说明；如有MGD文档、则提供链接。在Prerecording（21.93.72.57）除前述“正题名”一对一MGD外，还链接到“丛编-子丛编”系列MGD（含一个叙述性MGD和数十个一对一MGD）【与原LC-PCC PS对应】
• MLA BP（24条）：音乐图书馆协会最佳实践，再合并LC-PCC PS内容，包括上述MGD链接（方便使用，无需切换MLA和LC-PCC）。

上述一对一MGD仅针对正题名20多条PS中的一条，即预记录（Prerecording），没有涉及任何一个选项。由此可知，MGD是不完全的，针对的是那些需要详细解说指导的内容。即所谓：“当原RDA工具包的LC-PCC PS被评估并映射到官方RDA工具包时，声明的较长部分以及示例被标记为一组单独的官方RDA工具包文档——元数据指导文档（ MGD）”。

一早在微信群看到上图刘炜馆长发消息，美国国会图书馆（LC）“已经选择了开源的FOLIO图书馆服务平台作为其下一代的图书馆管理系。正如你们中的许多人已经知道的那样，FOLIO的创新架构允许最大限度的灵活性和可扩展性，这将使该平台能够随着我们需求的变化而增长。图书馆的FOLIO实施将得到EBSCO FOLIO服务的支持。最重要的是，BIBFRAME是一个强制性要求，这意味着对BIBFRAME描述的创建、存储和索引的本地支持。对于BIBFRAME计划来说，这是一个重要的里程碑，也是一个令人兴奋的里程碑!”

消息应该来自LC网络开发与标准办公室主任Sally McCallum在BIBFRAME讨论组的邮件。从邮件链接到LC官网新闻。难得见到新闻稿中3位馆长同时发声，图书馆馆藏管理系统（图书馆服务平台）对图书馆的重要性不言而喻。第一阶段3年，看来LC要真正用上BIBFRAME还需要几年时间，但毕竟终于可以进入实施阶段了。全文翻译如下：

国会图书馆努力改变馆藏管理和访问 Library of Congress Launches Effort to Transform Collections Management and Access (2022-9-21)

国会图书馆已授予一项重要合同，以进一步开发和实施一个新的开源 IT 平台，该平台将彻底改变图书馆庞大的物理和数字馆藏的管理方式，并使公众、国会、本馆员工和其他机构可以访问。

新的图书馆馆藏访问平台软件应用程序将作为本馆馆藏管理运营的核心，将多个独立的 IT 系统连接到一个一站式商店，用于本馆馆藏的采访、描述、典藏和发现。

本馆与马萨诸塞州伊普斯威奇的 EBSCO信息服务公司签订了一份 IDIQ 合同，初始支出为 777 万美元。该平台开发的第一阶段将在三年内耗资 1040 万美元，以满足本馆运营的规模和复杂性，并可选择投资于其他供应商可以开发的额外组件，并且可能会超过三年的时间框架。

EBSCO 将量身定制社区开发的开源图书馆服务解决方案 FOLIO，以提供满足本馆 IT 需求和本馆用户需求的图书馆服务平台。

“这是我们实施以用户为中心的方法以将更多人与本馆馆藏联系起来的旅程中的一个里程碑，”国会图书馆馆长 Carla Hayden 说。“我们感谢国会对这一下一代系统的慷慨投资，这对本馆的数字化前进战略至关重要，该战略利用技术弥合地理鸿沟，扩大我们的范围并增强我们的服务。”

该平台将取代几个遗留的 IT 系统，并为本馆工作人员提供新的、更高效的工具和工作流程，以大规模管理不断增长的物理和数字馆藏。它将为研究人员提供简化的发现体验和访问高质量元数据的新方法。它还将启用BIBFRAME，这是本馆和合作组织正在开发的新书目描述标准，它使用关联数据模型使书目信息在图书馆社区内外更有用。

当该平台全面运行时，它将使用户能够对世界上最大的图书馆的大量馆藏进行全面搜索。该系统将拥有更先进的 IT 安全控制，并将适应不断发展的技术和不断增长的数字内容。

“国会图书馆长期以来一直在为图书馆界开发开放格式和标准方面发挥着关键作用。支持关联开放数据的开源解决方案将不仅为本馆员工和用户带来好处，还为全国其他机构提供支持”，负责发现和保存服务的副馆长 Kate Zwaard (associate librarian) 说。

“图书馆馆藏访问平台的实施是本馆的最高技术优先事项之一” ，图书馆馆藏和服务副馆长 Robin Dale (deputy librarian)说。“这个新系统将使本馆能够跟上技术变革的步伐，并使其能够灵活地容纳本馆管理和提供给用户的数字内容的范围。”

国会图书馆是世界上最大的图书馆，提供现场和在线访问美国的创意记录以及来自世界各地的大量资料。它是美国国会的主要研究机构，也是美国版权局的所在地。探索馆藏、参考服务和其他计划，并计划访问loc.gov；在congress.gov访问美国联邦立法信息的官方网站；并在copyright.gov注册作者身份的创意作品。

2022欧洲BIBFRAME研讨会（BFWE，第六届）9月20-21日在匈牙利举行。

BIBFRAME Workshop in Europe 2022. 6th Annual Meeting (Hybrid Event), 2022/9/20-21. National Széchényi Library, Budapest, Hungary

本次会议注册563人，涉及56个国家，已超出欧洲范围（非洲7，亚洲16，大洋州2，欧洲26，北美3，南美2）。因新冠疫情（COVID-19）在2020年和2021年虚拟会议之后，2022年是混合会议，到场52人，Zoom会议511人。

自2017年首届会议以来，参会者及其国家逐年增加，网络会议更使注册人数快速上升：2017=16国41人，2018=20国80人，2019=19国93人，2020线上=29国275人，2021线上=47国455人，2022混合=56国563人。

本届会议有报告、专题讨论约20场。报告分3个方向：运行中的BIBFRAME、新发展、互操作。专题讨论（panel）2场：1、互操作（数据交换环境）；2、如何在没有太多背景的情况下接近BIBFRAME。内容丰富，会议网站有PPT与视频分享。

以下为报告清单[及概要]，报告人用所在机构标识（表明各机构对BIBFRAME的参与）：

[一] 运行中的BF

• （LC）BIBFRAME 实施之旅（试图过渡到“一站式”输入）
• [加拿大]阿尔伯塔大学图书馆的BIBFRAME实施：成功规划（依赖于 NEOS、PCC、LD4P 和 Share-VDE 等关键合作伙伴关系）
• 结束循环：斯坦福转移到生产（LD4P成员，与LC和 SHARE-VDE 合作开发）
• （匈牙利国家图书馆）从实用（编目员）的角度看书目模型中的作品概念
• （瑞典国家图书馆）论野心与模糊（身份，基于 BIBFRAME 的编目系统四年多的生产经验）
• （LC）高级检索与关联数据（使用LC的 BIBFRAME 编目界面探索一些想法）
• （宾州大学）在ShareVDE 2.0目录中测试用户体验
• （EBSCO）从进化到转型：使用网络使图书馆数据可见且可移植

[二] 新发展

• （Karen Coyle）开放WEMI-超越FRBR（都柏林核心社区小组，研究创建最小约束词表的可能性；有利于非图书馆元数据生产者）
• （康奈尔）发现关系（LD4P3，作品与作品关系，Hub数据集，基于在 Sinopia 中建模的 BIBFRAME 关系的显示图书馆目录结果的原型）
• （@Cult+Casalini Libri）来自 Share-VDE 的更新：进度状态和基于 BIBFRAME 的 SVDE 本体（svde:Opus 的创建、识别和建模；由LC、Share-VDE、斯坦福大学和 OCLC 代表组成的小组正在研究稻草人 BIBFRAME 交换造型）

[三] 互操作

• （芬兰国家图书馆）BIBFRAME 和 RDA 的和谐联姻——芬兰的做法（2022-2024：将 BIBFRAME 用于芬兰联合目录；RDA 和 BIBFRAME 之间的映射，并希望在新的数据模型中使用例如内容表达和合集；BIBFRAME 的芬兰语翻译等）
• （匈牙利国家图书馆）匈牙利的 BIBFRAME – 博士论文的结论（将LC官方的MARC 21-BIBFRAME 映射为 HUMNARC 格式）
• （OCLC）BIBFRAME数据在OCLC（致力于支持所有图书馆：完全过渡到 BIBFRAME、继续使用 MARC、采用混合模式）
• （PCC）入门：BIBFRAME 互操作小组 (BIG)（BIBFRAME 本体的不同实施决策是成功 BIBFRAME 数据交换的主要障碍；2022.6-，定义标准的 BIBFRAME“形状”以支持数据重用，包括与其他格式的转换；定义数据交换所需的核心 BIBFRAME 元素；通过 BIBFRAME 提出有关使用官方 RDA 的问题并提出解决策略；并根据需要收集用例以告知决策。）
• （LC）官方RDA和BIBFRAME（应用于 BIBFRAME 编目环境。 通过将 BIBFRAME Hub与 RDA 作品相关联，并显示 BIBFRAME Hub与传统头衔“规范”一致）
• （RSC）RDA 到 BIBFRAME 映射的更新

参见：

• 2021欧洲BIBFRAME研讨会信息（2021-10-17）
• 2020欧洲BIBFRAME研讨会：会议网站（未写博文）
• 2019欧洲BIBFRAME研讨会（2020-6-16）
• [2017-2018]欧洲BIBFRAME研讨会（2019-3-29）
• BIBFRAME在欧洲启动？2017欧洲BIBFRAME研讨会（2017-5-18）

2022欧洲BIBFRAME研讨会（BFWE，第六届）9月20-21日在匈牙利举行：

BIBFRAME Workshop in Europe 2022. 6th Annual Meeting (Hybrid Event), 2022/9/20-21. National Széchényi Library, Budapest, Hungary

会议网站有PPT与视频分享。以下为与新RDA（现通称“官方RDA”）关系较为密切的3个报告：PPT+[视频]+【本人备注】

参见：2022欧洲BIBFRAME研讨会（2022-10-14）

BIBFRAME实施之旅（BIBFRAME Implementation Journey / Sally McCallum, 美国国会图书馆网络开发和标准办公室主任）

• （摘录结论部分：MARC简化、BIBFRAME基于RDA开发，即将实施）
• s11.挑战：我们需要一个BIBFRAME到MARC的转换，它不仅对社区来说是一个好的MARC，而且遵循Voyager【LC目前的图书馆自动化系统】和LC多年来采用的所有MARC惯例；我们需要重新检查MARC冗余、MARC过度专指性以及导致MARC和BIBFRAME之间转换效率低下的非MARC相关约定；我们需要与社区合作，调整MARC，使其更简单，因为我们知道MARC在我们努力工作并向更丰富的环境过渡的过程中有着长远的未来。【PCC正开发“精简MARC”】
• s12.现在实施的优点：BIBFRAME是基于RDA开发的，新RDA培训和实施即将到来—使用BIBFRAME会更容易；LC计划在未来2-3年内实施以BIBFRAME为核心的新ILS【9/22宣布的FOLIO】，BIBFRAME/Voyager将贡献：BIBFRAME验证（本体元素、转换期望、模型和形状）；MARC检查：转录与检索的需要、消除冗余、检查复杂性。使我们能够更多地利用关联数据环境中的新发现机会。
• s13.谢谢，祝我们好运！

RDA到BIBFRAME映射现状（Update on RDA to BIBFRAME Mapping / Damian Iseminger, RDA指导委员会技术团队联络官）（3分钟视频，没有PPT）

• 由于新RDA等因素，映射工作推迟到2023年开始。对完成有信心。需要先解决一些问题：
• 1、与BIBFRAME的哪个版本/哪种口味(flavor)映射：SVDE？LC？或者同时？【关注BIBFRAME互操作问题】
• 2、类与属性：RDA类少、属性多，BF类多、属性少。
• 3、受众：面向开发者？编目员？

官方RDA和BIBFRAME（Official RDA and BIBFRAME / Paul Frank, 美国国会图书馆政策、培训和合作项目部编目政策专家）

• 摘要：官方RDA工具包预计将在明年取代原RDA工具包【美国实施新RDA】。本演示文稿将检查官方RDA工具包及其支持文档（编目政策声明和元数据指导文档），因为它们可能应用于BIBFRAME编目环境。它还将通过将BIBFRAME Hub与RDA作品相关联，并显示BIBFRAME Hub与传统的“规范”一致，提供更紧密地对齐BIBFRAME和RDA模型的选项。
• （讨论新旧RDA在4个方面的不同，及在BIBFRAME中可能的解决方案：1、合集资源-全集；2、译本-合集和个别；3、代表性内容表达；4、BIBFRAME Hub/作品组）
• s2-5.原RDA和MARC经验：官方RDA正被测试，尚未实施；FRBR和原RDA不易用MARC表达；MARC仍然是编目的通用语言；MARC具有本体的无法表达性[表达关系方面]；作品和内容表达级别的FRBR建模在实践中模棱两可；如果作品是一个抽象实体，那么如何将其描述为一个慎重的实体？我们在编目什么：作品、内容表达、载体表现、全部三者？PCC是否犯了一个错误，让作品和内容表达融合在一起？[LC名称-题名规范：作品？内容表达？]。自2012年以来，RDA和MARC之间的这种有点失调的关系一直“有效”；BIBFRAME Pilot的经验质疑了所有这些，并暴露了MARC中的这些缺陷；MARC可以阻止对RDA的理解，或者至少可以让人自满；BIBFRAME的结构不会容忍这一点。
• s6.官方RDA和BIBFRAME可能性：BIBFRAME是官方RDA数据的理想通信格式；【4种】记录方法；官方RDA比原RDA对关联数据更友好；LC打算在[用]官方RDA条款前，在BIBFRAME中指导编目员；BIBFRAME编辑器Marva【LC二代编辑器】和Sinopia【LD4P编辑器】免费提供。
• s7.摘要：使用MARC增强BIBFRAME；看官方RDA，它可以用BIBFRAME表示；看官方RDA工具包中的这些变化，它们可以将编目过程从基于MARC的平面世界改变为关联数据语义环境。
• s8.论题：1合集资源-【个人作品】全集；2译本-合集和个别；3代表性内容表达；4BIBFRAME Hub/作品组：BF和官方（和原）RDA间的本体区别。
• s9-14.[一]合集资源：全集
• 官方RDA：每个集合作品是新作品，因为集合了不同内容表达；WE锁定【基于LRM】；惯用总题名不是官方RDA组成部分，在“社区资源”；对规范检索点没有指引【或许因为分歧大，也在“社区资源”中】。
• 长期实践/原RDA：为方便起见，全集被视为“一件”作品：基于归档规则而非数据模型。
• 解决方案：[研究人员可能需要特定版本的全集]
• [1]作品可视为一个Hub/作品组【BIBFRAME 2.1类bf:Hub=bf:Work子类，见论题[四]】：用于搭配具有共同特征的不同作品的常用称谓。
• [2]对出版资源：将所有全集视为单独的静态、确定作品，并使其成为Hub；使用作品组标识(designation)：作品+区别（年份、出版者等）；将语法信息（VES、SES）添加到MGD【元数据指导文档】。
• [3]对超级作品：使用作品的BIBFRAME Hub减去区别；使用MARC来利用BIBFRAME，如果BIBFRAME作品被创建为MARC书目记录而不是规范记录，那么现在可能会发生这种情况[希望如此]【BIBFRAME没有规范；LC规范用MADS/RDF表示】。
• s13-14.Marva示例[可能的做法]：Hub：Dante的全集（1894年）；相关作品（元素标签标示关系）：Dante的全集。s15-20.
• [二1]译本：合集资源[视频略过未讲]
• 官方RDA：对于合集资源，译本就是新作品，因为集合内容表达不同；这意味着译本的题名是首选题名【只适合多作者；单作者合集首选题名为惯用总题名】。
• 长期实践/原RDA：如何在原RDA下标识内容表达？内容表达题名不存在；内容表达通过作品的规范检索点+内容表达属性标识。
• 解决方案：明确确定译本和原文之间的关系；不要从规范检索点推断；实体>作品>作品的相关作品related work of work？实体>内容表达>……的译本translation of ？s18-20.Marva示例：Hub：创建代表性内容表达为一个作品Hub。
• s21-26.[二2]译本：个别
• 官方RDA：译本不是新作品，而是原语言作品（代表性内容表达？）的内容表达；VES和SES条款不在官方RDA中，内容表达由AAP【规范检索点】识别；实体>内容表达>内容表达的首选题名preferred title of expression [原RDA内容表达没有首选题名]【原RDA使用作品题名+语种，现在用载体表现题名?】。
• 长期实践/原RDA：译本不是新作品，而是原语言作品的内容表达；原语言作品和译本之间的关系是在规范检索点中固有的；记录语法【AAP构成】在原RDA中。
• 解决方案：将原语言内容表达和译本之间的关系显示为显式链接[2种可用关系]：实体>内容表达>……的翻译translation of？实体>内容表达>内容表达的相关内容表达related expression of expression？s24-26.Marva示例：Hub[原语言/代表性内容表达]：Marai的Gyertyak csonkig egnek；作品[译本]：Marai的Embers[译本题名名为内容表达首选题名，不是AAP]；内容表达的相关内容表达：Marai的Gyertyak csonkig egnek。
• s27-29.[三]代表性内容表达
• 官方RDA：一种被认为是识别作品的标准canonical数据源的内容表达；可添加到作品描述中以标识“标准的”内容表达的特定元素。
• 长期实践/原RDA：混淆作品与原语言内容表达；本体歧义。
• 解决方案：代表性内容表达=Hub或超级作品；有助于解决由于缺少BIBFRAME内容表达实体而导致的建模差异。
• s30-32.[四]BIBFRAME Hub/作品组官方RDA：有4个实体作品、内容表达、载体表现、单件【WEMI】；能在一个RDA书目描述中单独描述一部作品吗？
• 长期实践/原RDA：BIBFRAME没有内容表达实体，所有RDA内容表达都是BIBFRAME作品；BIBFRAME不区分书目和规范（这是MARC的遗产吗？）
• 解决方案：让BIBFRAME Hubs简化建模差异：BIBFRAME Hubs=作品，BIBFRAME Works=内容表达，BIBFRAME Instances=载体表现，BIBFRAME Items=单件；让MARC通过创建BIBFRAME作品作为书目记录来促进这一点【“作品”书目记录而非规范记录】
• s33-34.下一步是什么？[视频略过未讲]
• 用MARC以现状（当前编目政策）测试官方RDA；查看以MARC表达官方RDA数据的困难所在；在给定的情况下，BIBFRAME是否有更多的语义意义？试验在BIBFRAME场景中的官方RDA；以BIBFRAME测试官方RDA的这些新方面（以上内容）；游说这些变化，使其成为官方政策——如果它们奏效的话【有争议、未确定】；在RDA的粒度和BIBFRAME的灵活性之间取得平衡；与根本不熟悉MARC的编目员一起测试；你可能会想到其他的下一步——有很多！

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

• 职责：Task Group on MARC Simplification for BIBFRAME Conversion (2022-2-1)
• 中期报告：Interim Report of the PCC Task Group on MARC Simplification for BIBFRAME Conversion (2022-6-1)
• 最终报告：Final Report of the PCC Task Group on MARC Simplification for BIBFRAME Conversion (2022-10-31)

这套简化字段，在职责文件中称“瘦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记录进行后续的下游修改。

2021年初，芬兰国家图书馆（NLF）提出为描述学术资源而扩展都柏林核心（DC），开发“学术资源应用纲要”（SRAP或DC-SRAP）。

NLF的理由是：DC常用于描述学位论文和高等教育机构的其他资源，用于存储并通过其机构存储库提供。但DC元数据术语本身不包含对这些资料进行简单描述所需的所有核心元数据元素，因此出现了不同的本地扩展。由此产生的负面影响包括：为相同目的开发多个模型所涉及的重复工作，工具（编目和搜索、指南）需要额外的开发工作，减少了使用不同模型创建的元数据之间的语义互操作性，DC元数据术语的实用性降低。为使DC成为一个更有价值的工具，促进DC用于学术著作的描述，NLF建议开发学术资源应用纲要（SRAP）。NLF认为，采用SRAP不仅将使DCMI元数据术语的扩展能够利用新增属性，完善许多现有属性的语义，而且还能减少开发其他本地学术著作的需求（Scholarly resources and Dublin Core, 2021-1-8）。建议并附上了SRAP草案（目前是2021-07-19的版本0.76）【访问Google文档】

SRAP主要开发者是2位NLF的DCMI成员Juha Hakala和Osma Suominen。日前在GitHub上放出了新的SRAP草案：

都柏林核心元数据倡议学术资源应用纲要（2022-10-6 草案）

Dublin Core Metadata Initiative Scholarly Resources Application Profile (SRAP) (Draft 2022-10-06)

当前版本针对学术论文、学位论文等，暂不包括研究数据，但有相关代码、相关数据集等属性。学术论文，增加了编者、资助者、资助号，发布状态（公开草案、预印本、印后本、出版、更新出版）及相关日期（如手稿收到日期、撤回日期等），呈现于（会议）等；学位论文，增加了隶属关系、导师、评审者、答辩主持人等。

新增属性除扩展DC外，还有来自现有词表：

Affiliation 隶属关系，schema.org属性：https://schema.org/affiliation

Date retracted 撤回日期，Fabio元数据术语：http://purl.org/spar/fabio/hasRetractionDate

以及MARC21关系词（MARC relator）：

Editor 编者：https://id.loc.gov/vocabulary/relators/edt

Funder 资助者：https://id.loc.gov/vocabulary/relators/fnd

Degree supervisor 学位导师：http://id.loc.gov/vocabulary/relators/dgs

Opponent 评审者：http://id.loc.gov/vocabulary/relators/opn

Praeses 主持人/答辩主席：http://id.loc.gov/vocabulary/relators/pra

然而，美国国会图书馆（LC）的MARC 21关系词属于责任者（creator / contributor）的角色，在定义上是SKOS概念（名词）、用于取值（宾语），并非属性（动词、谓语）。Karen Coyle在BIBFRAME邮件组提出“LC关系词作为属性”的问题（LoC Relators as Properties），其中特别提到RDA将关系词定义为“行为者”属性【新RDA将原“关系说明语”改为“属性”】，瑞典国家图书馆也基于LC关系词创建相应的属性列表。从讨论看，大家都赞同将关系词作为属性；但LC在BIBFRAME实现中仍使用关系词作为角色概念。

2022年12月，EBSCO宣布推出BiblioGraph，应用关联数据技术，让用户可以在Web上的任何地方查找和使用在线图书馆资源：

“BiblioGraph 利用 BIBFRAME 将图书馆目录转换为使用来自权威来源数据的关联数据资源——在图书馆目录中建立连接以显示相关的人、主题、单件、出版商等，允许用户在网络上查找和使用他们图书馆的资源。图书馆员工可以通过自动报告跟踪使用统计数据，展示人们使用 BIBFRAME 来使用图书馆目录的频率。

“当学术、国家或公共图书馆订阅 BiblioGraph 时，该机构会自动将数以千计的其他图书馆加入关联数据网络，该网络可用于打开 Google 等搜索网站，链接回图书馆并扩大知名度。自 2017 年与谷歌整合以来，这些技术的影响力在全球范围内不断扩大。2020 年，谷歌扩大了其借阅行动以包括更多服务。此后，BiblioGraph 将图书馆目录连接到谷歌在美国、加拿大和澳大利亚的知识面板，其他国家的图书馆也开始参与。”

2023年1月，EBSCO又宣称BiblioGraph提高了英国图书馆资源的可见性，包括在谷歌的知识面板和谷歌图书中找到借阅选项。

话说2020年，EBSCO收购了曾为美国国会图书馆（LC）开发BIBFRAME的Zepheira。Zepheira旗下使用BIBFRAME、把图书馆目录（MARC格式）和图书馆服务信息等转换为关联数据发布，方便通过搜索引擎等网络发现的服务Library.Link由此属于EBSCO。

Library.Link与谷歌知识图谱结合，到2021年已在美国、加拿大和澳大利亚3国的谷歌搜索和谷歌图书中提供图书馆借阅选项，现在英国加入成为第4国。

从功能上看，BiblioGraph似乎就是Library.Link。以上两篇新闻稿中都提到这是“EBSCO 在 2020 年收购 Zepheira 的直接结果”，但都没有提及Library.Link。

在EBSCO网站上搜索新推出的BiblioGraph，有百多个结果，但搜索Library.Link，只有2个结果。EBSCO是给Library.Link改名BiblioGraph吗？

在某个NoveList产品介绍（BiblioGraph NoveList Enrichment）中有这样一段：“我们的许多客户使用BiblioGraph，它将您现有的数据转换为关联数据格式，并将其发布到 library.link 网络。这使得像谷歌这样的搜索引擎更容易在搜索结果中查找和显示您的图书馆资源”。似乎以BiblioGraph作为产品名，保留library.link作为网站名？

参见：

• EBSCO Information Services Introduces BiblioGraph (2022-12-7)
• BiblioGraph from EBSCO Information Services Enhances Library Resource Visibility in the United Kingdom (2023-1-18)
• EBSCO收购关联数据公司Zepheira（2020-3-4）
• 【关于Library.Link】BIBFRAME用于“关联图书馆服务”（2022-5-27）

昨天（2023-2-15）在上海图书馆东馆乐享厅讲《BIBFRAME：发展与应用》。

参见文化和旅游研究上海图书馆基地：【讲座预告】胡小菁《BIBFRAME：发展与应用》|“智慧图书馆技术应用讲座”2023年第2期开放报名预约（2023-02-08）

这是智慧图书馆技术应用讲座第18期，因为先前几年COVID-19的影响，好像是本系列讲座首次开放现场参与。相较于网上300人报满，现场只有小数十人，显然大家已经习惯于网上参会了。

感谢智慧图书馆技术应用联盟的邀请，让我得以全面回顾BIBFRAME的发展过程，并与大家分享。视频回放和PPT在联盟网站（云瀚）及相关社交媒体网站也将发布。

昨天下午看了视频直播回放，对问答阶段自己的回复相当不满意。其实也是向来如此，自己特别不擅长应对，缺少娓娓道来、旁征博引的从容，总想着言简意赅、用几句话结掉问题。有的可能对提问的理解还存在偏差。以下试对现场回答再作些补充。

1、音乐资源【问题】BibFrame和schema.org各自的特点和优势？目前我们基于图书馆做国内音乐音像、乐谱等资源的语义网建设尝试，是Bibframe的拥趸，但在中途，发现国外（北美）的音乐图书馆link项目目前主要基于schema.org、RDA等。如果未来有可能国际对话、接轨，如何调和这两个方案之间的“差异”或形成互补？

【补充回答】我对音乐了解很少，前几天还在纠结音乐作品各种编号的中文对应名称。选什么词表，schema.org还是bibframe或其他，首先是要分析各词表定义的元素（类和属性），是不是足以涵盖本项目想要揭示的内容。因为没有做过schema和bf音乐相关元素的比对，所以无法给出意见。不过，大部分情况下单一词表都是不够的，需要扩展，可以用应用纲要的形式，纳入不同词表的元素，印象中瑞典国家图书馆的系统在bf以外也使用schema。不知道北美的这些音乐项目是什么时候开始建设的，如果在BF2之前，不采用BF是可以想见的。另外使用BF肯定需要扩展，可参考如LD4P对BF的扩展“演奏音乐本体”（PMO）。其次，选词表需要考虑其权威性、通用性、持久维护性等，现在来讲，schema.org和bf在这方面都没什么问题。

2、BF是否适用于细粒度描述，如目次、全文中实体。

【补充回答】BF是书目描述，目次没问题，但不适合揭示全文。面向全文的格式如TEI（Text Encoding Initiative）之类更合适。前几年参加中国索引学会，曾写了一篇文章《面向电子书的书后索引编制法——以地方志为例》，论及TEI。

3、科普MARC、BF和RDA三者关系。

【补充回答】以前的报告或培训中，多次以填表格做比喻，讲述两者间关系：MARC和BF作为结构标准，相当于那张表（各种要填写的项目）；RDA作为内容标准，相当于填表说明（哪个项目应该怎么填写、取哪个值等等）。另可参见博文：元数据和编目标准类型（2014-5-8）

4、CALIS推广BIBFRAME问题

【补充回答】应该说联合目录没有听说有使用BF计划；其他项目不了解。

5、BIBFRAME对FOLIO的挑战【没有补充】

6、对编目客户端的影响

【补充回答】可以借鉴BIBFRAME编辑器的功能，改进现有marc客户端。目前基本上是“录入”型的，可以借鉴bf编辑器的模式，对规范控制和取值词表字段/子字段采用查询输入方式，提高工作效率、减少拼写错误。

7、BIBFRAME在我国推广的前景（唯一现场提问）

【补充回答】除了特藏，如本PPT第2部分“应用”所举例子，在整合图书馆资源与服务、发现界面方面，也会有应用前景。

BIBFRAME项目启动已经过了12年，开发者美国国会图书馆（LC）仍未正式采用——对比MARC开发的8年，已经是1.5倍时间了。

昨天在BIBFRAME邮件组中，圣保罗大学图书馆有人问，该校一学院有WinISIS数据库的旧格式数据没法迁移到MARC，既然现在可以由MARC到BIBFRAME转换，是不是也可以把WinISIS格式直接转成BIBFRAME。一直对BIBFRAME持怀疑态度的Jeff Edmunds先问圣保罗大学有没有从MARC迁移到BIBFRAME的计划，然后直接泼冷水：“正如我多年来一直指出的那样，从MARC到BIBFRAME的迁移并不是将元数据从一种格式转换为另一种格式的简单问题。它对书目元数据的创建、维护和共享方式进行了根本性的改革，这将是一个非常昂贵和资源密集的过程”。并引用Marshall Breeding在2022年11月一次演讲的话作为旁证。

见：Re: BIBFRAME Digest – 19 May 2023 to 21 May 2023 (#2023-31) / Edmunds, Jeffrey. 2023-5-22.【另：此贴也介绍了一个报告，用MarcEdit等由WinISIS转换到MARC：Migrating from WinISIS to Koha – a case study / Rocio Jordan, ByWater. kohaCon 2016.】

网上搜到Marshall Breeding的报告。从报告看，作为多年为专业期刊撰写图书馆自动化系统年度报告的专家，他从图书馆自动化系统角度分析现状，总体不看好BIBFRAME。最大的问题是转换成本，以及近十年普遍的编目减员。报告最后他甚至说，图书馆界外对BIBFRAME并无兴趣，和MARC一样。以下为部分笔记。

BIBFRAME和关联数据：系统准备状态 BIBFRAME and Linked Data: System Readiness / by Marshall Breeding. Presentation for the Linked Data for Libraries Users Group of the Midwest Collaborative for Library Services on November 3, 2022（油管视频，1小时）

论题：[1]图书馆系统市场现状。[2]BIBFRAME的准备：图书馆服务平台(LSP) vs 集成图书馆系统(ILS)。[3]全球书目生态系统：不同类型、不同地区的图书馆如何获取书目记录。[4]BIBFRAME用于发现。[5]BIBFRAME用于可发现性。

BIBFRAME的准备。资源管理模型(ILS vs LSP)：目前基本上还没有原生支持BIBFRAME记录创建的系统，某些ILS可能永远不会强化BIBFRAME支持。

全球书目生态系统。高校馆：对BIBFRAME有强烈兴趣/尤其顶级研究馆，依赖声称支持BIBFRAME的LSP。公共馆和学校馆：对BIBFRAME兴趣缺缺，依赖不期望支持BIBFRAME的ILS。

预计BIBFRAME成本会更高吗？向BIBFRAME的过渡将涉及大量投资：技术开发、员工培训、文档等。在最初的过渡之后的许多年里，图书馆预计BIBFRAME的编目成本将大大高于MARC。在过去的十年里，图书馆的技术服务部门大幅缩减。RDA和BIBFRAME是在技术服务人员减少以及相关馆藏领域减少的情况下出现的。【生不逢时】

结论性观察：

• 以MARC格式表达的书目元数据将无限期持续；
• BIBFRAME在大型高校和国家图书馆获得推进；
• 这些馆所用LSP产品终会支持BIBFRAME作为原生编目环境（3-5年）；
• 公共、学校和专业馆[对BIBFRAME]很少或不采用或感兴趣；
• 大多数馆所用ILS不太会支持BIBFRAME；
• 全球书目交换依赖MARC；
• 当前环境包含由MARC到BIBFRAME映射；
• 任何未来环境必须支持BIBFRAME到MARC；
• 图书馆背景外对BIBFRAME无兴趣。

另见：

• Jeff Edmunds在2017年发起的讨论：邮件组大讨论：BIBFRAME将会失败？（2017-2-5）
• Edmunds去年的讽刺贴：MARC转换到BIBFRAME的愚人节公告（2022-4-24）

2022年9月美国国会图书馆（LC）宣布选择folio系统，由EBSCO承担。于是2023年初的BIBFRAME更新论坛几乎成了Folio论坛。向不缺席的OCLC不见踪影，LC本身也没有报告：

BIBFRAME January 2023 Update Forum (2023-1-30)

• 报告1、BIBFRAME Possibilities in FOLIO / Sebastian Hammer, Index Data（PPT标题：BIBFRAME and FOLIO）
• 报告2、Stanford’s Challenges with FOLIO / Jeremy Nelson, Stanford University
• 报告3-4、Managing Entities in FOLIO: An Overview of Current Efforts and Future Development（2个报告：Managing Entities in FOLIO: An Overview of Current Efforts / Jason Kovari, Cornell University ；FOLIO & Linked Data Functionality Review / Gloria Gonzalez, EBSCO）
• 报告5、Points from BIG discussions of Interoperability with Flexibility / Melanie Wacker, Columbia University

5个报告，只有最后的BIG（BIBFRAME互操作小组）是专注于BIBFRAME的。

刚过去的6月，BIBFRAME更新论坛回归，将关注重点放在了如何在MARC和BIBFRAME的混合环境中开始使用BIBFRAME，报告者单位也与以往相似（只没了学界）：

BIBFRAME June 2023 Update Forum (2023-6-26)

• 报告1、用BiblioGraph建设BIBFRAME环境 Building a BIBFRAME environment with BiblioGraph / Gloria Gonzalez, EBSCO Information Services

报告整理了多个Zepheira和EBSCO的BIBFRAME时间线，体现Zepheira的相关贡献。

主要介绍BiblioGraph即原Library.Link，主要功能：[1]转换MARC创建数据图谱；[2]策展馆藏和单件“活清单”；[3]用来自权威数据源的数据丰富资源；[4]推动从网络上任何地方更多使用图书馆目录；[5]在谷歌搜索中显示为一个选项；[6]加入不断扩大的可信图书馆元数据网络。最吸睛的就是谷歌搜索侧栏知识图谱中的“借阅”选项，目前在澳大利亚、加拿大、美国、英国可用。

参见：EBSCO推出BiblioGraph（Library.Link改名？）（2023-2-6）（2016和2017年BIBFRAME论坛也曾介绍过Library.Link）

最后提及EBSCO的FOLIO即将推出的主要关联数据功能：BIBFRAME用Marva编辑；基于图谱的存储；连接到其他FOLIO图书馆的网络；一键由MARC移到BIBFRAME；通过API和联合订阅源将关联数据发送到任何用户界面；由BiblioGraph加入更大的数据网络。

• 报告2、在混合MARC环境中使用BIBFRAME Using BIBFRAME in a mixed MARC environment / Harriet Aagaard and Andreas Andersson, National Library of Sweden

瑞典国家图书馆介绍其联合目录Libris：自2018年以来，我们在Libris生产BIBFRAME，但导入导出仍是MARC。目前在开发新目录Libris sök，使用Libris BIBFRAME。

• 报告3、在BIBFRAME环境中满足联盟所需：来自Share家族的案例史 Catering for consortia in the BIBFRAME environment: case histories from the Share Family / Tiziana Possemato, @CULT

意大利厂商介绍Share家族的新项目Parsifal，罗马图书馆联合会（URBE）的联合目录：https://parsifal.urbe.it/parsifal/home?l=en。界面延续之前的Share-VDE，可参见：Share-VDE在图书馆关联开放数据中的作用（2021-20-30）

【与Libris类似】Parsifal也是MARC进、MARC出，中心知识库CKB是BIBFRAME；同样提及使用BIBFRAME的优势是聚类作品。项目的另一特别是提供URBE学术出版社与Wikidata的连接。报告还介绍了不少作品聚类等数据清理的技术性问题。

• 报告4、跨越MARC和BIBFRAME之间的鸿沟 Bridging the gap between MARC and BIBFRAME / Jeff Mixter, OCLC

OCLC在总结多年来在关联数据方面的各项工作后，介绍2种编辑器：1、WorldCat实体编辑器（规范数据用）；2、BIBFRAME编辑器，允许使用BIBFRAME描述资料，并与MARC编目工具无缝配合，而WorldCat实体编辑器也将集成到BIBFRAME编辑器中。【又一种BIBFRAME编辑器】

• 报告5、LC在Folio的BIBFRAME和Marva的进展 LC’s progress with BIBFRAME and Marva in Folio / Doug Loynes, EBSCO Information Services, and Jodi Williamschen, Library of Congress

介绍LC的BIBFRAME编辑器Marva的变化。关键决定1：与FOLIO紧密互操作；关键决定2：Marva作为独立app，供非FOLIO馆作为前端；时间线：2023年11/12月，重点：专著套录。

2023年欧洲BIBFRAME研讨会（BFWE 2023）将于9月19-20日在比利时皇家图书馆举行，这是自2017年以来第7届。

年会会期2天，内容比美国国会图书馆每次1小时的BIBFRAME更新论坛要丰富得多。会议虽冠名欧洲，实际范围更广，除一直参会的美国外，今年还有报告人来自韩国、有报告介绍新加坡国家图书馆局的系统。如会议网站自述：BIBFRAME在欧洲研讨会的目的是成为一个论坛，分享关于BIBFRAME实施的实践、生产和规划的知识。

会议日程日前发布，包含大部分的报告摘要，可以了解BIBFRAME的应用现状。

BIBFRAME Workshop in Europe 2023

以下按涉及机构类型分类列出报告（产品Folio、Share-VDE多次出现）

【图书馆】

• 【美国国会图书馆 / Folio】[1] 美国国会图书馆更新 Library of Congress update / Sally McCallum，将启用FOLIO来处理BIBFRAME。[2] 编目员的关联数据 Linked Data for Catalogers / Judith Cannan
• 【瑞典国家图书馆】提取和链接作品实体 Extracting and Linking Work Entities / Andreas Andersson，2018年在将联合目录Libris由MARC21转换为基于BIBFRAME的关联数据格式时，做出了一个实际的妥协，将“作品”定义为每个实例中的匿名实体。现准备进行结构改革，正式将作品实体与实例分开并联系起来。
• 【新加坡国家图书馆】从雄心到上线：新加坡国家图书馆委员会迈向可运营的关联数据管理和发现系统 From Ambition to Go Live: The National Library Board of Singapore’s journey to an operational Linked Data Management & Discovery System / Richard Wallis
• 【芬兰国家图书馆 / Share-VDE】[1] 使BIBFRAME数据模型适应我们的需求：遇到的挑战和吸取的教训 Adapting the BIBFRAME data model to our needs: challenges encountered and lessons learned / Matias Frosterus，2022年，芬兰国家图书馆开始了一个项目，为采用BIBFRAME进行编目做准备。[2] Share VDE的可用性研究 Usability study of Share-VDE / Serafia Kari。
• 【加拿大阿尔伯塔大学】阿尔伯塔大学图书馆LSP迁移规划：BIBFRAME需求和要求 UAL LSP Migration Planning: BIBFRAME Needs and Requirements / Ian Bigelow等，2022年1月，阿尔伯塔大学图书馆启动关联数据实施计划；2023年启动新项目，将现有的Sirsi Symphony ILS迁移到新的LSP解决方案。
• 【LD4项目】[1] 生产关联数据第4阶段：在制度中立的数据池中真正共享数据 Linked Data for Production Phase 4: Truly Shared Data in an Institutionally Neutral Data Pool / Philip Schreur等，LD4P的下一步，计划转变编目模式，停止套录，使用共享源数据。[2] 一个社区开发的用于描述珍稀资料的BIBFRAME纲要 A community developed BIBFRAME profile for the description of Rare Materials / Paloma Graciani Picardo等

【厂商】

• 【@Cult + Casalini Libri / Share-VDE】Share-VDE和Share家族-生产方面的进步 Share-VDE and the Share Family – Advancements towards production / Tiziana Possemato等
• 【EBSCO / Folio】数据解锁：让图书馆在FOLIO中拥有丰富的联系和见解 Data Unlocked: Empowering Libraries with Rich Connections and Insights in FOLIO / Gloria Gonzalez，LC著名的BIBFRAME编辑器Marva与FOLIO平台的无缝集成。
• 【Ex Libris】在全球生态系统中从MARC到BIBFRAME From MARC to BIBFRAME in a global ecosystem / Adina Marciano等，Ex Libris产品Alma和Primo。
• 【OCLC】满足当今用户的需求：减轻迁移到链接数据的负担 Meeting users where they are today: easing the burden of migrating to linked data / Jeff Mixter，随着图书馆迁移到BIBFRAME，以MARC和MARC为中心的工作流程的必要性将持续存在。OCLC为合并规范编目工作流程和书目编目工作流程所做的工作。
• 【Index Data / FOLIO+Share VDE】FOLIO满足协作实体管理 FOLIO Meets Collaborative Entity Management / Sebastian Hammer，在FOLIO和Share VDE之间建立集成点。

【BIBFRAME专题】

• 【互操作】BIBFRAME互操作性小组（BIG）更新 BIBFRAME Interoperability Group (BIG) Update / Nancy Lorimer等
• 【编辑器】设计用户友好型BIBFRAME编辑器的考虑因素：信息组织专业人员的挑战和未来 Considerations of designing a user friendly BIBFRAME editor: Challenges and future of information organization professionals / Myung-Ja (MJ) K. Han等，创建BIBFRAME数据的两个著名的链接数据编辑器的比较。
• 【词表】BIBFRAME接受LRM载体表现说明的一种方法 A Method of BIBFRAME’s Acceptance of Manifestation Statement of LRM / Mihwa Lee [韩国公州国立大学]。BIBFRAME应该开发额外的属性和类，以反映LRM/RDA的实体、属性和关系。
• 【MARC】（讨论）MARC到BIBFRAME的双向性和开发者的观点 MARC to BIBFRAME both ways and the developer’s viewpoint / Sally McCallum等

【相关/社区报告】（尚无摘要/报告人，仅列标题）

• 1、Report from RSC【RDA】
• 2、En route to Linked Data / Maurits van der Graaf【关联数据】
• 3、Report from SWIB 2023 ”【Semantic Web in Libraries，2023/9/11-13，柏林 https://swib.org/swib23/（始于2009年）】

参见：

• 2022欧洲BIBFRAME研讨会（2022-10-14）
• 2021欧洲BIBFRAME研讨会信息（2021-10-17）
• 2020欧洲BIBFRAME研讨会（未写博文）
• 2019欧洲BIBFRAME研讨会（2020-6-16）
• [2017-2018]欧洲BIBFRAME研讨会（2019-3-29）
• BIBFRAME在欧洲启动？2017欧洲BIBFRAME研讨会（2017-5-18）

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

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子属性【定义用】

见：

• BFWE 2023报告（挂在“Share-VDE and the Share Family”报告下）：Development of the Share-VDE ontology: goals, principles, and process / Oddrun Ohren (National Library of Norway), Jim Hahn (University of Pennsylvania, University of Illinois), Tiziana Possemato (@Cult/Casalini). 31s.
• 本体：The Share-VDE ontology: a BIBFRAME extension for linked data discovery / Jim Hahn and Tiziana Possemato. https://doi.org/10.5281/zenodo.8332350