第六章数字图书馆互操作

第六章数字图书馆互操作第一页，共102页。第一节数字图书馆互操作概述第二节OAI互操作协议第三节Z39.50协议及Z39.83协议

提要第二页，共102页。第一节数字图书馆互操作概述第三页，共102页。根据USIEEE的定义,互操作性是指两个或多个系统相互使用已被交换的信息的能力。就其本质而言,互操作性是对异质实体(包括异种体系结构、异种操作系统、异种网络和异种语言等)中可获得资源的透明调用的能力。解决数字图书馆的互操作问题的难点在于各已有系统的建设并非遵循同一种标准或规范进行。第四页，共102页。一、数字图书馆互操作问题产生的原因(一)数字信息资源的组织和结构问题信息资源是数字图书馆建设和服务的基础,信息资源组织和结构与传统的图书馆不同。在传统图书馆中，信息资源的组织是由其物理形式组织和界定的，而在数字图书馆中，所有的信息资源都是以数字化的形式表示的，而且数字信息资源不论是在格式,还是数字信息的存储结构上都不尽相同。但以怎样的逻辑结构组织信息资源才能让它在数字图书馆中更方便地处理、利用以及与其它系统交互呢，是我们需要考虑的一个问题。第五页，共102页。一、数字图书馆互操作问题产生的原因(二)信息资源数字化中文件的命名问题目前数字图书馆在信息资源数字化加工标准的研究中达成一致的共识是:数字资源的命名必须是全球唯一的、长期的、独立于地址的。但实际上许多图书馆在资源数字加工中，对资源的命名方面遵从的是不同的标准，即不考虑资源命名的规范化，也不考虑文件命名对信息资源共享的影响，大部分图书馆是以自己特有的方式进行命名。第六页，共102页。一、数字图书馆互操作问题产生的原因（三）元数据问题通常数字图书馆都是将具有较高收藏价值的珍本、善本、语音、影视和科学数据等多媒体信息进行数字化加工，建立自己的特色数据库，以达到高质量地保存和管理这些多媒体信息，实现知识增值的目的，并提供在广域网上高速横向跨库连接的电子存取服务。元数据是建设数字图书馆过程中的关键性问题。由于数字图书馆中资源类型的多样化，单一元数据标准不能满足描述各种数字资源的需求，从而出现适用于不同资源或适用于不同组织的元数据类型。另外，在数字图书馆建设中，由于各个图书馆的独特需求或处理方式，即使相同类型的信息资源，也出现信息提供单位依据不同的标准对相同类型的资料进行元数据提取。第七页，共102页。一、数字图书馆互操作问题产生的原因（四）信息资源数字加工格式问题有许多图书馆和出版商在对信息资源数字化加工时，是根据它们自己的需要而采用了特定的格式。如影像格式除了BMP、GIF、JPEG、PNG、TIFF等标准格式之外,还有KDC、PIX、PSD、TTF、XBM等许多格式。同时，数字信息资源的形式也有多种，不仅有文本,还有图象、图形、声频、视频等。由于数字信息资源媒体的属性不同,对数字信息进行格式化的标准不同，即使对同一种数字信息进行处理的格式，不同的数字化加工单位采用的形式也是多样的。第八页，共102页。一、数字图书馆互操作问题产生的原因（五）体系结构方面的问题由于对数字信息的处理采取的方式不同,数字信息资源的存储结构也不相同，复杂的存储结构给数字图书馆互操作性进行相互转换带来了一定的困难。另外，不同的数据资源平台提供给读者检索的界面和查询的体系结构也是各个不同，在是否支持布尔检索、结果显示等诸多方面存在差异。第九页，共102页。一、数字图书馆互操作问题产生的原因二、数字图书馆互操作问题产生的原因（六）系统构架问题数字资源的数据是以集中管理和共享为特征的，因此数据库系统成为数据管理的主要形式,它是信息系统的主要支撑系统。但是,由于分布式数据库系统均是独立发展起来的,不同的出版商、不同的数字资源创建单位在系统的数据库结构、应用程序、网络和运行平台等方面有所不同，要对此进行集成,实现跨平台检索异构数据源,是数字图书馆的互操作性面临的又一个复杂的困难和问题第十页，共102页。第十一页，共102页。第二节OAI互操作协议第十二页，共102页。一、OAI互操作协议的起源开放文档先导（OAI，OpenArchiveInitiative)是一个旨在促进网络信息资源开发、发布与共享的一个合作组织。第十三页，共102页。OAI的第一次会议于1999年10月由美国图书馆和信息资源委员会(CLIR)、数字图书馆联盟（DLF）等组织发起来，在美国新墨西哥州的圣达菲市召开。“圣达菲协议”（SantaFeConvention）OAI-PMH（MetadataHarvestingProtocol，有时也写成OAI-MHP）第十四页，共102页。元数据标准是数字图书馆技术应用的一个重要方面，随着元数据标准应用的推广，逐渐体现出元数据的互操作是数字图书馆建设的关键。但是目前不同的资源对象采用不同的元数据格式，这直接影响信息资源的共享、交换和存取。OAI协议的主要目的是通过元数据采集的手段来实现网上发布信息的不同组织之间的互操作，因此，不同元数据标准之间的互操作可以通过OAI协议来实现。第十五页，共102页。二、OAI-PMH技术框架

