从Google图书搜索元数据错误说到数字化中元数据创建问题

    Nalsi本月开始把译文发到译言上,甚至没有同时发在自己博客Islander的西文编目笔记。译文大多是图书馆界的热点,“Google能使用OCLC的数据么?能,但是……”就是其中之一。原文”So, Can Google Use OCLC Records? Yes, But: Questions remain about the impact of WorldCat on Google’s metadata”发表在Library Journal (9/10/2009, 仅网站?)。
   
对GBS元数据的质疑始于加州大学伯克利分校信息学院的Geoffrey Nunberg,他在8月28日举行的Google Book
Settlement Conference上,列举了GBS中的元数据问题(Google Books: The Metadata Mess,PDF),诸如年份混乱、分类错误,而Google方面还不急于改进。他更指出GBS用只有3千主题的BISAC主题取代有20万主题的LCSH,数据并非来自图书馆,只适合书店、不适合学术使用。
作者另外发表了博文“Google Books: A Metadata Train Wreck” (August 29, 2009),其后又在The Chronicle Review上发表”Google’s Book Search: A Disaster for Scholars” (August 31, 2009),进一步阐述其观点。
    GBS的Jon Orwant在上述博文下长篇留言,指出元数据并非OCR而来。如前述译文,GBS的元数据来自不同机构,包括WorldCat及参与GBS的图书馆,Google员工所做的基本上只是在不同来源的元数据间做取舍。
    其实大家都知道,图书馆的元数据本身存在错误。分面OPAC出现后已将这些错误显性化,拥有大量图书的GBS或许更放大了这些错误,Thomas Claburn在Information Week上很夸张地说”Google Books Metadata Includes Millions Of Errors“(Sep 3, 2009)。
    Stephen’s Lighthouse在博文”The Google Books Metadata Debate” (September 8, 2009)中提供了很多讨论链接。最后举了Typo of the day for librarians这个专门讨论书目记录中各种拼写错误的博客为例,说明:Nobody’s perfect。

    Cataloging Futures的博主Christine Schwartz一直关注这场论讨,她则从中看到了图书馆面临的相同问题(Google’s metadata questions – they’re our questions also):

 · 元数据取自哪里?
 · 在数据化流程的哪个点抓取/创建元数据?

 · 如果外包元数据创建,是否自己做、如何做质量控制,或者由外包公司决定?

 · 元数据抓取/创建是一次性的过程,还是反复的过程?

 · 谁(或在自动抽取时,什么)创建元数据?

 · 在自动抽取过程后,是否做人工审核?

 · 在元数据创建中用户的职责是什么?

 · 如果有多个来源可选,什么是最佳来源?

 · 如果有多个记录可选,什么是最佳记录?能否自动选择?


另参见:
Coyle’s InFormation
GBS and Bad Metadata (September 07, 2009)
Google Books Metadata and Library Functions (September 15, 2009)

Cataloging Futures
Metadata problems at Google Books (September 03, 2009)
Google responses to metadata “mess” (September 08, 2009)
Google’s metadata questions – they’re our questions also (September 09, 2009)

开源与云计算结合的ILS──Koha Express

9月11日,为开源的图书馆自动化系统Koha提供技术支持的LibLime公司宣布,发布新的基于订购的托管服务Koha Express(LibLime Announces New Budget-Friendly
ILS for Small Libraries
)。

Koha原本就是全Web界面的开源软件,进入云时代可说顺理成章。实际上,LibLime公司原就在kohalibrary.com域名下有Koha的托管服务,实例见Live LibLime Customer Koha
installations
,包括学术图书馆、公共图书馆和图书馆联盟。
新闻稿称,Koha Express 运行Koha正式版(目前为3.0.2),是一个全功能的集成图书馆系统(ILS)。
在LibLime的云计算平台上,通过软件即服务(SaaS)方式分发,价格仅299美元/年,含软件安装及托管。目前世界六大洲有愈千所图书馆采用Koha,图书馆采用Koha Express,可以通过Koha开源社区相互支持,可用的资源包括实时聊天、邮件列表及LibLime公司贡献的详细文档。
此产品的目标客户是小型公共、学校及专业图书馆,在经济不景气的情况下,应该很有吸引力。设定数据导入上限为75000数据库对象,也只适合于小图书馆了。299美元的价格不含数据迁移、培训及OPAC定制。提供30天试用。

