2022年“RDA在欧洲”会议（附“合集”讨论）

2020年新冠疫情后，RDA在欧洲会议和EURIG年会就都改线上，原本今年11月的RDA在欧洲会议打算恢复线下，最终仍是虚拟会议，由西班牙国家图书馆承办。

本次会议有三部分：1、RDA实施进展；2、RSC年会和欧洲BIBFRAME研讨会概况；3、合集问题

【RDA实施进展（英国、德奥瑞、比利时）】

官方RDA工具包实施：不列颠图书馆现状（RDA Official Toolkit implementation: British Library Update / Alan Danskin）

不列颠图书馆（BL）：2022年10-12月准备文档，政策声明配套《RDA编目指引》【当对应美国《元数据指导文档》】。计划2023年1-2月测试，3月这是，4-5月准备培训资料，6-7月培训。参见：RDA元数据指导文档（MGD）：掌握新RDA（2022-9-10）

新官方RDA工具包及其在德奥瑞的实施（The new official RDA Toolkit and it’s Implementation in DACH / Renate Behrens, Barbara Pfeifer ）

《德国奥地利瑞士（DACH）3R手册》2019年3月-2022年12月开发中，出版后免费提供；计划2023年5月开始培训，首先针对具有编目经验者，未来将设计针对初学者培训。

以上两家计划都止于培训，没有提及实施时间。

RDA在比利时皇家图书馆（RDA at KBR: From roots to … / Hannes Lowagie）

比利时皇家图书馆（KBR）已在实施，其方法值得关注。首先是创建1个中心网页“编目指南”，如手册，收集所有新指南。然后在编目界面嵌入实时检查，验证并提示错误、解释新规则（问答阶段说明用XSLT，似乎是通过Z39.50）。

各国基本立场是尽可能不影响现行实践。如BL暂不实施代表性内容表达。如DACH手册：某些尚未在实践中得到证明的规则被更改或撤销；新RDA概念可以在经过更好的审查后在稍后时间采用。相对而言，比利时比较积极，所谓“与传统决裂”，但在ISBD不与RDA指引冲突时仍保留，尽可能顺利过渡。比利时是多语言国家（荷兰语50%、法语50%、德语），在取消拉丁语缩写以后，需要特别重视编目语言040$b的规则。【不知道加拿大如何处理英法双语问题？】

【合集（Aggregates）（德法美专家观点，RSC合集工作组示例与回应）】

苹果、胶水和奥卡姆剃刀：合集理论的批判性审视（Of apples, glue, and Occamʼs razor – A critical look at the theory of aggregates / Heidrun Wiesenmüller）

德国斯图加特媒体大学教授Heidrun是RDA-L邮件组的热心参与者。本报告探讨2011年IFLA合集工作组最终报告【链接见后】中的2个模型，认为应调整附录B替代方法，将其作为描述合集的基础。回应阶段，前RSC合集工作组主席Deborah Fritz对报告提及的问题作了详细解释。

合集是《IFLA图书馆参考模型》（LRM）新概念，新RDA采用。合集包括增强、汇编、并列3种，是以现有类别新增的上位概念。如合订、文集、期刊等，虽然都归入合集概念，实际上做法各异。这也就是为什么报告标题引“奥卡姆剃刀”即“若无必要，勿增实体”吧。

我们面前的道路：RDA和合集的法国分析（The Road Ahead of Us – the French Analysis of RDA and Aggregates /Mélanie Roche）

法国国家图书馆（BnF）提出现行合集存在的问题，法国编目规则的做法，以及该馆未来元数据生产工具NOEMI中，对合集的3种灵活处理个案。

最后的结论很法国：合集不是唯一不同意点；继续通过EURIG与RSC合作；通过模型达成互操作。

RDA、LRM和合集：实用性和理想（RDA, LRM, and Aggregates – Practicalities and Aspirations / Paul Frank）

美国国会图书馆（LC）表示依据PCC合集专责组报告【链接见后】，不影响现有编目实践，向前兼容。以BIBFRAME示例对全集、合集译本的处理。未来考虑BF Hub/作品组，正在测试Hub/Opus互操作。

