编目法则一及CNMARC 517字段的著录

    《图书馆杂志》2005年第3期居然登了4篇编目方面文章,似乎把今年的编目文章全发完了(不知有没有数量指标?)。推荐邓福泉的”对517字段适用范围的探讨“(第52-54,58页),对此问题的总结全面而颇有见地。作者介绍说,邓福泉”已发表图书馆专业论文百余篇”。从维普查得其自1989年以来发文86篇,基本上都是分编领域之作。其关注之专、数量之大,望尘莫及啊!

    不过,编目领域总有很多争议。看此文时,略微总结了一下原因,不外乎对著录条例、MARC格式及目录功能认识上的差异。我对此文的些许异议或补充也源自以上原因:

1、关于交替题名,此文推荐的著录方式是:
200 1  $a西行漫记,$a又名, 红星照耀中国
其实,这种方式不符合CNMARC的定义,不同的$a著录的应当是合订题名,而不是同一题名的不同形式。MARC 21对交替题名也采用著录在245$a中的方式,而不是将交替题名著录到245$b中。

2、关于图书更名后的原题名,此文认提供原题名检索点”纯属画蛇添足”,”毫无实际意义”。其实,提供原题名检索点的目的,是为了让读者在检索旧版本题名时,能了解已有新的版本。这是目录”导航“功能的体现。
    根据目前的著录惯例,连续出版物更名后,会在新、旧两条记录下为原题名与新题名互相做连接,但图书并无相应的连接字段,也不会找出旧记录,加上新题名的检索点――因为对读者来说,查新版图书者多半不需要旧版。反之,查旧版者或许并不知道新版的存在,故而需在新版记录中提供旧版题名检索点。

3、补充一个使用517字段的低级错误。常常有编目员不分青红皂白,不管是否有检索意义,一律将200$e其它题名信息(如”理论与实践”)做517。517字段在定义中并非只在有检索意义时才能做,因为第1指示符取0时,表明无检索意义,相当于做附注。然而,对于已在200$e中著录的其它题名信息,显然是无须再做附注的。至于第1指示符用上1(有检索意义),错误就不言而喻了。

    著名图书馆学家谢拉的”编目法则一“如是说:”没有编目员会认可任何其他编目员的工作。”我也未能逃脱此一法则。文中还有些处于业内商榷范围的内容,不再赘述。

附1:邓福泉对517字段适用范围的探讨“大纲
1 应使用517字段著录的题名
1.1 版权页题名
1.2 有独立检索意义的副题名
1.3 有独立检索意义的分卷题名(包括200$i和327$a)
1.4 交替题名(推荐著录于200第二个$a中)
1.5 合订题名(不推荐用423)
1.6 不被用作正题名的全称或简称题名
2 不宜用517字段著录的题名
2.1 经过规范处理的题名(用510或540)
2.2 单本书记录中不同于225字段的丛书名(丛书记录中用相应51X)
2.3 图书更名后的原题名(只做300,不做517)
2.4 连续出版物的变更题名(用430/440)
2.5 繁体字题名(200用简体,繁体字题名只做300,不做517)

附2:《图书馆杂志》2005年第3期其他3篇编目论文信息
李淑芬:1999-2003年我国文献编目研究论文的定量分析
黄京华:西文编目数据套录中需要特别注意的字段的审核
谢蓉:也谈ISBN的不规范现象与图书馆的应对措施

 

不可小觑的句点

    做西编,有一件无聊之极而又落伍之至的事情,就是要记住每个字段最后是不是要加一个句点”.”。具有讽刺意义的是,事情虽小,却是判断西编功底的一块试金石,故编目者不可轻视。
    只是USMARC/MARC 21的规定几乎可以说没有什么道理――有此想法大概也是功底不深的表现。常用的字段自然记得,不常用的,就要翻详版MARC格式。
    为此头疼的人肯定不在少数,所以Vianne Tang Sha专门整理了”Ending Punctuation for Bibliographic Data“,按字段顺序列出MARC书目记录格式中对字段结束处有无句点的规定,并举实例,方便大家随时在网上查。
    网页起首处,有对MARC手册中用语的说明:

    凡有”以句点结束”或”以句点结束,除非有另外一个标点符号”的说明,则以句点结束,即使有圆括号、尖括号和方括号(除非特别指出了这些符号)。

    换言之,上述”另外一个标点符号”不包括”括号”――真是奥妙得很。其实看最常见的504字段结尾处的”点”时有时无,就知道这个说明不是没有意义的了。
    看看Sha整理的内容,明白如果要根据MARC格式说明,列出一个二栏的表格――一栏为”有结束句点”字段、一栏为”无结束句点”字段――还是要伤些脑筋的。

 

 

无处不在的元数据

    印象中以前数据库的”字段”,现在都称为元数据了,各行各业都在研制元数据,电子商务、企业信息、政务资源、统计指标、档案管理、电子公文、信用信息……。原来生成/修改日期、访问权限之类计算机文件的”属性”,也变成了元数据,如MP3文件的元数据ID3,定义了作曲家、词作者、演唱/演奏者等数十个属性;更有数码相片文件的元数据复杂到了定义拍摄的经纬度和海拔。
    曾以为Google的关键词检索只需要人工智能分析词间关系,组成一个词表(或许是语义网、本体什么的?),不需要元数据。但看着Google近半年接两连三地推出各种专类检索工具/功能,学者Google Scholar的引文、电视Google Video的节目预报、地图Google Maps的企事业单位信息、电影(movie:命令)的影评与影院信息,以及最近引起广泛争议的Google工具条的网页自动链接AutoLink功能,终于明白其实在Google简洁检索界面的背后,肯定蕴藏着极其复杂的元数据,用以组织机器搜集到的看似无序的信息。

    我们的机读目录MARC有差不多40年历史了,或许可称得上元数据的前辈。定义了那么多字段、子字段,虽然不是都要用,看上去也很烦。于是不满意MARC者设计出都柏林核心元数据DC,来代替烦琐的MARC,只用十多个元素就够了,很爽。可渐渐发现不够用,于是加修饰词,先是标准修饰词,然后又可以自定义修饰词,现在弄得跟MARC也相去不远了。
    其实当深入到事物的内部,必然越分析越细致,需要的元素也就越多,就好象前面所举MP3和数码相片元数据的例子。看出版商描述图书信息的元数据ONIX,近200个元素(tag),与MARC相比,其烦琐程度可说是有过之而无不及。
    看来,在今后相当长的一个时期里,综合描述各类文献元数据的MARC还是很安全的――不会被淘汰。或许磁带时代顺序读取的产物2709格式,会因与时俱进而被XML或别的什么格式所代替,但MARC的基本字段、子字段应该不会有太大的变化。