 |
首页 | 手册 | 专题资料 | 常见问题 | 资源 | 注册机构 | 新闻 | 会员区 |
本章节阐述了 DOI ® 系统的解析部分，及其为标识符和相关数据提供持久关联的能力。本章节主要介绍 Handle System® 用于 DOI 号解析的概况。
© 国际数字对象标识符 (DOI) 基金会 ? 中文版最后更新：2017年9月
解析是一个标识输入——请求——发送至网络服务以返回特定输出结果的过程。返回的结果为一条或多条与被标识实体（例如 URL）相关的当前信息（状态数据）。多重解析通过 DOI 解析组件使用 Handle System 实现，其返回内容为与 DOI 标注的实体相关的多条当前信息——至少是一个 URL 加上允许管理的已定义数据结构。
DOI® 系统使用 Handle System® 对所指对象进行解析，将 DOI 号（例如 10.1000/140）解析为一条或多条（因此称为“多重”）类型化数据 ：例如 URL 代表（表明）对象、诸如电子邮件之类的服务、或一个或多个元数据项目。新的类型可以随时加入，使得 DOI 解析系统能够非常灵活快速地应对新的要求。解析可以被认为是一种机制，用于维持两个数据实体之间的关系；元数据项目即为被声明存在于两个实体之间的关系：因此，通过解析可以清晰自动地表达实体之间的这种元数据关系。
使用多重解析，DOI 号可以被解析为任意数量的不同关联值：多个 URL、其??他 DOI 号，或其他代表元数据项目的数据类型。解析请求可能返回当前信息的所有相关值，或者一个数据类型的所有值。这些返回值之后将在特定的“客户端”软件应用中做进一步处理。最简单的是，用户只需根据需要选择系统提供的选项即可操作。更复杂的自动化过程考虑到了自动选择正确的值以便于进一步处理。
DOI 的编号可以永久标注特定的知识产权实体（对象），形成的文件可以（或不可）通过互联网访问。URL 提供了与实体相关的特定因特网地址。上述两种标注的应用截然不同：前者标识一个实体，后者标识一个位置（可能或无法在该位置找到特定的实体）。
最早的 DOI 系统应用面向简单、单点的解析，提供了持久性标识符（不会出现“404 not found”错误消息）。每个 DOI 号都解析为一个唯一的 URL。通过在 DOI 记录中管理 DOI 与其解析到的 URL 之间的链接，可以更改实体位置，同时保持该实体编号为可用的标识符。请参见第5章，“应用” ，以了解更多信息。DOI 系统管理中首要的，也是最简单的任务即克服 URL 缺乏持久性的问题。
多重解析允许将一个实体解析为多条其它数据或实体。
DOI 号的解析可以包括，但不限于关联值。如位置 (URL)、电子邮件地址、另一个 DOI 号和描述性元数据。所指对象有多种类型（如抽象“作品”，物理“现象”，或表演），并不总是可直接访问的数字文件或其他形式，也就是说，解析有可能、也有可能不返回该对象的一个实例。解析也可涉及一个或多个中间映射操作。
DOI 解析记录可以包含一个或多??个可以找到对象的 URL。已分配 DOI 号的对象的其他信息可能包括但不限于：
通过自动多重解析，DOI 号可以被解析为互联网上任意数量的点：多个 URL、其??他 DOI 号、以及其他数据类型。如果 DOI 号可以指向多个可能的“解析”，应当如何在不同的选项之间进行选择呢？最简单的是，用户在一个提供的列表中进行手动选择。然而，面对日益复杂化和自动化的环境，这并不是一种可持续的解决方案。DOI 系统能够自动进行“服务请求”。据此，用户（更重要的是用户的应用软件）可以无缝地从一个 DOI 号传递给所请求的特定服务。
请参见下文 3.8.4.3 多重 URL 解析 及第 5 章，5.3 多重解析应用，以了解当前多重解析技术实现的详细信息。
ISO 26234 包含以下 DOI 系统解析中遇到的功能需求：
部署管理 DOI 号解析技术时，应支持下述 a) 至 l) 中列出的功能：
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 软件的一般性及技术性常见问题解答。
根据合约，CNRI 继续为 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 系统服务原型。
DOI 系统的高效运行取决于 DOI 号到相应 URL 或其他数据类型的精确解析。
维护“状态数据”是 DOI 号注册者的基本责任之一。要维护状态数据，注册者或服务机构必须以注册人授权的身份进行操作。针对 DOI 号记录中 DOI 号状态数据，IDF 目前正设想并研发更精密的的许可和访问模型。
Handle System 中，DOI 号能够解析为的数据类型是完全可以扩展的，从而允许将 DOI 号解析为互联网上可访问的任何数据。
对于数据类型的 URL（目前最常用的应用）的使用，我们建议为 DOI 号输入完整路径（例如：http://www.somepublisher.com/photo/photo#1.gif），而不是相对路径。当使用相对链接作为 DOI 号数据时，我们无法了解要解析的 DOI 号所处的环境（即当前的 html 状态）。
DOI 号可以解析为 Java 小程序或 CGI 脚本或其他动态机制。
当前的网络浏览器技术需要额外的功能，才能够处理对象编号，而不仅仅是网络地址（网络常见的命名方法）。因此，为了充分利用 DOI 号解析功能，很有必要为浏览器添加额外的功能。据预测，未来的网络浏览器将广泛内置解析功能，IDF 正在积极协商推广此想法。目前采取各种方式提供所需要的功能。
Handle System 客户端库免费提供，并可根据需要用于开发新的解析客户端，既可作为独立的应用，也可在完全独立的系统中使用。由于解析是免费的，因此可以脱离 IDF 完全独立使用，但我们鼓励开发者告知我们这些应用，从而我们可以 1) 推广给他人（如果它是公开的），2）与开发者合作，以加深其对 DOI系统的了解，从而帮助他们取得成功。
从 CNRI 获取可用的“解析器插件”，使用浏览器即可将 DOI 号解析为“doi:10.123/456”的形式，而不必再使用代理服务器。用户仅需下载并安装该插件，之后“单击”DOI 号（或在浏览器地址栏中输入 DOI 号）即可直接解析该 DOI 号。请参阅其他 HANDLE.NET® 软件。
另外，无需扩展网络浏览器的功能，用户可以使用 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 会员可以查阅关于代理认证要求、监视和报告政策的总结。
所需功能也可能通过脚本的形式发送给浏览器，如JavaScript。但是，从长期 DOI 系统策略出发，我们并不鼓励采用这些方式，因为出于中长期考虑，并不能保证浏览器支持这些脚本，例如：目前许多安全专家正呼吁电脑用户在电子邮件系统设置中关闭 JavaScript。
对于相关的应用，还请注意，DOI 是在 info-URI 命名空间（IETF RFC 4452，公共命名空间中带标识符的信息资产“info”URI 方案）中注册的 URI。另请参阅专题资料“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。
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_DOI 和 10.1000/demo_DOI/都是有效的 DOI 号，但DOI 号不以斜线结尾。如果代理服务器收到请求，解析一个以斜线结尾的 DOI 号，则无法找到该 DOI 号。代理服务器将返回一个错误报告，警告请求的 DOI 号以斜线结尾，并提供一个链接，用于解析包含相同字符串但不以斜线结尾的 DOI 号。
DOI 系统代理服务器事实上是运行在不同地点的多个服务器，各服务器均分负载。为了加快解析速度，代理服务器缓存 handle 值，TTL 设置为 24 小时。这意味着，如果一个 handle 值被改变时，需要 24 小时才能返回新的值。
注意 IDF 同时为 shortDOI? 服务运行的代理服务器不适用此 DOI 系统代理服务器规范。
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://www.bangxi.tw/index.html" },
"ttl": 86400,
"timestamp": "2004-09-10T19:49:59Z"
}
]
}
响应格式
响应是一个 JSON 格式的对象，包含一个“响应代码”（一个代表 Handle 协议响应代码的整数）、该 handle 值解析后得到的值，以及或是值列表，或是遇到错误，一个描述错误信息的字符串。
每个值都是一个 JSON 对象，通常包含 5 个属性：
Handle 值 data 是一个包含 "format"（一个字符串）和 "value" 属性的对象。
响应代码
查询参数
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://www.bangxi.tw/index.html" },
"ttl": 86400,
"timestamp": "2004-09-10T19:49:59Z
" }
]
});
CookiePusher 脚本在 DOI 系统的网站上运行 ( http://www.bangxi.tw )。代理服务器（ http://doi.org （首选）或 http://dx.doi.org ）位于 DOI.ORG ®域名下。CookiePusher 脚本的URL 为：
http://www.bangxi.tw/cgi-bin/pushcookie.cgi
以下示例中，向 CookiePusher 的请求包含了本地内容服务器的 URL 前缀：
http://www.bangxi.tw/cgi-bin/pushcookie.cgi?BASE-URL=http%3A//university.library.edu%3A9003/local_linking/
在欢迎页或登陆页，向用户网络浏览器 cookie 文件添加 cookie 的请求通常是不可见的，可以使用透明的 GIF。
<img src="http://www.bangxi.tw/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
如果没有本地内容副本，本地服务器必须返回请求到代理服务器，并标记为“NOLS = y”。代理服务器之后将解析 DOI 号，并将用户指向出版商的内容。（仍然支持该原形中所使用的以废除设置“nosfx = y”。） 正确设置“无本地服务”标记对于避免无限循环尤为关键。
http://doi.org/openurl?id=doi:10.1000/demo_DOI&nols=y
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
如果该 URL 在此列表中，则代理服务器将创建一个新的 URL，如下所示：
3.8.4.3 使用 10320/loc Handle 类型及多重解析
代理将依次遍历已知的选择方法，直到选出唯一的位置。每次迭代后，代理将采取以下四个步骤之一：
参照 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>
包含以下信息的 10320/loc 类型添加到该记录，代理服务器使用其进行重定向：
<locations chooseby="locatt,country,weighted"> |
 |
®，DOI® ，DOI.ORG® 和 shortDOI® 为国际 DOI 基金会商标。 |