标签： BIBFRAME

在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 的值域，就允许其客体可以是在不同命名空间中定义的某些题名资源。

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

德国的 Adrian Pohl 在BIBFRAME邮件组询问，一个行为主体（Agent，施事者）有多个职能时，应当如何记录。比如作者兼插图者，是在一个“贡献”中列出多个职能，还是每个职能各做一个“贡献”。（How to record an Agent with more than one role? (2016-12-22)）
Adrian Pohl 紧接着问了另一个关于职能的问题：在 BIBFRAME 2 中有没有与 BIBFRAME 1.0 中 bf:relator 对应的属性？目前最接近的是bf:role，但其值域是字符串，如果希望采用 MARC关系词URIs 是不能用的。（Recording roles with relator URIs and Bibframe 2.0 (2016-12-22)）

对于职能的困惑，LC 的 Ray Denenberg 给出的回应是，bf2的bf:role等于bf1的bf:relator，因为现有文档过时了，LC马上会发布 BIBFRAME 词表的更新（BIBFRAME 2.1版？）：
过去数月，我们在开发转换规范过程中，分析了 BIBFRAME 词表，在此过程中有些变化。我们计划尽早发布。
特别是，bf:role 现在是对象属性【值域不再是字符串】，bf:contributor 和 bf:creator 被排除【不在形式上区分贡献者与创作者，只以职能取值区分】。这是为了减少表达职能的不同方式。
所有贡献都通过 bf:contribution 属性引入（其客体是 bf:Contribution 类）。
关系词词表不会作为 BIBFRAME 本体的一部分、也不会导入 BIBFRAME本体。相反，LC将为自己实施 BIBFRAME 定义LC专用本体，会导入 BIBFRAME 本体和关系词。【LC会使用MARC关系词表，但其他采用 BIBFRAME 词表者可以使用其他关系词】

对于前一个问题，Ray Denenberg 的答案是，每个职能各做一个“贡献”：
如果一个“贡献”中有两个及更多职能说明，则是同一职能的两个不同表达（如两个不同URI）。
对“行为主体”也是如此，两个不同作者做两个“贡献”，只有当同一行为主体有不同表达时【比如一个VIAF，一个ISNI】，两个“行为主体”【的表达，其实是一个】才应当列在同一“贡献”中。

以下是 Ray Denenberg 所举“作者”职能的例子：
bf:contribution [
a bf:Contribution ;
bf:agent <http://id.loc.gov/rwo/agents/n85062876> ;
bf:role <http://id.loc.gov/vocabulary/relators/aut> ] ;

<http://id.loc.gov/rwo/agents/n85062876> [
a bf:Agent, bf:Person ;
rdfs:label “Gomes, Luísa Costa “ ] ;

<http://id.loc.gov/vocabulary/relators/aut> [
a bf:Role ;
rdfs:label “author” ] ;

如果其同时为“插图者”，需要同样再做一个 bf:contribution（以下例子为本人增补）：

bf:contribution [
a bf:Contribution ;
bf:agent <http://id.loc.gov/rwo/agents/n85062876> ;
bf:role <http://id.loc.gov/vocabulary/relators/ill> ] ;

<http://id.loc.gov/vocabulary/relators/ill> [
a bf:Role ;
bf:Role ;
rdfs:label “Illustrator” ] ;

——— 编目员终于不用再了解格式了 ———
一开始看到关于BIBFRAME如何表达的讨论，看到BIBFRAME 1.0到2.0类和属性的交替，看到复杂的三元组表达，我就担心，这都要让编目员弄懂吗？
然后仔细看BF editor，只有RDA，根本就没有BF词表的痕迹。相信如果BF编辑器界面变化，也不会是词表由1.0到2.X变化所致。
因此我的结论是：编目员只要掌握编目规则就好，不需要像了解MARC一样了解BIBFRAME中有哪些类、哪些属性，哪些有类又有属性，比如“贡献”要这样表达：bf:contribution a bf:Contribution