Logo

目录    上一章节:4 数据模型 下一章节:6 政策

 

5 应用

 

本章节讨论了如何使用多重解析提供的应用,这些应用能够将 DOI 号解析为多种解析选项中最合适的内容。这些选项包括可以手动选择的弹出式菜单,以及通过内容协商和关联数据实现的一致性自动化选择。

© 国际数字对象标识符 (DOI) 基金会  •  最后更新:2014年7月11日

 
5.1 简介
5.2 设计应用
      5.2.1 基本功能
      5.2.2 设计注意事项
5.3 多重解析应用
5.4 关联数据
      5.4.1 内容协商
5.5 应用配置文件
5.6 表达 DOI 号之间的关系
5.7 使用包含数字对象注册技术的 DOI 系统
5.8 使用 DOI 号标识片段
 

5.1 简介

为维护持久的标识符,当前管理服务须与注册者协同合作。要评价其管理服务,一个 DOI 应用通常要提供更多的值,而不仅仅是注册一个DOI——通常由注册机构提供增值服务(请参见第8章,“注册机构” ),如引文链接或元数据管理。

DOI 号可用来标识多种类型的内容,并且可以链接到该内容不止一个永久的、间接的链接。当注册者或第三方提供了有用的信息时,DOI 号同样可以提供或指向有关该对象的信息。该信息可包括与对象相关的任何类型的描述性元数据和任何类型的服务,如权利声明、警报服务、数据可视化,或任何其他相关联的信息或服务。通过定制 DOI 应用,可以通过多种途径使用该信息,以满足用户的需要。

本章节介绍 DOI 应用的基本知识,讨论开发者在利用该系统创建新服务时应考虑的设计元素,并描述了几个由注册机构基于 DOI 号解析提供的服务作为案例。此外,本章节还介绍通过应用配置文件分类服务的方法、如何使用词表映射框架结合 DOI 号解析和互用语义、以及 DOI 系统与数字对象注册表技术是如何工作的。

 

5.2 设计应用

 

5.2.1 基本功能

与 DOI 号相关联的数据以类型/值对的形式存储在 DOI 系统中,每个数据都有唯一的 ID。这是非常灵活和开放的:新的类型可以随时添加,并且这些值可以是任意复杂的。类型/值对可以是可管理的(例如:创建日期、权限等)、众所周知且标准化的(例如:URL、电子邮件、10320/loc)、或 RA 为实现特定应用目的而创建的(例如:包含二进制数据值的自定义类型或特殊格式的字符串)。一个 DOI 号可以关联许多类型/值对,相同类型可以有不同的类型/值对。但每个 DOI 号至少具有一个“URL”类型,其值为与该实体相关的 URL。

就最基本层面而言,所有 DOI 应用通过解析 DOI 号来查询 DOI 系统。可以创建请求以要求所有与该 DOI 号相关联的数据,要求所有特定类型的数据,或要求具有特定标识符的数据。(要了解更多有关 DOI 号解析的基础知识,请参见第3章,“解析” 。) 开发应用用来获得一个或多个类型,解析、评估、并根据相应的值进行操作。

例如,dx.doi.org 代理服务器建立了一项简单的服务,用来检查 handle 解析返回的类型/值对,也可以返回特定的信息。这项服务可以返回某个或多个 DOI 的注册机构的名称。在“http://doi.org/doiRA/”后面添加 DOI 号时,(HTTP GET) 请求将会返回一段包含注册机构名称的 JSON 代码。解析http://doi.org/doiRA/10.5240/B1FA-0EEC-C316-3316-3A73-L将返回:

[
  {
    "DOI": "10.5240/B1FA-0EEC-C316-3316-3A73-L",
    "RA": "EIDR"
  }
]

如果想通过一次请求返回多个 DOI 的注册机构信息,可在 DOI 之间使用“,”分隔。

 

5.2.2 设计注意事项

设计精良的支持 DOI 的服务十分重视灵活性和可扩展性。最具灵活性和可扩展性的方法是使用 DOI 系统作为一种轻量级的重定向机制,将标识符解析为结构清晰的数据。这种方法超出重定向的单一层面,用于提供 DOI 相关的服务。除了简单地解析 DOI 号和返回 URL,DOI 注册机构可提供多种解析服务,将一个 DOI 号链接至相关内容的多个选项(例如书目元数据),而这些选项可能包括用于特定元数据表达的请求或仅在特定语境中可用的元数据。

