分类： 若有所思

OCLC报告：关联数据，图书馆编目的未来

OCLC近日发布报告：关联数据，图书馆编目的未来

来自OCLC新闻：”Linked data: The future of library cataloging” is available now on the website.2024-6-24. https://www.oclc.org/en/news/releases/2024/20240624-linked-data-position-paper.html

先让Kimi读一下pdf文件，整理核心内容如下：

  • 这份文件是关于图书馆目录编目未来的报告，主要讨论了链接数据[关联数据]（Linked Data）的概念及其在图书馆领域的应用前景。以下是报告的核心内容概述：
  • 1. 链接数据的重要性：/ 随着在线信息量的增加，良好的元数据变得尤为重要。/ 链接数据是一种组织和连接网络数据的方式，便于不同系统和自动化服务的共享和使用。
  • 2. 链接数据的定义和作用：/ 链接数据通过使用统一资源标识符（URIs）打破传统的MARC记录，使图书馆数据更易于访问和连接。
  • 3. 图书馆元数据的局限性：/ 传统元数据适合已知项目的搜索，但发现潜在有价值的联系需要时间和专业知识。
  • 4. 链接数据的优势：/ 链接数据可以帮助用户发现意外的新路径和资源。/ 它提高了图书馆资源的可见性，并改善了搜索结果。
  • 5. 图书馆工作的转折点：/ 目前，图书馆的元数据主要在MARC记录和其他固定格式数据资源中创建和管理，这限制了它们在其他环境中的使用。
  • 6. 链接数据对图书馆的好处：/ 链接数据连接并扩展了图书馆知识，促进了偶然发现，并使图书馆专家能够专注于高价值的知识工作。/ 它还使图书馆能够积极贡献于全球信息生态系统。
  • 7. OCLC对链接数据的承诺：/ OCLC致力于提供基础设施、工具和专业知识，以支持图书馆在元数据演变中的过渡。
  • 8. 链接数据的实现：/ OCLC正在开发链接数据产品、服务和数据集，以连接数据并提供大规模数据管理所需的资源。
  • 9. OCLC的长期战略：/ 包括专业知识、数据、基础设施和工具，旨在帮助各种规模和类型的图书馆顺利过渡到链接数据模型。
  • 10. 链接数据的未来：/ 链接数据为图书馆提供了连接独特工作与更多用户、合作伙伴和社区的重大机会。
  • 报告最后邀请读者学习、实验、实践、成长和与OCLC一起创新链接数据，并感谢所有参与链接数据研究和技术项目的人员和合作伙伴。
  • 这份报告强调了链接数据在图书馆领域的潜力，以及OCLC在推动这一变革中的作用。

关联数据谈这么久，说它是编目的未来，并不是什么新观点。OCLC多年来一直关注关联数据，为什么突然发布一份看似平平无奇的报告？报告中说，“虽然OCLC对关联数据的研究可以追溯到十多年前，但我们刚刚开始将其集成到图书馆管理任务中”，显然是为推新产品/服务造势。目前来说，就是报告中提及的Meridian（子午线），WorldCat实体的集成服务工具（将另写博文）。

而Meridian应该只是开始，本报告“工具”部分说：“我们今天正在将链接数据集成到图书馆工作流中，同时也在为明天做计划。我们正在创建一套复杂的新工具，向现有记录和工作流添加有价值的链接数据元素，同时在可预见的将来维护并行MARC服务和应用程序。”

是不是可以这么理解——在可以预见的很长一段时间，还会有很多图书馆继续使用MARC，他们也需要让自己的目录进入关联数据世界。不用说，BIBFRAME也可以使用WorldCat实体标识符。

— WorldCat实体及关联数据标识符 —

从报告看，OCLC的关联数据战略，目前主要围绕WorldCat书目记录中的实体URI，WorldCat实体包括作品、个人、地点、事件等。上述几个网页中提供的数据是，WorldCat实体有1.5亿，已有4亿WorldCat实体URI（标识符）添加到WorldCat的MARC记录中。

年初的2024冬BIBFRAME更新论坛，OCLC有报告：OCLC为BIBFRAME所做的准备（OCLC’s preparation forBIBFRAME / Jeff Mixter. 9 slides），其中讲到OCLC在关联数据标识符及相关工具方面的进展：

  • 2023年12月，已将个人、地点和事件的WorldCat实体URI添加到WorldCat记录中
  • 2024年1月，开始将作品的WorldCat实体URI添加到WorldCat记录中
  • [工具]2024年1月底，WorldShare Record Manager集成WorldCat实体查找和URI插入编目工作流程。/ 发布此工具的目的在于，弥合传统记录和关联数据框架之间的差距，实现数据的无缝创建和管理。此工具将为MARC编目员提供在编目时添加关联数据特征的能力，以帮助改进数据转换到关联数据，并支持已经在BIBFRAME 2.0中编目的图书馆员。

参见：2024冬BIBFRAME更新论坛（2024-2-8） /posts/2024/0208/6201

BIBFRAME作品与实例的子类（及与RDA/MARC21的对照）

写上篇博文“如何查各类BIBFRAME记录（及作品和实例子类的表示）”/posts/2024/0611/6256】时得知在BIBFRAME中档案是实例的子类。印象中RDA没有“档案”这一类。

查RDA，“档案”使用术语 archival resource（档案资源），是一个文献（类型），但不属内容类型或媒介类型。于是想给RDA与BIBFRAME的文献类型作个对照。

RDA遵循FRBR/LRM模型，资源的四层实体为“作品W-内容表达E-载体表现M-单件I”。BIBFRAME（以下简称BF）只有三层实体“作品W-实例I-单件I”，其中BF作品对应RDA的作品和内容表达。

