进入2017年2月，BIBFRAME邮件组围绕着BIBFRAME是否会“失败”进行了热烈的讨论。
最初的话题由Jeff Edmunds发起，他是宾夕法尼亚大学图书馆编目与元数据服务部数字评估协调员。短短数天，陆续扩展出共5个话题、数十封邮件，不少是长篇大论。如话题发起者后来的解释，所谓“失败”指不能广泛接受或采用，在投入大量时间、关注和焦虑之后最终放弃。Karen Coyle深度参与，提出一些较为超脱的看法。讨论中不可避免地涉及RDA，引来RSC主席Gordon Dunsire的解释。
BIBFRAME Archives – February 2017
话题1：BIBFRAME will fail（2017-2-1发起）
话题2：Failure（2017-2-1发起，回复最多）
话题3：BIBFRAME in FOLIO（2017-2-2发起，尚无回复）
话题4：[BIBFRAME] Conceptual models, was: [BIBFRAME] Failure（2017-2-2发起）
话题5：Inbound Linked Data (no BIBFRAME required?) 2017-2-3发起
发起话题：BIBFRAME will fail (2017-2-1)
Jeff Edmunds说明他将在下月做题为“MARC之后的生活？发现的未来”的报告，中心命题之一是：不同于MARC，BIBFRAME不会广为采用。他提出5个要点，希望先听听反对意见：
1）与其在MARC时代所拥有的声望不同，LC缺少推行其标准或做法至书目元数据生态系统的权威。LC不再是书目元数据的主要来源，对它所生成的书目元数据的生态系统的影响极小。LC在推动BIBFRAME中最可能的盟友——具有经验丰富的编目馆员的大型学术和公共图书馆——正转移资源远离编目而进入其他领域（数字人文、评估、学生参与、开放获取等）。
2）当前ILS、发现、下一代等平台的技术基础设施不支持BIBFRAME，没有市场激励去改变。开源、协作项目如FOILO在开发上必然必须大部分基于当前及遗留的MARC数据，而不是大量放在假设的数据模型如BIBFRAME。
3）BIBFRAME在生产环境方面是非常不切实际的：我注意到，BIBFLOW项目尽管正式结束于2016年，没有发布实质性的最后报告。有吗？
4）BIBFRAME高度概念化、头重脚轻、过于复杂，以至难以被大多数图书馆理解和有效实施（参见许多图书馆采用RDA代替AACR2的失败）。谈论BIBFRAME的人（多个PCC委员会等）没有在创建兼容BIBFRAME的元数据，仅仅谈论而已。
5）图书馆（和档案馆等）资料的发现已不再主要运行于书目元数据(metadata)，而是运行于巨大数据(megadata)（我定义为一个复杂的元数据混乱）、全文和大数据（包括个性化数据）。其结果是，不怎么需要与欣赏高质量元数据。
反对意见代表，可举Amber Billey，PCC BIBFRAME任务组共同主席、哥伦比亚大学图书馆元数据馆员。其全面回复受到多人赞赏。
Re: Failure (2017-2-1)
首先我要提下，OCLC才在2015年打印了最后一张图书馆目录卡片，很多图书馆继续使用目录卡片管理其馆藏。因此只因为有了创建图书馆元数据的新方法，并不意味着较旧的数据交换格式（如MARC）会消失。我还想指出，在成为ISO标准前，Henrietta Avrams花了8年开发MARC，而现在我们致力于BF仅5年。这个过程不会像拨弄电灯开关。它会慢且迭代，涉及很多教育与合作。
对于你的问题，我整个想法是，你问了错误的问题。不要想“MARC之后的生活”，请考虑“有BIBFRAME（和其他本体）的生活”。如Karen所说，我们早已生活在填充着很多不同结构标准和标记语法的信息环境中。未来的ILS将需要处理和序列化不止MARC数据（并且某些目前的ILS已经这么做了）。BIBFRAME将只是建模图书馆元数据时很多可选口味之一。
回复你的每一点：
1）我在想，贵馆使用LCC和LC规范档吧？我还在想，贵机构也是PCC成员，LC是重要伙伴。如果LC采用BIBFRAME，那么PCC将支持其工作，PCC成员会从这种伙伴关系中获益。不，LC不再是书目元数据的主要来源。供应商是。他们通过他们的私有工具取得我们免费提供的数据，然后再卖给我们。但我们有潜力通过关联数据和本体如BIBFRAME免费我们的元数据。如此，像LC这样的机构有潜力成为关联开放书目数据的主要来源，供世界收割。LC已经是关联开放规范数据的主要来源。
2）是的。我们需要新工具以创建、分享和维护共享关联开放数据。但这就像你要用车试驾，而我们甚至还没建造引擎。我们还在焊接底盘！当然我们的关联数据会围绕当前和遗留MARC数据开发——这是我们的主要图书馆元数据来源。我们必须发展那些数据，使之能够集成并参与更广泛的网络。
3）为什么你认为生产环境中的BIBFRAME是“疯狂不切实际的”？以下是BIBFRAME生产环境的例子——Casalini的Share-VDE目录。完全建立在用关联数据RDF的BIBFRAME和其他本体： http://www.share-vde.org/sharevde/clusters?l=en
至于BIBFRAME，这是他们的初步发现： https://bibflow.library.ucdavis.edu/category/findings/
http://www.share-vde.org/sharevde/clusters?l=en
如同所有迭代开发，我们需要试验项目来测试更大目标的不同方面。BIBFLOW，如同LD4L、LD4P、LD4L-Labs及众多本地关联数据项目，沿着一条道路，通向开发一个成功的图书馆（和其他记忆机构）关联数据实践。
4）我想说，这是你的观点。对Web环境，MARC对外行看上去太复杂以至难以理解并有效实施。BIBFRAME要求我们从不同角度思考如何建模我们的书目描述，不过它确实是传统书目描述的一个相当简单的建模。它也不是特别“头重脚轻”（我不太理解你是什么意思——本体中没有头），词表中属性远多于类。我们需要学习图书馆界之外由W3C开发的skilset。
现在，如果你要看一个概念化的复杂本体——看看CIDOC-CRM。这是一个IFLA支持的ISO标准本体，用于描述文化遗产元数据。新的IFLA-LRM与CIDOC-CRM兼容，它是FRBRoo的核心，将重构RDA。
关于许多图书馆采用RDA取代AACR2失败的论断，可以请你提供一个来源吗？ 【Jeff回复说AUTOCAT邮件组中一个非正式投票结果】
请关注LD4P项目。我们将在数月内生产BIBFRAME元数据。
5）我同意我们需要更多结构化的高质量元数据——这正是BIBFRAME和其他关联数据词表/本体正在争取的。通过关联数据如BIBFRAME数据，我们能够准确描述关系。同时更精确地编码我们的数据！规范维护用URI比检索点串更简单而准确。
应该说，看到题主的最初回应（Re: Failure (2017-2-2)）及后续回应，开始感觉有点失望，因为更多是情绪的宣泄，而不是针对BIBFRAME本身的看法。仔细想想，这反映了编目部门在图书馆的现状，以及由此编目员的心理感受：人员削减，需要“证明自己的存在”，做更多其他事情（目录而外，要创建与维护发现服务、数字存储库和机构库、关联数据项目）。环球同此凉热，美国、德国、中国……。