数字资源唯一标识符解析系统研究，本文主要内容关键词为：标识符论文,数字论文,系统论文,资源论文，此文献不代表本站观点，内容供学术参考，文章仅供参考阅读下载。
[分类号]TP393.03
数字资源唯一标识符的产生是为了更好地利用以Internet为应用背景的大量的分布式 的异构资源。数字资源唯一标识符并非只是一堆不重复的字符串，真正有用的唯一标识 符应该形成一整套体系，一般的通用标识符系统应该包括名称空间，唯一标识符，命名 机构，命名登记系统和解析系统5个部分。数字资源唯一标识符的解析(Resolution)， 指的是计算机按照某种协议向某个网络服务递交数字资源的唯一标识符，发出解析请求 ，该网络服务接收该请求后按照某种约定来调出与该唯一标识符所标识对象相关的一个 或多个相关信息，之后将这些相关信息返回给请求者的整个过程。以DNS为例，解析即 是从某个域名(如www.abc.com)起，到获得与之对应的IP地址(如111.123.123.123)的过 程，之后计算机使用该IP地址与相应的Internet主机通讯。而DOI的解析是通过Handle System来实现的，解析从一个DOI开始，如10.123/123.111，到获得一个或多个相关的 结构化数据为止的过程，获得的结构化数据可以是指示对象实例存放地址的URL，或是 与标识对象相关的E-mail，或是一项或多项元数据。解析可以被认为是维护两个数据实 体间相互关系的一种机制；描述实体的元数据的一项即是对两个实体间的某个关系的声 明，这种关系通过解析来完成自动化的链接。
对于一个标识符系统来说，解析机制是其重要的组成部分，是实现标识符的可操作性 和互操作性的基础。不能够实现解析的标识符仅仅能起到标识对象的作用，在具有极大 资源量的Internet环境中，若不能由计算机及网络自动化完成实体间关系的关联就意味 着该标识符几乎没有价值。因此，建立一个强大而适用的解析机制并在其上形成解析系 统对于一个运用在Internet环境下的数字资源唯一标识符系统来说是至关重要的。
1 现有标识符解析机制分析
信息技术发展到今天，已经形成了很多应用在不同环境下的标识符方案，但是，很多 标识符方案仅仅定义了一个标识符名称空间及标识符语法构成机制，尚未形成一个完整 的包含解析系统在内的标识符系统。这类标识符包括：SICI，BICI，PII等等。这类标 识符详细地定义了其构成规则并由特定机构对其进行登记管理，但是其在制定时并没有 为其设计一套用于Internet环境的分布式的解析和管理机制，当需要对这些标识符进行 解析(即请求获得与其标识对象相关的信息)时，通常由使用该标识符的机构或系统通过 自定义的协议和约定来实现标识符与对应资源间的实际链接关系。因此，该类标识符没 有特定的解析机制和规则供研究分析。
URI/URN在高层为标识符的唯一化提供了解决方案，然而，它们并没有提供生存在网络 环境中的数字资源唯一标识符的解析机制的底层方案。URI只是规定了统一资源标识符 的语法构成，并未设计URI的解析机制，实际上也无法定义出一个解析机制，因为URI的 任务是运用不同的标识符方案名称将不同方案下可能相同的内部标识符区分开，以便形 成持久稳定互不冲突的唯一标识符，不同标识符方案可能采取不同的解析机制，URI工 作组不可能设计一套高层机制来包容现有的和潜在的解析机制，URI中“Uniform”指的 是标识符的统一，而非解析机制的统一。而URN的出现似乎是想在统一解析上跨出一步 。IETF URN工作组不仅制定了URN构成语法和注册程序，同时也在努力制定一套解析机 制，虽然目前这套机制离实用还有相当大的距离，而且研究进度很缓慢。URN工作组制 定的解析机制的基本思想是实现一个RDS，即Resolution Discovery System或Resolver Discovery Service。顾名思义，RDS工作在各标识符解析系统之上，为各种标识符提供统一的解析入口，使客户端系统无需判断不同的标识符应该采用何种系统来解析，而是统一地交给RDS去发现。其工作机理的简单示意图如图1所示。
当客户端识别出一个URN时，将其交给RDS处理，RDS负责发现可以解析该URN的实际解 析系统，并按照合适的规则将解析请求发送给该解析系统，之后真正的解析系统将标识 符解析后返回相关数据给客户端。从客户端的角度看，这是一个比较理想化的系统，因 为客户端无需直接面对并识别不同的标识符方案，因为不同的方案都由URN规则统一起 来并由RDS统一处理。但是，这样的RDS目前还没有很好地实现，更达不到广泛实用的阶 段，而且业界对这种方式也颇有争议，因为实际的解析仍然由各个标识符方案所依托的 解析机制来完成，在其上层附加的RDS实际上并未做实质性的工作。虽然URN和RDS被人 们关注和期待很久，但是目前仍不是解决标识符解析最本质最实用的方法。
当前最为普遍和实用的标识符解析机制仍然是基于HTTP/DNS的。虽然URL不足以担当新 形势下唯一标识符的重任，但是其作为Internet重要的基础组成，仍然被许多系统用来 对资源进行标识，并依托其现成解析机制对标识符和相关资源进行链接。利用URL充当 资源的标识并利用HTTP/DNS来进行解析存在着一个致命的缺陷，那就是，URL本身指示 的是资源的某一个实例对象所存放的地址，而随着时间的推移，对象的实际地址可能发 生迁移，而如果仍然使用原URL来标识对象，显然无法解析得到正确的结果。
为了解决因资源或系统更新而引起的URL失效问题，现有的系统大多采取URL重定向的 机制，即保留原有的URL标识，当该URL已经过时时，使用某种对应法则来将旧URL和新URL相关联，当用户请求原有URL时，仍然可以访问到更新过的资源。这种URL重定向可 以由系统构建者自己来实现，也可以象OCLC的PURL系统那样由一个统一的映射转换机构 管理和维护。这种保持标识符的持久性和可解析性的实现方式简单易行，然而缺点也很 明显，由于受到URL和HTTP自身规则的限制，使得该方式无法满足新形势下对唯一标识 符系统的灵活命名、持久稳定、协议独立、分布式解析及管理、互操作等一些要求，因 而该方式只能是个过渡性的策略。
目前比较成熟、被业界认可且已进入实用阶段的标识符解析系统便是Handle System。 Handle System是一个通用的分布式名称服务系统，它包括一套开放的系统协议，唯一 标识符名称空间以及协议的参考实现模型。该系统最早由美国DARPA资助CNRI机构进行 研发，目前Handle System的相关标准已被IETF接收为RFC文档。与其它的解析系统或机 制相比，Handle System优势在于：
(1)命名系统灵活，与URN兼容，可保持标识符的唯一性及持久性。
(2)基于Handle的命名机制可以包容现有的标识符方案。
(3)内建一套完善的Handle协议来支持对Handle的解析。
(4)对单个Handle可实现多重解析。
(5)Handle命名和Handle Protocol均实现国际化支持。
(6)分布式的服务和管理模式。
(7)安全而高效的解析和管理机制。
Handle System的这些特点使其明显优于其它解析方案，而基于Handle System实现并 投入使用的DOI系统的成功更是证明了Handle System是目前实现标识符解析服务非常理 想的途径。这次科技部科技基础性工作专项资金重大项目《我国数字图书馆标准规范建 设》之《数字资源唯一标识符应用规范》子项目研究小组以Handle System为蓝本，研 究、开发并在国内实验性部署了唯一标识符解析系统体系，取得了非常好的效果。
下面我们将以Handle System为主要研究对象，对其架构组成、运作机理等进行分析阐 述，并简要介绍基于Handle System的唯一标识符系统在国内的实验部署情况。
2 Handle System的名称空间
作为一个标识符系统，Handle System把标识符统称为Handle。Handle System名称空 间(Namespace)定义了Handle的构成法则。
Handle是由不同字符构成的字符串。Handle System中的每个handle由两部分组成：Handle的命名授权部分(Naming Authority，或视为前缀)以及跟随其后的在该命名授权 下唯一的本地名称(local name，或视为后缀)。命名授权(简称NA)和本地名称间通过ASCII字符“/”(0x2F)来分开。表1给出了以ABNF[1]表示法来定义的handle语法构成。
表1 handle语法构成
- FF)
；任何可以映射成UTF-8编码的
；Unicode 2.0字符的8位字节，
；除了0x2E和0x2F(对应于ASCII字符'.'
和'/')
；任何可以映射成UTF-8编码的
；Unicode 2.0字符的8位字节
举例来说：10.45/abc是一个符合Handle语法的标识符，它可以在互联网范围内唯一标 识某个资源对象。这个标识符的命名授权(前缀)分为两级：10是顶级命名授权，45是10 的下一级，这类似于域名的分级制度。整个命名授权10.45通常分配给某个机构，而本 地名称abc可以是该机构内部生成的一个用来标识自有资源的号码。
基于Handle结构的标识符最基本的命名原则是唯一性，在Handle System中，唯一标识 符Handle是由前缀和后缀两部分构成的，Handle的唯一性因此也由前后缀一起来达成。 在不同的前缀下，后缀可以相同，但在同一个前缀下，所有的后缀必须是互不相同的。 后缀的唯一性首先由唯一标识符的注册者在生成标识符后缀时来确认，在最终注册时会 由Handle系统来保障整个标识符的唯一性。
从Handle System名称空间的定义上来看，其结构简单易于实施，对于前后缀构成几乎 没有约束，因此可以很好地继承现有的一些标识符命名规则。此外它规定使用Unicode 2.0字符集及UTF-8编码，可以实现国际化支持。
唯一标识符生成后，需要在Handle System中注册才能够生效。Handle System负责对 唯一标识符及相关信息进行管理，并提供一套机制对唯一标识符进行解析。下面将介绍 Handle System是如何构成一个分布式名称服务系统来管理和解析唯一标识符的。
3 Handle System服务体系
3.1 Handle System体系框架
Handle System采用一种分布式、可伸缩可扩展的结构，通过Handle协议将系统的各个 服务组件联系起来，其整体架构如图2所示：
Handle System定义了一套分层的服务模型，其整体是由许多Handle服务来构成的。处 于Handle System顶层的服务称为全球Handle注册中心—Global Handle Registry(GHR) 。Handle System中所有的命名授权均由GHR来进行管理，只有在GHR中注册后，命名授 权才能够生效。在系统中，命名授权是作为Handle来管理的，这样的Handle称为NA Handle。NA Handle为客户端访问和利用Handle服务组件提供必要的信息。
在GHR下分布着很多其它的Handle服务，通常被称为是区域Handle服务—Local Handle Services(LHS)。每个LHS服务管理着Handle System下的一个子名称空间(Sub-Namespace)，不同LHS服务下的名称空间互不重叠。子名称空间通常由一些命名授 权下的Handle集组成，负责这些命名授权的Handle服务称为主服务(Home Service)，并 且是唯一一个为这些命名授权下的Handle提供解析和管理服务的Handle服务。由于命名 授权存在分级关系，所以，对命名授权负责的LHS也存在多层的上下级关系。
LHS实际上是一个逻辑上的服务概念，一个LHS将由一到多个服务站点(Service Site) 来构成，不同的站点可以分布在不同的地域，而同一个LHS服务下的各服务站点的功能 是一样的，可以将它们视为镜像关系。同一LHS下服务站点数量的多少可以根据实际需 要来配置。每个服务站点最终由若干台Handle服务器来构成，发至服务站点的Handle请 求最终被分发给这些Handle服务器。一个LHS所负责的子名称空间下所有的唯一标识符 及与标识对象相关的信息(这里称为标识符值集)分布存储在这些Handle服务器上，由其 响应用户请求并返回相应结果。
Handle System可以由任意数量的Handle服务组成；而构成Handle服务的服务站点的数 量从设计上讲并没有限制；同样对构成服务站点的服务器的数量亦无限定。服务站点间 的复制并不要求每个站点包含同样数量的服务器，换句话说，只要每个服务站点拥有相 同的复制了的Handle集，则每个站点可以将这些Handle分布在不同数量的Handle服务器 上。这种分布式方法为系统适应任意数量级的操作提供了可伸缩性，并且可以减轻或避 免系统单点出错造成的危害。
3.2 Handle System的管理和解析服务
由于Handle System本身采用分布式的架构，因此其管理和解析的模式也是分布式的， 你可以使用浏览器或专门的客户端管理工具在任何可以接入Internet的地方来对Handle 进行管理和解析。
基于Handle的唯一标识符由命名授权和本地名称来构成，一个机构如果需要为自己的 资源注册唯一标识符，首先需要向注册代理机构申请某个级别的命名授权，类似于域名 的申请；一旦获得命名授权，机构便可以将资源的内部标识(需要具有内部唯一性)作为 本地名称与命名授权结合成一个Handle并在Handle System中注册。在Handle System中 ，不仅维护着众多的唯一标识符，更重要的是维护着与唯一标识符所标识对象相关的一 些信息，这些信息在解析时可以返回给用户，以便告知被标识对象是什么样的资源，如 何获取该资源及相关的服务等。
唯一标识符及相关信息的注册可以使用管理工具批量地进行，数据注册完成后，唯一 标识符可以在互联网上进行发布，用户便可以利用各种解析途径来对唯一标识符进行解 析。目前支持的解析途径包括：使用专门的客户端管理工具，使用装有解析插件的浏览 器，使用HTTP代理服务器以及利用Handle System API来编程解析。无论哪种解析方式 ，其基本原理是相同的，其解析过程如图3所示。
假设用户在浏览互联网时遇到一个唯一标识符为10.abc/s13-u，它标识着某篇文献， 用户希望解析该标识符得到与文献相关的信息，或者下载全文，为此，
(1)用户的浏览器首先将该唯一标识符的NA Handle:0.NA/10.abc发送给GHR系统。
(2)GHR查询其Handle数据库，找到负责命名授权10.abc的LHS服务信息，该服务信息描 述了LHS的构成，包括该LHS由哪几个站点构成，每个站点包含几台服务器，各服务器的服务地址和端口是什么，该命名授权下的Handle如何在这些服务器上分布等等。
(3)客户端浏览器得到该服务信息后，据此判断10.abc/s13-u这个标识符应该发往服务 站点中的哪台服务器去解析。
(4)随后，浏览器对应的Handle服务器发出解析请求，在此期间，可能会根据需要对通 讯双方进行认证。
(5)Handle服务器根据客户端的请求从数据库中检索出与唯一标识符对应的信息，将解 析结果返回给用户。
4 Handle System协议简介
Handle System各服务组件基于Handle System Protocol来进行通讯。该协议是一个Client Server型协议，客户端软件使用该协议来通过网络向Handle服务器递交请求。 每个请求描述了要在服务器端执行的操作。服务器将处理收到的请求并返回一个指示操 作结果的消息。Handle System Protocol描述了客户端定位负责某个指定Handle的Handle服务器的程序，并定义了为执行任何handle操作而在客户端和服务器之间交换的 消息的语法和语义构成。Handle System Protocol包含的几个关键方面有：
(1)Handle Protocol既支持解析也支持管理。
(2)客户端可以用服务器的数字签名来对任何服务响应进行认证。
(3)服务器可以通过Handle认证协议来认证其客户端为Handle管理员。Handle认证协议 是一个Challenge-Response协议，支持基于公钥(Public-Key)和密钥(Secret-Key)的认 证。
(4)协议可以扩展以支持新的操作。控制指令可以用来扩展已有的操作。并且协议在定 义时允许向下兼容。
(5)分布式服务架构。支持不同服务组件间的服务引用。
(6)Handle及其数据类型均基于ISO-10646(Unicode 2.0)字符集。UTF-8是Handle Protocol强制的编码方式。
目前发布的最新的Handle System Protocol规范是2003年11月的2.1版本RFC 3652[4] 。该规范非常细致地描述了底层协议的组成元素的构成规则和各部分的意义，包括对数 据传输顺序、传输层、字符大小写、UTF8-String构成的约定，公共元素的4个组成部分 (消息封装、消息头、消息主体及消息证书)的详细定义以及消息传输的规定。此外，协 议还对客户端自举，查询请求、查询响应，错误响应，服务引用，客户端认证，Handle 管理，命名授权管理，Session及其管理等等一些操作的消息的具体构成进行了详尽的 描述。该协议规范文档为程序员实现客户端和服务器端软件提供了最底层的参考。
5 基于Handle System的唯一标识符系统在国内的部署情况
在进行了充分的调研后，《数字资源唯一标识符应用规范》项目研究小组认为Handle System作为一个名称服务系统所具备的各项特点可以很好地满足我们在国内搭建唯一标 识符系统基础平台的各项要求。研究小组以Handle System为蓝本，以子项目参与单位( 中国科学院文献情报中心，中国国家图书馆，CALIS中心，中央党校图书馆，中国医科 院信息中心)为主要实验单位，在国内搭建了一套唯一标识符实验体系，其框架如图4所 示。
目前我们在该标识符系统平台上成功进行了多项实验，主要包括：
(1)GHR系统的研发和设立；
(2)实现LHS与GHR的互连；
(3)“nlc”、“csdl”等多级命名授权及命名授权下唯一标识符的注册、管理和解析 等；
(4)唯一标识符各种类型的值的绑定(预定义、自定义类型)；
(5)身份认证；
(6)多级LHS及同一LHS中多服务器协同工作；
(7)唯一标识符多种途径的解析；
(8)与科学院的开放链接系统实现关联应用；
(9)其它辅助性功能开发。
《数字资源唯一标识符应用规范》子项目组最新的工作进展情况、唯一标识符系统相 关的研究报告及实验软件可以从我们的工作网站：www.doi.cn或http://cdls.nstl.gov .cn/cdls2/w3c上获取。
下一步工作组计划将实验范围扩展到实际应用领域，与各行业、机关、企事业单位联 合测试和验证该唯一标识符系统在国内各系统部署应用的可行性及其应用价值。候选实 验单位正在广泛征集中。
6 结论
作为一个纯名称服务系统，Handle System与其它标识符系统相比具有很多优点，开放 的Handle System系统框架和系统协议为实现基于Handle System的标识符解析系统提供 了充分且十分基础的参考。基于Handle System实现且已投入运行的DOI系统的成功更表 明了该标识符系统的设计是相当完善且实用的。我们在设计实现标识符解析和管理系统 时完全可以利用Handle System现有的技术框架和协议，或者根据实际需要在其上做部 分修改。此外，CNRI发布的Handle System服务器和客户端软件源码可以帮助程序员理 解并实现Handle System系统组件。
在具体使用时，具有高效名称解析服务的Handle System可以与LDAP或WHOIS + + 这样 的目录服务结合使用。利用Handle System来进行专业而高效的名称解析服务，利用目 录服务来提供反向名称查找等扩展检索功能，以便提供高附加值的服务。
作者E-mail:i_mac@263.net