“MARC数据，除了控制字段，总意在被人而非机器消费与理解，如同早期HTML被人读，而非被机器理解”—— Nate Trail
最近BIBFRAME邮件组围绕LC新近提出的BIBFRAME修订建议展开热烈讨论。美国国会图书馆（LC）网络开发与MARC标准办公室的Nate Trail谈到，即使没有BIBFRAME，用“资源”代替“实体”的工作也可以开始：现在虽然仍使用MARC，但LC已经开始鼓励编目员在多个字段放LC控制号（LCCN）和其他标识符，而不是写出题名或实体名，这样系统已经可以做链接。——换言之，MARC也可以与关联数据结合。
Nate Trail提到“Terry Reese正在其MARC转换器中建立实体解析过程，把标识符转为链接”。顺邮件中的链接看Terry Reese的博文，发现MarcEdit 6利用LC关联数据服务（查询id.loc.gov），增加了验证名称与主题规范（1XX、6XX、7XX字段）功能。目前MarcEdit 6.1已经发布，“验证标目”功能已上线（与博文截屏大致相同）。
关于MarcEdit另见：MarcEdit的RDA助手（2013年1月29日）
———- MarcEdit 博文摘译 ———-
MarcEdit 6 Wireframes — Validating Headings (Aug 09, 2015)
在过去一年中，我花了很多时间，寻求集成很多成长中的关联数据服务到MarcEdit的途径。这些服务，主要围绕词表发展，提供某些有兴趣的机会，增强现有MARC数据，或者强化使用这些特定词表的本地系统。如在Bentley这样的例子，是计算机能够如何利用这些端点（endpoints）的真实世界证明。
在MarcEdit，至今我已经创建和测试链接工具近一年，我期望探索的领域之一，是图书馆是否能使用链接服务建立自己的规范工作流程。概念上，应该是可能的——存在必需信息……确实只是放在一起的问题。因此，这就是我正致力的。使用图书馆在MarcEdit中发现的关联数据，我正致力于创建一项服务，将帮助用户识别无效标目以及带这些标目的记录”。
MarcEdit Validate Headings: Part 2 (Aug 23, 2015)
验证标目工具加为MarcEditor的一个新报告，让用户取一个记录集，返回一个报告，详细了解多少记录有相应的LC规范标目。本工具设计验证在1XX、6XX和7XX字段中的数据。本工具设置只使用LC规范档查询标目和主题。在适当时候，我会寻求扩展到其他词表。
目前本工具必须在MarcEditor内部运行——尽管在未来某个时点，我会把此（工具）由MarcEditor抽出，提供一个独立功能，与其他命令行工具集成。
……
如果该值为变体（即非规范形式），结果报告“返回记录号、术语的标准化形式、当前LC首选术语及该术语的URL”：
Record #612
Term in Record: bible.–criticism, interpretation, etc., jewish
LC Preferred Term: Bible. Old Testament–Criticism, interpretation, etc., Jewish
URL: http://id.loc.gov/authorities/subjects/sh85013771
Heading not found for: Bible.–Criticism, interpretation, etc
……我马上会增加代码，让用户选择按报告更新变体标目。
———- Bentley的例子 ———-
博文中提及的Bentley，是密歇根大学Bentley历史图书馆。该馆的ArchivesSpace项目，使用Google Refine，通过VIAF API查询LC规范记录，增强档案记录中的名称和主题。其中还用到Python的FuzzyWuzzy库处理字符串的模糊匹配。
代码主要采用GitHub上Matt Carruthers的：LCNAF-Named-Entity-Reconciliation
介绍博文（来自blogspot，有墙）：
Arkheion and the Dragon: Archival Lore and a Homily on Using VIAF for Reconciliation of Names and Subjects (Friday, July 24, 2015)
Order from the chaos: Reconciling local data with LoC auth records (Friday, July 31, 2015)
Arkheion and the Dragon, part II