开发人员可以选择使用所有或大部分 DOI 系统自身服务提供的信息,这样 DOI 系统便成为主要的服务供应商;或者,使用 DOI 系统指向一个或更多的外部服务,以提供所需的信息和功能。例如,DOI 系统可用于存储所有需要的数据,以显示一个带标记选项的简单菜单供用户选择;为可视化工具选择一个存储了大量科学数据的外部服务;或者 DOI 系统是存储多个图像文件不错的选择。

出于未来进一步设计的考虑, 在开发应用时,应使用标准化的格式存储、使用和分享高品质的机器可读数据。DOI 应用的设计可以为符合关联数据的最佳实现形式,即使用标准 HTTP 网络协议的内容协商功能,以机器可读格式显示数据。

鼓励利用 DOI 结构化数据的优势来创造服务,以保证 RA 应用之间的一致性。鼓励尽可能的协作。同时鼓励 IDF 以外的第三方应用开​​发人员利用 DOI 结构化数据的优势,参与创建服务。

本文后面将阐释一个基于多重解析和内容协商的 DOI 应用服务的示例。在任何时间均可创建新服务。如有问题,请发送邮件至contact@doi.org

 

5.3 多重解析应用

最基本的 DOI 应用是将 DOI 解析为“URL”类型。这是一种简单的、单点式的解析。代理服务器解析 DOI 号,发现 URL 类型并明确其关联值可以通过 HTTP 重定向返回给终端用户客户端(可能是网络浏览器)。该服务成功,是因为 1) 客户端软件通过 dx.doi.org 代理服务编程,以寻找 URL 类型、提取值、将其嵌入在 HTTP 重定向,并返回给终端用户客户端;以及 2) 特定 DOI 号的管理员了解该 URL 类型,并添加了适当的类型/值对。

多重解析允许将一个实体解析为多条数据或实体。多个类型/值对(不限于 URL 类型)可以返回到客户端,之后评估数据以确定下一步操作。(请参见第 3 章,“多重解析”,3.3 小节 。) 将 XML 或其他机器可读的数据与 DOI 号关联,更加扩展了多重解析的用途,可以增加功能、为协商内容提供更多选择,并促进关联数据应用的创建。

因此,当某些标准要求从一组可能的结果中做出选择时,多重解析可以用于开发相关的应用。应用开发人员可以创建一种类型,用于存储客户端使用的值,以生成选项菜单供用户在解析 DOI 号时使用。对于一个文档,用户可选择的处理方式可能包括:查看文档、查看文档元数据、通过电子邮件发送 URL 与朋友分享文档、访问作者博客等。对于一个数据集的登陆页面,用户可选择的处理方式包括:查看完整的数据集、仅查看选定的数据,或者根据其 DOI 号解析向客户提供的可用信息,采取其他的方式处理该数据集。

例如: 学术期刊文章分配了一个 DOI 号,但多个网站均提供了这些文章,读者可能希望从他们订阅的网站下载该文章。CrossRef 使用多重解析使用户能够解析一篇文章的 DOI 号,并选择希望查看的版本,如下面图 1 所示。

图 1 两个网站均提供了期刊文章:JSTOR 和 BioOne

通过使用“10320/loc”类型,该服务得以实现。“10320/loc”类型是一种既定的类型,指定了机器可读的 XML 格式的值,该值包含了“位置”列表,用于向客户端提供操作选择或“choose-by”的选项,用于解析 DOI 号时选择操作。它为从一系列可用选项中选择特定的 URL 或其他信息提供了一个标准化的机制。解析器可以应用已知的选择方法,按顺序根据解析器的环境(在代理服务器的情况下,使用 HTTP 请求)和每个位置的属性,选择一个位置。(要了解“choose-by”机制的运行原理,请参见第 3 章,“解析”,3.8.1.3 小节 。)

10320/loc 类型大大拓展了 DOI 服务的选项。除了图 1 所示的“用户选择”选项,存储在 10320/loc 类型中的数据可用于客户端(基于给定的标准),为特定的用户选择所需的 DOI 号解析结果。下图显示与 DOI 号相关联的(非管理)值 10.1525/bio.2009.59.5.9。该 DOI 号被注册时便拥有了一个单一的 URL 值(URL 和值类型,又名数据,等同于 JSTOR 的网址)。添加一个 10320/loc 类型能够提供其他的解析选项。当该记录返回给代理时,代理识别出 10320/loc 类型。如有要求,代理将根据给定的标准对位置值进行评估。

