若有所思 – 第 232 页

给Google工具栏加上喜欢的搜索工具

    偶然发现Google工具栏（第4版及以上）的自定义按钮功能，可以很方便地加上自己喜欢的搜索工具，方法非常简单──当然前提是浏览器已经安装了Google工具栏。比如想加一个豆瓣的搜索，只要：
1、访问豆瓣：http://www.douban.com/
2、点击搜索框，按鼠标右键，通常快捷菜单的最末一行就是“生成自定义搜索…”
3、点击“生成自定义搜索…”，会跳出“Google工具栏自定义按钮生成器”，可以修改自动获取的标题（douban）和说明（豆瓣），按一下“添加”就OK了
    以这种方式添加，IE会在工具栏上增加一个按钮，同时也在搜索框中增加一个选项。而Firefox则只在工具栏上增加按钮。
    使用中发现，不是所有网站的搜索框都能用这种方法添加到Google工具栏，如大众点评网就不行。

    我感兴趣的是，如何把搜索图书馆OPAC、自建数据库等加到Google工具栏上。当然可以如上那般告诉读者怎么做，但单个功能太简单，更好的方法把多个功能合成在一起，让读者点击一个链接就OK──就象conduit工具条那样。
    Google 工具栏 API介绍了添加自定义按钮的五种方法，特别详细介绍了第4版工具条的自定义按钮的XML语法，可以通过编写XML文件，并把文件提交到Google工具栏按钮库，实现一次点击安装。不过目前只适用于IE。
    在Google工具栏按钮库中查“OPAC”，目前已有三个图书馆提交了自己的OPAC按钮（意大利?、德国、日本），均适用于Google工具栏第5版。查“library”、“catalog”、“catalogue”分别有152、83及22项，互有重复，还夹杂着一些非图书馆应用，也多适用第5版。其中有台湾中央研究院OPAC，OCLC制作也好几个，包括WorldCat Search。

按钮添加后，其XML文件保存在本机文件夹：C:Documents and Settings登录名Local SettingsApplication DataGoogleCustom Buttons。从本机XML文件看，第5版按钮使用了Google工具栏API中没有提及的XML元素<gadget>，把搜索相关代码放在搜索网站的XML文件中（第4版一般在本机XML文件中直接使用搜索元素<search>），同时使用<update>元素实现本地按钮内容的与网站同步更新。
第5版工具栏自定义按钮的基本特点是在点击后，会下拉出一个由<gadget>定义的窗口。如Worcester理工学院的Gordon Library Quick Start，其<gadget>语句：
<gadget whole-dropdown="true" width="285" height="300">
http://hosting.gmodules.com/ig/gadgets/file/112404218028859408818/wpigordonlibrary.xml
</gadget>
添加到工具栏，点击后的情况如图：

这是做得比较漂亮的，除了几个搜索，还有即时参考咨询链接，可称一个网站小导航了。

本馆已有了适用IE与Firefox的conduit工具条，还有一些读者希望有适用TT与傲游的版本。而这个只适用于IE，所以暂时不打算制作。
要制作一个功能较为齐全的工具栏，与conduit相比，Google工具栏的自定义按钮不够傻瓜，因而也就更自由，或可实现conduit难以实现的功能。热衷于写代码的，应该可以做出很漂亮的应用。

