Logo

目录    上一章节:2 编码    下一章节:4 数据模型

 

3 解析

 

本章节阐述了 DOI ® 系统的解析元件,及其为标识符和相关数据提供持久关联的能力。本章节还介绍了用于 DOI 号解析的 Handle System® 的概况。

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

 
3.1 解析
3.2 简单解析
3.3 多重解析
3.4 DOI 系统解析需求
3.5 Handle® System 技术
      3.5.1 概述
      3.5.2 DOI 号解析技术支持
      3.5.3 使用 DOI 号的软件支持
3.6 DOI 号“状态数据”的维护
3.7 Handle System 解析接口
      3.7.1 定制解析软件
      3.7.2 本地解析器
      3.7.3 代理服务器
      3.7.4 代理认证、监视和报告
      3.7.5 其他机制
3.8 DOI 系统代理服务器技术细节
      3.8.1 使用代理服务器系统解析 DOI
      3.8.2 代理服务器查询参数
      3.8.3 代理服务器 REST API
      3.8.4 附加功能
            3.8.4.1 本地内容服务器(“合适版本”问题)
            3.8.4.2 参数传递
            3.8.4.3 使用 10320/loc Handle 类型及多重解析
 

3.1 解析

解析是一个标识输入——请求——发送至网络服务以返回特定输出结果的过程。返回的结果为一条或多条与被标识实体(例如 URL)相关的当前信息(状态数据)。多重解析通过 DOI 解析组件使用 Handle System 实现,其返回内容为与 DOI 标注的实体相关的多条当前信息——至少是一个 URL 加上允许管理的已定义数据结构。

DOI® 系统使用 Handle System® 对所指对象进行解析,将 DOI 号(例如 10.1000/140)解析为一条或多条(因此称为“多重”)类型化数据 :例如 URL 代表(表明)对象、诸如电子邮件之类的服务、或一个或多个元数据项目。新的类型可以随时加入,使得 DOI 解析系统能够非常灵活快速地应对新的要求。解析可以被认为是一种机制,用于维持两个数据实体之间的关系;元数据项目即为被声明存在于两个实体之间的关系:因此,通过解析可以清晰自动地表达实体之间的这种元数据关系。

使用多重解析,DOI 号可以被解析为任意数量的不同关联值:多个 URL、其​​他 DOI 号,或其他代表元数据项目的数据类型。解析请求可能返回当前信息的所有相关值,或者一个数据类型的所有值。这些返回值之后将在特定的“客户端”软件应用中做进一步处理。最简单的是,用户只需根据需要选择系统提供的选项即可操作。更复杂的自动化过程考虑到了自动选择正确的值以便于进一步处理。

 

3.2 简单解析

DOI 的编号可以永久标注特定的知识产权实体(对象),形成的文件可以(或不可)通过互联网访问。URL 提供了与实体相关的特定因特网地址。上述两种标注的应用截然不同:前者标识一个实体,后者标识一个位置(可能或无法在该位置找到特定的实体)。

最早的 DOI 系统应用面向简单、单点的解析,提供了持久性标识符(不会出现“404 not found”错误消息)。每个 DOI 号都解析为一个唯一的 URL。通过在 DOI 记录中管理 DOI 与其解析到的 URL 之间的链接,可以更改实体位置,同时保持该实体编号为可用的标识符。请参见第5章,“应用” ,以了解更多信息。DOI 系统管理中首要的,也是最简单的任务即克服 URL 缺乏持久性的问题。

 

3.3 多重解析

多重解析允许将一个实体解析为多条其它数据或实体。

DOI 号的解析可以包括,但不限于关联值。如位置 (URL)、电子邮件地址、另一个 DOI 号和描述性元数据。所指对象有多种类型(如抽象“作品”,物理“现象”,或表演),并不总是可直接访问的数字文件或其他形式,也就是说,解析有可能、也有可能不返回该对象的一个实例。解析也可涉及一个或多个中间映射操作。

DOI 解析记录可以包含一个或多​​个可以找到对象的 URL。已分配 DOI 号的对象的其他信息可能包括但不限于:

通过自动多重解析,DOI 号可以被解析为互联网上任意数量的点:多个 URL、其​​他 DOI 号、以及其他数据类型。如果 DOI 号可以指向多个可能的“解析”,应当如何在不同的选项之间进行选择呢?最简单的是,用户在一个提供的列表中进行手动选择。然而,面对日益复杂化和自动化的环境,这并不是一种可持续的解决方案。DOI 系统能够自动进行“服务请求”。据此,用户(更重要的是用户的应用软件)可以无缝地从一个 DOI 号传递给所请求的特定服务。

