标签： folio

FOLIO的BIBFRAME功能

月初去合肥，参加全国图书馆知识组织与新一代信息服务系统数据管理专题研讨会（好长的会名）。

  • 我讲BIBFRAME，包括最新进展，有今年9月欧洲BIBFRAME研讨会（BFWE 2023）EBSCO的Gloria Gonzalez关于FOLIO将如何用BIBFRAME，Maurits van der Graaf 对国际应用RDA和BIBFRAME的预测，以及Marshall Breeding去年的预测【参见：用BIBFRAME成本更高？（2023-5-23）】

会上EBSCO中国创新服务总监周奇有报告“FOLIO项目进展及案例分享”，其中两点我特别感兴趣：

  • 其一，folio的Poppy版本将有MARC编目（2023 R2第2次发布）。回来查Poppy（罂粟花）计划2023-11-20公开发布，在典藏app中新增quickMARC选项，可创建新的MARC书目记录（而不仅仅是导入记录）【见：Poppy (R2 2023) Release Notes. https://wiki.folio.org/display/REL/Poppy+%28R2+2023%29+Release+Notes】
  • 其二，2023年世界开放图书馆基金会大会（WOLFCon 2023）Gloria有个FOLIO与BIBFRAME的报告。回来查8月会议的这个报告，与她在BFWE 2023的报告风格、侧重各有不同。

——FOLIO的BIBFRAME相关功能——

以下概述自2个报告：

  • 关键关联数据功能将于2024年进入FOLIO：

[1]BIBFRAME编辑器【Marva，关联数据编辑器；可在FOLIO内部或外部使用】

[2]基于图谱的存储【关联数据DB】

[3]连接到其他FOLIO图书馆的网络

[4]一键从MARC移到BIBFRAME【ETL引擎，即提取、转换、加载，将多个来源的数据组合到中央存储库】

[5]通过API和联合提要[syndication feeds]将关联数据发送到任何用户界面【同步推送功能】

[6]可选加入BiblioGraph的更大数据网络【使用BIBFRAME Lite；关于BiblioGraph，参见：EBSCO推出BiblioGraph（Library.Link改名？）（2023-2-6）】/posts/2023/0206/6028

  • FOLIO将如何使用BIBFRAME：

BIBFRAME转换（关联数据转入/转出）

BIBFRAME编辑（书目、规范、管理数据）

BIBFRAME共享（API、同步、互操作）

BIBFRAME报告（追踪、测量、评估…）

  • FOLIO的关联数据核心变化：新增2个app、新增关联数据存储

[1]Marva编辑器app->关联数据模块

[2]图谱浏览器app->数据浏览模块

[3]关联数据DB（BIBFRAME存储）【FOLIO原来将MARC或其他格式书目记录导入简单记录库SRS DB保存，实际使用的是典藏DB，两个库相互链接。新增的关联数据DB将存入2个新增app生成的数据，并复制SRS DB中的数据。典藏模块将有2个存储即：1)典藏DB，2)关联数据DB，两者相互链接。】

FOLIO关联数据存储（BIBFRAME存储）

2023年BIBFRAME更新论坛

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月，重点：专著套录。

Folio实体管理应用（实体app）

在FOLIO的元数据管理特别兴趣小组（MM-SIG）支持下，实体管理工作组（EM-WG）在2020-2021年打算开发实体App，形成了2份文件：

之后EM-WG大概就结束活动了。2022年小组恢复活动，并更新了用例。

实体管理工作组的恢复，似乎与美国国会图书馆（LC）于2022年9月宣布决定采用由EBSCO支持的FOLIO有关。参见：美国国会图书馆选择folio系统（2022-9-22）

2023年1月30日LC的BIBFRAME更新论坛，已经与BIBFRAME关系不大，几乎成为其FOLIO更新论坛，其中第3时段的康奈尔大学Jason Kovari报告，针对FOLIO中的实体管理，介绍了上述2份文件。该时段后来增加EBSCO的Gloria Gonzalez报告，针对LC的FOLIO项目，在用于FOLIO的新BIBFRAME/关联数据需求部分，介绍“规范和实体管理功能”，提到以下两点：[1]自动化规范管理任务，用MARC书目和规范记录同步关联数据规范；[2]作为LC图书馆馆藏获取平台（LCAP）的一部分创建实体管理服务，FOLIO实体管理工作组将提供反馈。

根据“实体App愿景”，实体包括：行为者、体裁、地理、主题、作品、其他（如MARC和RDA词表），即通常的规范控制对象。通过管理、创建、缓存、发布，集成实体数据，支持实体的CRUD（即创建、读取/消费、更新、删除）功能。

概述：

  • 实体管理应用程序（实体App）是FOLIO架构的模块，在这里管理、创建、缓存和发布实体数据。该应用程序提供支持实体管理的功能，跨FOLIO应用程序集成外部和内部关联数据源，并提供促进基于实体的数据模型（如BIBFRAME）的一个组件。这将是FOLIO管理受控实体和支持FOLIO存储和支持的任何元数据模式的中心位置。
  • 为了方便其他功能，实体App必须缓存外部实体并存储内部实体。外部实体，如美国国会图书馆（LC）主题标题、LC名称规范档（LCNAF）、Getty词表、RBMS词表或任何具有关联数据端点的基于web的词库，可以在内部缓存，以便可以在MARC SRS、典藏和FOLIO内开发的其他数据存储中控制数据。
  • 实体App还将支持使用永久URI创建、维护和发布的本地定义实体。实体的本地管理示例可能包括机构的本地实体，这些实体不由现有的外部实体数据源表示，或创建关于外部实体的本地数据（例如：为有问题的主题标题添加替代标签）。
  • 实体管理工作组承认CODEX愿景，该愿景与实体管理概念之间存在一些重叠【本人说明附后】。然而，实体管理app旨在实现特定功能，以实现对Folio内实体的管理，并不局限于CODEX愿景，也不要求交付CODEX愿景的任何部分。
  • 在规范管理范围内，实体App以多种方式处理FOLIO和第三方查找服务中其他地方存储的数据。首先，实体App保存FOLIO中使用的受控标题的记录数据。这包括MARC SRS书目记录中1XX、6XX、7XX等字段中存储的标题等数据，以及FOLIO中当前管理的参考数据（例如：资源类型和载体类型）。

【说明】Folio使用Codex管理元数据（The Codex Vision），并作为规范化的元数据中心，供各种app调用。Codex不但映射导入各种来源的元数据，甚至还建立抽象的“作品”，以实现如典藏（Inventory）中的实物资源和知识库（KB）中电子资源（eHoldings）的关联。这显然与实体管理有交叉。

实体管理App作为规范控制工具，对于转向FOLIO的LC来说是刚需，其他图书馆不一定需要。而Codex作为不同FOLIO域和App之间的连接点，则是所有图书馆都需要的基础FOLIO域，二者本各有侧重。实体App完成后，Codex当可直接利用实体管理域中的规范数据。