OAI协议通过简单、低成本的元数据搜寻、共享和检索方式，支持用户对分布的数字对象存储库的开放检索，无论这些存储库采用什么技术平台、内部格式和检索协议。第十六页，共102页。信息仓储信息仓储信息仓储数据提供方服务提供方RecordResponseOAIVerbRequest第十七页，共102页。OAI协议的组件基本构架OAI协议的组件基本构架

第十八页，共102页。数据提供者1数据提供者2……数据提供者n服务提供者1服务提供者2……服务提供者nHTTPRequestOAIVerbHTTPResponseValidXML用户注册服务器OAI协议的组件基本构架一次操作OAI协议的组件基本构架第十九页，共102页。数字仓储(数字资料)元数据创建数字仓储(元数据)元数据映射符合OAI的元数据用于元数据收获的OAI接口元数据组织注册模块注册服务器服务提供者注册界面元数据采集器数据提供者的模块数字资料的发布数据提供者数据提供者的模块

第二十页，共102页。元数据仓储增值服务(如统一主题分类)注册模块元数据收集接口元数据采集器统一查询服务提供者注册界面元数据采集器注册服务器服务提供者元数据收集接口数据提供者用户接口用户服务提供者的模块服务提供者的模块

第二十一页，共102页。数据提供者与服务提供者的注册信息仓储分类组织注册服务查询服务注册界面数据提供者注册界面服务提供者用户界面用户注册服务器的模块注册服务器注册服务器的模块

第二十二页，共102页。三、OAI协议的几个概念1．资源（resource）资源就是元数据记录所描述的对象。2．项目（Item）概念上而言，项目可以看作一个容器，该容器保存着有关一个资源中的各种元数据格式的元数据记录。

第二十三页，共102页。OAI协议的几个概念3．唯一标识符（UniqueIdentifier）唯一标识符明确地指明了元数据信息仓储中的一个项目，以便通过OAI请求指令，从项目中抽取对应的一条元数据记录。

DC格式的元数据记录TEI格式的元数据记录EAD格式的元数据记录…………项目唯一标识符第二十四页，共102页。OAI协议的几个概念5．OAI记录（record）记录就是一定格式的元数据记录，由XML封装后提供给服务提供方。一个唯一标识符明确地定义了所要抓取的记录所在的项目，而元数据前缀参数（metadataPrefix）则指明了所要采集的记录是采用哪种元数据格式。

第二十五页，共102页。OAI协议的几个概念5．信息仓储（Repository）信息仓储由很多项目（item）组成。信息仓储由数据提供方管理，供服务提供方采集器定期或不定期的抓取元数据记录。6．集（Set）集也称为集合，是为了进行选择性获取而建立的项目分组结构。第二十六页，共102页。OAI协议的几个概念7．采集器（Harvester）采集器就是一段发送OAIrequest（OAI请求）的客户应用程序。采集器由服务提供方操作，服务提供方通过这种方式从元数据信息仓储中抓取元数据记录。

第二十七页，共102页。四、OAI互操作协议的指令OAI主要是通过指定的命令集，提供前端向后端信息仓储提取所需信息的协议。在OAI协议中，主要规定了六条请求(request)和响应(response)指令。第二十八页，共102页。OAI互操作协议的指令1、Identify

用于获取元数据信息仓储的相关信息。2、ListMetadataFormat

用来获取元数据信息仓储所支持的元数据格式种类。第二十九页，共102页。OAI互操作协议的指令3、ListSets

使用ListSets指令可以得到信息仓储集的结构，获取集名称等。4、ListRecords

