mg电子注册秒到体验金_Welcome

  • <p id="teghe"><label id="teghe"></label></p>
  • <pre id="teghe"></pre>
    <track id="teghe"></track>

    <acronym id="teghe"><label id="teghe"></label></acronym>

    Logo

    目录    上一章节: 3 解析    下一章节: 5 应用

     

    4 数据模型

     

    本章节介绍 DOI® 系统第二个主要技术组件的基本信息——DOI ® 数据模型。数据模型能够保证通过现有元数据方案分配的 DOI 号元数据具有互操作性。本章首先对该系统进行概述,之后在各小节中分别阐述了: DOI 数据模型政策目标、互操作性和良好的管理机制、元数据系统的三个工具、核心元数据、以及数据字典和用于元数据交换的方案。阅读本章节时,建议读者参考术语表

    © 国际数字对象标识符 (DOI) 基金会  ?   中文版最后更新:2017 年 9 月

     

    4.1 DOI® 数据模型概述
    4.2 DOI 数据模型政策目标
          4.2.1 互操作性
          4.2.2 管理性能
    4.3 DOI 元数据
          4.3.1 DOI® 元数据核心
          4.3.2 使用 DOI 核心
          4.3.3 管理 DOI 元数据方案的流程
                4.3.3.1 向核心受控词典添加值
                4.3.3.2 更新流程
          4.3.3 管理 DOI 元数据方案的流程
          4.3.4 DOI 数据字典
          4.3.5 词表映射框架
          4.3.6 元数据整合:IDF 的目标
    4.4 ISO 26324 中的元数据要求
    4.5 底层本体

     

    4.1 DOI® 数据模型概述

    离开元数据,标识符几乎没有价值。元数据在本文中可定义为有关被标识所指对象的信息。通过为人类或机器提供元数据,使其可以利用被标识的所指对象。元数据可以包括编号、标识符、描述、类型、分类、地点、时间、尺寸、关系和任何类型与所指对象相关的信息。

    各个 IDF 注册机构通过两种方式与元数据产生关系。第一,RA 将从所指对象提供者(通常为该所指对象的描述以及相关权利与政策)收集输入的元数据;第二,RA 将提供某个层面的输出或服务元数据以支持 DOI 系统服务。输入元数据将提供一些、但不一定是所有的服务元数据。在某些情况下,一个元数据声明的本身即为一个完整的 DOI 系统服务(例如,“为该所指对象提供一个 ONIX 产品信息”)。图 1 展示了元数据声明的两个流程 。

    Figure 1: Flows of metadata in and out of an RA

    图4-1: RA 网络中元数据声明流程

    DOI 系统的政策未对 RA 的输入与服务元数据声明作格式和内容上的限制,但其输入元数据必须支持 DOI 核心(见下文)的最低要求。RA 可以指定自己的元数据方案和消息,也可以全部或部分地使用现有方案,作为其输入与服务元数据声明。

    DOI 数据模型政策关注“RA 网络”中的内部管理和 RA 之间的元数据交换。其设计目标有二:

    1. 促进 DOI 系统用户网络的互操作性
    2. 确保注册机构对 DOI 号的管理达到最低质量标准,从整体上促进 DOI 系统管理。

    DOI 数据模型使用三种工具来支持其元数据政策:

    1. DOI® 核心元数据声明
    2. RA 之间数据交换的 DOI® 所指对象元数据声明方案
    3. 数据字典 (“DD”)

    RA 责任可以概括为以下三个方面:

    1. RA 须能够为每个分配的 DOI 号生成一个核心元数据声明。
    2. RA 之间的元数据交换需支持 DOI 系统服务,所指对象或服务类型的交换应当使用约定的 DOI 所指对象元数据声明“RMD”)。
    3. RA 在核心与所指对象元数据声明中使用的专有术语(数据元素和值)应在 IDF 的数据字典 (“DD”) 中进行注册。

    上述责任并不强制针对所有的 DOI 号,后面的章节将讨论有关互操作性的要求。

     

    4.2 DOI 数据模型政策目标

     

    4.2.1 互操作性

    DOI 数据模型政策的首要目标是促进 DOI 号用户网络内的互操作性。为实现这一目的,采取了一系列实现不同 RA 之间“语义兼容”的方法。本章节对此进行阐述。会员可以查看有关互操作性的 IDF 战略文件 。

    任何形式的标准化都需要考虑其互操作性。如果 RA 为所指对象分配用于私有域名的 DOI 号,以便管理所有元数据的采集和输出,则就没有必要进行标准化或履行与 DOI 数据模型保持一致的义务。RA 将公开其方案和声明,以供其供应商和用户遵循。这种情况被称为 DOI 系统的限制性使用 ,仅适用与某机构成为 RA 以后,为实现其特定目的,分配仅在其个人机构中使用的 DOI 号。

    然而,这种独立使用的情况是不常见的。通常情况下,当 DOI 号分配给所指对象后,便假定其具有互操作性: RA 或所指对象的提供者可能希望(现在或将来)DOI 号应可用于其他 RA 提供的服务 。例如,当一些 RA 正在为不同出版社的期刊文章分配 DOI 号时,这些 RA 和出版社可能希望其他 RA 提供的期刊类服务也能包含他们的 DOI 号。

    同样,许多 RA 也希望其服务可以包含其他 RA 分配的 DOI 号。这种互操作性即为 DOI 系统的主要优点之一。

    随着 RA 网络的发展,这种需求不断涌现,而所期望的机遇尚未出现。在这种情况下,无论是 RA,还是所指对象的提供者,都不希望为所指对象指定第二个 DOI 号,也不希望重新从源头提供或获取输入元数据。

    此外,未来一些 DOI 系统服务不会直接对 RA 负责。任何使用不同应用下不同 RA 分配的 DOI 号的服务提供者,都将面临元数据互操作性的问题。

    任何计划实施互操作性的 DOI 号——即可能在分配该编号的 RA 的直接控之外的服务中使用的 DOI 号——都符合 DOI 数据模型政策。实现元数据互操作性的目的有二:

    1. 确保不同 RA 持有的元数据不会功能不一致,及
    2. 确保不同 RA(未来可能是其他服务提供者) 之间能够以高效和可扩展的交互方式传输元数据。

    第一个目标通过 DOI 核心实现,第二个目标通过 RMD 和 DD 提供的交互功能实现。

     

    4.2.2 管理性能

    DOI 数据模型政策的第二个目标是“确保注册机构对 DOI 号的管理达到最低质量标准,从整体上促进 DOI 系统管理。” 该目标也可视为支撑互操作性的第一个目标,但其专门针对确保未来的 RA 能够尽到分配 DOI 号的责任,避免有歧义的 DOI 号进入网络。

    该政策提供了一个测试 RA 能力的简单测试:进行 DOI 核心声明的能力要求 RA 拥有一个支持分配无歧义的 DOI 号的内部系统,其基本要求即为能够很好地在网络中支持互操作性。此外,数据模型政策要求 RA 维护一份记录,用于记载 DOI 号的分配日期,以及 DOI 号分配给的注册者身份。

    DOI 系统数据模型政策同时也支持从整体上促进 DOI 系统管理机制的进一步开发。这是有可能实现的,例如,通过使用数据字典中注册为类型的条目,以及通过对 DOI 号、服务或应用配置文件进行分类。

     

    4.3 DOI 元数据

    一个单独的标识符(如一个 DOI)如果没有相关的元数据对其进行描述,是没有价值的。DOI 对于元数据的方法包含两个方面:第一,由 XML 方案支持,DOI 标准规定了一个特定的最小元数据集(“核心”元数据),用来描述 DOI 号的所指对象;第二,推进互操作性并协助 RA 创建自己的方案。IDF 提供了该核心使用的数据字典和全部条目的本体,以及注册机构注册的其他条目,并提供了名为“词表映射框架”的映射工具。本节将对这些资源进行阐述。

     

    4.3.1 DOI 核心元数据

    “DOI 核心”是一个最小元数据集,其目的有二: 识别互操作性

    本文中,“识别”指该核心元数据应足以清楚地表明 DOI 所指对象为何物(通过各种不同的分类),并允许用户合理准确地识别特定的内容(通过各种编号、标识符和关系)。这两点是相辅相成的,(例如)可以在不知道“卡萨布兰卡”的情况下知道这是电影或 DVD,反之亦然。识别出于发现所指对象的需要,同时也为用户提供发现所指对象的时间以及性质(有意或意外)。元数据的用户可以是人或机器。该核心的的结构通常但不总足以为一个所指对象提供独特的描述(“消歧”)。在某些情况下可能还需要专门的元数据元素。事实上,通常要为 referentName 添加附加描述文本,才能实现描述的唯一性。但这个方法并不令人满意,如果附加文本用于正式分类、尺寸、标识符、时间或其他结构化的语境元数据,则会破坏第二个目标互操作性。

    本文中,“互操作性”是指可以使用相同的软件组合或查询不同 DOI 注册机构的核心元数据,而无需语义映射或变换。当不同元数据方案中的数据元素及其值一致时,互操作性便得以实现。该核心通过强制使用共同的核心元素集和分类直接实现,当然仅支持有限的互操作性。

    DOI 号的分配要求注册者提供用于描述被分配 DOI 号对象的元数据。这些元数据至少应包含一个 DOI 核心元数据声明(又称 DOI 核心)。由 IDF (ISO 26324 注册中心)维护数据元素(包含子元素、基数等)、当前允许值和 XML 表达的规范。

    表 4.1 和 4.2 描述了 DOI 核心元素(这两张表格基于 ISO 26324 中的表 B.1 和 B.2制定)。注意:下面的表格可能包含 ISO 26324 以外的条款,但仅限于可以注册新项目的开放列表中的条款,因此下表完全符合 ISO 26324。DOI 核心的一个 XSD(XML方案) 由 IDF 维护。(请查看 DOI 核心 XML 方案页面以获取当前版本的版本说明,并链接至该方案,另请查看 DOI 核心 XML 方案政策说明 。) 该方案包含这些元素的一些附加子元素。

    表 4.2 展示了 DOI 核心元数据声明中的基本管理元素。这些元素涉及 DOI 号分配以及注册记录本身。

    对于 DOI 核心以外的其他元素和子元素,其值根据需要进行开发。这样的值集应注册至数据字典(归属 IDF—ISO 26324 注册中心),以便于使用统一的应用对不同来源的 DOI 数据进行整合。

    表 4.1 DOI 核心元数据声明中的描述性元素

    核心元素 出现 描述
    DOI name 1 分配给被标识所指对象的特定 DOI 号
    referentIdentifier(s) 0-n 参照同一所指对象的其他标识符(例如: ISAN、ISBN、ISRC、ISSN、ISTC、ISNI )。

    该元素包含了适用于 primaryReferentType 的一个类型元素。目前的方案可以识别 creationIdentifierTypepartyIdentifierType ,均为可以注册允许值的开放列表。
    referentName(s) 0-n 所指对象通常已知的编号(如:标题 )。

    该元素包含了适用于 primaryReferentType 的一个类型元素。目前的方案可以识别 creationNameTypepartyNameType ,均为可以注册允许值的开放列表。

    该元素也包含一个语言元素,其中的允许值列表为ISO 639-2 编码列表。
    primaryReferentType 1 所指对象的主要类型(例如:creation、party、event )。这是一个开放列表;可以注册新 primaryReferentTypes。
    structuralType 1 所指对象的主要 structuralType。

    对于creations,有四个互相排斥的 creationStructuralTypes physical、digital、performance、abstraction)允许根据整体形式进行分类。其中 structuralTypes 可以互相包含,所指对象的 structuralType 由整体形式进行定义 [例如:CD(physical )可能包含文件(digital ),其中包含了歌曲的 performance 录音(abstractions)],根据 referentType 的需要,其内容元素可以进一步划分。

    对于parties,有三个互相排斥的 partyStructuralTypes person、animal、organization )。这些列表是封闭的。
    mode 0-n 仅适用于 creations。所指对象可以获得的主要感官模式( audio、visual, tangible、olfactory、tasteable、none )。Mode 只标识主要感官模式。大多数物质可以通过五种感觉进行感知,但其中有些感觉可能微不足道。例如,一本印刷书籍可通过触觉或嗅觉进行感知,但与视觉相比,这两种感觉仅用作辅助或附带的功能,因此视觉是内容载体的主要感知模式。然而对于盲文图书触觉是主要感知模式。该列表是封闭的。
    character 0-n 仅适用于 creations。沟通的一种基本形式,所指对象的内容通过其进行表达。包含四个值: music、language、image、other 。该列表是封闭的。
    referentType 0-n parties 的所指对象类型规定: author、composer、book publisher、library、university、financial institution、film studio

    creations 是所指对象内容的抽象属性,与其 creationStructuralType 无关,通常使用 creationType 进行描述,其格式和种类元素等可以根据需要进行扩展(例如: audio file、scientific journal、musical composition、dataset、serial article、eBook、PDF )。

    parties 是与 referentType 相关联的角色,并使用 associatedPartyRole 进行描述 (例如: Composer、Author, BookPublisher、JournalPublisher )。

    这是一个开放列表;可以注册新 referentTypes。
    linkedCreation 0-n 仅适用于 creations。另一种与 referentCreation 相关联的 creation。

    此元素包含一个 creationRoleToCreation 元素,为可以注册允许值的开放列表。
    linkedParty 0-n 仅适用于 parties。另一个与 referentParty 相关联的 party。

    此元素包含一个 partyRoleToParty 元素,为可以注册允许值的开放列表。
    principalAgent 0-n 仅适用于 creations,主要负责创建或出版所指对象的一个或多个实体。

    此元素包含一个 agentRole 元素,用于指定其扮演的特定角色(例如: Creator、Author、BookPublisher)。这是一个开放列表,可以注册新允许值。
    dateOfBirthOrFormation 0-1 仅适用于 parties,(个人或动物的)出生日期或该 referentParty (机构的)形成日期。
    dateOfDeathOrDissolution 0-1 仅适用于 parties,(个人或动物的)死亡日期或该 referentParty (机构的)解散日期。
    associatedTerritory 0-n 仅适用于 parties,与 referentParty 相关联的地域(例如:出生日期、国籍或居住地)。其允许值列表为 ISO 3166a2 编码列表。
     

    表 4.2 DOI 核心元数据声明中的管理性元素

    核心元素 出现 描述
    registrationAuthorityCode 1 表示分配 DOI 号的机构代码(由 ISO 26324 注册中心授权)。
    issueDate 1 分配该 DOI 号的日期。
    issueNumber 0-1 关于 DOI 核心元数据声明特定版本的编码或其他标记
     
     

    4.3.2 使用 DOI 核心

    注册机构期望能够保证以最低的限度为每个分配的 DOI 号进行 DOI 核心元数据声明。通过两种方式可以完成:可以使用 DOI 核心 XSD,或者(更常用)DOI 核心元素可以被纳入由注册机构发布的更广泛的元数据方案中。

    如不要求,注册机构可以选择不生成 DOI 核心元数据,也就是说,可以根据内部表示的要求进行转换。

    注册者应当注意,最小的元数据集应当满足业务要求,而非该核心的最小技术要求,后者往往小得多。核心方案几乎不包含强制性的数据元素。最小集是必要的,但考虑到注册者与合作伙伴进行沟通所需的数据,可能无法满足需求。

     

    4.3.3 管理 DOI 元数据方案的流程

    “方案”包括了软件中的所有项目或文件的元数据集元素,旨在实现特定用途,以支持 DOI 的使用。通常情况下,指 XML 方案和 RDF 方案,或用于某些流程的一组已定义的字典条目。RA 愈发体会到使用常见机器可读 DOI 元数据方案带来的好处,尤其是“关联数据”。目前有两种 DOI 元数据方案: DOI 数据字典,包括在消息中使用的允许值集,以及元数据核心。该数据字典的完整版发布在 IDF 网站的会员区。该核心在 IDF 网站以 XML 方案的形式发布。

     

    4.3.3.1 向核心受控词表添加值

    许多核心元素的值由受控词表确定(或“允许值集”)。这些值在上表中以粗体突出显示。有些列表是封闭的,意味 RA 无法向其中添加值:

    creationStructuralType
    partyStructuralType
    mode
    character
    language (ISO 639-2)
    territory (ISO 3166a2)

    而有些列表是开放的,RA 可以向其中添加新值:

    primaryReferentType
    agentRole
    creationType
    creationIdentifierType
    creationNameType
    creationRoleToCreation
    associatedPartyRole
    partyIdentifierType
    partyNameType
    partyRoleToParty

    通过向 DOI 数据字典注册,RA 可以向这些列表添加新值。(见下文)

     

    4.3.3.2 更新流程

    DOI-RATech 小组具有更改现有 DOI 方案的权限。该小组的任何成员随时可提出更新方案的建议,或者提议引入新的方案。从 IDF 中挑选技术支持人员管理这些方案,负责实施这些变更。这些技术人员将确认每一项提议,并根据建议修改的范围和复杂程度估算完成更新所需的时间。对于常规变更,通常不会超过两周。该流程为:

    1. 递交提议
      DOI RA 会员通过 DOI-RATech 邮件列表,提交针对某个方案的变更建议,或提议一个新的方案。其格式是多样的,可以是一个具体的提案(例如:增加了一个新的允许值或元素),也可以是一种需求(例如:需要引入一种方法,以标识核心内独占 ID 方案的所有者)。列表上的其他成员可以提出意见。
    2. 通过提议
      如有必要,则要求对该提议进行说明、提出意见和建议,以便列表上的其他成员有时间进行回应。其目是在实施变更前达成共识。达成协议所用的时间根据提议的不同而有所不同:有时非常迅速即可通过;如果无法达成一致,则可能废除该提议。
    3. 实施草案
      一旦通过该提议或需求,即提供完成此更新所需的大概时间,并保证在该时间范围内出台该方案的草案。如因故推迟,则须提前告知 DOI-RATech 小组。
    4. 检验更新的或新的方案
      该小组将有一定的时间(常规更新通常为一个工作周)对该草案提出意见。如需进一步检验,则重复步骤 3 和步骤 4。
    5. 发布更新的或新的方案
      新版本的方案确认后,即上传至网站,以供 IDF 会员使用。
     

    4.3.4 DOI 数据字典

    核心使用的所有元素和允许值均收录于 DOI 数据字典中。该数据字典是一个层级化的本体,用于支持 DOI 元数据的有序开发。该字典的简介部分进一步介绍了其范围、结构和维护方面的信息。

    根据元数据核心及/或其允许值的修改,或发布的元数据核心以外的其他 DOI 消息方案,所有注册机构均可提交请求向该字典添加条目。任何注册机构通过向 IDF 注册新值后,即可将该新值添加至该开放允许值集。

    ISO 26324 规定,该数据字典作为资源库存储所有数据元素和允许值(可被用于每个元素的值的项目)。这些数据元素和允许值用于 DOI 元数据规范,应能够在本体内定义面向所有注册机构的任意元数据元素,并提供映射以支持数据交换所需的元数据集成与传递。如有需要,元数据面向特定的服务进行整合。在这种情况下,数据字典提供整合后元数据的映射,并以一个独立集的形式进行显示。核心元数据中注册者使用的允许值集应在该数据字典中进行注册。

    DOI 数据字典作为词表映射框架 (VMF) 中的命名空间进行实施和维护。

    用户不需要了解数据字典的底层的概念架构即可使用。该字典的主要特点包括:

    IDF 的基本作用之一是向用户保证其工作已经通过了同行评审,经历了实际工作的考验,并遵从合理的原则。数据字典的方法已通过 W3C 本体语言 OWL-DL。该数据字典采用在各类主要元数据方案中广泛接受和使用的底层本体,源于 indecs(电子商务系统的数据互操作性 (interoperability of data in e-commerce systems))框架体系。indecs 是一个影响广泛的多媒体元数据项目 (1998-2000) ,由内容、作者、创作者、图书馆、出版商和权利社区共同参与,开创的基于事件的元数据模型是集成数字事务解决方案的先例。请参见专题资料“indecs 框架体系”。

     

    4.3.5 词表映射框架

    IDF 支持并建议使用词表映射框架 (VMF),以促进注册机构方案与来自外部 DOI 域名(如 ONIX 或 DDEX 消息标准)的其它方案和本体之间的互操作性。IDF 托管 VMF 网站,也是 VMF 管理组织的一个组成部分。VMF 是一款可下载的工具,通过为主要内容标准提供可扩展的和可靠的映射,以支持跨社区的语义互操作性。

    VMF 将现有的 RDA/ONIX 框架扩展为一个综合的资源关系词和分类词表,它们形成的超集成为应用于发行商/制作人、教育和书目/文物社区(CIDOC CRM、DCMI、DDEX、DOI、FRBR、MARC21、LOM、ONIX、RDA)的主要标准。

    IDF 支持 VMF 的开发,鼓励 RA 使用其向其他方案映射核心或非核心的元数据元素,并乐意与 VMF 技术团队开展讨论。

     

    4.3.6 元数据整合:IDF 的目标

    IDF 认识到,元数据的自动整合是发挥作为数字化商务与文化工具的 DOI 全部潜力的关键。这也是语义网络和“关联数据”的潜在目标,即:网络应被视为结构化的、互联的、机器可处理的信息的媒介。同时,如同其目前的形式,呈现人们所需信息的文档网络。

    本文描述的工具(核心声明、DOI 数据字典和 VMF)为不同 DOI 所指对象元数据的整合提供了良好的实践基础和开端。关联开放数据等创举仅仅为技术和语法的进一步发展提供了必要的基础架构:它们并不为不同数据集的自动整合提供共享意义(“语义对齐”)层面的解决方案,而该层面的解决方案能够实现 RA 和其他方所提供服务的全自动交互,或提供满足一对一需求的解决方案。

    这里的关建在于开发结构合理的元数据方案,提供利用诸如 DOI 数据字典和 VMF 等工具的语义映射功能实现的服务。IDF 将为选择开发此类服务的 RA 提供帮助。

     

    4.4 ISO 26324 中的元数据要求

    ISO 26324 是 DOI 系统的 ISO 规范,描述了以下 DOI 元数据的功能和要求: 对象应当通过 DOI 元数据进行无歧义的、精确的描述。根据结构化的数据模型,DOI 号的所指对象能够关联任何所需的精确度和粒度等级的元数据,以支持与所指对象相关联的标识、描述与服务。其设计为实现以下目的:

    DOI 元数据应支持以下功能。

    例如:不把声音载体、书籍、视频和照片等视为具有不同(或类似)性质的完全不同物体,而是识别为具有同等属性的不同的值的创作物类型,其元数据可以受同样环境的支持。

    1. 媒体(如书籍、期刊、音频、音视频、软件、抽象作品、视觉材料)
    2. 功能(如编目、发现、工作流程和权限管理)
    3. 元数据层次(从简单到复杂)
    4. 语义障碍
    5. 语言障碍

    应当及时准确地记录用于描述和标识正在被分配 DOI 号的对象的元数据。DOI 元??数据规范中使用的数据元素和允许值应当存储在一个资源库中,从而通过选择现有的方案实现其互操作性。数据字典应当被作为存储所有数据元素和允许值的资源库。元数据应符合 DOI 核心元数据声明的最低要求。

     

    4.5 底层本体

    DOI 数据模型建立在语境本体上,许多其他应用也使用这一方式。(请参见第 1 章,“简介”,1.6.5 小节 )。IDF 确保对数据模型进行维护,并提供进一步的扩展和应用;RA 和 应用开发人员无需访问语境本体即可使用 DOI 系统(如果希望,他们也可访问);这里提供了一个高层次概念模型的图文说明,更多文档将作为词汇映射框架的一部分及相关材料提供。请咨询 IDF 已获得更多信息。

     

    上一章节: 3 解析    下一章节: 5 应用

     
    DOI_disc_logo ®,DOI® ,DOI.ORG® 和 shortDOI® 为国际 DOI 基金会商标。
    mg电子注册秒到体验金