伯克利协定与图书馆集成系统通用API

    数字图书馆联盟(DLF)于2007年夏成立图书馆集成系统发现界面专责小组(ILS-DI),分析在传统ILS与互联网发现应用之间达到有效互操作的问题,致力于提出一个技术解决方案──简言之,就是确定ILS以何种方式向图书馆与互联网开放。其背景是:越来越多的图书馆已经采用或正在开发独立于ILS的外部发现应用,包括OPAC前端,集成搜索服务、标签服务、社会化软件等。

    2008/3/6,DLF代表与主要图书馆应用厂商在加州伯克利讨论由小组提出的技术建议草案,即所谓“伯克利协定”(Berkeley Accord)。建议针对将ILS的数据和服务与支持用户发现的新应用集成的标准界面,允许图书馆部署新的发现服务以满足Web2.0时代不断成长的用户体验,充分利用高级ILS数据管理与服务的优势,催生新一代图书馆管理与发现应用中强大的创新社区与市场。
    与会者同意,通过部署特定推荐标准,经由开放协议与技术,支持一系列基本功能,包括:
1、收割(Harvesting):收割馆藏数据记录,完整的或基于最新变化的,核心书目记录或与馆藏、流通数据结合的记录。通过OAI-PMH接口实现。
2、可获得性(Availability):实时查询书目项的可获得性。通过ILS-DI专责小组指定的简单REST接口实现。
3、链接(Linking):固定方式链接到OPAC中任何项。通过ILS-DI专责小组为OPAC定义的URL模板实施。

    签署协定的厂商有(undersigned by):
   1. Talis
   2. Ex Libris
   3. LibLime
   4. BiblioCommons
   5. SirsiDynix
   6. Polaris Library Systems
   7. VTLS
   8. California Digital Library
   9. OCLC
  10. AquaBrowser
    唯一弃权的厂商(Abstention):
   1. Innovative Interfaces, Inc.

    经过三个月时间,ILS-DI于2008/6/4发布了长达78页的正式技术建议(DLF ILS Discovery Interface Task Group (ILS-DI) Technical Recommendation)(PDF, 269KB),包括四个层次的互操作共25个功能:
Level 1: Basic Discovery Interfaces
• HarvestBibliographicRecords (Data Aggregation, section 5.3.1)
• HarvestExpandedRecords (Data Aggregation, section 5.3.2)
• GetAvailability (Real Time Search, section 6.3.1)
• GoToBibliographicRequestPage (OPAC interaction, section 8.3.1)

Level 2: Elementary OPAC supplement
All of the above, plus
• HarvestAuthorityRecords (Data Aggregation, section 5.3.3)
• HarvestHoldingsRecords (Data Aggregation, section 5.3.4)
• GetRecords (Real Time Search, section 6.3.2)
• Search (Real Time Search, section 6.3.3)
• Scan (Real Time Search, section 6.3.4)
• GetAuthorityRecords (Real Time Search, section 6.3.5)
• Either OutputRewritablePage or OutputIntermediateFormat (OPAC Interaction, sections 8.3.2 and 8.3.3)

Level 3: Elementary OPAC alternative
All of the above, plus
• LookupPatron (Patron Functionality, section 7.2.1)
• AuthenticatePatron (Patron Functionality, section 7.2.2)
• GetPatronInfo (Patron Functionality, section 7.2.3)
• GetPatronStatus (Patron Functionality, section 7.2.4)
• GetServices (Patron Functionality, section 7.2.5)
• RenewLoan (Patron Functionality, section 7.2.6)
• HoldTitle (Patron Functionality, section 7.2.7)
• HoldItem (Patron Functionality, section 7.2.8)
• CancelHold (Patron Functionality, section 7.2.9)
• RecallItem (Patron Functionality, section 7.2.10)
• CancelRecall (Patron Functionality, section 7.2.11)

Level 4: Robust/domain specific discovery platforms
All of the above, plus
• SearchCourseReserves (Real Time Search, section 6.3.6; for academic libraries)
• Explain (Real Time Search, section 6.3.7)
• Both OutputRewritablePage and OutputIntermediateFormat (OPAC Interaction, sections 8.3.2 and 8.3.3)

    若干年前,图书馆对ILS厂商除了抱怨无计可施。2005年John Blyberg提出图书馆集成系统客户权力(ILS Customer Bill-of-Rights) ,引来讨论无数,正是这种状况。随着Web2.0的兴起,美国图书馆界竟然能在这么短的时间内通过努力让局面为之一变,真令人赞叹!随着建议在ILS厂商的逐渐实施,ILS通用API将使未来OPAC应用更加多姿多彩。

