约翰·霍普金斯大学的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)

中外文图书混合排架问题

    最近网友心底悠悠和“馆员”在“读吕叔湘《民国时期总书目》序”(2006-11-15) 下留言,针对的是吕老先生提出的中外文混合编排问题:
   “在我们的图书馆里,外文书和中文书是分开编目、分开收藏的。因此,不但是关于同一个问题的论著由于语种不同而分别编入两本目录,分别放在两个书架甚至两个书库,连一本书的原文和译本也不得不分开两处。再加上线装书与非线装书之分,目录是三份,书库是三处。对于从事学术工作的读者,这也是极大的不便。在欧美国家,很多图书馆都是混合编排,把同一著作的不同语种版本放在一起,同一题目不同语种的论著也放在一起。这对于读者目录和借书就方便多了。我不知道我们的图书馆工作者怎样考虑这个问题。”
    回复了留言,想想还是独立地写一篇。

    在前文中,我只说明在本馆,同种书有可能分散在中、西、日、俄、古籍五处(如果还有新线装,在古籍还要分置,就是六处)的问题,却不知道解决之道,也不知道大陆有哪个图书馆实现了中外文混合排架。
    所谓积重难返。排除其他因素,当大量的图书已经分开编目,建立起各自的排架号体系,即使有心想合排,也很难实施。因为合排不是形式,而是为了“把同一著作的不同语种版本放在一起”。这就要求给某些语种全部图书的每一册换排架号(索书号),改号不像重贴条码、加RFID标签,设计完工作流程后,基本上只是体力劳动。改号先要对每种书根据规则重新给号(从下文可知并不轻松),然后还要做索书号查重(大部分图书馆不接受重号),最后还涉及到找齐该种书的所有复本改贴书标,工作量不是一点点。

    因此基本上只有在图书馆建立之初就决定合排,才有可能使合排成为现实。而如何实现同一著作的不同语种版本放在一起,则是达成合排的关键因素,即不同语种文献如何按同一标准取同类书区分号。
    香港几家大学图书馆馆藏以西文为主,中文书如中国人用拼写、外国人用原名,同样按字母取克特号,达成中西文合并排架。而大陆馆藏以中文为主,并不适用克特表,如按此取号必然出现大量重号需要进一步区分,造成索书号过长。
    “馆员”所在馆是新馆,才开始进外文图书,正是设计合排的好时机。Ta询问一种可能性:即将各种西文图书的作者按照“世界人名翻译大辞典”全部译成汉语译名,再按照汉语译名取著者码,达到与中文图书的统一标准。

    对于中文馆藏为主的图书馆,这是一种可行的办法。但具体实施时,要达到“把同一著作的不同语种版本放在一起”的效果,还会碰到实际问题:
    首先需要解决人名规范问题。对西文作者,并不是简单地查人名翻译辞典就可以解决所有问题。各学科的名人,由于历史原因,常有不符合标准读音的中译名。如果完全查用音译名,就会与中译本排到不同的位置。记得《世界人名翻译大辞典》里间有一些名人的不同译法,但并不完整。虽然是“少数人”,但名人们往往高产或著作反复出版,实际上正是解决问题的关键。
    如果有一个高质量的人名规范档可以查,就可以解决大部分问题,只是目前国内规范库质量还有待改进。要做到中文译本与原作放在一起,馆内自己有规范可查就相当重要,当然可以边建库边做规范。
    这样做要求西文编目员了解各学科的著名人物及其作品。当然对中文编目员其实也是一样的,因为目前出版同一作者作品采用不同中译名的也不在少数,也要有火眼金睛方能识别。这从另一个角度说明了规范库的重要性。总之,合排对编目员有更高的要求,副产品是做出来的书目记录质量会更好。
    其次,要求本馆自动化系统能够有较灵活的检索功能。如果没有建规范库,能够在中文书目记录中记录作者原名的前提下,把作者原名设置为检索点,在给作者规范名称及取著者号时可以查找。
    再次,对于辞典中没有的人名,需要选择音译规则。这点比较简单,有现成的拿来用就是了。