图 2 显示了包含 10320/loc 数据类型的相同 DOI 号。该 10320/loc 类型包含了的地理位置信息,可被客户端用于自动选择用户被重定向到的 URL。

10.1525/bio.2009.59.5.9 的值
索引 类型 时间信息 数据
1 URL Sun Jan 02 2011 13:32:18 EST http://0-www.jstor.org.ignacio.usfca.edu/stable/25502450
1000 10320/LOC Mon Jul 27 2009 13:18:25 EDT <locations chooseby="locatt,country,weighted">
<location id="1" cr_type="MR-LIST" href="http://0-mr.crossref.org.ignacio.usfca.edu/iPage?doi=10.1525%2Fbio.2009.59.5.9" weight="1" />
<location id="2" cr_src="unca" label="SECONDARY_BIOONE" cr_type="MR-LIST" href="http://0-www.bioone.org.ignacio.usfca.edu/doi/full/10.1525/bio.2009.59.5.9" country="uk" weight="0" />
</locations>

图 2 10320/loc 类型的 XML 数据

客户端可被配置为:

不能识别 10320/loc 类型的客户端将忽略该类型/值对,仅使用 URL 类型做单一层次的重定向。我们了解到,先前的 DOI 客户端就是这样运行的。该类型允许增加新的属性,且不破坏数百万现有的 DOI 号。

请注意,即使该方法是应用于一个 RA 数百万现有的 DOI 号,也没有必要更改所有的 DOI 记录。根据 DOI 系统的基础架构设计,一个 DOI 前缀下所有 DOI 号使用的任何信息均记录于 DOI 前缀记录中。该记录标识了对该前缀负责的服务,客户端能够在整个解析过程中调用该信息。因此,当 RA 在某些时候需要改变关联数据的方式、指向不同的服务或使用不同的参数时,可能仅对一个 DOI 前缀进行更改,但这些变更会自动应用于该 DOI 前缀下所有的 DOI 号。

同样值得注意的是,Schema.org 提供的技术文档中指出各大搜索引擎会识别网页上的结构化数据,获取这些内容和数据的富摘要,并直接显示于搜索引擎的结果页面。Schema.org 不使用 RDFa,而选择了更为简洁的 HTML5 标记。“富摘要”的概念允许搜索引擎读取网页上有意义的语义内容。这种“富摘要”的作用与 10320/loc 和 “chooseby”方式异曲同工。如果 schema.org 定义了令人关注的富摘要,如果这些富摘要变得足够重要,那么它们可以很容易地被记录为值和/或由代理服务器生成。

 

5.4 关联数据

上述“choose-by”机制的一个重要用途是重定向到关联数据服务。关联数据是使用标准 HTTP 网络协议的内容协商功能,以机器可读格式显示数据的一组最佳实现形式的总称。这些最佳实现形式支持开发链接工具,使用来自多种网络资源的数据,而无需处理各类独占和不兼容的应用程序接口 (API),并且支持使用 HTTP 请求结构化格式的数据,以实现机器识别而非肉眼阅读。在网络发展的早期,人们关注大多数 URL,因此那时 web 代理仅仅将 DOI 号解析为肉眼可读的网页是合理的,但今非昔比。

位于 dx.doi.org 的 DOI 代理服务器能够支持 DOI 号的内容协商。在关联数据应用中,代理服务中的 HTTP 请求评估将决定该请求是 application/rdf+xml 形式的内容,还是一些关联数据常见的类似请求类型。面向这些特殊类型内容的请求可能来自于自动化流程或特殊的“关联数据”浏览器,但通常不会来自于最终用户。当然,其目的是允许外部开发者查询 IDF 注册机构所有的一系列广泛可靠的元数据记录,从而提供增值服务。

内容协商是一种公认的实现关联数据的方法。对于 web 服务器和 DOI 代理服务器而言,内容协商的意思是“我应该返回怎样的内容”。它允许用户请求网络资源的特定表达。例如,DOI 解析器可以使用内容协商来提供与 DOI 号相关联元数据的不同表示。除服务器驱动协商的实现基于客户端提供的可接受内容类型的列表外,发送至 DOI 解析器的内容协商请求与标准 HTTP 请求十分类似。

