扩展都柏林核心:学术资源应用纲要(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双重定义的资源,[是作为取值还是作为属性],社区可以各取所需。

RDA社区资源计划(2022-10-17)

那天看《RSC行动计划2022-2024》(参见2022-10-16博文),发现前几年的计划中,各年均有“支持社区开发社区资源”,现仅2022年有“继续审查社区资源区域并将决策传达给用户”,以为后续各年对社区资源关注度下降。

今天看到RDA-L邮件组推送《社区资源计划》,原来反而是准备扩大社区资源的贡献范围。按计划贡献团体分成二级:一级可以直接在RDA的内容管理系统中发布内容,包括目前已经在制作政策声明、翻译RDA文本的团体;其他有兴趣的团体可以联系出版方协商相关协议,并有可能收取一次性费用。这部分内容应该更多由提供者自我审核。另一级未来使用工具包的HTML编辑器创建CR内容,没有相关费用,内容需要得到RSC批准。

RDA社区资源包括社区细化社区词表,其内容在新RDA发布后有过调整,目前英文版社区资源包括从RDA正文和附录中移出内容:1、缩写、大写、人名附加(包括头衔),入相应语言;2、构建各种字符串的原工具包中遗留的英美条款(如法律作品、音乐作品、官方通信和宗教作品的规范检索点),入英语。

本文件还对社区资源的目标和要求、质量控制、在工具包中的显示等作出了说明。全文翻译如下:

社区资源计划 Community Resources Plan / [By James Hennelly, Director of ALA Digital Reference]. 2022-10-17

在与RSC讨论RDA工具包的社区资源(CR)区域后,制定以下计划,以解决CR结构和服务。

CR目标和要求

RDA工具包中的CR区域包含符合RDA标准的内容,但仅针对社区而非国际范围。源于RSC的决定,原RDA的某些部分(与字符串编码方案相关的条款,与缩写、大写和人名相关的附录,以及某些检索点条款)针对特定的社区实践,而不是更广泛的国际需求。

工具包英文版中的社区资源区域的初始内容包括缩写、大写、人名附加以及原RDA附录中的头衔术语的解构条款。这些已被重新构建为基于特定语言的术语页面。此外,截至2021年4月发布,用于构建各种字符串的原工具包中遗留的英美条款(如法律作品、音乐作品、官方通信和宗教作品的规范检索点)被迁移到该地区。

未来,RSC和RDA工具包的出版商正在寻求向更多的群体开放社区资源空间。以下是我们在CR空间的目标——

  • CR应可用于RDA工具包订户的所有感兴趣的社区。
  • CR应充分利用现有工具包技术和能力。
  • RSC和工具包出版商将监督CR开发,包括分配管理角色,并为贡献社区和合格内容制定指南。
  • CR贡献者将负责内容的开发和维护。
  • CR贡献者必须清楚地确定内容的作者,并声明它不是官方RDA。
  • CR内容将是可搜索的,并且在搜索结果中很容易识别为CR内容。
  • CR更新将顺应RDA工具包发布时间表。

CR层级

已经可以访问工具包内容管理系统(CMS)的参与者将能够在该系统中创建CR内容,这包括通过翻译和政策声明协议访问的团体。对这一访问级别感兴趣的团体应联系James Hennelly,以协商此类协议(此选项可能会收取一次性费用)。

无法访问CMS且对协议不感兴趣的团体可以使用工具包的HTML编辑器创建可添加到CR浏览和搜索中的CR内容。此选项没有与之相关的费用,但贡献者和贡献内容必须得到RSC批准才能纳入CR。

CR质量控制

  • 必须管理发布CR文档的能力,以确保只有服务于可识别的RDA社区的适当内容托管在此区域。
  • RSC仍然需要制定在这种情况下识别社区的指南。
  • 在可能的情况下,RDA地区委员会将负责确定应纳入CR空间的团体。
  • 如果没有区域委员会,RDA开发团队和广泛社区参与官将审查为CR空间做出贡献的请求。
  • 期望CR内容符合RDA指南和条款。
  • CR贡献预计将达到工具包相同的无障碍标准(AA)。

CR显示

  • CR空间将继续像当前一样在“资源”选项卡中访问。项卡中访问。
  • CR将按主题组织,然后按作者组(见下面的模型)。【注:与目前显示不同】
    • Community refinements
      • > British library
      • > Kansalliskirjasto
      • > Library of Congress
      • > Music Library Association
      • > OTHER DOCUMENTS
    • Community vocabularies
      • > British library
      • > Kansalliskirjasto
      • > Library of Congress
      • > Music Library Association
      • > OTHER DOCUMENTS
    • “其他文档”将链接到一个登陆页面,该页面将包括在 HTML 文档编辑器中创建的文档。(请参阅下面的着陆页模型。)
      • OTHER DOCUMENTS
        • Group A
          • > Document 1
          • > Document 2
          • > Document 3
        • Group B
          • > Document 1
          • > Document 2
        • Group C
          • > Document 1
          • > Document 2

现有的英文CR

当前的英文CR内容是来自 RDA 的遗留内容。因此,RSC 不会对其进行更新。期望一个代表英语社区的团体能够掌握当前的 CR 内容并管理其未来的发展。在 RSC 确定并批准这样的团体之前,RDA 工具包中的内容将保持不变。

CR开发

CR区域的发展需要一些时间。具有 CMS 访问权限的人员(翻译和政策声明编写者)在准备好提供 CR 文档时几乎可以立即开始。对于那些希望使用 HTML 编辑器做出贡献的团体,可能需要几个月的时间来实现生成“其他文档”页面所需的特殊标记和筛选。随着 CR 空间的发展,我们将监控用户反馈以确定未来的开发项目。

美国为实施官方RDA做最后准备:PCC RDA测试

美国合作编目项目(PCC)在2022年1月完成《元数据指导文档》(MGD)后,成立测试官方RDA工具包专责组,主要测试配套文档LC-PCC PS(政策声明)和MGD及其使用,可认为是为实施新RDA(现通称官方RDA)做最后准备。

测试官方RDA工具包专责组(Task Group to Test the Official RDA Toolkit

  • 专责组职责:
  • PCC测试官方RDA工具包专责组将对官方RDA工具包进行彻底测试,以确保PCC编目员可以使用该工具包以MARC和BIBFRAME的不同格式准确编目资料。我们不测试是否会实施官方RDA工具包。相反,我们希望在实施前,确保PCC政策声明和元数据指导文档在新的工具包中运行良好。因此,测试将包括在编目资料时使用工具包、相关LC/PCC政策声明以及元数据指导文档。专责组将定义此测试的参数,组织一批志愿者编目员进行测试,并评估测试结果。
  • 交付成果:
    • 定义测试回答问题的参数,例如:每个编目员应完成多少条记录;应涵盖哪些格式【资料类型】;应该涵盖哪些语言/文字等。
    • 从响应PCC邮件组征召的志愿者名单中组成一个小组进行测试。
    • 进行测试,记录遇到的任何问题。
    • 组成一个小组,评估编写政策声明和元数据指导文档的人员完成的编目。【!】
    • 确保评估者小组审查完成的编目,以确保应用了正确的政策声明和元数据指导文件。
    • 确保政策声明和元数据指导文档与官方RDA工具包中的相应条件或选项相关联,并且政策声明和元数据指导文件不相互冲突。
    • 确保当在多个政策声明或元数据指导文件中给出相同的指导时,指导和说明不相互冲突,编目结果相同。
    • 向LC、PoCo【PCC政策委员会】和RDA沟通委员会报告任何问题。

2月1日小组成立时的时间表是:7/8月提交初步报告,10月提交最终报告。实际上工作推迟约有半年。昨日小组发布消息开始进行评估,最终报告预计将于2023年春季发布。

消息中共享了完整的评估文档,有助于未参与测试与评估者了解评估设计及其内容,对其他国家开展基于本国实施RDA配套资料的评估也有参考价值。

PCC测试官方RDA工具包开始(RDA-L: PCC Test of the Official RDA Toolkit Begins / Adam Baron. 2022-10-17)

  • 测试将在10月17日至11月4日之间进行,评估将在2022年11月14日至2023年1月6日之间进行。工作组的最终报告预计将于2023年春季发布。
  • 为进行测试,要求测试人员使用官方RDA工具包、LC-PCC政策声明和元数据指导文档,以MARC或BIBFRAME中创建6-8个书目记录和至少1个规范记录(如果接受过NACO培训)。测试人员要记录他们为描述这些项目【资料】所采取的步骤以及遇到的困难,以确定哪些政策【PS】和指导【MGD】需要修订。
  • 为进行评估,评估人员将审查书目和规范记录,分析测试者模板,并在政策和指南需要更新的地方以及培训期间可能需要额外关注的方面编写意见。
  • 为协助测试,提供以下文档:
    • 测试人员文档,包括:测试人员指引、测试人员模板(空)、测试人员模板(样本)、测试人员测试后调查
      • 【测试人员模板为电子表格,9栏分别是:RDA元素[如title proper],MARC字段/子字段或BIBFRAME属性[如245$a],取值[如Music matters],所用RDA条款[如预记录Prerecording],[RDA] URI,所用LC-PCC PS[如LC/PCC Core.],所用MGD、MGD URL,附注/遇到问题】
    • 评估人员文档,包括:评估人员指引、评估人员模板(空)、测试人员模板(含错误、样本)、评估人员模板(样本)、评估人员测试后调查
      • 【评估人员模板为电子表格,13栏分别是:记录ID,格式[如图书/印本],MARC或BIBFRAME,记录的RDA元素[如title proper],RDA实体/指引/社区资源,参引的RDA页[如title of manifestation],RDA条款,[RDA] URI,问题类型[如LC-PCC PS],对LC-PCC PS的意见,对MGD的意见,MGD URL,概括意见】

【联想】从测试人员(编目)模板看,要记录用到的每个MARC字段、子字段(或者BIBFRAME元素)对应的RDA条款、涉及的PS及MGD,相当细致。测试要求创建6-8个书目记录和至少1个规范记录,按《测试人员指引》的说法需要高达45小时时间,也就是一个工作日完成1个记录。