RDA新术语：作品组（《RDA 和连续出版物编目》第2版出版）

上月《RDA 和连续出版物编目》第2版出版：

RDA and Serials Cataloging, Second Edition <https://alastore.ala.org/RDAserials2> / Ed Jones. ALA Editions, 2024. 240页. ISBN 978-0-8389-4871-2. $69.99

本书反映《IFLA图书馆参考模型》（LRM）在《资源描述与检索》（RDA） 最新修订版中引入的连续出版物新模型，“是日常实践的重要工具，也是不寻常或疑难案例的参考手册”。

第2版最重要的更新是介绍历时作品（diachronic work）概念，解释连续出版物作为一种历时作品，如何使用新的属性元素扩展计划（extension plan）来描述。关于历时作品，可参见：新RDA的“历时作品”（2019-5-22）https://catwizard.net/posts/20190522145047.html

另外，介绍新术语作品组（work group）并展示其在促进关系和支持搭配方面的有用性。

— 作品组（work group）—

查RDA工具包（https://access.rdatoolkit.org/），共有7个相关术语：work group 及 3对互逆属性（称谓、标识、规范检索点）

  • 作品组（定义）：由两个或多个作品组成的组，这些作品具有由词汇编码方案(VES)分配的共同称谓（A group of two or more works that have a common appellation assigned from a vocabulary encoding scheme.）
  • 作品组的称谓/属性：appellation of work group，appellation of work group of 
  • 作品组的标识/属性：identifier for work group，identifier for work group of
  • 作品组的规范检索点/属性：authorized access point for work group，authorized access point for work group of

从定义看，作品组大概属于“超级作品”范畴，比如把《红楼梦》和据此改编的电影、电视剧等放在一起。这是新RDA超越LRM的规定。

连续出版物对于“作品组”的要求可能更迫切。由于LRM认为“任何连续出版物作品都可以说只有一个内容表达，只有一种载体表现”（现常被称为“ＷEM锁定”），因此“连续出版物之间的所有关系都可以建模为作品对作品关系”，这既涉及接续、合并、拆分等（之前就视为不同作品），也涉及不同媒介版（印刷或电子）、多种语言版、本地版等。尤其是不同语言、不同媒介，以前视为同一作品的不同内容表达或不同载体表现，现在则为不同作品。参见：IFLA-LRM的连续性资源模型对RDA修订的影响（2018-6-29）https://catwizard.net/posts/20180629215026.html

看各国的政策声明，基本上未采用相关条款。如LC-PCC policy statements for appellation of work group，有详细说明：LC/PCC practice: Do not record the element. The element will be evaluated for use at a future time.

鉴于现在无论是MARC还是BIBFRAME，都没有相关字段或元素（类与属性）用于记录作品组，也就可以理解了。

艾利贝斯Alma已支持BIBFRAME

艾利贝斯作为目前最重要的图书馆自动化系统厂商，很多年前就着手在其Alma中开发实施BIBFRAME。可参见：艾利贝斯与哈佛图书馆合作开启“BIBFRAME路线图”（2017-5-12）https://catwizard.net/posts/20170512210545.html

2024年9月，艾利贝斯发布新闻，加州大学戴维斯分校自2024年5月上线开放关联数据（LOD）版Primo。同时，该校也成为第一个在生产环境中使用 BIBFRAME 进行编目的客户——Alma开始支持使用BIBFRAME 记录（作品和实例），从采购到资源管理、实现[流通]，一直到“发现”系统。此外，还支持以简单且可配置的方式使用 URI 丰富现有 MARC 记录。报道称，“BIBFRAME支持是我们社区共同愿景的第一步，即图书馆中的LOD，并支持多种LOD元数据格式”。

LOD版Primo主要是推出著名人物的“个人页面”，汇总来自可信外部来源和图书馆目录的权威详细信息。这并不新鲜，在十多年前OPAC 2.0时代就有，近年实施则有著名的Share-VDE。秉持一惯的开放姿态，艾利贝斯在其产品文档中，有“个人实体”数据的信息来源、排序、配置等详细介绍（Searching Linked Open Data – Person Entity. https://knowledge.exlibrisgroup.com/Primo/Product_Documentation/020Primo_VE/Primo_VE_(English)/150End_User_Help/Searching_Linked_Open_Data_-_Person_Entity）。【在该校发现系统试查莎士比亚，未看到“个人页面”，可能需要校内访问】

BIBFRAME支持也有页面（BIBFRAME Support. https://knowledge.exlibrisgroup.com/Alma/Product_Documentation/010Alma_Online_Help_(English)/Metadata_Management/005Introduction_to_Metadata_Management/BIBFRAME_Support），介绍各功能模块涉及内容。摘录部分：

  • 通过API创建、更新、查看和删除 BIBFRAME 作品和实例记录，API 支持 Sinopia BIBFRAME 编辑器，并允许直接从 Sinopia 无缝更新 Alma 中的 BIBFRAME 记录
  • 在 SRU（Z39.50） 中支持 BIBFRAME 记录，搜索可以以 BIBFRAME 等格式返回
  • BIBFRAME 记录也可以作为记录视图的一部分作为 MARC 记录进行动态查看【LC新版编辑器Marva Quartz也有此功能】

