标签： LC

美国国会图书馆：2023关联数据职位招聘

【白日梦】今天午睡，不知为何久睡到被唤醒，梦中情景历历在目……我向某人转述美国国会图书馆（LC）招聘信息：其一，接种新冠疫苗要求；其二，对职位的要求，当然首先是胜任各项工作，然后我让他猜学历要求是什么。他猜不出，我告诉他：没有任何要求。然后我就感慨，在吾国多小的机构招聘也是动则硕士博士的，LC竟然不要任何文凭。

午睡做梦而又清楚记得，本来少见，而梦境又过于真实，让我怀疑是梦还是非梦？起床问上午不在家的某人，是否和他说过LC招聘的事？没有。于是复述梦中其一其二，同样让他猜，他直接说猜不出。听说没有任何要求后，他表示质疑：他们不是有学校资格认证的吗？——做图书馆员是要有资格认证学校的学位，但技术人员没有这种限制啊。

附：[BIBFRAME] Job opportunity: 2 Linked Data positions at LC / Keven Ford. 2023-1-10 

上午在BIBFRAME邮件组看到LC有2个关联数据职位正在招聘——元数据应用的关联数据应用技术分析师，主要涉及书目框架BIBFRAME和关联数据服务id.loc.gov，也涉及其他标准如MODS、MADS、MIX、ALTO等XML模式，并为其他如PREMIS、METS、VRA提供维护服务。“我们大量使用XML技术、特别是XQuery和XSLT，但我们使用的更多，包括Python、NodeJS、Javascript、bash和SPARQL。我们利用XML数据库、MongoDB、Docker等”。

出于好奇，去看了美国政府官方网站USAJOBS上的招聘要求：Librarian (Linked Data Applications Technical Analyst)。头部最醒目的是新冠病疫苗接种要求（COVID-19 Vaccination Requiremen），说明目前对联邦雇员已没有普遍要求，但可能有些工作可能要求接种。条件的教育部分，说明“这份工作没有学历要求”（This job does not have an education qualification requirement.）。或许计算机奇才没学历很常见吧……

为BIBFRAME转换简化MARC格式

美国国会图书馆（LC）实施BIBFRAME已是箭在弦上，届时它将不再以MARC进行编目，代之以提供由BIBFRAME转换生成的MARC记录。为此，合作编目项目（PCC）于2022年初成立“BIBFRAME转换之MARC简化专责组”，其职责是检查LC的BIBFRAME2.0到MARC21转换程序和相关规范，据此开发一套简化的MARC字段，以准确有效支持BIBFRAME转换。年中和年末，中期报告和最终报告如期完成发布。见：

这套简化字段，在职责文件中称“瘦MARC”（Skinny MARC）。出于词义褒贬原因，小组先后考虑过一些其他术语，包括：简化MARC（simplified MARC）、基本MARC（essential MARC）、BF2MARC、用于BIBFRAME的MARC改编（MARC adaptation for BIBFRAME）、链接MARC（linky MARC）。特别说明的是，需要与先前的“轻量级MARC”（MARC 21 LITE, 2008版）区别开来。小组称不推崇任何上述名称，但或许是出于表述简单的考虑，在最终报告中多用“BF2MARC”。

小组提出的BF到MARC字段表，称为“来自BIBFRAME的MARC描述性字段的初步曲目”（Preliminary Repertoire of MARC Descriptive Fields from BIBFRAME）。所谓“初步”，是因为提供的2个表格中，主表“MARC<-BF”只有90多个变长字段子字段（如020$a）或定长字段位置段（如008/07-10），其中还包括12个无对应的008字段位置段，实际有对应的只有80多对。副表“MARC not included”列出没有对应BIBFRAME元素的近130个子字段等（如130/240$a）。可以想见这离成品有多大距离，LC的BF/MARC转换已历多年，我原本以为据此提出一套简化MARC格式是件并不复杂的任务，如此结果真是出乎意料。

