RDA元数据指导文档(MGD):作品、内容表达(命名、新旧变化)

RDA元数据指导文档(MGD)是美国官方RDA政策声明(LC-PCC PS)的配套文件,为某些实体、属性与关系提供详细的说明与使用指导。

参见:

叙述性MGD共20个,去年写了如上2个,本篇概述另2个即作品和内容表达。关注新旧RDA的差异,以及这2个实体涉及的Nomen(命名)——新实体Nomen及属性没有专门的MGD文档。

——Nomen实体——

【定义】除Nomen本身外,任何RDA实体的标签,包括名称、题名、检索点或标识符。

主要是作为其他实体的取值/值域(range)而存在。在没有Nomen实体时,很多元素是其他实体的属性;有了Nomen,就成为其他实体与Nomen之间的关系。

Nomen作为实体,通常作为检索点,受某种规则约束,或者直接取值于某个数据库或受控词表。

【作品MGD中的Nomen】

作品的检索点、作品的规范检索点、作品的变异检索点,作品的题名、作品的首选题名、作品的变异题名,作品的标识符,作品的称谓,[连续出版物] 识别题名(key title)、ISSN,[音乐] 音乐数字标识(numeric designation)、音乐作品序号(serial number),作品编号(opus number)、作品号(thematic index number)。【不懂音乐,不知道中译名】

【内容表达MGD中的Nomen】

内容表达的检索点、内容表达的规范检索点、内容表达的变异检索点,内容表达的题名,内容表达的首选题名、内容表达的变异题名,内容表达的标识符。

——MGD:作品——

(除以下叙述性MGD,作品另有十多个一对一MGD,涉及作品的检索点、附注,以及学位论文信息、频率)

【定义】作品是一种抽象实体,被定义为“独特的智力或艺术创作,即智力或艺术内容”。

【组成类型】作品可以指单个作品、作品的一部分、集合作品、历时作品、元数据作品、连续[出版物]作品、单个作品或静态作品。

【内容类型】当作品按其预期内容或背景分类时,可称为制图作品、舞蹈作品、法律作品、动态图像作品、音乐作品、实物作品、官方通讯、摄影作品、宗教作品、静态图像作品、文本作品或声乐作品。

【新建记录】见“作品:实体边界”以获取RDA条款及LC-PCC PS,以确定是否正在描述新作品。【参见:RDA新章:实体边界(2020-10-3)https://catwizard.net/posts/20201003112901.html;RDA应用纲要和实体边界(2022-1-7)https://catwizard.net/posts/20220107170156.html

【属性和关系(略)】作品的元素(属性和关系),按值域排列,从命名、属性(即无值域元素)开始、再后其他实体,最后为描述元数据作品的元素(元数据作品附注、记录来源、有效范围、参考源)。含《描述性编目手册》(DCM)Z1名称和丛编规范记录,以及规范数据MARC 21格式的LC指南补充。不包括LC/PCC未使用元素;不包括集合作品、手稿、连续作品或丛编(有其他指导文件)。

【新旧RDA变化】(14条)

[1]原RDA:作品题名中可以省略首冠词

(RDA 6.2.1.7)。官方RDA:首冠词始终保留在作品题名中,但可以从作品检索点中删除。【不排序字符】

[2]原RDA:作品的其他区别特征是元素(RDA 6.6),可记录为单独的元素,或作为检索点的一部分,或两者。官方RDA:包括作为作品区别特征的标识是作品检索点中附加元素和标识的“选项”;区别特征可记录为作品附注。【可选+附注】

[3]原RDA:表演媒介(RDA 6.15)是作品属性。官方RDA:音乐内容的表演媒介是内容表达属性;代表性内容表达的音乐内容的表演媒介可以被记录为作品的属性。【音乐:作品属性->内容表达属性(代表性内容表达的属性=作品的属性)】

[4]原RDA:调key(RDA 6.17)是作品的属性。官方RDA:内容表达的调是内容表达的属性;代表性内容表达的调可以记录为作品的属性。【音乐:作品属性->内容表达属性】

