EBSCO推出BiblioGraph(Library.Link改名?)

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作为网站名?

参见:

扩展都柏林核心:学术资源应用纲要(DC-SRAP)

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实现中仍使用关系词作为角色概念。

[update 2022-12-5] LC的Kevin Ford于12月2日在邮件组中回复,说明LC同时声明关系词为取值和属性,但属性声明由于不明原因删除,现已恢复。

对回复邮件的理解后简述如下(含个人理解,不保证符合原意):

约2017年,LC和DCMI把[行为者]关系词映射到dc:contributor[作为下位属性]。2010年LC发布关联数据服务ID.loc.gov,关系词同时发布为取值[MADS规范+SKOS概念]与属性[RDF+OWL],但不知何时属性声明被误删、现已恢复。LC作过测试,认为既作为名词[主语/宾语=取值]也作为动词[谓语=属性]没有问题。BF的关系词由1.0属性到2.x变为对象(间接方法),主要原因是可以对关系做更多陈述,如同schema.org引入角色[作为对象](可以连接不同属性)。对于LC双重定义的资源,[是作为取值还是作为属性],社区可以各取所需。

为BIBFRAME转换简化MARC格式

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

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