为此，最终报告概述首先指出：“我们团队认识到，当前的BIBFRAME环境还不够成熟，无法建立稳定可靠的MARC字段集以作为永久‘简化’集”。之后列举了小组工作的复杂性（摘录）【本人理解】：

  • LC 转换记录的可得性缺乏【LC没提供】
  • 同行示例的通行性缺乏【于是从开发Sinopia的[LD4]获取，但数据滞后于LC目前用的BF2.2，也没有用LC本地扩展bflc:】
  • 书目记录中罗马化的未来不确定性【LC4调查显示罗马化对图书馆运行与服务很重要，但LC更倾向于使用有限罗马化文字；亲历LC的BF到MARC转换在使用/不使用880字段间摇摆】
  • LC的BIBFRAME扩展(bflc) 的状态【主要款目在BF中没有对应物，只在扩展bflc:；BF新类Hub与240字段的关系】
  • 序列化MARC数据的不确定性【检索点1XX/6XX/7XX/8XX中不同子字段，对规范维护的影响】
  • 小组对专业格式的专业知识的限制

接着提出了9个希望PCC未来讨论的开放主题【略】

附录2，BIBFRAME到MARC 21(BF2MARC)转换原则和量规（摘录）：

1、BF2MARC记录看起来将不像原生MARC【包括只带最少的ISBD标点；淡化主要款目，但包含关系代码；可能用040或884字段中的代码标识转换生成的记录】

2、BF2MARC记录虽然不一定复制惯用的MARC技术或惯例，但仍应像传统MARC记录一样发挥作用，支持以下领域的基本机器和人类操作：a.提供所描述资源的明确标识；b.提供所描述资源的必要描述性细节；c.启用对书目检索点的受控检索；d.为书目检索点的存在提供合理的理由【附注】；e.启用对主题检索点的受控主题检索；f.提供足够的元数据出处以实现信任和管理。【这是小组的意见，更从涉及编目规则，LC是否认可？】

3、转换必然是一个有损的过程。BF2MARC数据的功能要求不是可以通过算法将其转换回BIBFRAME。

4、应允许并鼓励对BF2MARC记录进行后续的下游修改。

官方RDA与BIBFRAME（2022欧洲BIBFRAME研讨会笔记）

2022欧洲BIBFRAME研讨会（BFWE，第六届）9月20-21日在匈牙利举行：

BIBFRAME Workshop in Europe 2022. 6th Annual Meeting (Hybrid Event), 2022/9/20-21. National Széchényi Library, Budapest, Hungary

会议网站有PPT与视频分享。以下为与新RDA（现通称“官方RDA”）关系较为密切的3个报告：PPT+[视频]+【本人备注】

参见：2022欧洲BIBFRAME研讨会（2022-10-14）

BIBFRAME实施之旅（BIBFRAME Implementation Journey / Sally McCallum, 美国国会图书馆网络开发和标准办公室主任）

  • （摘录结论部分：MARC简化、BIBFRAME基于RDA开发，即将实施）
  • s11.挑战：我们需要一个BIBFRAME到MARC的转换，它不仅对社区来说是一个好的MARC，而且遵循Voyager【LC目前的图书馆自动化系统】和LC多年来采用的所有MARC惯例；我们需要重新检查MARC冗余、MARC过度专指性以及导致MARC和BIBFRAME之间转换效率低下的非MARC相关约定；我们需要与社区合作，调整MARC，使其更简单，因为我们知道MARC在我们努力工作并向更丰富的环境过渡的过程中有着长远的未来。【PCC正开发“精简MARC”】
  • s12.现在实施的优点：BIBFRAME是基于RDA开发的，新RDA培训和实施即将到来—使用BIBFRAME会更容易；LC计划在未来2-3年内实施以BIBFRAME为核心的新ILS【9/22宣布的FOLIO】，BIBFRAME/Voyager将贡献：BIBFRAME验证（本体元素、转换期望、模型和形状）；MARC检查：转录与检索的需要、消除冗余、检查复杂性。使我们能够更多地利用关联数据环境中的新发现机会。
  • s13.谢谢，祝我们好运！