用来抓取一个数据仓储中的多条完整的元数据记录。通过可选择性参数，此抓取可以是基于set或者datestamp日期标识的限定范围而进行。参数：set、from、until、metadataPrefix第三十页，共102页。OAI互操作协议的指令5、ListIdentifiers

获取可以从元数据信息仓储中查到的记录的标识符，是请求指令ListRecords的简短形式。通过可选择性的参数，可以通过Set关系或者Datestamp日期标志来定向抓取所需要的元数据头标信息。第三十一页，共102页。OAI互操作协议的指令6、GetRecord

从一个元数据信息仓储中抓取一条具体的元数据记录。参数：IdentifiermetadataPrefix。第三十二页，共102页。OAI-MHP协议是基于HTTP协议的，所有的OAI中的指令都在URL中编码成一个HTTP请求，由一个服务提供者发送给一个数据提供者，数据提供者中返回的结果都使用XML进行编码。假设一个数据提供者的基本URL地址为，如果我们要列出自2003-9-22以后数据提供者中所有新增资源的标识，则应向此数据提供者发出如下请求：第三十三页，共102页。请求http:///OAI-script?verb=GetRecord&identifier=oai:arXiv:hep-th/9901001&metadataPrefix=oai-dc第三十四页，共102页。第三十五页，共102页。五、各成员之间的交互第三十六页，共102页。OAI系统交互图OAI系统交互图第三十七页，共102页。六、OAI三方的交互数据提供方与服务提供方和用户之间的交互过程如下：（1）在注册服务器中进行数据提供方的身份注册，在得到注册服务器的注册成功响应并分配URL地址之后，向服务提供方提供元数据发布服务；（2）接受服务提供方的符合OAI协议的六条抓取指令请求，并返回符合请求条件的本地数据库中的相关元数据记录；（3）当用户需要得到详细资料时，接受用户的元数据记录联接请求，向用户返回详细资料。第三十八页，共102页。六、OAI三方的交互用户查询过程如下：（1）用户通过服务提供方的查询界面进行详细查询，如果用户不清楚服务提供方的信息，则可以从注册服务器中获得；（2）通过服务提供方的查询界面，用户可以通过书名、作者以及高级查询等方式，在服务提供方的元数据数据库中查找（3）如果用户需要相关元数据记录对应的详细资料，那么通过服务提供方所提供的元数据记录与数据提供方之间的链接，用户可以直接链接到数据提供方的储存器，得到原始资料。第三十九页，共102页。七、OAI-PMH协议的应用

第四十页，共102页。CALIS高校学位论文全文数据库系统总体框架CALIS高校学位论文全文数据库系统总体框架

第四十一页，共102页。第三节Z39.50协议第四十二页，共102页。一、Z39.50协议概况第四十三页，共102页。传统的数据库检索系统的不便之处：图书馆目录数据库、各种商业化信息检索数据库和各种光盘数据库产品，都有不同的检索途径。您需要知道它们的地理位置、

使用的检索系统环境和软件

界面等因素。

第四十四页，共102页。当您进入一个数据库检索环境后，您面对的是一个专门的操作界面。如果您需要通过互联网查询众多服务器的资源，虽然这些资源只需要

使用一个应用程序：

网络浏览器，

但是您面对的仍是另您

目不暇接的操作界面。第四十五页，共102页。有没有一种可能性，使用户通过单一的应用程序、单一的操作规则，检索来自：

不同机构、

不同的服务器、

不同的数据库管理系统、

不同的数据库资源

的信息资源？第四十六页，共102页。Z39.50标准的出现，为解决这个问题提供了一种可能性。Z39.50标准给我们带来的希望和可能性，是多方面的。第四十七页，共102页。Z39.50协议全称为InformationRetrievalApplicationServiceDefinitionandProtocolSpecification。应用于信息检索的标准。第四十八页，共102页。Z39.50是分布式虚拟联合数据库检索体系，其目的是实现网上多个数据库检索、规范查询格式、简化检索过程、实现异构系统和不同图书馆系统之间的通信。Z39.50协议提供了一个统一的方法，使得用户在检索服务方的信息时，不必学习和掌握服务方系统的检索命令和有关特性，也不必关心其系统的硬件平台。第四十九页，共102页。Z39.50协议是按照典型的客户机/服务器结构设计的，它把互联双方分别称为请求方和提供方（服务方），通过Z39.50服务为双方提供互连和检索服务。Z39.50协议规定了客户机与服务器间进行信息检索时，所用的格式与信息处理。第五十页，共102页。Z39.50协议最早在1984年推出，1988年美国国家信息标准组织（NationalInformationStandardOrganization，简称NISO）正式批准Z39.50-1988标准。从1989年到1995年，Z39.50协议先后通过了第二版（Z39.50-1992）和第三版（Z39.50-1995），由原先单纯的书目信息检索服务扩大为信息检索协议，目前正在进行第4版的制定。国际标准化组织（ISO）接受了Z39.50作为国际标准，定名为ISO23950。第五十一页，共102页。于2002年上半年公布了新一代的Z39．50协议：ZING（Z39.50International:NextGeneration），是一个面向互联网的协议。第五十二页，共102页。二、Z39.50协议信息检索服务机制