相关信息:
ILS-DI技术建议网页:宾州大学图书馆John Ockerbloom为ILS-DI小组主席,网站设在该馆。据云技术建议书也将发布在DLF网站。
Peter Brantley’s thoughts and speculations: ILS Basic Discovery (April 4, 2008)
加州大学伯克利分校图书馆Peter Brantley介绍DLF代表与主要图书馆应用供应商在加州伯克利讨论草案的情况,以及DLF对此事的新闻稿“ILS Basic Discovery Interfaces: A proposal for the ILS community”。

选择OPAC前端──威斯康星大学麦迪逊分校报告

    2006年初北卡州立大学(NCSU)推出基于Endeca的新一代OPAC前端,以此为契机,忽如一夜春风,市场上类似产品大量涌现,不依赖于特定的图书馆集成系统、商业的或者开源的,让想要步NCSU后尘的图书馆面临相当多的选择。
    虽然OPAC早已不再是图书馆资源的唯一入口,但更换OPAC外观及功能仍是需要认真对待的事,除功能外,一方面要听取用户意见,另一方面还要平衡费用(商业)与技术(开源),不可能凭着感觉拍脑袋决定。
    威斯康星大学麦迪逊分校图书馆(University of Wisconsin – Madison Libraries)为此于2007年冬成立了由8人组成的资源发现探索专责小组(Resource Discovery Exploratory Task Force),经过半年左右工作,于2008/6/2提出了长达74页的最终报告(PDF,870KB),并已获得认可。
    本报告以“资源发现”(Resource Discovery)为名;Lorcan Dempsey介绍时称“机构发现系统” (Institutional discovery systems);Marshall Breeding则将下一代OPAC称为“发现层界面” (Discovery Layer Interfaces)──未来OPAC大概会被“资源发现系统”之类名称取代了。

目次
1、执行摘要和结论
2、工作陈述/目标
3、环境扫描
4、文献评述
5、用户扫描
6、产品扫描
7、附录(专责小组职责、联机公共调查及结果、重点小组、开放论坛论题、参考文献)

    小组在2008年1月建了博客Resource Discovery at UW Libraries,可以看到整个研究及用户调查过程。最新博文(2008/6/6)转载了报告的第一部分Executive Summary and Conclusions。报告针对的是UW使用Voyager系统(现属Ex Libris)及参与OCLC(WorldCat)的特定状况,并未对所有相关产品作出完整的测评,但一些看法还是具有普遍意义的,并且提及很多实际应用的图书馆,因而具有相当大的参考价值。

    产品扫描部分分析了一些产品的特点(features)、优势(strengths)与不足/挑战(challenges)。特别针对商业产品的不足部分略作摘要:
6.1 商业产品(Vendor-Supplied)
6.1.1 Aquabrowser
    有些人把可视图当作噱头,而另一些人则认为非常新颖。[一开始主要是公共图书馆在采用,虽然报告称5/11查询时发现已有26个学术图书馆采用,虽然已有芝加哥大学在使用,但可视图的确有可能会让学者觉得太小儿科]
6.1.2 Encore和Enterprise Portal Solution [SirsiDynix]
    Innovative Interfaces是主要图书馆供应商中唯一不签署“伯克利协定”(Berkeley Accord)的。我们不应该与拒绝支持互操作标准的供应商合作。(p.29对“伯克利协定”的说明:几乎由所有主要图书馆供应商签署,支持提供一个基于XML的图书馆发现界面API (an API for use by XML-based library discovery interfaces)。理论上,使用这一API所写的发现界面可用于任何ILS)。
6.1.3 Endeca
    其界面由个别图书馆创建并负责更新,如同开源或非供应商提供的产品……但是,有共享代码的合作Endeca库工作环境。[与开源产品一样,要改变界面需要图书馆投入很多精力编程]
    Endeca与许多开源产品基于同样的代码。由于其在联机销售方面有巨大的市场占有率,不清楚未来图书馆是否仍会是其主要关注点。[应该说从来就不曾是吧,如果它退出图书馆市场,其维护就更成问题了?]
    除了每年的许可费,视[数据量]大小Endeca的价格从5万到40万美元。对于我们的情况,未经证实的价格在20-30万美元,年许可费5万美元。[唯一一个点明价格的,Why?]
6.1.4 Primo
    [只有优点没有缺点?]
