对《对ILS投标者的BIBFRAME期望》的意见

2018-8-22 德国国家图书馆 Lars Svensson 在BIBFRAME邮件组中,针对2018年2月《对ILS投标者的BIBFRAME期望》提出意见,认为应当提出“功能需求”而不是“技术要求”,并参考2013年BIBFRAME用例与需求,从不同方面举例。

原文件参见:2017 EBW:对ILS投标者的BIBFRAME期望(2019-4-3)

—— 对《对ILS投标者的BIBFRAME期望》的意见 ——
[BIBFRAME] Some comments on “BIBFRAME Expectations for ILS Tenders” / Lars Svensson (2018-8-22)

……我认为该文所采取的总体方向存在一些问题。我觉得它主要关注技术而功能要求太少。本文建议过渡,从范式(1)其中编目在MARC记录中直接完成,并且图书馆集成库系统(ILS)使用关系数据库(RDBM)存储编目和任何相关联的数据存储到另一范式(2)其中编目在RDF中完成(使用BIBFRAME数据模型),ILS使用三元组库来存储必要的信息。我想说的是,第一个假设未必是真实的(有相当长的一段ILS其中数据不使用RDBM存储,至少一些图书馆编目不通过创建或编辑MARC记录,但使用其他元数据格式,如果需要可以转换为MARC)。我还要说,对新系统范式的建议过于狭隘,甚至可能通过强制要求使用哪种技术来阻碍创新。例如,有一种称为图数据库的新兴技术,它允许以有趣的方式分析图中的数据,包括找到两个节点之间的最短路径,找到“孤岛”(图或子树未连接到图的任何其他部分)或松散连接的子树(例如仅由一条边连接的子树)。如果我们要求使用三元组库,则供应商将无法使用此技术,因此将失去实现有趣统计功能的可能性。在我看来,招标应该尽可能技术中立(至少在系统内部方面)。

那么招标要包含什么呢?
我的看法是它应该指定所需的功能。毕竟,有趣的是我们希望系统做什么(或者至少我们想要对系统做什么)。对于基于关联数据的系统,我能想到的非详尽列表将是【引用2013 BIBFRAME使用案例与需求,参见:BIBFRAME使用案例与需求(2014-10-26)】

– 系统必须能够以下列格式导入图书馆数据:
— MARC 21(多半有不同风味)【比如:德国的没有ISBD标识符?LC较少用连接字段?】
— 使用BIBFRAME数据模型的RDF
— 使用RDA数据模型的RDF
— …
– 系统必须能够以下列格式导出数据:
— MARC 21(多半有不同风味)
— 使用BIBFRAME数据模型的RDF
— DC-XML(用于OAI-PMH)
— …
– 系统必须支持下列导入和导出接口:
— SRU/SRW
— OAI-PMH(双向同步)
— Z39.50 😉
— W3C WebSub(确保系统是Web的)
— …
– 编目模块必须允许编目员:
— 将题名和规范连接到驻留在本地系统中的其他题名和规范(例如,连接出版物与其继承者或作者;连接作者与其出生地、出生地与其所属国家)
— 将题名和规范连接到驻留在联机数据库中的其他题名和规范(可能要求系统必须支持的搜索界面列表)
— …
– 系统必须允许管理者:
— 配置数据录入表单,如限制编目员可以使用哪个规范档
— 以标准化格式导入和导出数据录入配置和元数据纲要(可能说明此种格式清单,如SHACL, ShEx, JSON Schema, XML Schema……)
— 无缝包含第三方数据库(IEEE Xplore, EconBiz, PubMed, ………)到最终用户检索中
– 系统必须允许最终用户:
— 使用单一、统一搜索界面搜索图书馆内部内容和第三方数据库
— 导出书目引文到第三方引文管理系统
— 对匹配定制搜索的新内容订阅RSS/Atom源【推送】
— …
对我,此方法的优点是:
1) 客户需要考虑他们真正希望系统做什么
2) 供应商可以专注于以舒适的方式实现此功能,而不必专注于新技术。

Karen Coyle与Lars进行了一番互动,认为在关联数据的讨论中缺少内容:要做哪些链接?由此Lars对需求作了补充:
这让我想到了另一个重要的要求,我通常认为这是理所当然的,但这可能需要明确:
系统必须为系统中管理的所有实体公开可解引的URI。管理员还必须有一种方法可以为所有或某些类型的实体(例如,不得共享的资源)禁用此功能

发表评论

电子邮件地址不会被公开。 必填项已用*标注


*