第五十三页，共102页。Z39.50协议的所有功能由一组服务定义（ServiceDefinition）组成，服务定义描述了Z39.50协议中的服务（Services）和支持的操作（Operations）。Z39.50协议将服务分成几组，一个组称为一个机制（Facility），机制对服务进行归类和划分，也就是若干服务和操作的逻辑组合。Z39.50协议定义了11种机制，包含了13种服务。第五十四页，共102页。Z39.50协议定义的服务分为：

证实型服务：由请求方或提供方发出请求，需要对方响应的服务。非证实型服务：由请求方或提供方发出的请求，不需要对方响应的服务。条件证实型服务：由请求方或提供方发出请求，对方根据条件可能会做出响应的服务。第五十五页，共102页。Z39.50协议属于一种面向会话的（Session-oriented）有状态的协议，目前广泛使用的因特网超文本传输协议（HTTP）是一种无状态的协议，因此Z39.50协议与HTTP协议不同，它的服务和机制在一个会话期间内会连续出现状态的变化。第五十六页，共102页。1．初始化机制—InitializationFacility（初始化服务（InitService））初始化服务的功能是由请求方发起产生一个初始化操作，并建立一个Z联动。Z联动（Z39.50-association或Z-association），也称为Z39.50联接，Z39.50请求方与Z39.50提供方是通过一个Z联动来进行通讯的，该Z联动是包含在一个应用联动（ApplicationAssociation）之中。Z联动是由请求方直接建立并由请求方或提供方终止的一个会话，在一个应用联动中，可能有多个连续不断的Z联动。同时在一个Z联动中，又可以有多个并行操作。第五十七页，共102页。2．搜索机制—SearchFacility（搜索服务（SearchService））

搜索服务是指请求方创建的一种证实型服务，用以创建搜索操作。利用搜索服务，请求方向提供方提交检索表达式，对提供方的一个或多个数据库进行查询。提供方在数据库中检索符合条件的记录，并把检索结果记录全部或部分返回给请求方，或将查询结果集保存，并对每一条记录按所处的位置进行标识后，供后续的操作引用。第五十八页，共102页。一个结果集可以认为是命中记录的标识的集合，结果集模型的逻辑结构为一个有序列表。列表的每个条目分别对应每条命中记录，条目由三部分组成：a.条目所处位置的序号；b.对应记录所在数据库的名字。c.对应记录在数据库中的唯一标识。第五十九页，共102页。3、提取机制—RetrievalFacility（提交服务（PresentService）和分段服务（SegmentService））第六十页，共102页。提交服务（PresentService，表示服务）允许客户端从结果集中请求一个或多个记录。这包括请求对集中的特定范围内记录的请求（如第10号记录到第20号记录），对记录中特定项的请求（如请求返回标题和作者）定义所需记录的参数（如格式信息，UNIMARC、USMARC、MS-WORD或者HTML；或者采用的语言，中文或英文等），以及其他一些元数据信息。服务器也可以提供其他一些元数据（如评分、单词出现频率、文档长度等等），使客户端能够将不同服务器获得的结果进行合并。第六十一页，共102页。如果分段服务有效，而且返回的记录超过了提交响应消息的大小，记录不能在一个提交响应中返回时，提供方首先会将待发送的记录分成若干段，通过分段请求依次将记录返回到请求方，最后才发出提交响应。第六十二页，共102页。4．删除结果集机制—Result-set-deleteFacility（删除服务（Deleteservice））

删除服务是指请求方创建的一种证实型服务，用以创建删除操作。删除服务使请求方能够请求提供方删除指定的结果集，或删除在Z联接中建立的所有结果集。第六十三页，共102页。5．浏览机制—BrowseFacility（扫描服务（Scanservice））

