 |
首页 | 手册 | 专题资料 | 常见问题 | 资源 | 注册机构 | 新闻 | 会员区 |
本章节阐述了 DOI ® 系统的解析元件，及其为标识符和相关数据提供持久关联的能力。本章节还介绍了用于 DOI 号解析的 Handle System® 的概况。
© 国际数字对象标识符 (DOI) 基金会 • 最后更新：2014年8月7日
解析是一个标识输入——请求——发送至网络服务以返回特定输出结果的过程。返回的结果为一条或多条与被标识实体（例如 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.doi.org/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://www.doi.org/index.html" }, "ttl": 86400, "timestamp": "2004-09-10T19:49:59Z" } ] });
CookiePusher 脚本在 DOI 系统的网站上运行 ( http://www.doi.org )。代理服务器（ http://doi.org （首选）或 http://dx.doi.org ）位于 DOI.ORG ®域名下。CookiePusher 脚本的URL 为：
http://www.doi.org/cgi-bin/pushcookie.cgi
以下示例中，向 CookiePusher 的请求包含了本地内容服务器的 URL 前缀：
http://www.doi.org/cgi-bin/pushcookie.cgi?BASE-URL=http%3A//university.library.edu%3A9003/local_linking/
在欢迎页或登陆页，向用户网络浏览器 cookie 文件添加 cookie 的请求通常是不可见的，可以使用透明的 GIF。
<img src="http://www.doi.org/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 基金会商标。 |