试查山西省图书馆的图创Interlib系统

    在沁县参加青树活动时,听山西省图书馆说计划明年就把所有县馆馆藏都纳入省馆的集成系统中,在我看来这是一项宏大的计划。当时正在身旁的台湾玄奘大学吕明珠老师告诉我,她看过山西省馆的OPAC,非常先进,酷似北卡州的系统,还有标签、点评──虽然可能由于宣传原因,还没什么读者用。这自然引起我的兴趣。
    访问山西图书馆集群管理系统,确认是广州图创公司的Interlib系统。试查感觉,总体上框架还不错,细节则尚需推敲(不适用Firefox)。截图在此

    检索入口略显繁杂,但检索结果一览确实像极北卡州立大学馆的界面,上部是用于缩小检索范围的分类分面(还可选择隐藏),左侧是其他分面分馆(为今后加入各县馆藏做准备)、主题著者出版日期文献类型语言种类分类。除出版日期按年份顺序排列外,其他均按命中数量排列。
    检索结果的排序选项匹配度(缺省)、出版日期主题词题名责任者索书号题名拼音的升序、降序排列。有检索结果的RSS订阅预留了图书封面的位置,但尚未配上。
    用缺省的“题名”试查“上海”,从结果看为任意一致(而非常见的前方一致),当属题名关键词检索。
    分别看出版日期排序和责任者排序的结果:
    出版日期排序应该没有用定长字段,而是直接采用了出版日期著录字段──由此按降序排列,第1条是民国77年(1998年)、第3条是“出版日期不详”,接下来都是推测的出版年(加方括号),到第31条才是最新的2008年,第36条2007年。这是软件系统的问题。还有书目记录的问题:期刊没有按连续出版物处理,而是每一装订本做单独的书目记录,并且没有著录出版日期,导致期刊都排在最后。
    责任者排序应该没有用检索字段,而是直接采用了责任说明,因此作者前按题名页照录的国别等连同括号一起用于排序,而不是从作者姓氏开始。并且以这种方式,应该只对第一个责任者有效。还有另一个排序规则问题,看着既非笔划,也非拼音,使用快典网(http://bm.kdd.cc/)试查几个汉字内码,估计是按unicode编码排序的,这种排序对用户而言基本是无意义的。
    估计题名也是依此法排序的,所以除题名排序外,还有题名拼音排序──而目前大多数系统的汉字排序都是拼音序。

    详细结果页,有读者总评(5个星的评级)、Tags(标签)、收藏读者书评功能。
    增加标签及收藏需要登录,据帮助(?图标)说明,如背景色为黄色的,表示本人已经给此书加过的标签。不知道标签能否用于检索。
    读者书评不知道入口在哪里,或许收藏后方可写书评?
    评级则不需要登录,并且一旦做出评价就不能更改──这出乎我的意料,在此需要郑重地向作者郑念致歉(该书译为“程念”),因为试功能,随手给她的《上海生死劫》打了个1星。幸亏每条书目记录有固定链接,刷新一下页面后,发现可以再次评价,作为补救再打个5星──由此读者总评是3星(共2票),也就是说,一个人可以做N次评价。是不是有点问题?
    详细结果页右侧有相关资源相关借阅(借阅此书的读者所借阅的其他相关图书)、相关主题。大约使用不久,相关借阅没有看到内容。只是相关主题也没有,倒是有点奇怪,不知道打算放什么内容。相关资源分别是以题名查询豆瓣WorldCat谷歌百度图书CNKI。用百度图书而没有用谷歌图书,有点不解。以《上海生死劫》为例,在谷歌图书上还可以看到片断,而点击百度图书的结果则是“很抱歉,您要访问的页面不存在”。
   
    OPAC分面显示、多种排序的结果,是让书目记录中的错误更多地展示出来,此次试查同样证实这一论断。不多言。

附1:
图创软件称其Interlib系统推出一年半,已有300家图书馆使用,其中有广东省馆(45家分馆)及黑龙江省馆(30个分馆),势头强劲啊。
其产品中还有“Internet托管平台”,正是数月前写“求助:寻找‘云计算’的图书馆自动化系统”(2008-10-14)中提到的那种:“若干年前,曾见过一个SaaS的图书馆自动化系统网站,有一些小型图书馆利用它的服务。不用买电脑、不用系统管理员,这个网站就是自己的自动化系统。”

附2:
山西省馆有一个“晋图论坛”,见到其中有一贴子“Interlib培训教程视频”,除各业务模块(采访、编目、流通、期刊、系统管理)视频外,还有其用户手册及培训教程。
论坛建于2007年12月,贴子不多,标题大致浏览一过,发现2008-04-29影子的“图林博客之最”,标明摘自2008年4月18日图书馆专刊的雨禅文(原出自“最…..的图林博客”(2008-01-20)),又让自己陶醉一把。

关于青树活动,参见:
云海之上II:
撒下青树的种子(一)(2009-02-06)
撒下青树的种子(二)(2009-02-14)

辅仁大学图书馆服务队 (2009-02-01)
图书馆读者犯罪动机与图书馆管理政策 (2009-02-09)

读秀──MARC免费收集系统

    一个月前,OCLC公布了新的WorldCat记录的利用政策(Policy for Use and Transfer of WorldCat® Records),引起国外博客圈热烈讨论(OCLC Policy Change),反对声音激烈,认为OCLC赋予自己的权利过大。有意思的是,国内却完全是另一番风光,联合编目中心似乎并不在意保护自己的利益,面对厂商大规模收集MARC记录的明显意图,还没有向图书馆提出相关建议。

   
最近几个月,经常听到图书馆说买读秀,也已经有不少大馆购买了,还有整个省团购的。读秀是什么?我至今也不是很明白,因为没花时间去了解。但我知道,它有
一个重要功能:籍此免费获取图书馆的MARC记录──图书馆在每年付以十万为单位的银子订购读秀的同时,还要向读秀免费奉送自己所有馆藏的MARC数据。
花不菲代价买东西,不是商家附送什么优惠,反而要把自己那么多数据拱手相送,听上去匪夷所思,却不幸是事实。
   
当我第一次听说时,当然要问“为什么”?丫枝给我的答案是“要在读秀的网站加本馆的链接,直接链在OPAC中显示本馆是否有此书的纸本、电子“。后来知道,只是在读秀网站加本馆链接,读秀并不提供在本馆OPAC上显示读秀链接的方便。而要达到在读秀网站加本馆链接的结果,图书馆本来只需要提供极简单的几个信息就可以实现,即题名、作者、出版社、出版年(如果有ISBN当然更方便)。
   
这里不想推测读秀要图书馆提供MARC记录的真实意图。现在有不少图书馆人觉得编目是浪费时间,因为那些书目信息出版的时候已经全有了。其实编目员很多时间花在给分类号、主题词这些主题标引,以及做作者、团体的名称规范。虽然分类法、主题词表乃至规范库很不令人满意,但这些信息是对出版物不可或缺的内容揭示。新一代OPAC要实现分面展示,让读者在输入最初的检索词后,只需简单点击展示的链接,就可以完成随后的检索并得到需要的文献,这在很大程度上依赖于由编目员增加的信息,因为这些信息是进行书目数据挖掘的基础。真正有眼光的人是不会小视编目员增值的数据的。
   
除了信息价值,图书馆的MARC数据也是有经济价值的,它们是图书馆积累一二十年的数字化资产,怎能轻易送人?每家图书馆的MARC记录,小馆也会有数万
条,大馆甚至可达百万数量级。或许某些MARC数据来自书商的“免费”提供,但那是图书折扣的一部分;或许某些MARC数据来自联合目录,下载每条只需
0.10元,但即使只有10万条,也值一万元呢,更何况,那是联合目录对成员的优惠,事实远不只这个价。

   
据说读秀的书目已经不少于160万了,随着越来越多的图书馆购买读秀,这个数量还会增长,因为它在销售的同时,也在一举两得地收敛书目数据。在这一过程中,损失最大的无疑是那些联合编目中心。说到了影响他们生死存亡的阶段,或许有些言过其实,但形势确实很严峻。如CALIS联合编目中心,对详编记录支付每条2元的费用,这些年来,也该支付了数百万元;同时还制定了严格的质量标准并多方进行质量控制。现在,这些高质量的数据,不需分文,几乎转眼间大多已经或即将成为读秀的囊中之物,令人感觉不可思议。
    或许图书馆觉得自己没什么损失,那些MARC记录,放着也是放着,又不能卖钱。但是,数据是Web2.0时代最重要的财富。当读秀得到了所有的MARC数据,图书馆在与读秀的下一轮谈判中,将会处于什么样的地位?
    据说读秀现在还只要中文的,未来还会要外文的。读秀得到这些数据,可以做什么?至少现在,图书馆提供的MARC数据使读秀在极短时间内成了一个巨大的联合目录。接下来还能做什么,可以展开一下想象力……

   
应该说,图书馆从联合目录合法下载的MARC记录有使用权,但未必有所有权,可以随便送给厂商。国内知识产权不完善,现有的联合编目中心对图书馆没有那么大的约束力,但至少那些中心可以知会图书馆,请馆长注意保护MARC数据──如前所说,要达到在读秀网站加本馆链接的结果,只需要提供极简单的几个信息就可以实现,不需要提供完整的MARC记录。众所周知,2709格式的MARC记录是不可直接使用的,从使用角度,或许EXCEL表格的书目信息更方便处理。如果读秀一定要求MARC数据,而有的图书馆系统无法导出简编记录,或者不知道如何将导出的完整MARC记录转成简编记录,联合编目中心完全可以提供一个小软件,快速实现这样的转换。

耶鲁大学的VuFind使用调查

    VuFind在开源的OPAC前端中发展得不错,前几天刚得到第三届梅隆技术协作奖不说,澳大利亚国家图书馆早就用它做了自己的Beta版OPAC,而耶鲁大学也已经试验了不短时间。
    耶鲁大学原来的OPAC名叫Orbis,他们的VuFind则称为Yufind。2008/10/6-19,他们面向用过Yufind的大学生进行了一次调查,得到83个回复,结果大致如下:

检索结果:79.3%发现结果是他们预期的,75.6%发现了他们需要的。
分面:85.0%喜欢;不喜欢的主要原因是结果与其检索不符,或者装入太慢。
比较:57.8%喜欢Yufind甚于Orbis;但当问及查书首选时,Orbis占40.2%、Yvfind占35.4%。
Yufind不足:一些回复者指出检索太宽泛,有时返回高度不相关结果,且响应过慢;另一些回复者找不到他们知道肯定有的结果,比《自然》杂志。

    调查结果表明Yufind很有希望,但需要重大改进。调查让馆员有了改进的方向。
    比如分面方面:缩减象时代、格式之类含有误导元数据的分面[编目数据错误吗?];排除只命中提问中一个检索词的记录;从可用性结果分析,分面列表应该有排序先项,可以按字顺排列[看来目前是按结果数量排列]。
    比如通过馆藏量、流通量或下载量计算,使流行馆藏(如《自然》)容易找到[相关性排序自法问题]。
    比如与本馆服务无缝集成:输出到Refwork/Endnote,通过文献快递或馆际互借订书。

    调查中有一个部分采用了“系统可用性量表”(System Usability Scale, SUS),用正负各五个陈述,采用五点尺度的李克特量表(Strongly Disagree, Disagree, Neutral, Agree, Strongly Agree),据称返回值70被认为其可用性可以接受,低于70则需要进一步改进是。此次调查返回结果为66,很接近了。
    其SUS部分如下:

我想我愿意频繁使用Yufind
我发现Yufind不必要地复杂
我觉得这系统很容易使用
我认为用这个系统需要技术人员支持
我觉得Yufind的不同功能集成得很好
我觉得Yufind中有太多不一致
我想象中大多数人学用Yufind会很快
我觉得Yufind用起来很麻烦
我感到用Yufind很自信
在可以上手Yufind前,我需要学很多东西

调查结果全文: Opinion Survey of Yufind/Vufind

参见:再看国外流行的开源软件──第三届梅隆技术协作奖