图书馆源发现应用openAPI标准化

[摘 要 ]对图书馆资源发现应用涉及的内容、数据类型、OpenAPI用户及需求、OpenAPI应用类型进行分析,从OpenAPI的通用标准和图书馆资源发现应用涉及的行业标准两个方面对图书馆开发OpenAPI涉及的相关标准进行调查和分析,并结合OpenAPI的用户类型和应用类型给出标准的采用建议.

[关 键 词 ]资源发现应用　OpenAPI采用标准推荐建议

[分类号]G250.7

资源发现(resources discover)是指根据用户请求信息找到匹配用户需求资源的过程等.作为数字图书馆时代图书馆的核心业务和功能,资源发现应用也是国内外图书馆行业相关OpenAPI的主要应用场景,其主要作用表现在两个方面：一方面开放了资源的外部访问和调用,为本机构和第三方机构资源的Mushup以及更进一步的增值怎么写作提供了一种简便可靠的方式；另一方面则通过资源调用接口特定的资源内容、格式、使用数量和频度等权限信息,保护资源提供者的资源在可控范围内被合法和安全利用.目前,国内外图书馆界资源发现应用中有越来越多的OpenAPI被开发和应用.但正如《国内外图书馆行业相关OpenAPI现状调查与分析》以及相关实践和研究所揭示的那样,目前OpenAPI的开发和应用,尤其是相关的开发中,技术标准的多重性使开发人员耗费大量的时间和精力去熟悉相关标准、解析相关的应答,大大提高了开发成本.尤其是对基于合作提供怎么写作的机构(如CALIS)来讲,如成员馆不采用统一标准发布API,实现统一资源发现应用怎么写作的难度可想而知.在当前国内图书馆资源发现应用的OpenAPI开发尚未大规模展开之时,对国外图书馆相关OpenAPI采用的标准进行调查研究并推荐合适的标准,对未来资源发现OpenAP[的开发具有很强的现实意义.

1图书馆资源发现OnAPI应用场景分析

美国威斯康辛大学图书馆2008―2009年针对资源发现应用发展趋势和应对策略,专门成立项目组进行多层次的调查研究,结果报告显示：“图书馆未来的资源发现界面应该尽可能和具体数据类型无关,要在改善整体设计和功能的基础上尽可能减少各类资源发现界面的数量,为此,应尽可能随时随地地应用和开放相关资源OpenAPI,将资源发现界面组织和重组的工作越来越多地留给用户”.

1.1　资源发现应用涉及内容、数据类型分析

图书馆资源发现应用基本涉及到了其提供的各类型馆藏数据,包括对各种类型印刷版资源进行揭示的目录数据、数字馆藏涉及的商业数据库和特色数据库中的资源数据、读者利用图书馆过程中产生的历史记录数据及各数据库使用情况统计数据、图书馆地理位置开放时间等机构相关信息以及图书馆提供的一些词表术语数据等.目前,国外图书馆的这些馆藏数据都已被纳入OpenAPI的应用范围,其中以印刷型馆藏书目数据和数字馆藏数据为主.

馆藏书目数据的来源是各图书馆的书目数据库,书目数据多采用统一的标准(MARC)进行标注.因此,不管国内外图书馆采用哪种MARC标准,也不管采用的自动化系统如何纷杂多样,如果不考虑书目数据编目标注过程中的质量问题,各个数据库中书目数据都是标准的.调查发现,国外书目数据相关OpenAPI多提供两种类型的返回数据：精简记录和MARC全记录,目前返回数据混乱的情况出现在精简记录所包含的内容和具体数据格式方面.

与书目数据相比,数字馆藏的商业数据库和特色数据库方面采用的标准则多种多样,同样内容标注字段的名称各不相同,数据格式也各不相同,数据馆藏0penAPI的开发也比较混乱,有的(如美国国家医学图书馆)针对各个数据库开发API,有的(如剑桥大学图书馆)则先对相关数据库的数据及格式按照统一标准进行整合后提供统一的API或者为数据库统一管理平台开发API对外提供开放,显然后者更有利于OpenA-PI的标准化.

1.2资源发现应用OpenAPI的用户及开发需求分析

图书馆开发的资源发现应用OpenAPI的用户主要有三类：①本机构开发人员.图书馆开发的OpenAPI相当多地是为本机构其他应用调用而开发的,开发目的是通过这些OpenAPI将分散的众多的资源集成融汇在一起,或者借助于这些OpenAPI实现其他便捷增值怎么写作.由于这些OpenAPI大多是本机构开发人员及其团队开发的,因此其“随意性”较强,涉及的资源类型多样,发布协议、数据格式、数据内容可根据相关需要自行设定,权限控制信任度最高,相关文档大多不特别规范.②合作机构开发人员.面向此类人员开发的OpenAPI一般只涉及到机构某种或某几种资源数据库,合作机构对行业标准和相关术语比较熟悉,利用情况一般都在可控范围之内,信任度较高,文档比较规范,说明了具体的数据格式、调用方式等.③第三方机构和个人.面向此类用户的OpenAPI对用户数量、利用总体情况,用户行业术语熟悉情况等都无法掌控,需要考虑可读写和禁止读写内容的情况、权限控制比较复杂,数据内容需尽可能采用大众比较熟悉的标准,相关文档的规范性要求非常高.

按照资源发现应用用户与系统的交互功能可划分为查询应用、更新应用和提醒应用三大类,其中查询应用和更新应用需要实时进行交互,而提醒应用则只需要提前定义提醒内容即可实现自动提醒,无需实时进行交互.更新应用包括读者为书目发表评论、评级、标记标签等,都需要具有“写”操作权限,查询应用和更新应用一般只需要“读”权限即可.

2　图书馆资源发现应用OpellaPI通用标准规范分析

2.1数据封装发布协议(模式)标准分析

OpenAPI封装发布协议(模式)定义了OpenAPI交互数据的方法和格式.Musser J.于2011年5月份对OpenAPI注册网站Programmable Web登记的全体OpenAPI采用的封装发布协议进行统计和分析后,得出分布和变化趋势.　REST(REpresentational State Traner,表述性状态转移)、SOAP、JaScript和XML-RPC四种封装发布协议(模式)基本上已囊括了所有的OpenAPI；REST以绝对的优势成为主流封装发布模式并有逐年上升的趋势；SOAP是各OpenAPI采用次多的协议,但呈逐年降低的趋势；JaScript近年有逐年小幅增多的趋势,而采用XML-RPC方式的正在逐年减少.

REST实际上并不是一种标准,而只是一种针对网络应用的设计和架构方式,2000年由Roy T.Fielding博士在其博士论文中提出.REST是利用标准的HTTP方法和URI标准实现轻量级架构,具有“可利用缓存提高响应速度”、“浏览器即客户端模式简化了软件需求”、“通信无状态性提高了怎么写作器的扩展性,也适合云计算环境”、“基本上支持所有的浏览器”、“清 晰的应用设计”和“可返回多种不同格式”、“可实现直接交互等优点,目前已经成为网络怎么写作非常流行的方法,也出现了针对REST设计的协议规范,如OpenAPI REST Protocol Specificationttoj,但尚未获得业界的认可.国外图书馆行业多数OpenAPI也都是采用REST模式.

SOAP(简单对象访问协议)是Web Service的基本协议,采用XML作为标准的数据传输格式,使运行于不同操作系统并使用不同技术和编程语言的应用程序可以互相通信,但由于违反了REST通用接口和语义可见性等架构约束且解析和安全控制较繁琐等原因,在OpenAPI的开发中使用数量正在减少,多应用于一些比较老的系统中.

XML-RPC是Web Service的一种延续,简化了繁重的解析和安全控制,需要对原有系统进行少量改造才可实现.

这三种方式比较适合于请求与应答模式,如以搜索关键字和范围限定为参数发起搜索请求获得匹配的检索结果列表,JaScript则更多地应用于Web应用的图形绘制(如GooeMap应用)等相关OpenAPI中.

2.2数据格式标准分析

OpenAPI的数据格式定义了返回数据的表征格式,目前应用于OpenAPI中的数据格式保守估计也有数十种(据项目组的初略统计国内外图书馆行业OpenAPI数据格式已经有20余种),但大部分API优先提供的是XML格式和JSON(JaScript bject Nota―tion)格式.Musser J.2011年5月的调查显示：在Programmable web登记的近3 200个OpenAPI中,55％以上的API也支持JSON,但多数API都支持多种数据格式,2006年到2011年新开发的API中只有20％支持JSON,却也有20％的API不再使用XML格式.除此之外,比较流行的数据格式还有GData、Atom、RSS、HTML、YAML、RDF、CSV、TEXT、DC、OpenSearch以及PHP、Python、Ruby等脚本语言描述的格式.其中,JSON作为一种轻量级的数据交换格式,既易于人阅读和编写,也易于机器解析和生成,并可实现跨怎么写作器使用,因此成为包括OpenAPI在内的网络应用中越来越流行的数据交换格式.OpenAPI虽然采用的数据格式很多,但却没有必要进行标准化和统一,因为这些数据格式都有相应的应用重点领域,比如,对于怎么写作器端紧密集成来讲,XML是最好的方式,而对于简单的网络集成应用来讲,JSON则是最优的方式,HTML用于人类可读的内容,序列化(serializations)格式的数据用PHP、YAML等则比较合适,RDF则用于高级集成,而且为了适应不同的应用要求,往往都会提供多种返回的数据格式.

2.3安全控制与采用许可规范分析

相关调查显示,安全问题是OpenAPI开发者最为关心的问题之一.目前安全问题的解决方案主要有以下两个方面：

2.3.1　安全控制规范安全控制主要涉及相关的认证模式、访问量控制和频次控制.认证模式主要采用API key、IP地址绑定、用户名认证,甚至有些需要在上述基础上增加SSL支持.访问量控制限定每月访问量或者每日访问量,频次控制限定每秒链接次数或者连续链接之间的间隔,超过限定就会对相关账户、IP或者API key限用或停用.或者根据不同认证用户返回不同粒度的数据或设置不同的读写权限.实际上,国外图书馆关于书目数据的OpenAPI调用,尤其是简略格式的数据,一般都是无限制使用,不需要认证,也无需进行访问量控制和频次控制等安全控制.但是对于有版权限制的数字馆藏资源数据和包含隐私数据的读者个人信息或借阅历史数据则都要严格的认证,访问者需要联系OpenAPI提供者进行注册并获得授权(API key或用户名)后才可以使用且多数都需要限定在IP范围之内.近年日益流行开放授权规范OAuth目前虽主要应用于社交应用相关的OpenAPI中(已有20％的OpenAPl支持OAuth规范并呈迅速递增态势),但也可应用于图书馆具有安全控制的资源和数据OpenAPI的认证中,最先可应用的就是读者借阅信息查阅等含有隐私信息的OpenAPI.

2.3.2采用许可规范　OpenAPI软件层面的采用许可规范可参照开源软件的相关规范(如GPL、MPL、APL、BSD和CC)进行处理.许可规范主要是规定OpenAPI及其代码使用、复用、传播、发布、非商业使用、缺陷免责等方面的内容.OpenAPI提供数据方面的许可一般都限定在非商业使用许可,商业使用需要获得更进一步的授权.图书馆的书目数据还可采用开放数据的相关规范,如剑桥大学图书馆采用的PDDL规范,即非商用可免费不加限制利用.

2.4 OpenAPI文档撰写规范

开发OpenAPI的目的是方便其他人或机构利用该API进行调用而进行的二次开发,因此需要撰写规范的文档提供参考,但项目组对OpenAPI的调查过程中却发现相关的开发文档比较混乱粗糙,需要进行规范.虽然各类OpenAPI用户对文档规范程度的要求不同,但参考Programmable网站OpenAPI的登记规范和部分OpenAPI的文档,我们认为规范的文档至少应该包含这些内容：OpenAPI的名称、提供者及其相关信息、实现功能描述、封装发布协议、数据格式、数据请求的表达和所支持数据请求方式、数据请求和返回内容详细实例和说明、安全控制和使用授权的相关说明、调用过程中易出现的问题及解决方法、问题建议反馈的有效等,必要的话,应该提供主要编程语言调用的相关代码实例等.

3　图书馆资源发现应用OpenAPI行业标准规范分析

3.1　资源发现应用相关查询协议标准规范分析

美国数字图书馆联盟2008年12月推出了旨在将图书馆自动化系统为图书馆和图书馆之外其他机构的资源发现应用的规范“图书馆集成管理系统与外部资源发现应用有效互操作API技术推荐规范”,已经为Talis、Ex Libfis、LibLime、SirsiDynix、Polaris、OCLC和AquaBrowser等机构所签署遵循使用.该推荐规范抽象了图书馆行业资源发现怎么写作的“基本发现功能、OPAC功能、读者设计代替0PAC应用、特定领域专门发现平台”4个层面数据的交互、功能和封装,值得OpenAPI的开发者参考.该规范推荐REST作为界面设计规范,推荐SRU和OAI-PHM作为API查询和收割的协议规范.

3.1.1 SRU规范SRU协议是美国国会图书馆为改进Z39.50协议而开发的面向网络环境的信息检索协议,目的是通过提供通用的框架结构,整合对各种网络资源的访问规范.SRU Web怎么写作定义了Explain、 SearchRetrieve、Scan三种基本操作方法,将查询参数包含在URL中实现了Web查询的标准化、利用CQL(Contextual Query Language)查询语言执行查询并返回以DC、MARC、MODS等规范描述的XML格式文档.虽然包括美国国会图书馆、英国剑桥大学图书馆、中国科学院国家科学图书馆等机构都提供了SRU的怎么写作接口平台,但其应用远远不及其前身――元老级的书目数据查询协议Z39.50广,但Z39.50协议过于复杂,依据其进行开发的难度较大,虽然后来也出现了一些基于Z39.50的网络OPAC ,但其应用仍旧受限,图书馆行业之外基本上没有应用.若要为Z39.50的资源数据库提供OpenAPI,则必须利用ZETA Perl、YAZ等Z39.50开发API进行二次封装.需要说明的是,SRU信息检索协议目前的操作还不支持“写”操作,所以还只能应用于资源发现应用的查询应用中,增加评论、评级等更新应用仍需要采用其他方式来实现.

3.1.2 OAI-PHM协议0AI-PHM协议规范是OAI(Open Archives Initiative)为解决网络上元数据的互操作问题提出的元数据收割协议.该协议框架下有两种类型的参与者：数据提供者和数据怎么写作者.数据怎么写作者以HTTP协议支持的方式向数据提供者发送请求,返回XML格式的资源描述元数据；数据提供者对外发布元数据的接口就是某种形式的OpenAPI.2008年该组织推出的OAI-ORE数字对象复用和互操作规范在OAI-PHM元数据收割的基础上增加了复合数字对象的收割能力,也是OpenAPI实现可参考的协议规范,上述推荐规范囿于时间关系没有进行推荐.需要说明的是,借助于OAI-PHM和OAI-ORE规范实现的OpenAPI更适用于合作机构之间和用户特定应用中的大量资源数据交互,因为这两个规范的“检索”功能比较弱而且只能传输XML格式数据,也不支持“写”操作的更新应用,可用于资源发现应用的“提醒应用”.借助于RSS、AtomPub协议实现RSS怎么写作接口也可看作简单的OpenAPI,实现功能与OAI-PHM比较相似.

3.2行业内容数据格式标识规范分析

图书馆行业OpenAPI返回数据的描述语言和格式与行业外OpenAPI并没有太多的不同,主要也是返回XML和JSON格式的数据,不同的是内容数据格式.调查发现主要有三类：MARC类型数据、DC类型数据和特定内容格式数据.

3.2.1　MARC-XML和MARC-JSON　MARC-XML由美国国会图书馆推出,将MARC格式描述的资源全部以XML结构化的语言标记,字段标识符被标记在dat―afield的tag属性标签下,子字段标识符被放置在sub-field的code属性标签下,数据内容被标记在subfield相应的code属性标签下,各机构使用时并没有太多区别,只是有些机构简化调用,XML没有使用相应namespace.MARC-JSON目前尚无正式的标准格式,OCLC 2010年3月份推出了草案版的MARC-JSONt23j,仍旧以datafield、tag、subfield、code来序列化标识具体的描述内容,只是数据格式转变为JSON.也有人对此进行了简化,使用fields：字段标识符：字段内容,等字段标识符：subfield：字段标识符：字段内容的形式进行标识.但是,MARC标准只是图书馆行业的标准,行业之外很少有人熟悉,MARC格式的数据,不管是全纪录数据,还是精简记录数据,一般只应该由图书馆机构内部用户或者图书馆合作机构用户来使用,因为对于数百个MARC字段以及相应的子字段和指示符,即使专业人员有时都搞不清楚具体字段标识符数字真正代表的语义,开发API时除非必要,不宜向图书馆行业之外的机构和个人返回此类格式数据.

3.2.2 DC系列格式DC源于出版领域,只使用15个核心要素(2005拓展版使用了22个要素)来描述资源,已经成为一种国际范围内通用的适用于资源发现系统的元数据标准,为众多领域的用户所熟悉,SRU和OAI―PHM也对DC提供了支持.为了便于各行各业的用户利用DC,DCMI提供了DC-TEXT、DC-HTML、DC-DS―XML和DC-RDF4种描述数据的格式供选择.D种格式的描述数据使用的标识标签就是要素的名字,普通数据阅读者根据要素的名字即可知道要素所描述的内容.因此,建议图书馆面向第三方机构和个人开发和提供OpenAPI时,采用DC系列格式返回数据.

3.2.3特定内容格式数据除了MARC和DC外,国外一些图书馆在开发OpenAPI时定义了特定内容XML格式的返回数据(如美国北卡罗尼娜大学图书馆的Cata-logWS API),也有的(如美国Ann Arbor District图书馆的PatREST)对返回结果列表MARC格式使用非行业术语标签进行转化,转变成读者比较熟悉的XML结构化结果.另外,也有的机构为文献可用状态设定规范,以满足馆际互借文献可用状态的查询,如德国图书馆联盟利用JSON和XML制定DAIA规范.但是出于OpenAPI标准化的需要,我们认为除面向本馆开发人员的OpenAPI和特定需求外,尽可能不要在面向第三方机构和个人开发OpenAPI时提供此类特定内容格式数据,以减轻他们在利用和解析不同OpenAPI时的负担.4结语

本文针对图书馆资源发现应用OpenAPI的开发问题,对目前OpenAPI采用的通用标准和图书馆相关的行业标准进行分析并推荐了可以使用的相关标准,但是技术层面的标准化还是相对容易的,机构和开发人员标准化的意识才是最重要的.而且,OpenAPl只是图书馆资源发现应用对外实现提供调用的一个接口,数据的标准化程度还和前期资源的描述、整合有着密切的关系.因此,要想实现真正的标准化,还需对所要开放的资源进一步的优化.另外,图书馆资源发现应用的“更新应用”尚未发现相关标准,需要进一步研究.