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。管理员还必须有一种方法可以为所有或某些类型的实体（例如，不得共享的资源）禁用此功能。