题外话:
    其实排架的理论与实践相距甚远。编目时总尽可能把同种书、同类书取相邻、相近的索书号,到了书库,如果不采用全排架,编目时的所有努力倾刻化为乌有。而在架上找书,也是件苦差事。
    最近看到曾浪迹天涯的资深编目员Sandford Berman()抨击LC多年前即计划停止分类,代之以按书的高度排架。
    LC的计划似乎并未付诸实施。其实如果能够全排架,就可以很方便地找到书,索书号按书的高度取也没什么关系。如果有RFID,那索书号就更没有什么用了。
    只是,不做学问不会懂得的在书架间浏览的所得与乐趣,也就永远的失去了。

参见:The Cataloguing Librarian: Berman’s Plea to ALA’s Executive Board / by Laurel Tarulli (2008-9-30)

ISBD著录用标识符有何用?


    在书店辞书区找一本字典未果,不死心,往边上书架找,竟看到一册ISBD统一版中译本,很是意外。一是想不到在这个通俗书店里会有这么专业的书,二是想不到被放在语言教育类。如果想去书店买这本书,应该会到哪个类去找呢?

    节前收到国家标准《电子资源著录规则》(征求意见稿),这两天先睹为快。
    作为书目著录类标准,同样遵循ISBD,也就少不了著录用标识符──“由书目机构提供,置于每一书目著录项目或著录单元(第一著录项目的第一单元除外)信息之前或书目著录项目之中的标识符号”,也就是在图书馆目录(尤其是卡片格式)中会看到的 . — = / . , : ; + ( ) [ ] 这些被赋予特殊意义的标点符号。

    由此不免再次想起,这些符号还有意义吗?
    做中文编目基本上不考虑这些标识符,因为CNMARC隐含着要求系统在显示书目时自动生成这些符号,大多数情况下无须在编目时录入。
    而发展较早的USMARC及后续MARC 21,则要求在记录时手工加上标识符。虽然做熟后很少会出错,毕竟是无端增加的、可以说没有什么意义的符号,可归入无效劳动之列。

    ISBD的这套标识符实为手工时代的遗留物。
    ISBD设计的最初目的是书目数据的国际互换,以及机读转换。据此生成的书目信息,能够在不了解目录所用语言的情况下,实现各著录项目的人工识别。但它对机器识别并不理想,虽然标识符前置,但同一符号出现在不同著录单元前(尤其是每个著录项目首项),歧义是普遍存在的问题。计算机交换书目数据一直基于元数据标识(如MARC的字段名、子字段),而非ISBD标识符。
    目前标识符的作用主要在文献引文和印刷型书目中得以体现,图书馆目录显示也可不用──如本馆目录是洋人所做,对CNMARC记录并未自动生成标识符,似乎也不影响内容的识别。
    美国通行四种不同的文献引文标准,与ISBD并无瓜葛。我国的《文后参考文献著录规则》(GB/T 7714-2005)可以认为使用了ISBD推荐的符号,但也只是极少几个而已。印刷书目采用文献引文格式也足够了。那么,复杂的ISBD标识符还有什么用呢?

    统一版征求意见时,在忙别的,没想到要提出这个问题。难道没有其他人提出过类似看法?如果有,有没有对这种看法提出过批驳(因而保留了这些标识符)?书蠹精应该很清楚吧。

国际标准书目著录(统一版) / 国际图书馆协会和机构联合会编 ; 顾犇翻译. — 北京 : 北京图书馆出版社, 2008. — 281 页 ; 29 cm. — ISBN 978-7-5013-3565-7
以上参考文献著录信息取自IFLA网站:Translations of the International Standard Bibliographic Description (ISBD)

参见:国际标准书目著录(ISBD)2006统一版草案公示 (2006-07-11)

 

[update 2008-10-26]  书蠹精:关于ISBD著录用标识符答编目精灵问 (2008-10-25 20:41:16)