参见美国做法：RDA元数据指导文档（MGD）：合集（2022-9-14）

RSC合集工作组示例（与回应）

[一]描述集合或被集合作品和内容表达（Describing Aggregating or Aggregated Works and Expressions, or Both / Deborah Fritz 前RSC合集工作组主席）

以不同类别示例，说明描述集合作品(aggregating work)的优点。

[二]RDA中合集：翻译和整体-部分结构（Aggregates in RDA: Translations and whole-part structures  / Gordon Dunsire前RSC主席）

值得记取的3点：[1]翻译的合集，不是：合集的翻译（即使整本翻译，也是其中单个作品的翻译）[2]整体和部分：载体表现包含某些但非全部内容表达部分=合集（如3集指环王中的2集），载体表现包含所有且仅内容表达部分即内容表达整体=非合集（如全部3集指环王[这时整体不是合集，但期刊、全集是！]）[3]聚集结构的差异化提供更多的控制和选择，以满足当地需求（对合集可以采用不同粒度处理方法）

[四]用RDA处理歌曲集（Treatment(s) of Songbooks in RDA: Using the Tools of the Toolkit / Damian Iseminger RSC技术团队联络官）

参考（Heidrun Wiesenmüller提供）：

参见：

MARC记录中使用ISO 639-3语言代码指南（PCC）

合作编目计划（PCC）日前发布《MARC记录中使用ISO 639-3语言代码指南》。

目前MARC（包括CNMARC）所用语言代码为ISO 639-2，ISO 639-3是在其基础上扩展的，含近8千个语言代码（也是3字母）。

PCC提出在书目和规范记录中使用ISO 639-3进行编码，目的是为用户提供更准确精细的语言信息，特别是对于土著语言、手语、历史语言和人工语言，以及更好地识别某些语言（如汉语和阿拉伯语）的视听资料记录中的口语或歌唱语言。

需要说明的是， ISO 639-2实际上由两个标准组成：ISO 639-2/B（书目，MARC所用语言代码）和ISO 639-2/T（术语）。两者涵盖相同的语言，但在某些情况下代码不同，而ISO 639-3使用ISO 639-2/T代码。

指南规定继续使用MARC语言代码进行编目（书目记录008/35-37及041字段），只在找不到具体代码的情况下，选用附加的041字段记录ISO 639-3语言代码。无论代码是否相同，只要使用ISO 639-3代码没有增加有关资源语言的附加信息，就无需使用ISO 639-3代码创建041字段。如果有多种语言，找不到MARC语言代码但有ISO 639-3代码，则只做ISO 639-3编码的041字段。

未来可能会开发宏或其他自动化手段，由ISO 639-3语言编码生成ISO 639-2语言代码字段，从而避免重复编码。

指南规定，对于ISO 639-3中认为的宏语言（语言家族），应尽可能使用最具体的代码。以汉语为例，其标准书面语使用代码cmn（普通话/国语），不用对应MARC代码chi的宏语言代码zho（汉语）。示例5.4. 粤语影音资料：

008/35-37 (Lang): chi
041 1# $a chi $j chi $j eng $h chi（中文对话，中英双语字幕，译自中文）
041 17 $a yue $a cmn $j cmn $j eng $h yue $2 iso639-3（粤语、普通话对话，普通话、英语字幕，译自粤语）
245 00 $a 少林足球 = $b Shaolin soccer / $c 寰宇娛樂有限公司 ; 星輝海外有限公司 ; 編劇周星馳, 曾 謹昌 ; 監製楊國輝 ; 周星馳導演.
245 00 $a Shao lin zu qiu = $b Shaolin soccer / $c Huan yu yu le you xian gong si ; Xing hui hai wai you xian gong si ; bian ju Zhou Xingchi, Zeng Jinchang ; jian zhi Yang Guohui ; Zhou Xingchi dao yan.
546 ## $a In Chinese (Cantonese or Mandarin) with optional subtitles in traditional Chinese, simplified Chinese or English.【中文（粤语或普通话），可选繁体中文、简体中文或英文字幕。】