关于conduit工具条：目前已有本馆及清华大学、国家图书馆制作使用。[update 2008-11-6: 厦门大学工具条内测版下载网址：http://xmulibrary.ourtoolbar.com/]
另可参见：
浏览器工具条的推广及反馈 (2008-03-15)
本馆浏览器工具条使用统计 (2008-01-11)
制作图书馆的浏览器工具条 (2007-03-13)
定制浏览器工具条 & 定制RSS源 (2006-08-01)

update 2008-11-6:
Deepocean留言指出，Firefox2及IE7以上支持OpenSearch，可以自定义把其它网站的搜索框集成到浏览器的搜索框中。厦大的测试网址：http://deepocean.amoyu.org/searchplugin/xmulib.html
网上搜索到一个很简单的实例介绍：Firefox 3 tips: 加入自定义的OpenSearch，入门不错。

PCC实施废除440字段

合作编目项目(Program for Cooperative Cataloging)发布“PCC Guidelines for Field 440”(1页PDF)，建议成员馆从2008年10月24日起废除440字段，以490 1代替。

490字段第1指示符“1”的新定义：
1 – Series traced in 8XX field
New Definition:
When value “1” is used, the appropriate field 800-830 is included in the bibliographic record to provide the series added entry.

改变440字段的建议早在6月6日即已提出（MARC Proposal No. 2008-07）。背景声称是由于440字段既是丛编描述又是规范检索点，其实这又有什么关系呢？LC不再维护丛编规范记录，使440没有存在的根基才是真正的原因。讨论中曾想取消490 1，但由于大多数图书馆的丛编索引取决于490第1指示符，最终确定从文字上修改第1指示符“1”的定义。
如果取消490 1，对编目员来说就省事了，直接在8XX字段著录就是了，而按现在的决定，是要在8XX重复。大部分情况下，书上的丛编描述与丛编规范是一致的。

由于丛编规范名不再存在，同日提出的另一项与之相关的建议（MARC Proposal No. 2008-06）是在800-830及490中增加$3，说明所用丛编名适用的范围或时段。看实例比看说明省事得多：
例一：
830 #0 $3 1980: $a DHEW publication $x 0090-0206
830 #0 $3 1982- $a DHHS publication $x 0276-4733
例二：
830 #0 $3 <May 1986-> $a Tourism research series.
例三：
830 #0 $3 v. 1-8 $a Collection Byzantine $x 0223-3738
830 #0 $3 v. 9 $a Collection des universités de France $x 0184-7155
例四：
490 1# $3 <1981->: $a Reference works
830 #0 $a Reference works.
例一、例三的两条830字段应该是分别出现在两条不同的书目记录中的，而例四的则是同一书目记录中的两个不同字段。由此也可以看到490与830其实是完全一致的。

via Catalogablog: Field 440

背景：
2006-4-20 LC宣布停止对丛编的规范控制，2006-5-1 实施
网上反对签名达 3495 个
2006-5-4 LC宣布推迟到2006-6-1实施
2006-5-11 LC专业人员协会执委会通过“对LC管理层停止生产丛编规范记录生产的决议”
2006-6-1 LC停止创建丛编规范记录

约翰·霍普金斯大学的Umlaut应用

约翰·霍普金斯大学(JHU)图书馆新近在该馆链接解析器SFX和OPAC上增加了一些新功能，提供链接到公开访问的全文图书，链接到图书预览/片断，而且在页面中嵌入“书内搜索”。这些功能由Umlaut链接解析器前端实施。使用Umlaut的JS帮助器代码，可以方便地在OPAC中嵌入Umlaut的内容。JHU使用的集成系统是Horizon。
嵌入OPAC页面不难，但为实现前述功能，在写代码上还是花了不少功夫，目前仍待改进。并且所用的有些服务有了新的API，也需要据以更新Umlaut。
现在的代码不少由暑期实习的研究生Jason Ronallo所写。看他的自我介绍可知，本项目由Ruby写成。
目前Rubyforge上的Umlaut项目页面尚未发布任何文件，有关内容发布在Code4Lib的wiki上。
自半年前JHU的Jonathan Rochkind“重新”启用Umlaut，一直努力推介Umlaut，希望感兴趣共同完善。目前Umlaut功能依赖于SFX实现，Rochkind也希望可以用于其他链接解析器。

目前用到的服务包括：
· 亚马逊
· Google图书搜索(GBS)
· Internet Archive (IA)
· HathiTrust（http://www.hathitrust.org）
· OCLC的身份档(WorldCat Identities)（作者信息）
· isbndb.com（图书比价网站）
封面图像来自：
亚马逊
GBS
Open Library
CoverThing（来自LibraryThing）

新功能的实现依赖于多项外部服务，因而速度不能保证。但由于采用Ajax逐渐载入获取的数据，用户可以先看基本书目信息，外部数据在loading…完成后逐渐显示，使用体验还不错。
图书馆收藏的图书，可公开访问的毕竟不多，且多半是过了版权保护期的，在美国是1923年以前的旧书；而有“书内搜索”与片断预览的，则主要是新书，并且据Rochkind所知，数量相当大。所以他认为后者会更受用户欢迎。二者结合，不知占馆藏几何？无论如何，集成众多图书信息的OPAC，增值不少。

下面是Rochkind举的若干例子。

一、链接OA的数字化图书：
· GBS：使用LCCN、OCLC号及ISBN匹配。不知目前所据为何，未来将改用GBS的Data API。
GBS与IA链接实例：Mark Twain’s letters

· Internet Archive：目前使用作者/题名匹配，未来将改用出现不久的OpenLibrary API。想来目前的“参见”，链接到同书的各种不同版本，就是通过作者/题名匹配的。
IA链接实例：Prison memoirs of an anarchist

· HathiTrust：与GBS一样，使用LCCN、OCLC号及ISBN匹配。
只在GBS没有时才显示。Rochkind指出，有些GBS不提供全文的，HathiTrust提供全文。
可惜他所举的例子Chaucer’s Canterbury tales（SFX链接）到HathiTrust后，同样显示由于版权限制不能看全文──后面的多个例子使我相信，HathiTrust显示全文是有访问IP限制的。
在OPAC中，Chaucer’s Canterbury tales并没有显示HathiTrust链接，因为在该馆的这条MARC记录中，没有LCCN、OCLC号及ISBN。或许可算书目数据质量影响用户体验的一个歪例吧。

二、嵌入书内搜索：
· 亚马逊和HathiTrust实例：Vision on fire : Emma Goldman on the Spanish Revolution
由于版权保护，HathiTrust说明有18个检索结果，但并不显示相关内容。
亚马逊的结果则有内容片断，黑体显示检索词，链接到原文需登录。

· GBS和HathiTrust实例，同上：Mark Twain’s letters
GBS检索结果显示片断，用黄底突出显示搜索词。此书在美国属开放存取，但在中国是“摘录视图”。
HathiTrust同样说明由于版权限制，不显示相关内容。

三、作者信息：
根据OCLC书目号，链接到WorldCat Identities。
Umlaut具有显示维基百科相关页面的功能，但由于Identities会包含维基百科页面，所以JHU目前关闭了这个功能。

四、IA有声图书：
目前使用的IA搜索API会显示是否带有声书，而Open Library的API并没有此项功能。所以对有声图书，未来仍将沿用原API。
实例见：The adventures of Tom Sawyer

所有截图见：约翰·霍普金斯大学的Umlaut应用

via Bibliographic Wilderness
Digital Book features in link resolver and opac (2008-10-16)

Umlaut的相关信息：
相关代码说明：Bibliographic Wilderness: Umlaut APIs (2008-10-2)
内容在Code4Lib的wiki：Umlaut partial html API javascript helper
Rubyforge的Umlaut项目页面
Bibliographic Wilderness: Rethinking the role of an OpenURL link resolver (2008-9-25)
开源的链接解析器前端Umlaut (2008-03-01)

关于HathiTrust：
图有其表：大象来了 (2008-10-14)

关于WorldCat Identities：
规范档2.0：WorldCat身份档 (2007-02-14)

关于OpenLibrary API：
Open Library也提供API (2008-5-11)

关于GBS API：
用Google图书搜索API增强OPAC (2008-03-16)
在OPAC中加入Google图书信息 (2008-06-06)
在图书馆OPAC预览Google图书 (2008-09-23)

关于书内搜索：
Google与Amazon书内搜索比较 (2005-05-07)
亚马逊“书内搜索”扩展功能 (2005-05-18)