6.1.5 WorldCat Local
    相关性排序算法会将本地资源列在第一或第二,此外排序算法是私有的。目前拥有某一文献的WorldCat成员馆数在排序中摇摆不定,和[搜索]词在记录中出现情况一样,但成员馆的类型并未考虑在内。由于WorldCat有大量公共图书馆,那些我们的服务对象可能极感兴趣的一些极有学术价值与昂贵的文献则会排名较低。
    只包含有OCLC号并列入WorldCat的本地馆藏……订购中、处理中、剔除中的无法处理。
    对由于订购而装入MadCat[本地OPAC]的第三方许可或购买的记录……可能有或没有相应的OCLC记录。……肯定OCLC和其他图书馆正在处理这个大问题。
    当前我们把位于SFX的电子期刊馆藏的MarcIt记录装入了MadCat,我们必须如已在做的那样,加入OCLC的eSerials项目,但这方面可能更复杂。
    WCL没有索书号检索……
    [显然OCLC还有很多问题要处理;而图书馆首先得加入更多WorldCat项目,才有完全解决这些问题的可能。OCLC显然很欢迎长达4页的全面测评,但报告中提出的N多问题,或许OCLC并不一定觉得都需要处理。]
6.2 开源(Open Source)
    [开源部分由于大多尚无实际应用,基本未作测评,只是泛泛而谈]
最后部分列出的浏览器扩展、工具条及小工具(平台)(Browser Extensions, Toolbars, Widgets and Gadgets)
Zotero
BookBurro
Conduit
iGoogle, NetVibes, PageFlakes, yourminis
Facebook

Via Lorcan Dempsey’s Weblog: Institutional discovery systems (2006-6-6)
参见:
OPAC改朝换代由此开始 (2006-01-16)
WorldCat Local:取代本地OPAC?(2007-04-16)
Encore是个什么“工具”?(2007-06-06)
芝加哥大学图书馆的LENS:高校馆也用AquaBrowser (2008-01-05)
Ex Libris的OPAC前端Primo (2008-05-09)

CNKI引文数据库与H指数、W指数

    丫枝介绍w-index后(h指数(h-index)之变体–w指数(w-index)诞生),去那儿留言鼓动他做牛人们的h-index和w-index,看到结果(图林牛人们的h指数与w指数选择阅读图情牛人经典文献(鸡鱼w指数)),也想算算自己的指数几何。
    进入CNKI中国引文数据库(http://ref.cnki.net/),看到左栏“统计数据”下有“作者统计”,想当然地由此而入,其下已有“H指数”这一项,但如何获取w指数?总不至于逐篇查找后统计?
    看丫枝一日间做了N多牛人的统计,网上碰到,就讨教如何做成的。一来二去,才发现自己弄错了入口,如丫枝所言,“在初级检索处,直接输入作者名就行”──JADSL的人机交互老师Michael B. Twidale说,What you see depands on what you know,这里居然是个逆向干扰的例子。
    如上所说是新的引文库入口,需要注册才能使用(依丫枝告,免费注册使用),直接检索的结果提供题名及被引频次等信息,可依次复制到EXCEL中处理。由于进入时看得不仔细,一度从旧版进入(竟然是无需注册的),结果发现检索结果一览就是表格形式的,可以整批复制到EXCEL表中,处理起来方便不少。(在CNKI主页上看介绍新旧引文库应该是一致的,但实际检索结果略有差异,不知何故)
    根据丫枝发来的统计表样例,按文章被引频次在EXCEL表中降序排序,从上到下有N篇被引N次,则H指数为N;有M篇被引10M次,则W指数为M。果然“简单”。

    转引丫枝对w指数值意义的说明:
i) w 指数为 1 或者 2,表示该研究者已经学到了一个课题的基本。
ii) w 指数为 3 或者 4,表示该研究者已经掌握了 the art of scientific activity。
iii) w 指数为 5,表明他是位成功的研究者。
iv) w 指数为 10,表明他是为出色的科学家。
v) 工作 20 年后 w 指数超过 15,或者 30 年后指数超过 20,那就是顶尖科学家了。

    查了一些人的H指数和W指数后,感觉H指数更有区别性,任何人只要发表一篇文章得到一次引用,就得到H指数为1;而要使W指数为1,至少须得有一篇文章被引十次以上(不是总被引次数)。我查到几位H指数从1到4的,W指数均为0──W指数用来给大牛们排名还有点用,要用做一般人的评价指标则是形同虚设了。不过,如果上面这个“意义说明”竟被有关部门认可,也会让N多牛人非常伤心的。

    老槐曾认为当年选择“三大检索刊物”作为大学排名研究的依据是由于这几个刊物的检索功能而非收录内容(排行榜研究的智慧),事实是否如此不得而知。但此次丫枝做引文分析选CNKI而舍CSSCI,则明确申明是功能的原因。自己很少有几次不得已使用CSSCI,总有恨铁不成钢的感觉──多少年了,得到荣誉无数,怎么还看不到多少长进呢?

参见:
CNKI的引文检索功能(兼及维普)(2005-09-14))
Scopus与引文评价H指数 (2007-09-12)
中美数图研讨班2008·人机交互与数字化图书馆 (2008-05-24)