开放资源互操作协议OAI研究，本文主要内容关键词为：协议论文,操作论文,资源论文,OAI论文，此文献不代表本站观点，内容供学术参考，文章仅供参考阅读下载。
1 引言
随着数字图书馆的发展，各种数字资源间的互操作性也变得越来越重要，特别是同一类型的资源如果由不同单位来制作，选用不同的数据库平台，进行一个人口的检索就变得很困难。所以人们一直致力于对分布式资源进行统一检索的开发。要实现这一目标，归纳起来有三种方式：代理模式（也可成为元搜索模式），即通过检索代理对不同的目标源分别检索，然后对检索结果统一处理；联邦检索模式，即各个目标源严格遵守统一标准或协议从而实现底层的跨库检索；采集模式，即通过元数据采集协议将分布的元数据集中起来提供统一检索。本文对这三种模式进行了对比介绍，并着重对应用越来越广泛的采集模式OAI元数据互操作机制、协议规范及应用进行了详细介绍和讨论。
代理（Proxy）模式的跨库检索，是指用户通过统一的检索界面输入查询请求，系统接收并处理用户的查询提问，并按照目标库的特定检索格式和地址发送相应的检索请求，然后对各个目标库返回的结果逐一进行处理，从而将查询结果返回给用户。这种方式必须对目标库所能接受的查询语句的格式，返回结果的页面格式逐一分析，并编写相应的程序代码。优点是对集成的目标数据库设有具体要求，不受目标库的限制，集成工作主要在代理方完成。缺点是性能差，而且目标库对所接受的查询语句的格式或者查询结果的返回方式进行调整后，代理方必须重新进行代码编写；而且当集成的目标数据库种类和数量较多时，系统维护和开发的代价比较高，同时检索的效率也比较低。象数字图书馆界的SDLIP协议完成的互操作也是在客户端和代理之间定义了轻型传输协议，查询语言和其他接口来进行通讯。同方光盘股份有限公司的UniSearch检索平台电是典型的代理模式。对目标库的结构不了解，同时目标库没有支持通用协议的数据库，只有依靠这种方式才能实现跨库检索。
联邦检索模式的跨库检索特点是集成方法容易，但系统设计代价高。象符合Z39.50的系统，在进行互操作时，客户端只需要知道目标库的名称、IP地址和端口号，按照协议规定的查询语句格式向目标库发送查询请求，并对目标库返回的严格符合协议规定的响应进行解析，将各库的检索结果合并后呈现给用户。这种模式需要所有的目标库必须严格遵守Z39.50协议规定；而客户端只需要按Z39.50协议发送查询和解析结果，与前面介绍的Proxy模式相比，编码工作极大简化。缺点是该协议的开发是在Web流行之前，是基于TCP/IP协议的C/S模式，采用的很多技术方案已过时或过于繁琐，而且协议细则本身过于繁琐，极大地妨碍了数据提供方的开发难度。
采集模式与前面两种介绍的分布查询模式都不同，它其实是一种查询本地元数据库的方式，即用户只需要在服务提供方提供的查询界面进行查询，该查询的内容完全局限在服务提供方所采集的元数据的基础上，没有采集进来的数据是不可能查询到的，所采集的对象也是符合采集协议的数据库。简单地说就是该模式明确的分开了数据提供和服务提供两个概念，数据提供方只负责按照OAI协议发布（Export）元数据，不提供查询服务；而服务提供方通过OAI元数据采集协议从数据提供方采集（Harvester）元数据，以此为基础建立索引，提供查询服务。该模式的优点是数据提供方和服务提供方的为实现跨库检索所需付出的编码代价都较小，比较容易实现，而且这种方式开放共享的只是元数据，而不是数字对象本身，既有利于各类异构资源的发现，又能保障商业数据库的利益。
这三种方式比较而言，联邦式检索对参与互操作的数字图书馆系统要求最高，代理模式的要求最低，然而，检索质量也因系统的耦合程度不同而受影响，耦合度高的联邦式检索质量最高，采集式次之，代理式最差。下面我们着重介绍用OAI协议来进行采集式检索。OAI采集式检索提供一个统一界面来检索不同数据库的内容，系统实现代价低。
2 OAI协议背景
OAI，是Open Archive Initiative的缩写，意为开放文档先导。该组织由数字图书馆联盟（Digital Library Federation，DLF）、美国网络信息联合会（Coalition Networked Information，CNI）、美国国家科学基金会（National Science Foundation，NSF）等机构联合资助。
OAI最初起源于电子出版界（E-print Community）的分布式数字资源库系统计划。所谓数字资源库（e-print）指那些接收研究人员自行提交的电子化的研究报告或文章并提供存储管理和公共检索的系统。OAI计划将这些开放的数字资源库连成一个体系，支持用户对所有资料库的开放式检索，无论这些资料库采用何种技术平台，内部格式和检索协议。随着OAI的发展，它的应用也远远超出了这一范围。原则上对任何数字对象都可以适用，图书情报领域、电子出版界、出版商及科研人员都越来越多的关注OAI。
何谓“Open Archive”？“Open”一词并不是说可以免费、无限制的访问OAI的数据库，而是指资源库（Repository）的结构（Architecture）上的开放。Archive一词最开始主要指学术论文（Scholarly Papers），后来随着OAI的发展，其含义有了更广阔的理解，适用于各种电子文档。
在OAI框架下，开放式的数字资源库，作为数据提供者，可以是任意技术平台和内部结构，可以有自己专门的服务系统，元数据格式和检索协议，但可以支持第三方系统（即数据采集方）利用元数据采集协议采集自己的元数据。服务提供方采集数据提供方的元数据，并以此为基础建立索引，从而为用户提供增值服务。协议规定数字资源库中的每一条元数据记录要按统一标准制定唯一标识符，并与数字对象进行链接。
3 元数据采集协议概述
OAI元数据采集协议框架把系统的参与者分成数据提供者（Data Provider）和服务提供者（Service Provider）两类，前者是指支持OAI元数据采集协议（Open Archive Initiative Protocol for Metadata Harvesting，OAI-PMH）的元数据发布者；后者通过OAI元数据采集协议（OAI-PMH）从数据提供者那儿采集元数据，并以此为基础提供增值服务的服务者。
而所谓的实现OAI协议，对数据采集方而言，就是按照协议规定的格式和参数发送指令；对数据提供方而言，就是能对由采集方发起的请求指令按协议规定的格式返回对方想要的数据。
OAI-PMH协议是基于HTTP请求的。也就是说，需要通过一个标准的WEB服务器将接收到的OAI-PMH请求转发给后台专门的软件来处理这些请求。所以，指令在传输过程中需要HTTP编码和解码。
按照HTTP协议规定，OAI-PMH的请求必须通过HTTP的POST或GET方法提交。POST方法的优点是在参数传递的长度上没有限制。元数据库必须同时支持POST和GET两种方式。所以，对每个符合OAI协议的元数据库必须有一个唯一的BaseURL，该BaseURL必须包含HTTP服务器的服务器地址和端口号。在响应客户端发出的Identify请求时，元数据库必须把BaseURL作为响应的子元素反馈给客户端。
所有的OAI-PMH请求都是在BaseURL的基础上加上一列“key=value”形式的参数对组成。有多个参数时，顺序可以任意，但必须用“&”符号进行连接。对于HTTP GET方法，参数用一个“？”连接在base URL后面，而参数间用“&”连接。对于HTPP POST方法，参数必须包含在POST的消息体中，请求的Content-Type必须是application/x-www-urlencoded。
每一个元数据采集者发出的OM-PMH请求指令至少要包含一个健值对，其健为字符串“verb”，值为OAI-PMH规定的六条指令之一。其他的参数根据具体的指令而定（详见表1）。
表1：OAI-MPH指令参数对应表
备注：空白表示该指令不支持此种参数。
协议同时规定，所有的OAI-PMH的响应（Response）必须是结构良好的XML格式的文档实例（XML instance Document），XML的编码必须为UTF-8格式，不采用实体引用（Entity References）而采用字符引用（Character References）方式，因为后者可以允许XML格式的响应以一个单独的XML文档被处理，而不依赖文档外部的实体声明。所有的响应必须包含一个XML声明，其版本始终为1.0，编码始终是UTF-8，即＜？xml version=“1.0”encoding=“UTF-8”？＞。其余的部分必须包含在一个名为“OAI-PMH”的根元素中，该元素必须包含三个命名空间（Namespaces）属性。
按照OAI协议，元数据库（Repository）中有条目（Item）和记录（Record）两种概念，同一条目可以对应多条记录，这些记录包含的信息只是元数据格式不一样，拥有共同的唯一标识符。也就是说元数据库中的每一个条目必须有一个唯一标识符，同一条目可以有不同的元数据格式表现形式。协议还规定，数据提供方可以随意定义自己的元数据格式，但每一个条目都必须支持DC格式的元数据。
通过前面的讨论我们可以看出，OAI协议并不是一个检索协议。举例来说，一个声称实现了OAI协议的元数据库，并不意味着可以通过指定的DC中某一个元素的具体值进行记录的采集。也就是说采集方不能期望采集“title=×××”或“creator=×××”等形式的记录，而是把所有符合日期的元数据全部采集过来。
此外，元数据采集并不是最终目的，采集元数据是为了提供检索服务。我们可以看出OAI模式给最终用户提供的检索服务只能停留在元数据阶段，如从对方采集的元数据格式是DublinCore，则检索字段也就只能局限在DC的15个元素范围内。这与人们期望的深度内容检索有一定差距，但毕竟给目前各种分布异构的海量信息检索提供了一种思路，尤其对实现声音、图象、软件、文本等异构异质的信息源的统一检索具有重要的意义。
4 OAI协议的应用实现
按照前面的介绍，对OAI协议的实现（Implementation）包含两部分，对数据提供方而言，要能通过Web服务器接收采集方发送的6条指令，并用XML格式返回相应的结果；对采集方而言，能发送HTTP请求到制定的BaseURL，并对接收到的HTTP相应进行解析。
目前有很多研究机构已经开发了许多开放源码的程序，用于实现OAI协议，分别采用不同的开发语言如JAVA、PERL、PHP、C++等，能应用于不同的操作系统平台如Windows、Linux、Unix等，具体可见http：//www.openarchives.org/tools/tools.html。
其中OCLC开发的OAICat和OAIHarvester，分别用于数据提供方和数据采集方的实现。该软件采用JSP/SERVLET技术，能用于Tomcat、BEA Weblogic、Resin等Servlet引擎，程序结构设计良好，完全采用面向对象的设计，具有很好的扩展性。
在OAICat软件包中，OAIHandler是最重要的类，它分析采集方发送的HTTP请求，按照“verb”参数的值调用与之对应的类。其次是Identify、ListIdentifiers、ListRecords、GetRecrods、ListSets、ListMetadataFormats六个指令类，而这六个指令类又都是继承的抽象类Server Verb。
在OAIHavester软件包中，核心类是Harvester，它主要用于负责完成采集任务，此外还有Identify、ListRecrods、GetRecrod，这三个类都是继承的抽象类Harvester Verb。
由于OAICat和OAIHarvester只是实现了OAI协议部分，要成为具体的应用程序，还需要做一些扩展和定制的程序开发。我们在此基础上开发了一个基于关系数据库的数据提供方，即能通过OAICat，把存储在关系数据库中的元数据信息通过Web进行发布，使得第三方只要按照OAI协议即可将本地库中的元数据信息采集过去。而通过OAIHarvester，只需要简单的配置目标库的BaseURL，即可把对方的元数据信息采集到本地的关系数据库中。
在进行实验的过程中我们也发现，按标准协议开发的解析程序在对从某些数据提供方采集回的数据解析时会抛出异常或报错，这往往是由于数据提供方返回的响应没有严格遵守协议规定的XML Schema。
目前由清华大学图书馆承建的CALLS高校学位论文库二期项目便已决定采用OAI模式。也就是说，各校可以独立开发自己的全文学位论文库系统，但要求各校统一元数据格式，并按OAI协议发布（Export）自己的元数据记录。CALIS中心则按照各校提供的BaseURL将各成员校的学位论文元数据信息集中起来，以此为基础提供检索服务和全文链接服务，从而实现对分布式系统的统一查询。这种模式属于一种松散的互操作模式，不需要各校使用统一的数据库系统，也不需要各校人工提交数据。可以在本地建立自己的系统后，按协议规定的格式和提交方式来定义数据，即可实现数据的自动提交。
5 结论
通过以上的分析可以看出，这个协议出台的目的就是要加强分布式资源的发现。目前采纳这种协议的系统越来越多，美国的NSDL项目是由NSF资助的多学科参与项目，目的是建立关于科学、数学、工程、技术和教育的学习环境。这个系统的技术框架由康奈尔大学为主设计，采用OAI协议来实现采集的功能，将来准备和圣地亚哥超级计算机中心合作把采集过来的元数据通过后处理进行集中存储，并通过SDLIP协议提供查询服务。Cyclades项目是由欧盟支持，意大利、德国和英国联合开发的针对Internet上开放学术文档系统也是准备采用OAI协议来进行集成服务。从OAI的官方网站上可以看到越来越多的系统在网站上注册成为数据提供者和服务提供者，有理由相信采集式检索将来会在开放资源领域得到越来越广泛的应用。