邮件组大讨论:BIBFRAME将会失败?

进入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本身的看法。仔细想想,这反映了编目部门在图书馆的现状,以及由此编目员的心理感受:人员削减,需要“证明自己的存在”,做更多其他事情(目录而外,要创建与维护发现服务、数字存储库和机构库、关联数据项目)。环球同此凉热,美国德国、中国……。