RDA术语:元素超类型、上位元素以及超元素

德国斯图加特媒体大学的Heidrun Wiesenmüller教授是RDA-L邮件组最积极的提问者。她看RDA非常仔细,因为在参与编写德语社区RDA编目手册。7月14日她发邮件指出,RDA术语表中有“元素超类型 代:上位元素”【也有“上位元素 见 元素超类型”,以及“元素子类型 见 下位元素”等】,这说明应当使用术语“元素超类型”【或“元素子类型”】,但在RDA文本中两个术语却在不同位置同时使用。

  • 试查载体表现元素“声音特征”(sound characteristic):
  • 页面上部,预记录(Prerecording)说明:This element is an element supertype.
  • 页面最下,相关元素(Related Elements)列出:For narrower elements, see ……
  • Heidrun还说,在某些也有下位元素的页面(预记录部分)却没有如上这句。比如:creator person of work(难道是因为它既有上位元素、也有下位元素?)

有同行回应同时使用二个同义术语大概是“疏忽”,但一直没有RDA官方出来澄清。7月20日Heidrun忍不住吐槽官方是不是都在休假,终于RSC秘书Linda Barnhart出来回应:

  • 元素子类型(首选术语)=下位元素,元素超类型(首选术语)=下位元素
  • 另外实际上还有实体相对的:实体子类型=下位实体,实体超类型=上位实体
  • Linda并说明原因:大约一年前,RSC讨论了这个问题,这些交叉引用被添加了进来。 当时,该小组决定RDA应保留这“同一事物的两个名称”作为过渡方式——但该小组还认为,上位和下位应该在以后逐步淘汰,以支持一致(和首选)的术语。
  • 大概因为“超类型/子类型”是新名词,所以“添加”大家熟悉的“上位/下位”作为“过渡”,之后是要删除的。
  • Heidrun回应:更愿意保留“上位元素/下位元素”,这不仅更容易理解,而且还因为“元素超类型/元素子类型”有与“超元素/子元素”混淆的风险。
  • 杨百翰大学的Robert L. Maxwell表示赞同:没有理由用一个需要解释和讨论才能理解的新术语来代替一个众所周知的和得到理解的术语。
  • 我也持同样观点。
  • 综上所述,RDA中与元素有关的有三对术语:
  • 元素超类型/元素子类型 element supertype / element subtype(元素的上位类别/下位类别)
  • 上位元素/下位元素 broader element / narrower element(见上)
  • 超元素/子元素 super-element / sub-element
  • 超元素/子元素的术语表定义:
  • 超元素:从一个或多个子元素聚合数据值的元素(An element that aggregates data values from one or more sub-elements.)
  • 子元素:一种较大元素的组成部分,该较大元素从两个或多个元素聚合数据值。(An element that is a component of a larger element that aggregates data values from two or more elements.)
  • 比如:载体表现的超元素“出版说明”聚合子元素“出版地点”、“出版者名称”和“出版日期”。
  • Heidrun解释是整体/部分关系。

对于术语用词,她还有另外一个疑问:为什么一对拼写用连字符而另一对不用?看术语表里都作了互见,可见两种拼写在语言上都是正确的。

FRBR讨论组即将关闭

2017年《IFLA图书馆参考模型》(IFLA LRM)发布,取代FR(功能需求)系列,原“FRBR评审组”改名为“书目概念模型评审组”(BCM评审组)(Bibliographic Conceptual Models Review Group = BCM Review Group)。近日Christine Oliver(Chris Oliver)代表BCM评审组宣布,计划关闭FRBR邮件讨论组:

“IFLA 的 FRBR 评审组负责创建、监控和维护此讨论组。当 FRBR、FRAD 和 FRSAD 于 2017 年随着 IFLA LRM 的批准而过时之时,评审组更名为 BCM 评审组、即书目概念模型评审组。

“评审组在 2018 年和 2019 年的业务会议上讨论了 FRBR 讨论组。是否值得更改讨论组的名称?两次都一致决定终止讨论组,因为讨论组已经很多年没有有意义的活动了。近年来,在少数几次使用该讨论组的情况下,消息只是通常不是特别相关的公告,并且也在其他讨论组中发布。

“我们的结论是讨论组不再符合创建它的目的。这封电子邮件是为了让您知道该讨论组将很快结束。“关于国际图联书目概念模型的开发,评审组正计划扩大和改进其国际图联网站<https://www.ifla.org/bcm-rg>,这将是跟踪模型工作的更好方式。

“感谢您成为忠实的订阅者,尽管几乎没有活动。”

随后已由OCLC退休的Glenn Patton(曾任WorldCat质量管理主任)对Chris,以及邮件组开设者Patrick Le Boeuf 及Sophie Felfoldi表示感谢。

