若有所思 – 第 235 页

选择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)

在OPAC中加入Google图书信息

Google图书搜索(GBS)中有不少图书可以看全文或可做全文搜索，在图书馆OPAC中加上其链接，实际上等于为图书馆增加了一大批电子书。当然，如果能有GBS可看全文图书的全部书目记录加入到OPAC，对图书馆更是免费的午餐──MBooks已经提供了这样的午餐。

说回GBS，3月份时Google发布了GBS的API，不到三个月，已有很多图书馆在OPAC中加上了GBS链接。上月DePaul大学的Hilary Kraus在NGC4LIB邮件组征求实例“Integrating Google Book Search content into OPACs”，得到不少回应。这是她前几天的总结“Integrating Google Book Search content into OPACs — summary of examples”，发出后又收到一些回应。

    从使用情况看，有直接将链接结果嵌入网页的（显示封面或/和显示图书状态──noview, partial, full），也有提供链接即时查询的（意味着有可能实际上没有该书）。似乎大部分是采用在OPAC模板中嵌入JavaScript的方法实现，不同的是有的嵌在结果一览页，有的嵌在详细显示页（后者“打扰”GBS的机率小些）。肯特州立大学采用Innovative公司的自动化系统，其目录KentLINK用前者，在页面嵌入了“Google Book Search viewability API script”。
    德国科隆大学的Oliver Flimm则告知他们采用在后台使用GBS的JavaScript-API的方法实现（实例），目前只对full和partial两种提供链接。由于这种方法意味着不是由浏览器访问GBS，而是由服务器对GBS做批量操作，故而约翰·霍普金斯大学的Jonathan Rochkind询问是否会受到Google方面的流量限制。Oliver的回复是他也很担心，但岂今为止还没有。
    这种由服务器端操作的好处是每本书只查一次，而不会每次显示该书目时做一次查询。Oliver说他在Google的BookAPI新闻组提出将这种方法作为GBS-API的官方扩展，但未得回应。他并提出可以做一个本地快照，保存ISBN及对应GBS的full/partial状态。
    前些天开会时，遇到复旦数字化部张主任，讲到他们在OPAC中加上超星等电子书的链接，采用的大概就是这种方法吧。其实前年访问复旦时，张主任就曾介绍过他们链接教学参考书的情况，自己居然一点都不记得了，惭愧！

参见：
用Google图书搜索API增强OPAC (2008-03-16)
密歇根大学MBooks提供OAI接口 (2008-06-02)

[update 2008-6-7]
刚看到 GBS API 于5月31日推出了服务条款，如果要使用这项服务，请仔细阅读，实在很复杂。
2.11 举了一些不可做的事，其中一条："crawl," "spider," index or in any non-transitory manner store or cache information obtained from the Service。因此Oliver所说的方法应该是被禁止的。之前大约服务条款未定，所以Google方面没有回应。

Via Covers from Google: Too good to be true? from Thing-ology (LibraryThing’s ideas blog) by Tim（2008-6-6）

LC对书目控制未来工作组报告的回复

    6月1日，距报告正式发布近5个月，美国国会图书馆副馆长Deanna B. Marcum (Associate Librarian for Library Services)发布了对书目控制未来工作组报告的回复“Response to On the Record: Report of the Library of Congress Working Group on the Future of Bibliographic Control”(PDF, 441 KB)。
    文前说明收到报告后，她请三方帮助进行分析，对报告中的每项建议提出应否实施的解释：
1、LC采编部(Acquisitions and Bibliographic Access Directorate)管理组(Management Team)
2、图书馆服务部(Library Services)的内部工作组
3、Thomas Mann，对书目控制系统所提出的改进大加批评的LC参考馆员
    除了Mann仍坚持已见，1和2都持强烈支持态度。尤其是2，花数月时间仔细分析LC对工作组报告已经及未来可以做的。

估计这个内部工作组是Marcum为撰写此回复而临时组织的。而找Mann则是为了表明听取不同意见──Mann对报告的负面回应二个多月前已经发布。

    在3页说明之后，是长达72页的正文，依次对报告中提出的各项建议(Recommendation)予以回复，每个回复包括三部分：
        LC的回应与准则(LC Response and Rationale)：说明是否支持该建议及理由
        目前的行动(Action: Current)
        计划中的行动(Action: Planned)
    文件太长，无暇细看。全文搜索了一下，有理由、无理由，有条件、无条件，基本上报告中提出的建议都接受了（大多标为Support），除了以下这条明确“Do not support”：
1.1.3.2 发展一种机制，认可在编目前以自动方式创建的书目记录著录部分。(LC: Develop a mechanism to accept these data in a fully automated fashion so that the descriptive portion of the bibliographic record is created prior to cataloging.)
理由是目前ONIX和ECIP与出版社工作流程之间尚不兼容。LC计划继续参与ONIX开发，将会关注从ONIX中抓取数据的机会。

这唯一的一条“不支持”，看上去与“支持”也没什么两样。据此本人的结论是：照单全收──本来就可说是在Marcum授意下完成的报告，有这种结果也是不难理解的。
接下来，大概就是跟着LC行动了？

Via: Marcum on WoGroFuBiCo (from The FRBR Blog by William Denton)

参见：
《书目控制未来报告》（草案）解读 (2007-12-05)
“记录在案”走入歧途──对书目控制未来工作组报告的回应 (2008-03-23)