multiple_resolution

图1:服务自动选择数据

请参见下文 3.8.4.3 多重 URL 解析 及第 5 章,5.3 多重解析应用,以了解当前多重解析技术实现的详细信息。

 

3.4 DOI 系统解析需求

ISO 26234 包含以下 DOI 系统解析中遇到的功能需求:

部署管理 DOI 号解析技术时,应支持下述 a) 至 l) 中列出的功能:

  1. 高效和无限扩展的协议;
  2. 对分配标识的绝对数量或标识符的字符串长度没有限制。
 

3.5 Handle® System 技术

 

3.5.1 概述

Handle System 技术由 CNRI 开发,用于完成 DOI 系统内的解析任务,因为它符合 DOI 概念标注解析的要求,具有一系列其他现有技术所不具备的优势:

该 Handle System 技术的一大亮点是解析多重、可扩展的数据类型。同时,Handle System 无预设限制,DOI 系统是 Handle System 的一个应用,为其添加特定的限制,从而管理知识产权交易及相关事项中的有关对象,例如已定义的元数据元素和运行政策。Handle System 是数字对象体系结构的解析组件,设计用于在网络中长时间管理信息。虽然 DO 架构的其他组件(资源库与注册组件)不是 DOI 系统的组成部分,但实现某些 DOI 功能需要对其加以利用。(请参见第5章,“应用”,5.7 小节 )

Handle System 由本地 handle 服务组成。一个本地 handle 服务 (LHS) 由一个或多个站点组成,一个网站由一个或多个 handle 服务器组成。Handle 服务器存储 handle。每个本地 handle 服务都是唯一的,handle 存储于全球 Handle 注册中心®。LHS 利用“前缀”handle 查询存储于其他 handle 的服务。DOI 号专有使用指定的前缀 10 作为其 Handle 语法的一部分,并用于区分与本手册中描述的 DOI 系统整体使用的其他 handle 。

有关 DOI 使用 Handle 的更多信息,请参阅专题资料 DOI 系统®与 Handle System® 。有关 Handle System 的更多信息,请参阅关于 Handle System 和 Handle.net 软件的一般性及技术性常见问题解答

 

3.5.2 DOI 号解析技术支持

根据合约,CNRI 继续为 DOI 系统提供技术与运行支持。未来和现在的注册机构可以查询相关的技术服务协议,以获取更多信息。

 

3.5.3 使用 DOI 号的软件支持

请查阅 DOI工具列表,可以了解当前正在使用和开发中的工具及其描述和资源链接。

CNRI 提供了伺服小程序和工具,可能对一些用户和程序员具有实用价值。(请联系 Handle System 管理员以获取信息:hdladmin@cnri.reston.va.us)。包括:

net.handle.batch.DOIBatch

一个 DOI 号的批加载程序。

net.handle.apps.admin_servlets

该伺服小程序用于通过网络管理 handle。如果您允许从本地 web 服务器管理 DOI 号,则该程序十分有用。

net.handle.apps.simple

如果您决定推出自己的 handle 软件,该程序包提供了若干关于如何使用 handle 客户端库的例子。

net.handle.apps.tools, net.handle.apps.site_tool

一些用于低级别 handle 服务器维护的工具。在编写自己的代码前,请确保检查无误。

应用程序接口 (API)

除 Java 外,库可用于 Python、Perl 和 C 语言。DOI 系统所特有的库正在开发 Acrobat/DOI 系统服务原型。

 

3.6 DOI 号“状态数据”的维护

DOI 系统的高效运行取决于 DOI 号到相应 URL 或其他数据类型的精确解析。

DOI Data

图2:DOI 号记录

维护“状态数据”是 DOI 号注册者的基本责任之一。要维护状态数据,注册者或服务机构必须以注册人授权的身份进行操作。针对 DOI 号记录中 DOI 号状态数据,IDF 目前正设想并研发更精密的的许可和访问模型。

Handle System 中,DOI 号能够解析为的数据类型是完全可以扩展的,从而允许将 DOI 号解析为互联网上可访问的任何数据。