Guidelines for the use of ISO 639-3 language codes in MARC records (Approved Nov. 22, 2022; last revised: Nov. 30, 2022)

MARC记录中使用ISO 639-3语言代码指南（目次）

[一] 如何录入
[1] 书目记录：041字段语言代码
示例  041 07 $a fra $a gsl $2 iso639-3【字段第2指示符=7=来源由$2说明，子字段$2来源代码=iso639-3】
[2] 规范记录：377字段相关语言
示例  377 #7 $a leh $2 iso639-3
[二] 哪里找代码
[三] 宏语言
[四] 历史语言
[五] 示例
1. ISO 639-3为与资源相关的所有语言添加新信息【强烈建议添加】
2. ISO 639-3为与资源相关的某些语言添加新信息【强烈建议添加】
3. 与资源相关语言的ISO 639-3和MARC语言代码等效【不需要手动添加】
4. 无法确定与资源相关的至少一种语言的ISO 639-3语言代码【使用und表示未知；如果所有语言均未知，可不做】
5. 宏语言中的语言【首选具体代码而非宏语言代码】
附录：ISO 639-3和MARC语言代码（ISO 639-2/B）的不同
代码不同含意无不同【如汉语chi为zho，藏语tib为bod】
其他历史语言【有更多历史语言】
其他类型语言的附加代码【手语、人工语、古语言、已灭绝语言】
宏语言【如汉语宏语言zho与16种语言相关】
集合语言【ISO 639-3无等效代码，如凯尔特语（其他）cel，比亚语nub】
特殊代码【与MARC语言代码相同：mis（混杂语言）mul（多语言[6种以上]）und（不确定）zxx（内容无语言）】

—— ISO 639-3 汉语代码 ——

指南提供了几个ISO 639-3代码来源，其中官方维护者SIL：https://iso639-3.sil.org/code_tables/639/data，缺点是没有语言名称的交叉引用（即异名参照）。

网站的ISO 639-3宏语言映射列表（ISO 639-3 Macrolanguage Mappings）https://iso639-3.sil.org/code_tables/macrolanguage_mappings/read，其中汉语列出16种（见下，除手语、洋泾滨英语外的15种在用语+文言文）。文言文lzh之外另有古汉语och，猜想或许用于甲骨文、金文之类的古文字。

附：在SIL查chinese结果近20个。显然不完整，但闽语、粤语分得特别细。大致按地域分类重排如下：

  • Collective+Genetic 集合【ISO 639-3无集合语言代码】

（639-5: zhx），Chinese (family)    

  • Macrolanguage+Living 宏语言+在用

zho（639-2/T: zho，639-2/B: chi，639-1: zh），Chinese【汉语】

  • Individual+Living 单个+在用
cmn，Mandarin Chinese【普通话/国语】
csl，Chinese Sign Language【中文手语】
cpi，Chinese Pidgin English【洋泾浜英语】
cjy，Jinyu Chinese【晋语】
czh，Huizhou Chinese【徽州话】
wuu，Wu Chinese【吴语】
gan，Gan Chinese【赣语】
hsn，Xiang Chinese【湘语】
hak，Hakka Chinese【客家话】
cdo，Min Dong Chinese【闽东话】
nan，Min Nan Chinese【闽南话】
cpx，Pu-Xian Chinese【莆仙话】
mnp，Min Bei Chinese【闽北话】
czo，Min Zhong Chinese【闽中话】
yue，Yue Chinese【粤语】
csp，Southern Ping Chinese, Southern Pinghua【桂南平话】
cnp，Northern Ping Chinese, Northern Ping Chingese, Northern Pinghua【桂北平话】
  • Individual+Ancient 单个+古代

och，Old Chinese【古汉语】

  • Individual+Historical 单个+历史
ltc，Late Middle Chinese【中古汉语】
lzh，Literary Chinese【文言文】

扩展都柏林核心：学术资源应用纲要（DC-SRAP）