一些 DOI RA 将该方法应用于其所有的 DOI 号,提供的服务返回常见机器可读格式的元数据。针对 DOI 注册材料应用关联数据原则和技术的一个显著优点是,它是“值得关联的数据”,即组织化的增值的数据,由注册机构管理、订正、更新并统一维护。其具有持久性,避免了“数据腐败”。在实践中,关联数据实现质量的好坏仅与要链接到的数据、以及要使用的链接的意义和语境相关。DOI 系统可提供“组织化的数据”,即一致、管理、链接。因此您可以放心地链接到其他“高质量的数据”,同时仍可使用标准的关联数据技术。

 

5.4.1 内容协商

内容协商通过 DOI 注册机构面向其 DOI 号而实施,特别用于向其用户提供增值的元数据表示。内容协商支持一些引文格式(其中一部分在 RA 之间通用)。使用内容协商能够发出偏向特定 RA 内容类型的请求,但也会降低其他 RA 对于标准内容类型的响应。面向这些服务的请求可能来自于自动化流程或特殊的“关联数据”浏览器,但通常不会来自于最终用户。其目的是允许外部开发者查询 IDF 注册机构所有的一系列广泛可靠的元数据记录,从而提供增值服务。CrossRef、DataCite 和 mEDRA 分别通过 http://data.crossref.orghttp://data.datacite.org以及http://data.medra.org 的服务支持要进行内容协商的 DOI 号,可使用格式化的元数据进行查询。

对于来自 HTML 页面头部信息包含 GET "Accept: text/html" 的普通浏览器的请求,DOI 号被解析,用户被重定向到发行商的登陆网页 URL。例如,DOI“10.1126/science.169.3946.635”重定向到一个描述文章 “The Structure of Ordinary Water”的登陆页面。发出内容协商的请求,而不要求使用 HTTP 标题 “Accept”,HTTP 头信息 GET 包含了可被客户端接受的其他内容类型(客户端知道该如何解析),这些数据类型作为常见的请求发送给链接到的数据。对于头信息为 GET "Accept: application/ref+sml 的浏览器请求,解析上述相同的 DOI 号则将用户重定向到 RA 的元数据服务。此外,如果 citeproc JSON 可用,客户端希望接受 citeproc JSON,如不可用,客户端仍可处理 XML RDF,这样,客户端可以发出一个包含“Accepte”头信息的请求,其中同时列出“application/citeproc+json”和“application/rdf+xml” 。

10320/loc 类型使用代理进行编译。基于 GET,位置值用于重定向到合适的元数据服务,之后该服务为用户创建响应。对于 CrossRef、DataCite 和 mEDRA 的 DOI 号,所有发送至 dx.doi.org 的要求非“text/html”内容类型的请求,将被重定向到该 DOI 号注册机构托管的元数据服务。

如下表所示,使用上述 DOI 号,除 URL 类型外,所有 CrossRef 的 DOI 号均包含 10320/loc 类型:

10.1126/science.169.3946.635 的值
索引 类型 时间信息 数据
1 URL Tue Jan 17 2012 14:39:18 EST http://0-www.sciencemag.org.ignacio.usfca.edu/cgi/doi/10.1126/science.169.3946.635
1000 10320/LOC Tue Jan 17 2012 14:39:18 EST <locations chooseby="locatt,country,weighted">
<location weight="0" http_role="conneg" href_template="http://0-data.crossref.org.ignacio.usfca.edu/10.1126/science.169.3946.635" />
</locations>

所有的内容协商查询使用作为变元进行请求的 DOI 号,重定向到位于 data.crossref.org 的服务。(相同但未使用特殊“关联数据”内容协商进行标记的 DOI 号(例如,所有的传统网络浏览器事务)将退回到预期的 URL 类型,并转回传统的 DOI 重定向。) 下面显示的是一个内容协商请求的 Accept 头信息,其中同时列出了“application/citeproc+json” 和 “application/rdf+xml”,以及由服务返回的元数据。http://crosscite.org/cn/ 提供了更多有关关联数据应用的信息。

当解析一个 DOI 时,内容协商请求分别进行解析,则代理将返回“Vary: Accept” HTTP 头信息。开发人员可以此确定哪些 DOI 提供内容协商的支持。