对于数据类型的 URL(目前最常用的应用)的使用,我们建议为 DOI 号输入完整路径(例如:http://www.somepublisher.com/photo/photo#1.gif),而不是相对路径。当使用相对链接作为 DOI 号数据时,我们无法了解要解析的 DOI 号所处的环境(即当前的 html 状态)。

DOI 号可以解析为 Java 小程序或 CGI 脚本或其他动态机制。

 

3.7 Handle System 解析接口

当前的网络浏览器技术需要额外的功能,才能够处理对象编号,而不仅仅是网络地址(网络常见的命名方法)。因此,为了充分利用 DOI 号解析功能,很有必要为浏览器添加额外的功能。据预测,未来的网络浏览器将广泛内置解析功能,IDF 正在积极协商推广此想法。目前采取各种方式提供所需要的功能。

 

3.7.1 定制解析软件

Handle System 客户端库免费提供,并可根据需要用于开发新的解析客户端,既可作为独立的应用,也可在完全独立的系统中使用。由于解析是免费的,因此可以脱离 IDF 完全独立使用,但我们鼓励开发者告知我们这些应用,从而我们可以 1) 推广给他人(如果它是公开的),2)与开发者合作,以加深其对 DOI系统的了解,从而帮助他们取得成功。

 

3.7.2 本地解析器

从 CNRI 获取可用的“解析器插件”,使用浏览器即可将 DOI 号解析为“doi:10.123/456”的形式,而不必再使用代理服务器。用户仅需下载并安装该插件,之后“单击”DOI 号(或在浏览器地址栏中输入 DOI 号)即可直接解析该 DOI 号。请参阅其他 HANDLE.NET® 软件

 

3.7.3 代理服务器

