2024欧洲BIBFRAME研讨会

2024欧洲BIBFRAME研讨会 https://www.bfwe.eu/helsinki_2024(第8届年会),欧美国家图书馆主办,2024/9/17-18在芬兰赫尔辛基,亲身+虚拟混合活动,免费注册与会。会议日程2024/7上线、含报告介绍;2024/10/8报告PPT+视频(YouTube)上线。

以下简单的会议笔记,按个人随感归并排列。

  • LC深度参与会议:首场报告介绍LC动态,又主导第2天的两个圆桌讨论,一是BIBFRAME编辑器的未来(摆脱MARC平面性,使用AI的可能性)、二是BIBFRAME/MARC双格式环境(Modern MARC什么样)。

首场报告内容比2个月前LC主场丰富得多:•关于BIBFRAME:从为什么转向BIBFRAME要花这么长时间(系统、社区、数据),到LC过去3年(2021-2023)今后3年(2024移到BIBFRAME、2025实施Folio、2026适应RDA)的任务。2024年8月LC的重要里程碑——15名编目员开始以BIBFRAME输入记录。•关于MARC:特别说明LC倾向于采用新的3XX字段(代替006-008编码数据字段),BF到MARC转换将逐渐把原260分解为可重复的264等。•关于非拉丁字母数据,BCP47将用于LC的BIBFRAME和转换为MARC。•结语:LC很高兴已经开始转向BIBFRAME;期待将重点从转移(shift)本身,移到BIBFRAME关联数据的开发(exploitation)[这才是吃瓜群众真正的期待];LC将继续提供MARC,但以“现代”形式[modern MARC]。(Sally McCallum: BIBFRAME, MARC, RDA)

  • BIBFRAME编辑器,目前已有3种;另外还有OCLC的编辑器在研发中。

Flanders中央编目,测试3种开源关联数据编目系统:Libris XL、Marva、Sinopia。将选择1种进一步开发。(Lynn Van Kerckhove, Guy Cools: Towards a new way of cataloging in Flanders)

  • BIBFRAME映射,2个报告专论MARC21以外格式的映射:

SHARE Family第一家SHARE Catalogue,最初使用BIBFRAME 1.0。现使用Wikibase.Cloud,做UNIMARC到BIBFRAME 2映射。(Claudio Forziati: The UNIMARC-BIBFRAME mapping in SHARE Catalogue: an evolving path)

韩国公州国立大学李Mihwa教授继2023年后再次与会,讨论KORMARC的映射问题。(Mihwa Lee: KORMARC data mapping for BIBFRAME transforming)

  • 艾利贝斯,今年官宣支持BIBFRAME的Alma已上线。本次会议2个报告介绍各自参与艾利贝斯“关联数据焦点小组”,以特藏测试BIBFRAME的经历:

利兹大学使用Sinopia编目珍稀图书(Trevor Hough, Kim Taylor: Adventures in BIBFRAME: Cataloguing Rare Books Using Sinopia at the University of Leeds)。

迈阿密大学法律图书馆,从Sinopia、经由Alma到Primo(Adina Marciano, Margarita Perez Martinez: Unlocking BIBFRAME: Practical Insights for Alma and Primo)

  • OCLC,前几年感觉在BIBFRAME方面参与度比较低,随着LC开始实施BIBFRAME……

今年报告主题是:在图书馆工作流程中大规模处理关联数据。两部分内容:(1)WorldCat实体,介绍新推出的OCLC推出Meridian(WorldCat实体集成服务工具),也提及OCLC新数据模型:WorldCat本体。(2)BIBFRAME:摄入(测试LC和Sinopia/Alma)、导出(大规模测试,以评估导出BIBFRAME的质量),数据差异问题(OCLC正在努力创建一套高度可靠、一致且对开发人员友好的BIBFRAME数据),编辑器(征召开发合作伙伴测试中)。(Jeff Mixter:  Working with linked data at scale in library workflows)

  • 实施方面:互操作、数据存储、数据完善

互操作BIBFRAME互操作小组(BIG)正在进行的工作。两个下属小组,分别制定用于验证基础BIBFRAME描述(又名BF Interlingua=交际语中间语)的形状指南,开发验证结构(DCTap电子表格的结构,DCTap到SHaCL的转换:DCTAP = Dublin Core Tabular Application Profiles,SHACL = Shapes Constraints Language)。(Nancy Lorimer: BIBFRAME Shapes: Validating our Approach)

蓝色核心计划:意在转变编目模式、停止套录,由一个图书馆联盟维护和运营。除美国高校馆以外,美国国会图书馆也参与其中。期待其3年计划的2025年测试与实施。(Kalli Mathios: Planning and Designing: An Update from Blue Core)。

瑞典国家图书馆:不断完善其数据。去年是“作品”,今年关注归一化书目数据中不同层次的“类型”,据称包含如体裁/形式之类,竟有2000种之多(Andreas Andersson: Normalising and coordinating types in bibliographic data)

  • 多格式、不影响当前编目流程,也是BIBFRAME应用的一个选项?

以Share-VDE开始兴盛的Share Family中心知识库CKB格式无关(MARC21、UNIMARC、BIBFRAME/RDF)。采用SVDE本体(BIBFRAME扩展),与第三方整合(Alma, FOLIO, Sinopia)。(Tiziana Possemato, Serena Cericola: Share Family: advancements in linked data collaboration)

新加坡国家图书馆局的关联数据管理系统(去年年会报告续),即将上线侧栏知识图谱导航。BIBFRAME捕获书目记录的细节,Schema.org为搜索引擎提供结构化数据;Schema.org作为知识图谱的“通用语言”词表。不取代当前的编目流程和实践(Richard Wallis: Building a Semantic Knowledge Graph at National Library Board Singapore)

  • RDA现身本次会议。2023年会的初始日程有RSC报告、但最终没有。

今年报告人为RSC主席,概述RDA的组织结构、修订过程、工具包发布、RDA注册、社区资源、国际合作、切换官方工具包。可全面了解现状,但没有提及与BIBFRAME的映射。(Renate Behrens: News from RDA)

另外还有2个应用RDA的报告:

欧洲厂商Axiell Group的Quria图书馆服务平台:关联数据基于RDA注册、WEMI聚类,各种格式数据经由MARC21导入导出。(Magdalena Olofsson, Emma Tennevall: Linked Data LMS: Experiences from Production)

芬兰国家图书馆的关联数据项目(去年年会报告续):采用BIBFRAME数据模型,与RDA深度整合(BFFI数据模型)——当BIBFRAME与RDA不同时,多遵从RDA(如用WEMI,根据RDA拆分一些BIBFRAME属性)。(Matias Frosterus: Expressions and Aggregates in BIBFRAME)

参见:https://www.bfwe.eu/

艾利贝斯Alma已支持BIBFRAME

艾利贝斯作为目前最重要的图书馆自动化系统厂商,很多年前就着手在其Alma中开发实施BIBFRAME。可参见:艾利贝斯与哈佛图书馆合作开启“BIBFRAME路线图”(2017-5-12)/posts/2017/0512/4483

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)/posts/2022/0630/5897,以科睿唯安(艾利贝斯的母公司)终止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,/posts/2024/0916/6303),着重于单条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)/posts/2020/0628/5427,其中所引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的转换规范,减少数据形式上的差异,或有助于降低聚合处理难度。