集思广益的规则修订方式――从MARC 21修订想到的

    近期MARC邮件组最热烈的话题之一就是2005年的提案（Proposal 2005-X）。引起我兴趣的不是提案的内容，而是MARC 21的修订程序。
    象我这样完全的局外人，也能及时了解MARC 21修订情况，是因为有MARC论坛（邮件组），还有与修订有关的专门网页MARC Development，上面集中了所有相关信息。修订过程是透明化的，既有邮件组可以发表意见，还有专项提案、讨论，感兴趣者都可参与。规则修改结果在正式公布实施前，大家就已经了解。
    负责MARC 21修订的委员会MARBI的工作目标之一是建立标准的持续评价机制。它对提案有规范化的程序，提案内容除包括修改的MARC格式类型（书目、规范、馆藏、分类、团体信息）、涉及的数据元素（字段、子字段、定长字段字符位等）、提议简述等信息外，还要求对建议一旦实施将产生的潜在影响，回答十二个专门问题，作为提案附件一并提交。这就要求提议机构对所提出的建议深思熟虑，并有一些调查研究，而非头脑灵光一现的结果。
    这种集思广益修改标准的方式，似乎是一种国际通行形式。如IFLA的ISBD系列修订，在发布正式稿之前，先以修订稿形式向全世界征求意见。又如DCMI也常对都柏林核心元数据的有关提议公开征求意见。

    最近欣喜地看到国内在规则修订方面的变化。CALIS联合编目中心开始在一定范围内征集“业务规则修改、业务工作存在的问题”的提案（见厦门大学图书馆编目部“关于CALIS专家组/质量控制组集训班提案的说明”），而《中图法》编委会网站上也挂上了让人期待的“中图法BBS站”。

    很多东西到中国都会水土不服，所谓橘逾淮则为枳。那天看到“中图法BBS站”时，曾期望它早日开通，大家可畅所欲言，互相切磋探讨，求同存异，开国内图书馆界专门领域论坛之先河。可是看到三天后E线上那个同样期待它开通贴子用所谓“肉食者”的措辞后，我不禁为这个尚未开通的BBS担忧。如果把所有可以发表言论的地方，都变成了可以随意谩骂的场所，那么只能说，MZ是我们消受不起的盛宴。

 

蓝博图的Z39.50软件

     现在编目工作中，套录书目记录占了工作的主要部分。而套录基本上通过Z39.50方式检索、下载书目数据，这就需要Z39.50客户端软件。有了Z39.50客户端软件，可以从很多来源套录收费或免费的书目记录。
     很多图书馆集成系统都有了Z39.50客户端功能，可以下载、上载记录。即使图书馆系统中没有Z39.50功能，也可以使用专门的Z39.50客户端软件套录数据。国内最早的免费Z39.50客户端软件是丹诚公司的Z39.50前端软件Ztrans（官方下载地址：http://www.datatrans.com.cn/203.asp）。而蓝博图科技公司的Z39.50客户端和服务器软件Z39FindBook可称后起之秀。

     蓝博图公司称Z39FindBook为“图书数据网络查询系统”，据称既能作为客户端，又能作为服务器。作为下载数据的普通用户，我只关心它的客户端功能。
     它自我介绍的突出优点如“广播查询”、“自定义添加数据库服务器”，以及“中西文MARC数据的兼容问题”，是很多Z39.50客户端都具有的基本功能；而“批下载功能”可能对回溯转换有帮助，但我总怀疑如果使用的话，对短时间出现的大量检索请求，来源服务器是否能够应付，是否会影响其正常服务，从而将你视为非正常利用而有所限制。