另外,无需扩展网络浏览器的功能,用户可以使用 DOI 系统代理服务器(http://doi.org(首选)或 http://dx.doi.org)解析 DOI 号。在这种情况下,DOI 号解析依靠使用 URL 语法:一直使用的示例 DOI 号 (doi:10.10.123/456) 就是从以下地址解析而来的:“http://doi.org/10.123/456”。任何标准浏览器都能够解析这种形式的 DOI 号。代理服务器(包括 doi.org 和 dx.doi.org)可以通过 IPv6 访问,并支持 DNSSEC。

使用代理服务器(Handle System 和 HTTP 之间的网关)不会影响 HTTP 的引用字段(即链接源得以保持,似乎用户来自源链接,而非 doi.org 或 dx.doi.org)。仿佛从未“经过”代理服务器:它会发送一个包含当前 URL 或 handle 解析相关信息的重定向到原来的客户端,像通常的情形一样,最终 HTTP GET 来自用户客户端的请求。

通过 HTTP 代理服务器使用的 DOI 号(在 “http://doi.org” 中生成 URL)将保持其持久性。只要 (1) 保持 DOI 系统核心,即,只要给定的 DOI 号 (10.123/456) 可以使用 Handle System 进行解析,以及 (2) 名为 doi.org 的代理服务器保持运行,以及 (3) 提供基于 http 网络运行的核心网络服务功能保持正常工作,那么使用代理解析的 DOI 号 (http://doi.org/10.123/456) 就能够保持持久性。理解其运行理念的关键在于模块化。代理服务器使用、但不仅限于使用核心DOI 号解析服务。核心 DOI 号解析系统可以添加其他网关和其他方法,且丝毫不影响 doi.org 代理的持续运行。

在创建和推广使用代理服务器的同时,CNRI 和 IDF 一直致力对代理服务器的精心维护,因为这是保证数以百万计基于 DOI 号网络链接完整性的核心部件。随着时间的推移,保证这些链接的功能要求同时维护核心 DOI 系统和特定的网关服务:doi.org,从而这些链接实例能够访问核心 DOI 系统。当然,这并不是唯一的方法,只是互联网分层服务的一种变化形式。doi.org 本身依赖于域名系统 (DNS)、IP 寻址和路由等。随着时间推移,核心 DOI 号解析功能将以多种方式为多种服务所使用,这个流程也将变得越来越复杂(我们希望如此)。例如:OpenURL 解析器发现了 DOI 号的原始形式(如 id=doi:10.123/456),便可使用 doi.org 代理,或设置立自己的网络-DOI 号代理服务器,亦或使用 handle 协议直接查询 DOI 系统。

IDF 会员和 RA 可以查阅代理政策的相关信息。
 

3.7.4 代理认证、监视和报告

IDF 会员可以查阅关于代理认证要求、监视和报告政策的总结

 

3.7.5 其他机制

所需功能也可能通过脚本的形式发送给浏览器,如JavaScript。但是,从长期 DOI 系统策略出发,我们并不鼓励采用这些方式,因为出于中长期考虑,并不能保证浏览器支持这些脚本,例如:目前许多安全专家正呼吁电脑用户在电子邮件系统设置中关闭 JavaScript。

对于相关的应用,还请注意,DOI 是在 info-URI 命名空间(IETF RFC 4452,公共命名空间中带标识符的信息资产“info”URI 方案)中注册的 URI。另请参阅专题资料“DOI 系统与网络标识符规范”。

 

3.8 DOI 系统代理服务器技术细节

用户可以使用 DOI 系统代理服务器(http://doi.org(首选)或 http://dx.doi.org)解析 DOI 号。在这种情况下,DOI 号解析依靠使用 URL 语法:一直使用的示例 DOI 号 (doi:10.10.123/456) 就是从以下地址解析而来的:“http://doi.org/10.123/456”。任何标准浏览器都能够解析这种形式的 DOI 号。代理服务器(包括 doi.org 和 dx.doi.org)可以通过 IPv6 访问,并支持 DNSSEC。

 

3.81 使用代理服务器系统解析 DOI

DOI 系统使用Handle System® 管理数字对象(请参阅资专题资料“DOI 系统与 Handle System”)。从架构层面来看,DOI 号即为 handle。

DOI 系统代理服务器本质上是一个 Web 服务器,懂得如何与 Handle System 对话。本文中,大多数网络上的 DOI® 号都嵌入在 URL 中,即使用代理服务进行 DOI 号解析。对于所有包含代理域名和 DOI 号的 HTTP 请求,例如:

http://doi.org/10.1000/demo_DOI

代理服务器将向 Handle System 查询该 DOI 号,从 handle 记录中获取 URL(或如果 handle 记录包含多个 URL 时,则随机挑选一个),并发送一个 HTTP 重定向到该用户的网络浏览器。

随着 DOI 号数量的增加,DOI 号中除单个默认的 URL 以外,还添加了其他数据。这有时被视作多重解析。更高级的应用可以使用这些附加的值。这些应用能够使用多条数据,例如,增强的元数据位置或有关文档。

代理服务器不仅能处理 URL 类型值,还能处理 10320/loc 类型值。这些值由 XML 组成,里面包含了 DOI 号的多个跳转链接以及代理服务器在哪种情况下使用信息。更多相关信息,请查看 3.8.4.3 使用 10320/loc Handle 类型及多重解析

当无法找到查询的 DOI 号时,代理服务器默认显示“未找到 DOI 号”的错误页面。

10.1000/demo_DOI10.1000/demo_DOI/都是有效的 DOI 号,但DOI 号不以斜线结尾。如果代理服务器收到请求,解析一个以斜线结尾的 DOI 号,则无法找到该 DOI 号。代理服务器将返回一个错误报告,警告请求的 DOI 号以斜线结尾,并提供一个链接,用于解析包含相同字符串但不以斜线结尾的 DOI 号。

DOI 系统代理服务器事实上是运行在不同地点的多个服务器,各服务器均分负载。为了加快解析速度,代理服务器缓存 handle 值,TTL 设置为 24 小时。这意味着,如果一个 handle 值被改变时,需要 24 小时才能返回新的值。

注意 IDF 同时为 shortDOI® 服务运行的代理服务器不适用此 DOI 系统代理服务器规范。

 

3.8.2 代理服务器查询参数

noredirect
不使用 URL 或 10320/loc 值重定向;而显示 handle 值。
ignore_aliases
通常代理服务器会将 HS_ALIAS 类型值视为该解析的值;使用该参数,HS_ALIAS 类型值将被忽略。
auth
权威查询。代理服务器将跳过缓存,通过一个权威的服务器解析该 handle 值。
cert
认证查询。代理服务器要求收到 handle 服务器一个验证响应。最终用户通常不需要使用该参数。
index
只在指定的索引解析该 handle 值。解析多个索引时可重复使用。
type
只解析特定类型的 handle 值。解析多个类型时可重复使用。
urlappend
该参数的值可添加在重定向 URL 的末尾
locatt=key:value
多重定向时使用;通过指定 key:value 值对来决定 10320/loc 值中重定向选择。
action=showurls
多重定向时使用;返回可能的 XML 格式的重定向地址。
nols=y
某些图书馆或机构的特殊 cookie 会导致 DOI 系统代理服务器使用本地服务将用户重定向至“合适版本”。例如,用户可能被重定向至图书馆已的购期刊全文地址,而不是一个提示需要付费的登陆网页。用户可使用该参数阻止本地服务的重定向。
 

3.8.3 代理服务器 REST API

DOI 系统代理服务器 REST API 提供了通过 HTTP 实现有计划的访问 DOI 号解析服务。

请求/响应 示例

一个 REST API 请求可通过标准的 HTTP GET

/api/handles/<handle> 发出

API 返回 JSON。

例如,http://doi.org/api/handles/10.1000/1 得到的响应为:

{ "responseCode": 1, "handle": "10.1000/1", "values": [ { "index": 100, "type": "HS_ADMIN", "data": { "format": "admin", "value": { "handle": "0.NA/10.1000", "index": 200, "permissions": "011111111111" } }, "ttl": 86400, "timestamp": "2000-04-13T15:08:57Z" }, { "index": 1, "type": "URL", "data": { "format": "string", "value": "http://0-www.doi.org.libus.csd.mu.edu/index.html" }, "ttl": 86400, "timestamp": "2004-09-10T19:49:59Z" } ] }

响应格式

响应是一个 JSON 格式的对象,包含一个“响应代码”(一个代表 Handle 协议响应代码的整数)、该 handle 值解析后得到的值,以及或是值列表,或是遇到错误,一个描述错误信息的字符串。

每个值都是一个 JSON 对象,通常包含 5 个属性:

Handle 值 data 是一个包含 "format"、string 和 "value" 3 个属性的对象。

响应代码

查询参数

DOI 系统代理服务器 REST API 是 CORS 兼容的;但是,JSONP 同时也支持使用 "callback" 查询参数。

查询参数 "pretty" 可使服务器对 JSON 进行美化后输出。

查询参数 "auth" 可使代理服务器跳过缓存,通过查询主 handle 服务器获取最新的 handle 数据。

查询参数 "cert" 可要求代理服务器从源 handle 服务器得到一个验证响应。最终用户通常用不需要使用此参数。

查询参数 "type" 和 "index" 可对解析响应的类型及索引进行限制。可设置多个 "type" 和 "index" 参数,并以此来获取符合要求的值。例如 :

例如,http://doi.org/api/handles/10.1000/1?type=URL&callback=processResponse 得到的响应为:

processResponse({ "responseCode": 1, "handle": "10.1000/1", "values": [ { "index": 1, "type": "URL", "data": { "format": "string", "value": "http://0-www.doi.org.libus.csd.mu.edu/index.html" }, "ttl": 86400, "timestamp": "2004-09-10T19:49:59Z" } ] });
 

3.8.4 附加功能

一些附加功能已置入 DOI 系统代理服务器,为使用 DOI 服务器设定其 DOI 号的 DOI 系统用户提供附加服务。

3.8.4.1 本地内容服务器(“合适版本”问题)

学术和技术杂志上文章的 DOI 号通常解析到出版商网站。通常需要付费或者订阅才能够从那些网站上检索此类文章。图书馆通常会购买一份或订阅多份杂志作为馆藏,供其读者查阅。对于这些机构的用户,需要根据发出解析请求的用户的位置和关系相应地解析该 DOI 号所在地址,合理的做法通常是选择该机构本地副本中的一个。
国际 DOI 基金会,CrossRef CNRI ,图书馆和图书馆服务提供商称其为“合适版本”,开始合作研究解决方案,并于 1999 年开发了一个原型。(详见 D-Lib 杂志 ,2001年9月,“ Linking to the Appropriate Copy ”)。
DOI 号解析系统、CrossRef 元数据数据库和 OpenURL 联合为图书馆提供切实可行的合适版本解决方案。该架构的关键组成部分包括:(1) 可以满足图书馆合适版本项目查询的本地内容服务器;(2) 可以将查询重定向到本地内容服务器的DOI 号解析系统;(3) 查询发起者识别解析系统中适当的本地内容服务器的方法;(4) 大量关于查询项目的元数据资源,以满足本地内容服务器对合适版本的查询。
CrossRef 为其图书馆联合会员单位提供如下解决方案:会员机构用户点击 DOI 号,该 DOI 号和一个 cookie(已通过“CookiePusher”机制在用户的网络浏览器中预先设定)即被发送到 DOI 系统代理服务器。代理服务器识别标识在 cookie 中的本地内容服务器,创建包含 DOI 号的的 OpenURL,通过 HTTP“重定向”到用户网络浏览器的方式发送到用户的本地域名解析。本地解析器将 DOI 号以 Ope​​nURL 的格式发送到 CrossRef。CrossRef 返回以 DOI 号命名项目的元数据。本地内容服务器将其识别为本地所有文章,创建一个指向该项目的 URL,并将其作为 HTTP“重定向”发送到用户的网络浏览器。
如果该文章不是本地所有的,则本地内容服务器将该请求返回到代理服务器,并标记为无本地副本,之后代理服务器将以通常的方式解析该 DOI 号,并重定向用户的网络浏览器到出版商网站。
要获取该流程的完整说明,并了解图书馆加入该本地链接解决方案的方法,请登陆官方网站,浏览关于 CrossRef 附属图书馆本地链接的文档
截至本文撰写期间,仍然只有 CrossRef 为大多数与该问题相关的 DOI 号及关联元数据提供解决方案。无论如何,这种情况将随着 DOI 系统的持续发展不断得到改观。普遍认为,未来将提供多个元数据源。这就要求同时调整 DOI 号解析数据与本地内容服务器行为。寻求解决最初“合适版本问题”的合作团队认识到了这一点,已就该专题进行了初步讨论,并期望更多合作的加入,以改观现状。
“CookiePusher”机制(请查看 D-Lib文章了解详细信息)用于在用户的浏览器中设置 cookie。cookie 中包含 URL 并能够被代理服务器所识别。代理服务器将根据该 URL 重定向 DOI 号解析请求。为防止未授权用户设置 cookie 和重定向流量到其自己的解析器,CookiePusher 机制提供了一个 BASE-URL列表,其中包含已授权本地内容服务器的 URL。BASE-URL 可以是脚本或目录的 URL,甚至是顶级域名,但必须是 OpenURL 能够识别的服务器。如果请求中的 BASE-URL 不在列表中,则该脚本将不会设置 cookie,但会返回一条“没有你所查询的 cookie”的消息。当 CrossRef 附属机构加入时,便采集了其 BASE-URL。

CookiePusher 脚本在 DOI 系统的网站上运行 ( http://0-www.doi.org.libus.csd.mu.edu )。代理服务器( http://doi.org (首选)或 http://0-dx.doi.org.libus.csd.mu.edu )位于 DOI.ORG ®域名下。CookiePusher 脚本的URL 为:

http://0-www.doi.org.libus.csd.mu.edu/cgi-bin/pushcookie.cgi

以下示例中,向 CookiePusher 的请求包含了本地内容服务器的 URL 前缀:

http://0-www.doi.org.libus.csd.mu.edu/cgi-bin/pushcookie.cgi?BASE-URL=http%3A//university.library.edu%3A9003/local_linking/
建议使用 URI 十六进制 (%) 编码。

在欢迎页或登陆页,向用户网络浏览器 cookie 文件添加 cookie 的请求通常是不可见的,可以使用透明的 GIF。

<img src="http://0-www.doi.org.libus.csd.mu.edu/cgi-bin/pushcookie.cgi?BASE-URL=
http%3A//university.library.edu%3A9003/local_content_server/">transparent.gif</img>

下面是一个拥有 24 小时 TTL 的 cookie 示例:

Name: Demo-OpenURL
Information: \"http://university.library.edu:9003/local_content_server"
Domain: .doi.org
Path: /
Server Secure: no
Expires: Wednesday, October 23, 2013 10:28:11 PM

cookie 设置后,代理服务器将识别 cookie 中标识的本地内容服务器,创建包含本地内容服务器 URL 和 DOI 号的 OpenURL:

http://university.library.edu:9003/local_content_server/openurl?doi=10.1000/demo_DOI
并通过 HTTP “重定向”到本地内容服务器的方式发送请求。

如果没有本地内容副本,本地服务器必须返回请求到代理服务器,并标记为“NOLS = y”。代理服务器之后将解析 DOI 号,并将用户指向出版商的内容。(仍然支持该原形中所使用的以废除设置“nosfx = y”。) 正确设置“无本地服务”标记对于避免无限循环尤为关键。

http://doi.org/openurl?id=doi:10.1000/demo_DOI&nols=y

3.8.4.2 参数传递

DOI 系统和 CrossRef 出现以前,学术出版界实施了双边链接协议,使用的参数(doi/元数据)包含在标准的 URL 中以进行数据交换。该方式使其能够收集来自其他站点的请求,比如请求来自于其他发布商的网站,或来自于某个期刊和某篇文章。之后,他们可以根据请求发出者的情况,实施特定的访问规则或为其内容定价。
当出版商开始使用 DOI 号后,他们也开始思考如何使用 DOI 号和 DOI 系统的代理服务器,以便于参数交换并摒弃个人双边链接协议。各出版商经过多年协商、不断改进,通过了一个流程。该流程通过代理服务器实现,被称作“参数传递”。这些出版商现为 CrossRef 成员。
在参数传递中,涉及两个 URL,两者均可能为查询字符串,且/或包含参数:(1) “查询者”将包含 DOI 号的解析请求发送至 http://doi.org/;(2) “所指对象”在 DOI 系统中注册与 DOI 号相关联的 URL。参数传递需要将这两个 URL 的查询字符串结合在一起,形成一个“出站”链接。两个字符串中使用的参数名称必须是唯一的,并为各方定义。URL 选择使用 OpenURL 格式是因为其指定了一组参数名称可避免出现命名冲突。(要了解用于参数传递的可用 OpenURL 参数,以及特定的常用 CrossRef 参数集,请参阅“通过 DOI 系统代理进行参数传递 。)

DOI 系统代理服务器接受 OpenURL 形式的解析请求。例如 :

http://doi.org/openurl?url_ver=z39.88-2003&rfr_id=ori:rid:crossref.org&rft_id= doi:10.1256/003590&rfr_dat=cr_setver%3d01%26cr_pub%3dSource%20Publisher%26cr_work%3dSource %20Journal%20Title%26cr_src%3dSRC-NAME
将由代理服务器识别为一个参数传递请求。解析 DOI 号后,将根据一个“选择性加入”列表检查该域名 URL(该列表中标识了参与参数传递的机构)。

如果该 URL 此列表中,则代理服务器将创建一个新的 URL,如下所示:

假定所指对象已经开启能够使用嵌套参数的服务,如果同意加入参数传递,出版商将接受常用 CrossRef 参数集中的任何参数。
CrossRef 帮助文档中将讨论 OpenURL 格式变化或参数传递参与者变化所带来的参数变化。

3.8.4.3 使用 10320/loc Handle 类型及多重解析

DOI 系统代理服务器或网络浏览器插件的主要用途之一就是解析 DOI 号 (handle) ,以获取资源的 URL。对于包含多个 URL 值的 DOI 号,代理服务器(位于 http://doi.org 和 http://hdl.handle.net)仅选择 DOI 号解析返回值列表中的第一个 URL 值。因为该列表中的顺序是不确定的,无法智能选择客户端将被重定向的 URL。为了提高从包含多个 URL 的 handle 和 DOI 号选择特定资源 URL 的能力, 以及向 handle 到 URL 解析过程添加新功能,开发了 10320/loc handle 值类型。
背景
每个 handle,即每个 DOI 号,都要分配一组值,其中每个值都有一种类型,用于定义该数据的句法和语法。有些类型的值用于管理:所有者或创建日期。其他则供客户端使用:URL 字符串、电子邮件地址、复杂的数据类型(如二进制数据、XML代码或其他handle)。
如果用户分配的类型未在用户社区内注册和识别,为了避免客户段之间的冲突,类型均分配至他们自己的 handle,从而这些类型可以在 Handle System 中进行定义和识别。目前正在开发这样的程序。前缀“10320”是一个随机五位数字符串,已经被 Handle System 管理员预留,用于标识 handle 类型。对于 10320/loc 类型,后缀“loc”是“location”的缩写形式。
属性
10320/loc 类型指定了一种包含位置列表的 XML 格式的 handle 值。每个位置都有一组相关的属性,如果或当使用地址时,帮助确定该地址。整个位置列表可以向解析客户端提示选择地址的方法,包括一系列按顺序选择的方法。代理服务器(或任何其他解析客户端)可以应用任何已知的选择方法,按顺序根据解析器的环境(在代理服务器的情况下,使用 HTTP 请求)和每个位置的属性,选择一个位置。
位置集合以及集合中每个位置条目的属性是开放式的,以便未来添加功能时可以向后兼容。少数属性已被定义为“标准”,所有的解析器都能够使用。
XML 的顶级结构包含以下已定义的属性:
chooseby
chooseby 属性标识了以逗号分隔的选择方法列表。如果未指定 chooseby 属性,则使用默认值(目前为 “locatt、country、weighted”)。
每个位置均定义了如下的属性:
href (必须)
该位置的 URL。
weight(可选)
使用随机选择时,应为该位置设定 weight (0-1) 。weight 属性设置为 0 时,位置不会被选择,除非 a) 该位置在其他属性中已明确指示;b) 没有其他合适的位置;或 c) 该位置已通过其他方式选择,如国家或语言。如果一个位置没有设置 weight 属性,则假定其 weight 值为 1。
选择方法
目前定义的选择方法有:
locatt
仅从 Proxy/DOI 号-URI 链接中的属性选择位置。如果有人创建了如下链接:doi:10.123/456?locatt=id:1 ,那么解析器将返回一个值为 1的“id”属性(即下面解析示例中的第二个位置)。
country
仅选择与客户端国家位置相匹配的“国家”属性。如果未找到匹配的位置,则选择无国家属性的位置(而不是“匹配错误”)。http://0-hdl.handle.net.libus.csd.mu.edu 和 http://doi.org 代理使用 GeoIP 查找确定客户端所在的国家。
weight
基于随机选择的一个位置。代理将检测每个位置的“weight”属性,应为一个浮点非负数。加权允许进行非常基本的负载均衡,但同时也是一种确保某些地址只能直接寻址的方法(例如通过 country 或 locatt/属性)。如果加权选择方法应用到地址所具有的 weight 均为负数,则从其余地址中进行随机选择,并忽略其位置的 weight。

代理将依次遍历已知的选择方法,直到选出唯一的位置。每次迭代后,代理将采取以下四个步骤之一:

解析

参照 DOI 号 10.123/456,其拥有值类型 10320/loc,具有下表所示的位置属性:

      <locations>
        <location id="0" href="http://uk.example.com/" country="gb" weight="0" />
        <location id="1" href="http://www1.example.com/" weight="1" />
        <location id="2" href="http://www2.example.com/" weight="1" />
      </locations>

有以下选择结果:
參照: 10.123/456 来自位于英国的一个客户端
结果: 根据第一个位置和客户端地址的“country”属性,“country”选择方法选出第一个位置。
參照: 10.123/456 来自位于英国以外的一个客户端
结果: 根据“country”属性,利用“国家”选择方法去除第一个地址,使用“加权”随机选择方法从其余两个地址中选择一个。
參照: 10.123/456?locatt=id:1
结果: 根据“locatt”选择方法和“id”属性,使用第二个位置。
參照: 10.123/456?locatt=id:0
结果: 根据“locatt”选择方法和“id”属性,使用第一个位置。由于“locatt”选择方法选出了唯一匹配的位置,解析器不会继续执行“country”选择方法。
參照: 10.123/456?locatt=country:uk
结果: 根据“locatt”选择方法和“country”属性,使用第一个位置。
參照: 10.123/456?locatt=country:us
结果: 根据“country”属性,未发现与美国相关的位置,利用“国家”选择方法去除第一个地址,使用“加权”随机选择方法从其余两个地址中选择一个。
具体使用案例 - CrossRef
DOI 号 10.1177/1522162802239753 被分配给 Graft: Organ and Cell Transplantation 期刊(已停刊)中的一篇文章,该 DOI 号被更新后指向两家提供该文章的归档服务机构。

包含以下信息的 10320/loc 类型添加到该记录,代理服务器使用其进行重定向:

      <locations chooseby="locatt,country,weighted">
        <location id="1" cr_type="MR-LIST"
                  href="http://0-mr.crossref.org.libus.csd.mu.edu/iPage?doi=10.1177%2F1522162802239753" weight="1" />
        <location id="2" cr_src="clockss_su" label="CLOCKSS_SU" cr_type="MR-LIST"
                  href="http://graft.edina.clockss.org/cgi/reprint/6/1/18" weight="0" />
        <location id="3" cr_src="clockss_edina" label="CLOCKSS_Edina" cr_type="MR-LIST"
                  href="href="http://graft.edina.clockss.org/cgi/reprint/6/1/18" weight="0" />
      </locations>

“chooseby”属性 (locatt、country、weighted) 使用默认设置。在本示例中,前两种选择方法均失效,代理使用“weighted”作为选择标准。第一个位置 (mr.crossref.org) 权重为 1 ,高于另外两个。本示例中,代理重定向到 mr.crossref.org,CrossRef 网站脚本解析该 DOI 号之后,以下列形式将页面展示给用户:
http://doi.org/10.1177/1522162802239753
结果页面显示两个归档服务机构提供该文章的下载。CrossRef 脚本使用 10320/loc 数据中的 id =“2”和id =“3”以显示来自其中一个服务机构的两个资源。
该通用机制可用于多种不同的配置,包括构建一个指定两个位置之一属性的链接作为参数,在这种情况下,用户会仅以通常的方式进行重定向,而显示使用 CrossRef 创建的多重解析页面。作为以前的代理或插件备用系统的原始 URL 服务器并不支持 10320/loc。
 

上一章节:2 编码    下一章节:4 数据模型

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