美国国会图书馆（LC）近日宣布开始“BIBFRAME 2.0实施注册”，收录不同机构实施的BIBFRAME相关项目，可以是已经实施的、开发中的或者计划中的。
BIBFRAME 2.0 Implementation Register
LC在2014年启动过“BIBFRAME实施注册”，2014-2015年间共有14或15个项目注册。网址相同，目前先前注册项目暂列在2.0实施注册页面下部，为的是方便相关机构修改后继续注册2.0。不久将彻底删除。如对BIBFRAME发展历史感兴趣，需抓紧时间保存。
现在2.0实施注册下已有3项，都是先前注册项目的更新，更新日期均为2017-4-14，分别是：
1、美国陆军工程兵研究发展中心图书馆：BLUEcloud Visibility（内容未变）
2、斯坦福大学。由LD4L项目更新为LD4P项目（参见：重量级图书馆关联数据项目LD4P获得资助，2016-5-10）
3、德国国家图书馆：BIBFRAME 2.0 Implementation Register（计划2018年实施）
2014年初ALA仲冬会议上，加州大学戴维斯分校 Michael Colby 介绍该馆刚得到IMLS资助为期两年的项目“编目再发明：未来图书馆运作模式”（Reinventing Cataloging: Models for the Future of Library Operations）（ALA 2014仲冬会议中的BIBFRAME，2014-2-5）。算一下的话，项目应该在2016年初完成。
当时没有BIBFLOW这个名称。在IMLS网站，无论是“BIBFLOW”还是“Reinventing Cataloging”都查不到。通过校名，查到2013财政年度的这个项目（金额$493,619） ：LG-06-13-0201-13
Program: National Leadership Grants for Libraries
The University of California Davis University Library will investigate the future of academic research library technical services by assessing the current landscape and developing a roadmap for strategic planning and investments in the coming years. This roadmap can be continuously updated as new data models, standards, workflows, and practices emerge and evolve. Currently, complex workflows and interdependent systems have constrained academic libraries from fully leveraging the benefits and efficiencies of modern technological infrastructures. This research study will include acquisitions, licensing, cataloging, processing, digitization, and newly identified areas that will encourage using technological resources.
虽然并未提到BIBFRAME，但应该就是BIBFLOW项目了（研究性大学图书馆技术服务的未来）。而其中提到的Roadmap，也终于在2017年3月14日完成，并于日前在项目网站发布，悄悄地。一直关注此项目的 Jeff Edmunds 本月初在 BIBFRAME 邮件组发布了消息。
BIBFLOW: A Roadmap for Library Linked Data Transition (Prepared 14 March, 2017) / MacKenzie Smith, Carl G. Stahmer , Xiaoli Li, Gloria Gonzalez
I. 导论
II. 为什么关联数据
III. 转变基础
IV. 路标概述
V. 阶段一：MARC生态系统中的关联数据 。V.a 步骤一：关联数据查找MARC编目平台 ；V.b 步骤二：MARC 批插入 URI；V.c 步骤三：关联数据导入/导出 API；V.d 阶段一完成
VI. 阶段二：转变到原生关联数据生态系统 。VI.a 步骤一：发起转变到关联数据原生编目 ；VI.b 步骤二：批转换遗留MARC记录；VI.c 步骤三：迭代转换非目录图书馆系统
VII. 转变工作流程 。VII.a 套录 ；VII.b 原编；VII.c 连续出版物编目；VIII. 规范控制
IX. 厂商参与
X. 发现
XI. 当前图书馆关联数据实施调查
附录A：厂商参与态势
附录B：术语词汇
此次发布的报告是网页形式，数十个页面链接，看起来很是不便；其中有不少图示，分辨率更是低到完全看不清。Roy Tennant 自告奋勇转换成了PDF文件，并放在他自己的网站上供下载，但对看不清的图示就无能为力了。其中二阶段各三步骤的转换路标（conversion roadmap）还勉强能够看清：
摘录报告部分段落：
“本报告的主要发现是，图书馆转变到关联数据，处在比大多数人相信的更好位置。更广的关联数据生态系统和语义网，总体上建立在对实体（人物、地点等）和行动（写作、获取等）的共享唯一标识符的基石上。图书馆具有很长的共享数据治理和标准的历史，因此图书馆文化很适合转变到关联数据，图书馆的结构化数据（MARC）处在很好的数据转换位置。鉴于上述情况，我们的结论是，关联数据代表着机会而非挑战，本路标意在作为希望抓住这一机会的图书馆的指引。”（I. 引言）
“MARC和关联数据编目框架的关键差异是，MARC基于记录，而关联数据基于图谱 (graph)。不同于理论上无限的知识图谱，记录有着固定数量的字段和子字段。……扩展框架的唯一途径是，通过一个复杂的、自上而下的驱动过程，由许多机构与治理团体参与讨论与采用，接着重新编程处理这些记录的所有软件系统。 ”“基于图谱的知识系统则不受制于任何以上局限。它们可强化使用信誉良好的受控词表描述对象的能力，同时提供可扩展性，让用户增加新知识节点（字段）到其描述图谱。”（II. 为什么关联数据）
“转变到关联数据并非数据转换活动……转变到关联数据要求增加新数据到每一条记录，数据常会难以由机器消歧。特别是，成功的转变到关联数据生态系统，要求在转换时增加大量共享的公开承认的唯一标识符（URI）到每条记录。基本概念是，在一个图谱中为所有实体提供一个唯一的、机器可操作标识符。”“从数据角度，转变到关联数据的主要障碍，是将MARC记录中实体的文字表达，与机器可操作URI联系起来。这种联系必须反向实施到所有遗留记录（艰巨任务），必须更新图书馆系统，在处理新记录或编辑已有记录时创建这种联系……”（III. 转变基础）
上月美国国会图书馆（LC）公布了BIBFRAME2.0词表更新、相关组件，其中包括MARC字段到BIBFRAME2.0的转换对照表（MARC 21 to BIBFRAME 2.0 Conversion Specifications）。近日，LC以提供了MARC到BIBFRAME转换的并列比较工具，可以直观浏览一条MARC记录转换为BIBFRAME记录后是什么样子的：
BIBFRAME Comparison Tool — Compare MARCXML to BIBFRAME2
提供2种查询记录的途径：书目记录ID（001字段）或LCCN控制号（010字段）
BIBFRAME2的序列化方式2种可选：Turtle 或 RDF/XML（默认前者）
该工具副标题“从MARCXML到BIBFRAME2”，但目前展示的是MARC编辑界面，并非MARCXML。这是由于实际转换工具是由MARCXML转为BIBFRAME的，即需要先经过早年的转换工具将MARC转换为MARCXML。选择显示MARC而非MARCXML，应该是由于对编目员来说，其可读性和简洁性上更高。
默认样例为BIB ID=5226/LCCN=82060878，非RDA记录。看BIBFRAME记录，大致区块为以下6大类：
1 作品 ，包含：
– 题名（首选题名）
– 管理元数据（头标/0XX部分）
– 分类号（050/082）
– 008部分代码
– 贡献（1XX/7XX，连接“施事者”）
– 连接“实例”
– 连接“主题”
2 实例 ，包含：
– 著录（2XX-5XX）
– 008部分代码
– 连接“馆藏”
– 连接“作品”
3 馆藏（050LC索书号）
4 主题（6XX）
5 施事者（1XX/7XX）
6 各类代码值，定义所属“类”，用于以上各类的属性取值，多为头标/0XX的代码。
样例中可以看到几处bflc: 命名空间（BIBFRAME的LC扩展）的使用，应该都是为转换处理而临时设置的：
编目级别（管理元数据）：bflc:encodingLevel a bflc:EncodingLevel ;【头标17，#=f/full】
贡献（作品）：bf:contribution a bflc:PrimaryContribution【主要责任者1XX】
题名（作品/实例）：bflc:titleSortKey “Snoopy on wheels /” ;【去不排序字符？含子字段末“/”】
施事者：
bflc:name00MarcKey “1001 $aFlanagan, Terry.” ;【含MARC子字段名】
bflc:name00MatchKey “Flanagan, Terry.” ;【不含子字段名的字符串】
bflc:primaryContributorName00MatchKey “Flanagan, Terry.” .【主要责任者1XX】
BIBFRAME2.0不以元素区分创作者、贡献者，所有责任者都是“贡献”contribution，再加上不同的“职能”role 。或许是在处理上还不能一步到位地提供具体的职能，LC扩展了表明主要责任（创作者）的类 bflc:PrimaryContribution 和3个属性 bflc:primaryContributorName00MatchKey，bflc:primaryContributorName10MatchKey，bflc:primaryContributorName11MatchKey（应该分别对应100/700、110/710、111/711）。为什么7XX？因为7XX也可能是创作者。