扫描服务是指请求方创建的一种证实型服务，是请求方发出浏览提供方定义的数据库检索词表的请求。第六十四页，共102页。6．排序机制—SortFacility（排序服务（SortService））

分类排序服务是指请求方创建的一种证实型服务，用以创建分类排序操作。分类排序服务允许请求方请求提供方对结果集进行分类排序（或合并多个结果集后再分类排序）。第六十五页，共102页。7．访问控制机制—Access-controlFacility（访问控制服务（Access-controlservice））访问控制服务是指提供方创建的一种证实型服务。允许提供方可以对请求方的行为采取必要的限制和控制措施。提供方在执行初始化、查询、表示或删除服务时，对请求方的权限提出置疑，要求请求方必须予以回应以证实合法身份或权限，否则提供方可以终止连接。第六十六页，共102页。8．计帐/资源控制机制—Accounting/ResourceControlFacility（资源控制服务（Resource-controlservice）、触发资源控制服务（Trigger-resource-controlservice）、资源报告服务（Resource-reportservice））第六十七页，共102页。资源控制服务是提供方创建的一种条件证实型服务。资源控制服务允许提供方发送资源控制请求，其中可以包含资源报告。该报告可以通知请求方实际或预计的资源消耗是否超出事先商定的限制（或在提供方内建立的限制），并且请求请求方同意通过资源控制响应继续操作。第六十八页，共102页。触发资源控制服务在一个操作期间由请求方创建的一种非证实型服务。触发资源控制服务允许请求方请求提供方创建资源控制服务，或者取消操作。第六十九页，共102页。资源报告服务是请求方创建的一种证实型服务，用以创建资源报告操作。资源报告服务允许请求方请求提供方发送属于指定的、已经完成的操作或者整个Z-联接的资源报告。第七十页，共102页。9．解释机制—ExplainFacility（无任何服务）

解释机制不包含任何服务，而使用查询和提取机制中的服务。解释机制是Z39.50-1995加上的功能，它提供一个解释数据库（Explaindatabase）让请求方查询，以得知提供方的相关信息，包括提供方可供查询的数据库有哪些、所支持的属性集及错误信息、记录语法什么样，有哪些可浏览的语词表、以及扩展服务等。有了这些信息后，Z客户端才能设定自己的状态，并显示告知给使用者。第七十一页，共102页。10．扩展服务机制—ExtendedServicesFacility（扩展服务群服务）

扩展服务群服务允许请求方在提供方建立、修改、删除任务包。提供方在一个特殊数据库中维护这些任务包。扩展服务群服务是指请求方创建的一种证实型服务，用以创建扩展服务群操作。第七十二页，共102页。在图书馆的信息系统中用到的扩展服务主要有：

保留结果集（PersistentResultSet）：请求方可以存储Z联动中的结果集，并在另一个Z联动中指定从此结果集中检索资料，所保留的结果集可以增加或者删除。保留查询语句（PersistentQuery）：可以在提供方存储查询语句，以便在以后的查询中使用。第七十三页，共102页。在图书馆的信息系统中用到的扩展服务主要有：

定期查询服务（PeriodicQueryScheduleService）：这项服务可以指定系统定期、自动地以上述保留查询语句进行查询。订购资料：可以让使用者订购资料，这些资料可能来自结果集或者是馆际互借系统。订购者的名字与住址都会列入订购单中，也包括账户资料及订购号码。第七十四页，共102页。在图书馆的信息系统中用到的扩展服务主要有：

资料库更新：这个服务可以让Z客户端更新服务器上的记录。转出规范：此服务允许请求方定义记录的组合方式，以便转出并送到目的地。规范中包括：栏位、语法、地址。转出请求：此服务可以让提供方呼叫转出规范，并使用转出规范，以指定的格式要求服务器送一份记录到某地址。第七十五页，共102页。11．终止机制—TerminationFacility(关闭服务)