　　我最感兴趣的是该软件“解决了小语种的问题，可以下载日文、韩文、俄文等小语种的数据”。只试过日文，所言非虚。我用过的国外Z39.50客户端软件，检索中、日文都是乱码；而国内Z39.50客户端软件，检索日文有的都是乱码，有的则部分乱码（如汉字正常、假名乱码，或反之）。这个Z39.50客户端软件是唯一可以基本正常显示日文数据的。说基本，是因为检出的早稻田大学数据，汉字、假名正常，反而罗马字母拼写丢失不少。不过对我们来说，并不需要罗马字母拼写数据。
只是，要能够检出日文也不容易。现在输入ISBN、罗马字母拼写检索正常，输入汉字假名则未必有检索结果。估计其他语种可能也会有类似问题。软件仍有可改进之处。

     该系统的另一个优点是其内置庞大的Z39.50服务器信息，说网罗或许有过，但的确搜罗不少。其中“自定义Z39站点”是国内服务器；“Z39站点”信息应该主要来自丹麦Index Data公司的“Z39.50服务器名录”，大概信息太多了，不及一一测试。去年试用时曾发现澳大利亚国家图书馆NLA的Z39.50服务器地址没有更新，现在仍是如此。NLA已更换系统，现相关信息应为：地址catalogue.nla.gov.au，端口7090，数据库VOYAGER。
     如果软件改进一下的话，或许应该按服务器的国家而非名称排列Z39.50服务器信息。用户使用时一般并不知道单位名称，但无疑知道所编图书的语种与出版国别，以国别排序，有助于用户快速选择相应的服务器。
     那么多服务器信息，要知道哪个内容多、检索速度快，还真不那么容易。可参见本人曾介绍过常用的中西文Z39.50服务器信息。另外，日文比较好用的是早稻田大学的服务器（地址133.9.92.63，wine.wul.waseda.ac.jp，端口210，数据库INNOPAC），格式近似USMARC。

     如果图书馆网络没有国际出口，不能直接利用国外数据，可以使用该公司的“图书数据网关系统Z39.50Gate”。只要在自己的Z39.50软件中设置该公司的服务器URL、端口、帐号和密码及相应的数据库。看上去有中、日、韩、西、德、法、俄、越南、泰国数据，真牛！用起来如何？不好说，或许不是24/7服务的。

     Z39.50标准是由美国国会图书馆（LC）维护的。或许蓝博图公司可以将Z39FindBook登记到LC的Z39.50 Software中去，在更广范围内宣传自己的产品。当初我就是在那儿知道丹诚公司的Ztrans的。

 参见：

雅虎及其上下文搜索、订阅搜索

    一直以来，关注Google而极少关注雅虎。虽然也有雅虎邮箱，还承游园邀请建立了Yahoo! 360，但如雅虎搜索一样，平常都没怎么用。

    数月前，Search Engine Watch将其年度奖中最重要的“杰出搜索服务奖”授予了雅虎，而此前四届此奖均由Google获得。当时看到，也没有什么感觉，因为对雅虎所知甚少，也没花时间去看评语。

    前两天看到一些与雅虎有关的消息，花些时间看看了看雅虎。

    一条就是昨天日志中说的索引Thomson Gale公司的付费数据库。
    美联社的那个报道中还提到，与Google引起争议的扫描图书馆藏书计划相对应，雅虎与美国国会图书馆合作扫描那些以前无法访问的文献。不过我在网上没找到相关报道。

    第二条不记得是什么消息了，但让我找到了雅虎的Web Search (Y!Q)，也就是上下文检索（Contextual Search）。Beta版，不支持汉语。
    作为例句的“I need to know the gas mileage for my audi a8 2004 model”找到的结果比较准确。有点搞笑的是，搜索结果居然首先出现提示信息“Contextual Search disabled because your query is longer than the supported length.”不过这似乎并没有影响其查找结果，靠后的几个关键词都出现在了检索结果中，而“I need to know”这样的提问语则被忽略。
    但我如法炮制的搜索语“I need to know something about Shanghai”，检索结果中首条就在标题中出现提问语“need to know”，当然文中有“Shanghai”。分析一下，应该是例句中有较多关键词，如Audi、a8、2004、model、gas、mileage。而我的搜索语中仅Shanghai一个关键词而已，如不加入其他短语，则等同于仅输入一个词，故而雅虎将所有词均视为关键词搜索。
    总之遇多关键词检索是可以一试的啦。只是也有疑问，如果我想知道关于“奥迪a8 2004型汽车每公里油耗”，为什么我不直接输入“Audi a8 2004 model gas mileage”，而要输入前面那么多废话？或许汉语与英语句法结构不同，外国人要找同样的信息并非如上面顺序输入，而是如例句那般以gas mileage audi a8 2004 model顺序？而有了上下文，雅虎就可以了解最重要的信息是“Audi A8”，而非“gas mileage”？

    第三条是关于“雅虎订阅搜索”Yahoo Search Subscriptions的，昨天日志中曾提及。Search Engine Watch上的这篇“Yahoo Search Subscriptions Brings Premium Content Into Web Search”有全面深入的报道与评述，值得一看。