从本体（词表）看，BF类（实体）多、几乎与属性的数量相当。而RDA类（实体）很少，但有内容类型对应于内容表达，有媒介类型对应于载体表现。因此直觉BF作品子类可对应RDA内容类型，BF实例子类可对应RDA媒介类型。但初步对比表明，事实并非如此。我甚至找出AACR2章节和MARC21头标和008、007字段来做对照，试图找出BF作品/实例子类的依据或来源。

首先，BF实例子类与RDA媒介类型差别很大，只有缩微和电子（计算机）2个相同：

BIBFRAME实例子类
Print
Archival【RDA无档案】
Tactile【RDA内容类型中细化触觉】
Electronic
Microform		RDA媒介类型
audio【BF作品子类】
computer
microform
microscopic【BF无显微，新增】
projected【BF无投影】
stereographic【BF无立体】
unmediated【含BF的Print+Tactile】
video【BF作品子类有MovingImage】

仔细想想，BF实例的5个子类，都可能包含多种内容类型，如印刷品，可能含文字、地图、图像、乐谱、舞谱、手稿等等（缩微同）；档案还能包含音视频、电子资源等更多内容类型。也就是说，我当初认为的其与RDA媒介类型对应的想法根本不对路。

其次，RDA的内容类型是多种内容类型的组合，如cartographic tactile image（含地图、触觉、图像）。而BF的作品子类包含2个方面：内容类型和组织形式（RDA术语“扩展计划”extension plan）。作为MARC21的替代，BF作品子类与MARC21头标06位记录类型（内容类型）和07位书目级别（RDA扩展计划）的对应更好（下表BF作品子类后的标记=MARC21头标取值）。

BIBFRAME作品子类
Text=06a
Cartography=06e
Audio=06ij
NotatedMusic=06c
NotatedMovement【新增】
Dataset=06m【细分】StillImage=06k
MovingImage=06g
Object=06r
Multimedia=06m【细分】
MixedMaterial=06p
Manuscript=06dft【RDA无手稿】

Collection=07c
Arrangement【无对应】
Integrating=07i
Monograph=07m
Serial=07s
Series【无对应】		RDA内容类型
cartographic dataset
cartographic image
cartographic moving image
cartographic tactile image
cartographic tactile three-dimensional form
cartographic three-dimensional form
computer dataset
computer program
notated movement
notated music
performed movement【BF无专指类/属性】
performed music【BF属性】
sounds
spoken word
still image
tactile image
tactile notated movement
tactile notated music
tactile text
tactile three-dimensional form
text
three-dimensional form
three-dimensional moving image
two-dimensional moving image

RDA扩展计划
integrating determinate plan
integrating indeterminate plan
static plan
successive determinate plan
successive indeterminate plan		MARC21/Leader
06 – Type of record
a – Language material
c – Notated music
d – Manuscript notated music
e – Cartographic material
f – Manuscript cartographic material
g – Projected medium
i – Nonmusical sound recording
j – Musical sound recording
k – Two-dimensional nonprojectable graphic
m – Computer file
o – Kit【BF无套件】
p – Mixed materials
r – Three-dimensional artifact or naturally occurring object
t – Manuscript language material

MARC21/Leader
07 – Bibliographic level
a – Monographic component part
b – Serial component part
c – Collectiond – Subunit
i – Integrating resource
m – Monograph/Item
s – Serial

与RDA相关的备注：

  • 1）archival resource 档案资源，是一个文献（类型）。多个元素有档案相关规定，如：作品属性：system of organization；载体表现属性：date of production，title of manifestation。
  • 2）manuscript 手稿：RDA术语表中没有“手稿”，但在一些作品、内容表达或单件元素中有相关规定
  • 3）series丛编：RDA有多个丛编相关元素，为载体表现元素
  • 4）print 印画：print特指印刷图片如版画，而不是BM实例子类所指广义的印刷品——RDA术语常很特别（比如unmediated 无中介）。

如何查各类BIBFRAME记录（及作品和实例子类的表示）

有同行想找使用bf:Archival的例子，但没有找到，在BIBFRAME邮件组寻求帮助。

美国国会图书馆（LC）负责BIBFRAME的网络开发与MARC标准办公室的Nate Trail首先给出的解答是：档案（bf:Archival）是实例（bf:Instance）的一个类型（rdftype），因此在id.loc.gov上查实例会看到更多。

按Nate给出的实例检索式（https://id.loc.gov/search/?q=cs:http://id.loc.gov/resources/instances），侧栏细化检索有类型分面，目前Archival有1025条。【此法对查找不同类型记录特别方便，如修改为作品检索式（https://id.loc.gov/search/?q=cs:http://id.loc.gov/resources/works），再由侧栏分面细化限定】

然而，实例中并未使用bf:Archival。BIBFRAME词表网站的Archival类（https://id.loc.gov/ontologies/bibframe.html#c_Archival）的示例，也没有直接使用bf:Archival。

Nate后来解释：对作品和实例类型，LC不使用子类作为资源的名称（如bf:Archival），而是保留bf:Instance，用一个rdf:type属性进一步定义它。如BIBFRAME词表网站中的示例片断【特别是第2行】：

<bf:Instance rdf:about=http://id.loc.gov/resources/instances/5811340>【bf:Instance类】
    <rdf:type rdf:resource=http://id.loc.gov/ontologies/bibframe/Archival/>【子类Archival】
    <bf:title >
      <bf:Title >
        <bf:mainTitle >Benjamin Silliman correspondence</bf:mainTitle>
      </bf:Title>
    </bf:title>
…
</bf:Instance>