在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 (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)

Open Library也提供API

Open Library也有API了,又多了一个可以强化OPAC内容的来源了。
从目前的功能看,可以通过向http://www.openlibrary.org/api/things发送GET请求查询、获取对象,由于是Open Library的每条书目是一个wiki页面,有历史记录,因而甚至可以获取书目信息的某个特定版本(version)。

Open Library所用wiki引擎为Infogami,可以存储结构化的数据,其所谓的“对象”包括任何页面(每种书一个页面)的模板、版本、作者等,每个对象各有其对象类型。看对象类型,没看出有没有最感兴趣的全文链接(/type/uri?)。
有一个“API沙盘”可以用来试手。

比较有意思的是David Pattern谈论此事的博文。看看这位对Huddersfield大学OPAC做过很多领先改进的技客,如何看待互联网环境下的Z39.50标准──SRU(当然还有MARC):
“关于此API,在Code4Lib邮件组中有一场有趣的辩论──它们是否该用SRU、还是只用简单的API更好?我完全赞同非图书馆技术人员也可用得上的简单API。”
“我已在图书馆作为开发人员工作了近14年,我从未使用(甚或认真看过)SRU。当我阅读说明书(specification)时,我感觉自己的眼睛开始慢慢变得呆滞。也许是因为我由COBOL语言写电子数据交换(EDI)处理软件起步,我总是怀疑开发图书馆用(如Edifact,Z39.50,MARC等)说明书者全都是帮虐待狂 ; -)”

参见:Self-plagiarism is style: new API from OpenLibrary