via: Ex Libris 很高兴地宣布加州大学戴维斯分校成为第一个上线 BIBFRAME 的机构

Ex Libris is excited to announce UC Davis as the first institution to go live with BIBFRAME (2024-9-23). https://exlibrisgroup.com/announcement/ex-libris-is-excited-to-announce-uc-davis-as-the-first-institution-to-go-live-with-bibframe/

新闻最后链接有艾利贝斯白皮书：探索发现与编目的未来：用关联开放数据和人工智能改变图书馆体验

An Expedition into the Future of Discovery and Cataloging: Transforming the Library Experience with Linked Open Data and AI. https://exlibrisgroup.com/wp-content/uploads/An-Expedition-into-the-Future-of-Discovery-and-Cataloging-Linked-Open-Data-Whitepaper-Apr-2024.pdf

提到该公司LOD的三个支柱：更好的可发现性、协作编目、全球互操作性。说到“协作编目平台”，不免联想到当年“元数据平台MetaDoor引发OCLC起诉科睿唯安”（2022-6-30）https://catwizard.net/posts/20220630104542.html，以科睿唯安（艾利贝斯的母公司）终止MetaDoor平台达成和解（OCLC and Clarivate settle lawsuit. 2022-11-07. https://www.oclc.org/en/news/announcements/2022/oclc-clarivate-settle-lawsuit.html）。

bf:Hub不是作品

想知道BIBFRAME的类Hub（bf:Hub）究竟是什么？博文比较长，先说个人结论：bf:Hub是内容表达（或内容表达组）。间接佐证：bf:Hub在2021年发布时定义为bf:Work的子类，现在bf:hasExpression属性仍同时用于bf:Hub和bf:Work类。

  • 背景

1997年国际图联（IFLA）《书目记录的功能需求》（FRBR）提出书目资源四层实体“作品—内容表达—载体表现—单件”（后常简称WEMI），2017年取代FRBR系列的《IFLA图书馆参考模型》（IFLA LRM）继承此模型。本文中不加限定说明的WEMI均为LRM概念（为方便以lrm:标识），如标题中的“作品”即指lrm:Work。

美国国会图书馆（LC）的BIBFRAME 2.0模型是三层核心类“作品—实例—单件”，bf:Work对应lrm:Work+lrm:Expression。当BIBFRAME 2.1和2.3词表新增bf:Hub（作为两部作品之间桥梁的抽象资源），形成“Hub—作品—实例—单件”四层基本模型类（Basic Model Class），似乎正对应LRM的四层，但BIBFRAME 模型图现在仍是2.0版，没有Hub类。

这2个四层实体/类真是一一对应吗？bf:Hub相当于lrm:Work吗？尽管有人这么并列，我之前也这么认为，但每每看到bf:Hub记录，总有点怀疑。上月博文“Bibframe Hub 聚类现状”（2024-9-16，https://catwizard.net/posts/20240916094541.html），着重于单条bf:Hub记录，看其侧栏关联的记录。这次希望更详细了解bf:Hub本身，选择原语种为英语的《哈姆雷特》及其中译、《红楼梦》及其英译，略做探究。由于上文所引Nate Trail，bf:Hub数据来自LC相应的规范记录，因此与规范库 （authorities.loc.gov）对照。

  • [1] 作品规范记录对应lrm:expression？

BIBFRAME 2.0 模型只有三层Work—Instance—Item。规范记录对应Bf:Work，书目记录对应bf:Instance，感觉很完美。

如果bf:Hub数据来自LC相应的规范记录。难道规范记录对应bf:Hub？

LC规范库，作品的规范记录大多通过名称-题名查找，少数（如匿名作品）通过题名查找。以莎士比亚《哈姆雷特》为例，查：Shakespeare, William, 1564-1616 hamlet，现有108条结果，约60条标记为规范标目，含中译3条。以下为其中4条：

Shakespeare, William, 1564-1616 hamlet（主记录，关联460条书目记录）

Shakespeare, William, 1564-1616. Hamlet. Chinese（中译，关联1条书目记录）

Shakespeare, William, 1564-1616. Hamlet. Chinese (Lin)（林同济中译，未关联书目记录）

Shakespeare, William, 1564-1616. Hamlet. Chinese (Zhu)（朱生豪中译，未关联书目记录）

LC的题名/名称-题名规范用于书目记录的130/240等字段，同一作品常有多条记录（如上，有不同语种、同一语种不同译本，以及不同选本、部分，等等）。因此作品规范记录显非lrm:Work，更接近lrm:expression。

按编目规则，文献原语种不加语种限定，因此仅有题名、无任何限定的那条记录（我暂称为“主记录”），可对应LRM的代表性内容表达，而非lrm:Work，在规范记录中应该也没有字段给予特别标识。