关闭服务是请求方或提供方创建的一种证实型服务。它不创建任何操作，也不是任何操作的一部分。它允许请求方或提供方突然终止所有激活的操作，并可以终止本次Z联接。第七十六页，共102页。三、Z39.50协议交互过程第七十七页，共102页。Z39.50的工作过程大致是:客户端向服务器端发出创建连接的请求,服务器端做出回应,创建连接成功;用户在客户端输入检索条件,由客户端将检索表达式转为逆波兰表达式并进一步将其转换成用抽象语法标记ASN.1(AbstractSyntaxNotationOne）描述的Z39.50标准格式,依据基本编码规则(BER,BasicEncodingRules)进行编码,形成应用协议数据单元(APDU,ApplicationProtocolDataUnit)位串,然后作为检索请求发往服务器端的检索系统;第七十八页，共102页。服务器端检索系统接收应用协议数据单元(APDU)并对其解码,转换成自身的检索命令,再执行该命令,并从后台数据库中找到满足检索条件的记录,将所有满足条件的记录的标识组成结果集返回到客户端;客户端发出显示某个记录内容的请求,并给定其在结果集中的编号,服务器端找到对应的记录标识,将记录返回到客户端;客户端发出终止连接的请求,服务器端做出响应,连接结束。第七十九页，共102页。

服

务

器（Server）

客

户

机（Client）

源端服务使用者

(OriginService-User)

目的端服务使用者

(ServerService-User)

请求

确认

指示

响应

协议信息

服务提供者(Service-Provider)

源端

(Origin)

目的端

(Target)

第八十页，共102页。Z39.50客户机Z39.50服务器1数据库Z39.50服务器2数据库Z39.50服务器n数据库连接请求1查询请求1（APDU）连接响应1查询响应1（APDU）图形第八十一页，共102页。四、Z39.50协议应用模式

第八十二页，共102页。

单层客户服务器模式

单层客户服务器模式第八十三页，共102页。采用单层客户服务器模式的好处是：充分利用客户端的计算资源，使客户端具有较强数据处理能力，能完成复杂的功能，减轻服务器的计算量；服务器可以设计的相对简单，易于实现和维护。缺点是：Z39.50客户端软件维护工作量大，因为客户软件修改或升级以后，用户必须获得一个Z39.50客户软件的一个新的拷贝，才能使用Z39.50协议进行查询。第八十四页，共102页。多层客户服务器模式多层客户服务器模式第八十五页，共102页。用户可以利用标准的浏览器来访问应用服务器，应用服务器能同时接收和处理多个用户的请求，将其转化成Z39.50的服务请求提交给Z39.50服务器，并将Z39.50服务器的返回结果用主页的形式返回给用户。采用这种方式可以为不同用户提供高效率的服务。第八十六页，共102页。五、Z39.50协议和OAI-MHP协议的比较分析

第八十七页，共102页。用户Z39.50客户机Z39.50数据库Z39.50数据库Z39.50数据库用户服务提供方数据提供方数据提供方数据提供方Z39.50分布检索模式OAI集中检索模式图形第八十八页，共102页。六、Z39.50的用途第八十九页，共102页。1.公共目录查询通过Z39.50客户端专用程序，可以提供公共目录查询服务。用户可以输入一个检索词，

在全球众多图书馆服务器上

查找所需要的书目信息。第九十页，共102页。2.编目使用支持Z39.50的客户端程序，可以检索并下载书目记录。利用Z39.50的客户端程序，编目员选择一个功能较完备的客户端软件，就可以检索全球众多图书馆的书目数据资源。图书馆工作人员可以通过因特网同时检索多个服务器上的书目数据，并对这些数据进行比较选择。第九十一页，共102页。3.联合目录建立联合目录，曾是图书馆提供服务的一种有效工具。但是，建立联合目录，有很多困难和管理方面的问题，代价较高。借助Z39.50提供的编目和公共目录查询服务，可以建立虚拟联合目录，不必改变参与合作的图书馆原有的目录体系和工作流程。读者可以坐在计算机前，像查询本馆目录一样同时查询各图书馆的目录，并查看相关的资料和馆藏信息。各图书馆可以根据本馆读者的需要，通过系统设置，建立稳定的联合目录服务体系。第九十二页，共102页。4.馆际互借

过去，图书馆的馆际互借基本上是通过手工方式进行的。虽有少数图书馆通过计算机实现馆际互借服务，但因使用不同的管理系统软件，很难跨越不同的管理系统软件实现计算机作业。Z39.50标准的实施，不但可以使读者随时获取馆藏信息，还可以提供发送图书的服务，实现相应的帐户管理和结算功能，可以一次完成对其它图书馆资料的查询和申请馆际互借的过程。第九十三页，共102页。5.光盘检索

当用户查找光盘信息资源时，必须先熟悉信息提供商设计的专用检索软件操作，并分别对不同的光盘数据库进行检索。如果光盘信息检索系统能够提供符合Z39.50标准的检索接口，用户就可以使用