2021年初，芬兰国家图书馆（NLF）提出为描述学术资源而扩展都柏林核心（DC），开发“学术资源应用纲要”（SRAP或DC-SRAP）。

NLF的理由是：DC常用于描述学位论文和高等教育机构的其他资源，用于存储并通过其机构存储库提供。但DC元数据术语本身不包含对这些资料进行简单描述所需的所有核心元数据元素，因此出现了不同的本地扩展。由此产生的负面影响包括：为相同目的开发多个模型所涉及的重复工作，工具（编目和搜索、指南）需要额外的开发工作，减少了使用不同模型创建的元数据之间的语义互操作性，DC元数据术语的实用性降低。为使DC成为一个更有价值的工具，促进DC用于学术著作的描述，NLF建议开发学术资源应用纲要（SRAP）。NLF认为，采用SRAP不仅将使DCMI元数据术语的扩展能够利用新增属性，完善许多现有属性的语义，而且还能减少开发其他本地学术著作的需求（Scholarly resources and Dublin Core, 2021-1-8）。建议并附上了SRAP草案（目前是2021-07-19的版本0.76）【访问Google文档】

SRAP主要开发者是2位NLF的DCMI成员Juha Hakala和Osma Suominen。日前在GitHub上放出了新的SRAP草案：

都柏林核心元数据倡议学术资源应用纲要（2022-10-6 草案）

Dublin Core Metadata Initiative Scholarly Resources Application Profile (SRAP) (Draft 2022-10-06)

当前版本针对学术论文、学位论文等，暂不包括研究数据，但有相关代码、相关数据集等属性。学术论文，增加了编者、资助者、资助号，发布状态（公开草案、预印本、印后本、出版、更新出版）及相关日期（如手稿收到日期、撤回日期等），呈现于（会议）等；学位论文，增加了隶属关系、导师、评审者、答辩主持人等。

新增属性除扩展DC外，还有来自现有词表：

Affiliation 隶属关系，schema.org属性：https://schema.org/affiliation

Date retracted 撤回日期，Fabio元数据术语：http://purl.org/spar/fabio/hasRetractionDate

以及MARC21关系词（MARC relator）：

Editor 编者：https://id.loc.gov/vocabulary/relators/edt

Funder 资助者：https://id.loc.gov/vocabulary/relators/fnd

Degree supervisor 学位导师：http://id.loc.gov/vocabulary/relators/dgs

Opponent 评审者：http://id.loc.gov/vocabulary/relators/opn

Praeses 主持人/答辩主席：http://id.loc.gov/vocabulary/relators/pra

然而，美国国会图书馆（LC）的MARC 21关系词属于责任者（creator / contributor）的角色，在定义上是SKOS概念（名词）、用于取值（宾语），并非属性（动词、谓语）。Karen Coyle在BIBFRAME邮件组提出“LC关系词作为属性”的问题（LoC Relators as Properties），其中特别提到RDA将关系词定义为“行为者”属性【新RDA将原“关系说明语”改为“属性”】，瑞典国家图书馆也基于LC关系词创建相应的属性列表。从讨论看，大家都赞同将关系词作为属性；但LC在BIBFRAME实现中仍使用关系词作为角色概念。

[update 2022-12-5] LC的Kevin Ford于12月2日在邮件组中回复，说明LC同时声明关系词为取值和属性，但属性声明由于不明原因删除，现已恢复。

对回复邮件的理解后简述如下（含个人理解，不保证符合原意）：

约2017年，LC和DCMI把[行为者]关系词映射到dc:contributor[作为下位属性]。2010年LC发布关联数据服务ID.loc.gov，关系词同时发布为取值[MADS规范+SKOS概念]与属性[RDF+OWL]，但不知何时属性声明被误删、现已恢复。LC作过测试，认为既作为名词[主语/宾语=取值]也作为动词[谓语=属性]没有问题。BF的关系词由1.0属性到2.x变为对象（间接方法），主要原因是可以对关系做更多陈述，如同schema.org引入角色[作为对象]（可以连接不同属性）。对于LC双重定义的资源，[是作为取值还是作为属性]，社区可以各取所需。