那么，是不是bf:Work对应lrm:expression，bf:Hub对应lrm:Work？

  • [2] bf:Hub对应什么？

以前大致浏览过bf:Hub检索结果一览，感觉并没有合并相同作品。如前所引，bf:Hub数据来自LC相应的规范记录。从LC规范库与关联数据服务（id.loc.gov）的查询结果对比，两者大部分形式一致，但bf:Hub的结果数（82条）比规范记录数（约60条）还要多出不少。以下1条对应于规范库“主记录”：

Shakespeare, William, 1564-1616 hamlet（主记录）Identified By：Lccn: n80008522

由两者的名称-题名形式对比，推测多出来的那些bf:Hub，应该来自未使用规范形式的书目记录（这些bf:Hub记录中没有LCCN规范记录ID）。回顾先前博文“Hub：BIBFRAME模型下的超级作品”（2020-6-28）https://catwizard.net/posts/20200628160934.html，其中所引2019年欧洲BIBFRAME研讨会上Kevin Ford关于bf:Hub的MARC来源的介绍，正是这么说的。可是由于当初的博文误读，结论和标题完全错误。

换言之，目前bf:Hub不只对应原有的规范记录以及规范库结果，离lrm:Work距离更远。

  • [3] 四层关系Hub—Work—Work—Instance

特别奇怪的是，从BIBFRAME各类记录侧栏的关系追溯，通常竟然有4层（如果加上Item的话就是5层模型了）：

Hub（has Expression）Work（has Expression）Work（has Instance）Instance

猜测在有bf:Hub前，bf:Work兼作品/内容表达，因此有两层？好奇前一层Work的数据何来。另外从数据看，bf:Hub像某种内容表达组。

  • 以《哈姆雷特》主记录为例：

【Bibframe Hub】（有LCCN，对应规范记录）

https://id.loc.gov/resources/hubs/83e65f55-ac8f-fcb8-ea65-120fbbbaccec.html

Title = Hamlet

Identified By = Lccn: n80008522

侧栏：Has Expression = Shakespeare, William, 1564-1616 Hamlet（数十条/名称形式相同，此为第1条）

【Bibframe Work】（无ID，来源不明；与下条“分类号”不同）

https://id.loc.gov/resources/works/7624041.html

Title = Hamlet

Classification = LCC: PR2795.M3 H38

侧栏：Has Expression = Shakespeare, William, 1564-1616 Hamlet, 1751（数十条/名称形式各异，此为第1条）

【Bibframe Work】（无ID，URL标识同instance，对应书目记录）

https://id.loc.gov/resources/works/10026252.html

Title = Hamlet, 1751

Classification = LCC: PR2878.H3 K5 1751a

侧栏：Has Instance = Hamlet, 1751（一条）

【Bibframe Instance】（对应书目记录）

https://id.loc.gov/resources/instances/10026252.html

Title = Hamlet, 1751

Identified By = Lccn: unk84045293

  • 仅偶尔遇3层，即：Hub—Work—Instance

如《哈姆雷特》规范标目中未注明中译者的那条Shakespeare, William, 1564-1616 Hamlet. Chinese（仅1条书目记录） 

【Bibframe Hub】（有LCCN，对应规范记录）

https://id.loc.gov/resources/hubs/35bf8775-775a-4808-8ba0-6d52396cf7a1（长标识）

Title = Hamlet. Chinese

Identified By = Lccn: no2016051867

Note = Data source: (hdg.: 哈姆雷 = Hamulei ; translator, Peng Jingxi)

侧栏：Has Expression = Shakespeare, William, 1564-1616 Hamuleite

【Bibframe Work】（无ID，URL标识同instance；译者与Hub不同）

https://id.loc.gov/resources/works/23394582.html

Title = Hamuleite

Contribution = Fu, Guangming, 1965- (Translator)（傅光明）

侧栏：Has Instance = Hamuleite

【Bibframe Instance】（对应书目记录）

https://id.loc.gov/resources/instances/23394582.html

Title = Hamuleite: Hamlet

Identified By = Lccn: 2023388166 = Isbn: 9787201123844

  • [4] 遗留数据问题

大规模的数据往往经不起细察。曾说自己手黑，随便一查就会发现错误问题。当年关注OPAC 2.0，发现新功能常使一些原本隐藏的数据错误显现出来。这次也一样，上述《哈姆雷特》记录汉译者有问题；《红楼梦》（Cao, Xueqin, approximately 1717-1763，用姓名查可包含各种变异题名结果），看到各种版本混在一起，不同英译本被聚合在一个bf:Work下。

前述[2]中多出来的bf:Hub记录，凸显遗留数据未采用规范形式的问题。[3]中的聚合匹配错误，同样体现数据的各种问题，不一定是错误，也可能由于编目规则的逐步进化。如果通过细化不同时期MARC记录到BIBFRAME的转换规范，减少数据形式上的差异，或有助于降低聚合处理难度。