RDA到BIBFRAME映射现状（Update on RDA to BIBFRAME Mapping / Damian Iseminger, RDA指导委员会技术团队联络官）（3分钟视频，没有PPT）

  • 由于新RDA等因素，映射工作推迟到2023年开始。对完成有信心。需要先解决一些问题：
  • 1、与BIBFRAME的哪个版本/哪种口味(flavor)映射：SVDE？LC？或者同时？【关注BIBFRAME互操作问题】
  • 2、类与属性：RDA类少、属性多，BF类多、属性少。
  • 3、受众：面向开发者？编目员？

官方RDA和BIBFRAME（Official RDA and BIBFRAME / Paul Frank, 美国国会图书馆政策、培训和合作项目部编目政策专家）

  • 摘要：官方RDA工具包预计将在明年取代原RDA工具包【美国实施新RDA】。本演示文稿将检查官方RDA工具包及其支持文档（编目政策声明和元数据指导文档），因为它们可能应用于BIBFRAME编目环境。它还将通过将BIBFRAME Hub与RDA作品相关联，并显示BIBFRAME Hub与传统的“规范”一致，提供更紧密地对齐BIBFRAME和RDA模型的选项。
  • （讨论新旧RDA在4个方面的不同，及在BIBFRAME中可能的解决方案：1、合集资源-全集；2、译本-合集和个别；3、代表性内容表达；4、BIBFRAME Hub/作品组）
  • s2-5.原RDA和MARC经验：官方RDA正被测试，尚未实施；FRBR和原RDA不易用MARC表达；MARC仍然是编目的通用语言；MARC具有本体的无法表达性[表达关系方面]；作品和内容表达级别的FRBR建模在实践中模棱两可；如果作品是一个抽象实体，那么如何将其描述为一个慎重的实体？我们在编目什么：作品、内容表达、载体表现、全部三者？PCC是否犯了一个错误，让作品和内容表达融合在一起？[LC名称-题名规范：作品？内容表达？]。自2012年以来，RDA和MARC之间的这种有点失调的关系一直“有效”；BIBFRAME Pilot的经验质疑了所有这些，并暴露了MARC中的这些缺陷；MARC可以阻止对RDA的理解，或者至少可以让人自满；BIBFRAME的结构不会容忍这一点。
  • s6.官方RDA和BIBFRAME可能性：BIBFRAME是官方RDA数据的理想通信格式；【4种】记录方法；官方RDA比原RDA对关联数据更友好；LC打算在[用]官方RDA条款前，在BIBFRAME中指导编目员；BIBFRAME编辑器Marva【LC二代编辑器】和Sinopia【LD4P编辑器】免费提供。
  • s7.摘要：使用MARC增强BIBFRAME；看官方RDA，它可以用BIBFRAME表示；看官方RDA工具包中的这些变化，它们可以将编目过程从基于MARC的平面世界改变为关联数据语义环境。
  • s8.论题：1合集资源-【个人作品】全集；2译本-合集和个别；3代表性内容表达；4BIBFRAME Hub/作品组：BF和官方（和原）RDA间的本体区别。
  • s9-14.[一]合集资源：全集
  • 官方RDA：每个集合作品是新作品，因为集合了不同内容表达；WE锁定【基于LRM】；惯用总题名不是官方RDA组成部分，在“社区资源”；对规范检索点没有指引【或许因为分歧大，也在“社区资源”中】。
  • 长期实践/原RDA：为方便起见，全集被视为“一件”作品：基于归档规则而非数据模型。
  • 解决方案：[研究人员可能需要特定版本的全集]
  • [1]作品可视为一个Hub/作品组【BIBFRAME 2.1类bf:Hub=bf:Work子类，见论题[四]】：用于搭配具有共同特征的不同作品的常用称谓。
  • [2]对出版资源：将所有全集视为单独的静态、确定作品，并使其成为Hub；使用作品组标识(designation)：作品+区别（年份、出版者等）；将语法信息（VES、SES）添加到MGD【元数据指导文档】。
  • [3]对超级作品：使用作品的BIBFRAME Hub减去区别；使用MARC来利用BIBFRAME，如果BIBFRAME作品被创建为MARC书目记录而不是规范记录，那么现在可能会发生这种情况[希望如此]【BIBFRAME没有规范；LC规范用MADS/RDF表示】。
  • s13-14.Marva示例[可能的做法]：Hub：Dante的全集（1894年）；相关作品（元素标签标示关系）：Dante的全集。s15-20.
  • [二1]译本：合集资源[视频略过未讲]
  • 官方RDA：对于合集资源，译本就是新作品，因为集合内容表达不同；这意味着译本的题名是首选题名【只适合多作者；单作者合集首选题名为惯用总题名】。
  • 长期实践/原RDA：如何在原RDA下标识内容表达？内容表达题名不存在；内容表达通过作品的规范检索点+内容表达属性标识。
  • 解决方案：明确确定译本和原文之间的关系；不要从规范检索点推断；实体>作品>作品的相关作品related work of work？实体>内容表达>……的译本translation of ？s18-20.Marva示例：Hub：创建代表性内容表达为一个作品Hub。
  • s21-26.[二2]译本：个别
  • 官方RDA：译本不是新作品，而是原语言作品（代表性内容表达？）的内容表达；VES和SES条款不在官方RDA中，内容表达由AAP【规范检索点】识别；实体>内容表达>内容表达的首选题名preferred title of expression [原RDA内容表达没有首选题名]【原RDA使用作品题名+语种，现在用载体表现题名?】。
  • 长期实践/原RDA：译本不是新作品，而是原语言作品的内容表达；原语言作品和译本之间的关系是在规范检索点中固有的；记录语法【AAP构成】在原RDA中。
  • 解决方案：将原语言内容表达和译本之间的关系显示为显式链接[2种可用关系]：实体>内容表达>……的翻译translation of？实体>内容表达>内容表达的相关内容表达related expression of expression？s24-26.Marva示例：Hub[原语言/代表性内容表达]：Marai的Gyertyak csonkig egnek；作品[译本]：Marai的Embers[译本题名名为内容表达首选题名，不是AAP]；内容表达的相关内容表达：Marai的Gyertyak csonkig egnek。
  • s27-29.[三]代表性内容表达
  • 官方RDA：一种被认为是识别作品的标准canonical数据源的内容表达；可添加到作品描述中以标识“标准的”内容表达的特定元素。
  • 长期实践/原RDA：混淆作品与原语言内容表达；本体歧义。
  • 解决方案：代表性内容表达=Hub或超级作品；有助于解决由于缺少BIBFRAME内容表达实体而导致的建模差异。
  • s30-32.[四]BIBFRAME Hub/作品组官方RDA：有4个实体作品、内容表达、载体表现、单件【WEMI】；能在一个RDA书目描述中单独描述一部作品吗？
  • 长期实践/原RDA：BIBFRAME没有内容表达实体，所有RDA内容表达都是BIBFRAME作品；BIBFRAME不区分书目和规范（这是MARC的遗产吗？）
  • 解决方案：让BIBFRAME Hubs简化建模差异：BIBFRAME Hubs=作品，BIBFRAME Works=内容表达，BIBFRAME Instances=载体表现，BIBFRAME Items=单件；让MARC通过创建BIBFRAME作品作为书目记录来促进这一点【“作品”书目记录而非规范记录】
  • s33-34.下一步是什么？[视频略过未讲]
  • 用MARC以现状（当前编目政策）测试官方RDA；查看以MARC表达官方RDA数据的困难所在；在给定的情况下，BIBFRAME是否有更多的语义意义？试验在BIBFRAME场景中的官方RDA；以BIBFRAME测试官方RDA的这些新方面（以上内容）；游说这些变化，使其成为官方政策——如果它们奏效的话【有争议、未确定】；在RDA的粒度和BIBFRAME的灵活性之间取得平衡；与根本不熟悉MARC的编目员一起测试；你可能会想到其他的下一步——有很多！