内容协商通过使用 HTTP URI,使得人们和用户代理以标准格式(如 RDF 和 XML)利用对象有关信息,并获取其他改进发现功能的相关 URI。通过使用 DOI 系统持久、高质量的数据,数据关联的目标正在实现。关联数据应用的数量将继续增长。如有需要或关于新服务的想法,请联系 contact@doi.org 以获取更多信息。

 

5.5 应用配置文件

DOI 号可以分组到应用配置文件 (AP)。应用配置文件用于定义 服务(包括元数据服务),该组 DOI 号可以使用这些服务。每个 DOI 号可以是一个或多个 AP 的成员。例如,默认情况下,每个 DOI 号是一个应用配置文件的成员,该配置文件将该 DOI 号解析至某些网络地址,这些网络地址至少包含了该 DOI 号的最小核心元数据。应用配置文件可以作为一个概念组使用,但也可以从技术上理解为 DOI 数据模型中解析机制的一部分。由应用决定正式注册 AP 和将其作为每个 DOI 解析返回的结构化数据(例如作为一个标签)一部分的机制。潜在用户请咨询 IDF。

 

5.6 表达 DOI 号之间的关系

通过使用词表映射框架 (VMF) 将解析功能与简单、实用且互用的语义相结合,以定义(或从现有方案中映射)特定的关系,从而 DOI 系统可以为关联数据的开发和其他相关使用 DOI 号标识实体的机制提供进一步支持。强烈建议该系统的潜在用户加入 IDF 社区,就该问题展开讨论。