对于大中型图书馆、图书馆联盟,LibLime在同日宣布提供企业级Koha(LibLime Announces LibLime Enterprise Koha),应该是Koha ZOOM的托管服务LibLime Enterprise Koha。提供云计算服务,对LibLime来说,是不是独立安装更方便维护呢?
网上有演示版,可以实际试用,做增删之类的管理操作。公司称软件仍将保持开源。也就是说,还是可以免费下载到本地安装使用的。

Koha Express和LibLime Enterprise Koha都集成了今年初发布的Web编目平台 ‡biblios(参见数图研究笔记:面向未来的编目平台:biblios.net (2009/1/20))。

Via Library Technology Guides

PS:去年通过辅仁大学毛庆祯教授,了解了一点Koha。毛教授致力于在两岸推广Koha应用,Koha台湾网上论坛,可说是中文的Koha社区。

社科院联合目录全MARC数据免费下载及dp2catalog查询软件

    《数字图书馆论坛》2009年第7期末整版广告:全国社会科学院联合编目中心(http://ssucs.org)提供MARC数据免费下载。试了一下,是全MARC数据的Z39.50下载。记得以前社科院西文也用的CNMARC,这次试查结果看,目前也用MARC21。
    在国内,提供Z39.50匿名访问的书目数据库已属罕见,带分类主题的全MARC数据更是凤毛麟角,还要在杂志上做广告?显然是系统开发者数字平台(北京)软件公司(http://www.dp2003.com)的广告了,二位开发者是江汇泉和谢涛。该公司还提供免费的Z39.50前端软件,对此等好事,很乐意在此推广。
[update 2010-06-02: linquanzhi提示,可能由于软件更换,此服务器已停止。]
下载方式:
通过Z39.50协议,提供100多万种MARC数据下载

Z39.50服务器特征:
支持Unicode字符集
支持UNIMARC/USMARC/DC元数据等多种数据格式
支持Z39.50、Web Service等多种协议

Z39.50服务器参数:
服务器地址: ssucs.org
端口号:210
字符集:UTF-8
数据库:all, cnmarc_books, cnmarc_series, usmarc_books

免费的Z39.50前端:数字平台公司出品的dp2catalog
下载地址:http://www.dp2003.com/dp2catalog/publish.htm

   
很多年前在网上找到还是丹诚公司的免费Z39.50前端软件Ztrans,一直用到现在,很顺手不想换。一开始不会用,还发电邮向谢涛先生请教过。三年前,江汇泉先生曾向我推荐dp2catalog,仍然是免费的,当时家中电脑还是Win98的,安装不了,
正好又换了工作方向,就搁下了。去年江先生曾发给我dp2catalog使用手册,说明支持MODS、MARCXML等XML格式的元数据,说可以用美国
国会图书馆目录检索试验,只是自己近年离编目越来越远,没有花时间钻研。
    今天安装了dp2catalog,在线安装速度还是很快的(安装网页说明文字竟然E文)。因为用惯Ztrans,所以很适应dp2catalog,不过仍没有试验XML格式的。
    存在的问题是,社科院服务器的地址竟然错误,用的是旧IP吧,需要根据上述参数更改。另外缺省配置了很多Z39.50服务器,遗憾的是由于前述国内现状,检索有结果的很少。
    由于支持几十种不同的字符集,新增服务器信息时,一定要提供字符集──很多时候使用者是不知道的,设置时就很困惑了,不像Ztrans那么傻瓜。最好提供一个最常见的字符集为缺省设置,如果没有检索结果或检索结果为乱码,自然会想到是字符集问题,此时再更改不迟。