FRBR讨论组是IFLA(国际图联)众多邮件讨论组(Mailing lists service)https://mail.iflalists.org/wws/lists之一。我还保留着2005年5月16日订阅后收到的第一封邮件,当时用的是本馆邮箱(学校邮箱还没开设)。近十年讨论组很不活跃,除2016-2017年LRM发布前后略有讨论,基本上没什么实质性内容。关闭也可说是明智的选择吧。

退订访问网址:https://mail.iflalists.org/wws/info/frbr(想来不退订也没关系)

2021夏BIBFRAME更新论坛

自2012年起,美国国会图书馆(LC)每年在美国图书馆协会冬夏两次年会上召开BIBFRAME更新论坛。由于COVID-19,去年夏天开始都是虚拟会议,今夏6月28日召开。今年四个报告,比较罕见地没有OCLC、也没有厂商。报告已经上网:

BIBFRAME June 2021 Update Forum

一、BIBFRAME 100进展报告(Progress Report on BIBFRAME 100 / Sally McCallum, Library of Congress)

在今年仲冬会议上已经报告过BIBFRAME 100,即2021年起全部350名编目员将每周5天用BF编目,这里的100原本是100%的意思,不知为何现在的目标是成功达到80-90%编目员用BIBFRAME。

报告的第2部分是四个主要任务:

二、LD4P与社区:PCC数据池与LD4(LD4P and Community: The PCC Data Pool and LD4 / Philip Schreur, Stanford University,代表LD4社区;会议网站标题:Community and Data Pool)

报告首先用1张图示PCC数据池:编目员、[编辑器]Sinopia<->实体数据存储、OCLC-PCC编目,SHARE-VDE、SHARE-VDE簇&知识库、QASHARE-VDE缓存<-规范缓存。

其后介绍LD4社区,包括其原则、兴趣小组(发现、伦理、非拉丁文字、Sinopia、[应用]纲要、珍本资料、连续出版物、维基数据),以及将在2021/7/19-23在线召开的2021年LD4关联数据会议。会议主题包括:关联数据教育,包容不同的声音,采用关联数据的实用步骤,关联数据的可靠性和可用性,将关联数据纳入日常运营,关联数据宣传。

关于LD4可参见:关联数据编目走向现实——新项目LD4P3及LD4社区(2020-12-10)

三、BIBFRAME数据交换规划(BIBFRAME Data Exchange Planning / Melanie Wacker, Columbia University, Chair, Program for Cooperative Cataloging Policy Committee,代表PCC编目政策委员会)

主要介绍将于2021/9/9-10召开的PCC虚拟会议,议题是:在系统与实施之间交换BIBFRAME数据。参与者包括:PCC政策委员会(PoCo)、LC、欧洲BIBFRAME小组、OCLC、厂商、LD4、国家图书馆【有哪些?】等(含观察者)。

1、召开本次会议的原因有:

  • 1)BIBFRAME 100——LC正推动大多数编目员只做BIBFRAME
  • 2)PCC参与LD4/Sinopia
  • 3)数据池
  • 4)PCC元数据应用纲要将使用“BIBFRAME 作为初始基础数据模型”
  • 5)美国以外的BIBFRAME工作
  • 6)实施间的不一致会对系统之间的数据交换和跨数据源的查询产生负面影响。如:rdfs:label 与 rdf:value;bf 命名空间的扩展如 bflc, pmo, arm; LCSH 复杂主题标题的编码(如使用 MADS/RDF);bf:Agents建模使用来自 LC 名称规范档的规范 URI vs RWO URI,或者Wikidata;使用 URI 而不是空节点。

2、期望成果:

  • 1)生态系统和基础协议- 就 BIBFRAME 环境中数据交换的含义达成一致- 定义 BIBFRAME 交换的核心需求,如: 应该有一个标准化的序列化吗? 是否需要商定最低 BIBFRAME 描述? 如何建模/塑造 BIBFRAME 元素? 开发工具,包括验证技术;对发现层和用户体验的影响
  • 2)工作流程和工具- 确定需要在哪些系统之间共享哪些数据的用例和期望。随着更多图书馆和供应商进入该领域,这可能会发生变化;接收新数据的可接受频率是多少?如何鼓励*上游*更改以避免数据冲突?- 就何时、为何链出以及何时在本地复制数据和缓存的最佳实践达成一致- 测试交换的想法。开发系统之间共享数据的用例和计划,潜在有:Share-VDE、Sinopia、国家图书馆、LC、OCLC、需要的系统如ILS厂商。为测试制定粗略的实施时间表- 探讨成立国际BIBFRAME标准化与交换小组

四、BIBFRAME 2.1版及未来计划(Version 2.1; And future plans …. / Kevin Ford, Library of Congress,会议网站标题:BIBFRAME Vocabulary: An update and future plans)

概述BIBFRAME 2.1更新。然后回顾MARC更新史,包括内容、负责与参与机构、修订方式。对比BIBFRAME,现在并没有指导小组或咨询委员会,在GitHub以问题(ISSUE)方式提出建议、讨论……。

参见:BIBFRAME本体2.1版发布(4层确认)(2021-6-25)