建议注册机构在设计类型关系时使用以下所示的关系词(“通过已定义类型关系……,该 DOI 号与其它 DOI 号关联”

这里的相关语义“关系词”或(在 OWL/RDF 条目中的)“属性”将表示 2 个不同来源或部分的 DOI 号链接起来。IDF 在其数据字典的命名空间中加入了少量“主要”关系词,用来表示现有内容标准和数据库中来源与部分之间最常见的关系。建议 RA 将其应用于其方案中。作为起始,已提出五个主要的来源与来源的关系词,和一个主要的部分到来源的关系词:

基于内容标准和数据库,此列表仅仅是一个开端:其中每一项都表示了 VMF 中的一个重要概念。然而,RA 经常使用一些现有的自己的关系词,或希望使用一些更专业的关系词。例如,RA 希望指明“改编”、“摘录”或“编辑”,而不仅仅是“派生”。原则上这可以进行任意粒度层面的扩展。利用 VMF,可以为这些主要关系词提供层级上的子关系词,例如:

IsDerivedFrom
        IsAdaptedFrom
            IsTranslatedFrom
                IsAutomaticallyTranslatedFrom
        IsCompiledFrom
        IsExtractedFrom
        IsUpdatedVersionOf
        IsCreatedFromBasis
        IsReplicaOf
        etc

RA 可以根据需要,将其添加至 DOI 数据字典。本文仅展示了很少一部分,集中在 VMF 子集:本文中使用的所有示例均以其他编号收录于 VMF,还有其他更多。

该小型本体还包含“IsSameAs”,可以映射 RA 自己方案中的任意指定关系词,或者其方案,如 DC 或 foaf,例如:

doi:HasMainSubject owl:equivalentProperty     foaf:IsPrimaryTopicOf

出于明确的互操作性考虑,该结构化关系词采用了 RDF/OWL 标准(如 owl:equivalentProperty,rdfs:subPropertyOf)。该结构提供了一个虽小但强大的层次化与等价关系词本体,以允许 RA 创建并获取包括 DOI 号在内的关联数据,根据基本推理,将其解析为希望的或所需的条目。除了最初的主要关系词,该关系词本体的规模和范围可以根据 RA 的需求进行扩展。

建议的主要关系词列表

关系词 定义
doi:IsDerivedFrom 派生(例如,改编、摘录或编译)与被派生来源之间的关系词。
doi:IsManifestationOf 具体表现(例如,定影表演)与其实现的工作之间的关系词。
doi:HasSubject 创作物与其以某种方式参考的实体之间的关系词。
doi:IsReplacementFor 创作物与其取代的创作物(例如,软件的更新版本)之间的关系词。
doi:IsPartOf 创作物与其一部分之间的关系词。
doi:HasContributor 创作物与提供其构成的部分之间的关系词。

上述所有的关系都是多对多的。

每个主要关系词均有不限量的子类(可以添加至数据字典的任意位置)。例如:

IsDerivedFrom
        IsAdaptedFrom
                IsTranslatedFrom
        IsCompiledFrom
        IsExtractedFrom
        IsUpdatedVersionOf
        IsCreatedFromBasis
        IsReplicaOf
        etc

IsManifestationOf
        IsPerformanceOf
        IsFixationOf
                IsRecordingOf
       etc

IsReplacementOf
        IsUpdatedVersionOf
        etc

IsPartOf
        IsChapterOf
        IsMemberOf (for sets)
        etc

HasSubject
        RefersTo
        HasMainSubject
        etc

HasContributor
        HasAuthor
                HasPrefaceAuthor
        HasEditor
        HasIllustrator
        etc

 

5.7 使用包含数字对象注册技术的 DOI 系统

有些 DOI 选择其他方法得以实现,即使用包含 CNRI 数字对象注册的软件,该软件提供了补充性功能。Handle System 和数字对象注册均为广义数字对象体系结构的组成部分。若要对基本技术进行一些定制,可以通过 CNRI 或其机构完成(请注意,该注册技术并非 DOI 系统的一个组成部分,亦非由 IDF 管理,但授权 DOI 使用。)。

数字对象 (DO) 注册软件由 CNRI 开发,配合 Handle System (在 DOI 系统中使用)。它提供反向查找功能,类似于卡片目录或电话目录,从而可以通过搜索已注册的属性找到标识符。该软件是开放、免费的,已应用于多个不同的领域,包括 DOI 应用(例如,电影和电视行业的娱乐业标识注册,EIDR)。随时随地使用该系统,可以使注册变得相对低廉快捷。DO 技术由 CNRI 开发,在很大程度上受政府资助,可以免费或以很小的成本获取。

与 DOI 系统一起使用的注册软件可​用于联结以各种形式分布的数据源,使多网络架构成为可能。一种简捷的方法要求一些注册机构向单一的可检索注册提交已定义的一组实体的元数据。提交的材料将根据特定的元数据方案进行处理,对提交的内容进行语法验证,并分配给注册的实体一个标识符 (DOI) (假定该实体尚无标识符)。这些元数据将进行索引,用于检索。一次检索可以返回一个或多个条目,包括标识符,可在任何操作或环境下指示已标识的实体。

一种简单的情况会涉及许多问题和可能的变更,同样这个情况本身也会发生架构变化。在该情况下,存储在注册和标志符解析系统中的数据,以及注册机构保留的数据都可能发生变化。例如,注册可能仅仅包含最少的参考数据;注册机构运行一项服务,以提供注册所持有的核心数据以外的数据,这些数据可能并不标准;标识符仅持有指向注册的指针。另外,解析系统可持有核心数据,注册可持有扩展数据,而注册机构仅起到提交数据的作用。在架构上,注册软件并不局限于单一的中央注册情形。多个注册可以同步进行,因此添加一个新条目或更改一个条目将立即反应给其他注册。

实现这样的系统原型所需的努力很大程度上取决于特定的功能要求。关键任务在前期分析,以确定配置和定制现有软件的要求。

 

5.8 使用 DOI 号标识片段

在某些情况下,应用可能需要标识实体的一个片断,而非整个实体。如果可能并且有用的话,每个这样的片段可分配一个单独的 DOI 号(例如,如果一本书中的某个表格可能被重复使用多次的话)。DataCite 是一个注册机构,通过使用标准的 #-fragments、DOI 重定向及代码和W3C MFIDs (Media Fragment Identifier,一个被采用的标准,DOI 解析器不能解析),解析这个 DOI http://doi.org/10.5446/12780#t=00:20,00:27

然而,这并不总是可能的。有时人们希望标识“该实体的任何片段”,而该实体总是不断变化的。对于这种情况,可以采用“模板 handle”:一个模板 DOI handle 可以以一种基准规则的形式被包含,允许该基准规则进行任意数量的扩展,并按照一种模式被解析为完整的 DOI handle,而无需单独注册每一个这样的 handle。例如,这将允许使用 DOI 号来指涉一个视频中的无数片断,而不必使用单独的 handle 注册每个可能的片断。如果该模式需要被改变,例如,视频被移动或使用不同类型的服务器提供视频剪辑,则只有基准 DOI 号(handle)需要改变,而先前的无数扩展仍可正确解析。

 

上一章节:4 数据模型 下一章节:6 政策

 
DOI_disc_logo ®,DOI® ,DOI.ORG® 和 shortDOI® 为国际 DOI 基金会商标。