[5]原RDA:管辖地(RDA 6.21.1.4)是作品的属性。在描述法律作品时,记录受另一司法管辖区颁布的法律、法规等管辖的司法管辖区(即团体)。官方RDA:管辖地是团体和地点之间的关系。在描述政府(即团体)时,记录该政府颁布的法律、法规等管辖的司法管辖区(即地点)。【属性变关系】

[6]原RDA:目标受众(RDA 7.7)是作品的属性。官方RDA:内容表达的目标受众是内容表达的属性;代表性内容表达的目标受众可被记录为作品的属性。 【作品属性->内容表达属性】

[7]原RDA:作品检索点没有通用元素。官方RDA:作品检索点的新元素,包括用于构建用于作品的规范检索点和用于作品的变异检索点的一般说明。

[8]原RDA:为作品(RDA 6.27)、音乐作品(RDA6.28)、法律作品(RDA6.2 9)、宗教作品(RDA6.30)和官方通信(RDA 6.31)构建检索点的具体说明。官方RDA:检索点是使用编目社区特有的字符串编码方案构建的;作品检索点的RDA元素包括基本说明;英美资源遗产指南位于资源>社区资源>社区细化>作品细化。【特定类型作品的检索点->社区资源

[9]原RDA:记录音乐作品(RDA 6.14)、法律作品(RDA6.19)、宗教作品(RDA6.23)和官方通讯(RDA6.26)的题名的具体说明。官方RDA:英美资源遗产指南位于资源>社区资源>社区细化>作品细化。【特定类型作品的题名->社区资源

[10]原RDA:ISSN(RDA 2.15)、ISSN系列(RDA 2.12.8)和ISSN子系列(RDA2.12.16)的单独元素作为载体表现属性。官方RDA:ISSN元素用于记录ISSN、系列ISSN和子系列ISSN,它是作品和命名之间的关系元素。【连续出版物:载体表现属性->作品和命名关系】

[11]原RDA: 频率(RDA 2.14)是载体表现的属性。官方RDA:频率是作品的属性。【连续出版物:载体表现属性->作品属性】

[12]原RDA:识别题名key title(RDA 2.3.9)是载体表现属性。官方RDA:识别题名是作品和命名之间的关系元素。【连续出版物:载体表现属性->作品和命名关系】

[13]原RDA:参考源(RDA 5.8、8.12、24.7、29.6)是属性元素,它引用了参考源、来源中的位置以及找到的信息的简短陈述。官方RDA:参考源是(元数据)作品和载体表现之间的关系元素;只记录载体表现的称谓或IRI。【属性->关系】

[14]以上未列出的其他元素,已从原RDA属性更改为官方RDA中关系元素。【更多:属性->关系(附注->检索点)】

【连续出版物说明(以上10-12):原RDA的载体表现属性,在官方RDA成为作品属性或作品与命名间关系,原因是《IFLA图书馆参考模型》(LRM)的WEM锁定,即“任何的连续作品都只有一个内容表达和一个载体表现。连续出版物之间的所有关系都可建模为作品和作品的关系”。参见:IFLA-LRM的连续性资源模型对RDA修订的影响(2018-6-29)https://catwizard.net/posts/20180629215026.html

——MGD:内容表达——

【定义】内容表达是以字母数字、音乐或舞蹈符号、声音、图像、物体、运动等形式或这些形式的任何组合,对作品进行智力或艺术实现。

【属性与关系(略)】先列与命名相关的元素,然后是与实体无关但由编目员转录或记录的属性元素,许多与特殊格式相关【不同的内容类型】,其后其他实体。

【代表性内容表达】目前LC/PCC尚未为代表性内容表达元素(为作品元素)制定任何政策。

【新RDA变化】(3条)

[1]原RDA:无对应。官方RDA:代表性内容表达。

[2]原RDA:无对应。官方RDA:集合内容表达。【参见上引:合集】

[3]原RDA:RDA17.10-17.12被载体表现的内容表达/示例化的载体表现。官方RDA:Expression manifested/Manifestation of expression(同),明确提及为“快捷方式”(Shortcuts,直接关联两个RDA实体而不记录中间实体或关系的关系元素)。

美国国会图书馆: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记录进行后续的下游修改。