BIBFRAME2.0词表更新、相关组件公布

2016年4月,LC发布了BIBFRAME 2.0词表(bf2)(BIBFRAME词表2.0发布,2016-4-23)。此后,为准备进行BIBFRAME第2阶段试验,LC一直在为录入bf2格式的数据而努力。过了差不多一年,LC在本月发布了BIBFRAME 2.0相关组件,分享内容包括:1、更新的词表,2、MARC到BIBFRAME转换规范,3、MARC到BIBFRAME转换程序(BIBFRAME Vocabulary updated, MARC to BIBFRAME conversion specifications and programs released, March 10, 2017))。消息发布在BIBFRAME邮件组:
BIBFRAME specifications and conversion programs made available / McCallum, Sally (13 Mar 2017)

摘译如下:
LC正把整个书目数据文档转换到BIBFRAME,由MARC书目记录转换为BIBFRAME作品和实例描述,并与由MARC规范中的题名和名称/题名规范记录转换而来的作品描述集成。此次发布的组件即由上述工作形成,供大家使用BIBFRAME2.0词表实施开发,或者调查关联数据环境。

– BIBFRAME 2.0 词表更新:包括增加、改变、删除。
另外,在bf:之外新增命名空间bflc:,收录BIBFRAME的LC扩展,有些是为MARC转换而临时设置【类6个、属性9+20个】
先前版本:https://github.com/lcnetdev/bibframe-ontology
当前版本:http://www.loc.gov/bibframe/docs/
【在当前版本的清单页面,各元素的Change Notes注明变化情况:包括New新增、修改revise/fix等,其中2017年新增或修改37个
删除类2个:WorkTitle、InstanceTitle,删除属性3个:barcode、otherEditionOf、contributor,不以元素区分创作者、贡献者

MARC到BIBFRAME2.0规范MARC 21 to BIBFRAME 2.0 Conversion Specifications
共有依MARC字段块划分的20个转换对照表及说明文件,为所有MARC字段、指示符、子字段到bf2元素的对照,分别映射到I实例、W作品和Item单件。少数未使用的元素标记为“nac”(不尝试转换),在MARC环境外无意义的标记为“ignore”。

MARC到BIBFRAME转换程序
Index Data公司为LC编制。用XSLT写成,由MARCXML转换为BIBFRAME2.0
LC目前用这些转换程序开发试验项目,期望随工作进展加以调整。LC的Github页有详细使用说明。

即将提供的其他BIBFRAME工具:能够看BIBFRAME描述的工具
LC使用Index Data的Metaproxy工具,配合其图书馆自动化系统Voyager的OPAC,实现使用Z39.50或SRU搜索,搜索结果可以MARC、MODS、马上会有BIBFRAME2.0获取。其他工具将在完成后宣布。
BIBFRAME Implementation, Tools, and Downloads页面目前标记着3个coming soon:MARC到BIBFRAME比较观看器BIBFRAME2.0编辑器BIBFRAME演示数据集/BIBFRAME样例】

为什么BIBFRAME 2.0取消属性的定义域和值域

在BIBFRAME 2.0中,原来的 Domain(定义域)和 Range(值域)变成了 Used with(用于)和 Expected Value(期望值)。

Karen Coyle在BIBFRAME邮件组中询问,作出这种改变是否有特定的使用案例支持:
[BIBFRAME] BIBFRAME 2.0 question (2017-1-16)
LC的Ray Denenberg在十多天后作出回复(2017-1-27),认为虽然取消了强制限定,但实际上并不一定减少了限制,并从三方面举例说明【括号中为本人理解】:

– 由约束引起的意想不到的“限制”【模型本身决定了使用限制】
在1.0中,题名仅应用于作品和实例,主题和创建者仅应用于作品。我们发现,对某些(诚然罕见的)案例,题名、创建者和主题可应用于单件层。【这种罕见案例对编目员不难想像。2.0依此扩大了使用范围,或者也在某种程度上对原模型有所修正】
另一方面……【考虑到BIBFRAME模型】例如,只有作品会有实例,因此 bf:hasInstance 的定义域仍然是 bf:Work。

– 构造类的复杂性 【不值得过于复杂】
假设要通过施加定义域到属性bf:title,来限制题名用于作品、实例和单件。可以用很多方法这么做,包括构造的或人工的类。我们判定,这样做的好处值不回复杂性增加所致费用。【不是不能实现,比如可以用随后Simon Spero邮件所举OWL2的Manchester Syntax
另一个例子,对于属性 hasEquivalent:一个作品可等同于另一个作品,一个实例对另一个实例,或者一个单件对另一个单件。但一个作品不能等同于一个实例,或者一个实例对一个单件,等等。换言之,主体的资源类型(作品、实例或单件)必须与客体的资源类型相同。这是个强加的逻辑限制,但因为不能以明智的方式作出限制,因此hasEquivalent的值域不受限制。【1.0中没有为其提供定义域、值域;2.0中其“用于”和“期望值”均为 Work, Instance or Item】

– 扩展 【不局限于使用BIBFRAME资源】
BIBFRAME支持由外部(非bibframe)命名空间提供信息的能力。
例如BIBFRAME的题名,是类型 bf:Work 的一个资源。如果想要属性 bf:title 的客体必须总是在BIBFRAME命名空间,则 bf:title 的值域就会是 bf:Title。不限定 bf:title 的值域,就允许其客体可以是在不同命名空间中定义的某些题名资源。

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