最近正想把放在TPI学位论文库中的元数据导出,转入本馆的书目系统。要转入图书馆的书目系统,必须是MARC格式,而TPI只有导入MARC,没有导出MARC,所以必须自行编制处理程序,把原来的元数据转成MARC格式,心里很是不爽。
正巧Keven在咒它,愿MARC“永垂不朽”。或许“MARC必须去死 (MARC must die)”,可它竟然如此不知趣,不肯自行退出历史舞台,需要别人来将它杀死 (Murdering MARC)?
讲到MARC,必得话分两头。一头是MARC记录格式,也就是标记系统,如200、245这样的字段,$a、$3这样的子字段;另一头是MARC交换格式,也就是所谓的ISO 2709格式。
以TPI元数据转换为例,要做两方面的处理。首先是一头,先做一个对照表,把需要的TPI元数据对应到MARC的字段、子字段。为生成完整的MARC记录,还必须添加一些TPI中没有的元数据。其次是另一头,让转出的元数据经处理后,形成2709格式。
Keven说,“抛弃MARC最大的阻力应该来自图书馆所拥有的书目数据,以及业已装机的、成千上万的图书馆自动化系统。”在我看来应该不是。理由是:
一、图书馆所拥有的书目数据多半是2709格式的,这种格式只要编制合适的程序,可以很方便地批量转换成其它形式(反之倒未必)。
二、目前没有图书馆自动化系统(ILS)会以2709格式存储书目数据供检索。2709格式只是一个交换数据的标准格式,系统将MARC数据导入后,多半以某种数据库形式存储数据。
三、为提供检索,ILS需要在MARC数据导入时对各字段、子字段做索引。一个字段、子字段可以做成多个索引,如200$a题名可以做题名索引,也可以做关键词索引;不同字段、子字段可以做成一个索引,如CNMARC的200$a和MARC 21的245$a都可以做在题名索引中。因此MARC数据在转入系统后,如果不考虑数据转出的要求,无需保留原有的标记系统。
四、如果有可以替代2709格式的标准,只需更新ILS的数据导入部分,系统就可正常运行。
五、ILS中的书目记录编辑部分可能是需要做最多修改的部分,但基于以上“三”的原因,系统应当不需要完全重写。如Innovative系统在新建或编辑记录时,就可以不使用MARC格式。
MARC的确是个老骨董了,与它同时代的计算机应用怕没几个还活得这么滋润的。这个,自然有它的理由。比如MARC是文本格式的,在四十年后的今天仍然可以用机器正常读出(虽然仍难看懂)。但我想最直接的理由,就是还没有制定出一个可以替代它的公认标准。
美国国会图书馆(LC)早就制定出了MARC XML,把2709格式的MARC 21变成了可由通用(而非图书馆专用)软件处理的格式。RedLightGreen大概是第一个参照LC标准转换书目数据,实现FRBR集中同一作品功能的网上书目数据库了——顺便提一句,由于它的主人RLG被并入OCLC,RedLightGreen不久将会被关闭,想了解它的得尽早去看。
也有其它MARC的XML格式,只是大家都不急着推广它们成为标准。理由不会是国际图联(IFLA)不尽心吧?
喜欢传统MARC的人对XML不感兴趣,而喜欢XML的人则对MARC的字段、子字段不感兴趣,或许这才是真正的原因。
我对MARC XML很有兴趣,并期望它能成为未来的书目元数据标准。理由当然不能是我熟悉那些字段、子字段。MARC的字段、子字段用在一般人看来莫名其妙的数字、字母,其实正是其优势所在。因为它没有语言障碍,更重要的是——没有文化障碍。在英语优势的环境下,应该是很重要的一种考虑。它比其它用自然语言做标识的元数据更有优势,可以做为中介语,直接对应至各国语言。
也就是说,我希望保留MARC记录格式,而以MARC XML作为MARC交换格式标准,取代2709格式。
当然,MARC记录格式本身还有两方面的问题需要改革:
一、MARC记录中很有一些冗余数据,是当年计算机处理能力有限时遗留下来的,有必要加以改革。
二、最令人痛心的是,MARC记录格式众多。比如目前国内一般中文用源自UNIMARC的CNMARC,西文用MARC 21;而在日文,CALIS用CNMARC,国图似乎用MARC 21。
也该是统一的时候了——国际上,英国已放弃UKMARC改用MARC 21,德奥两国也在准备采用MARC 21。本来IFLA当年不以USMARC为标准,另起炉灶制定UNIMARC就是一个大错,至今仍抱着UNIMARC不放岂不是一错到底?
更新(2006-9-14 21:00)
把博客当成笔记本,写完就忘记了。刚才看别的东西,忽记起其实早已有人在筹划一个可以替代2709格式的XML国际标准了,这个名为MarcXchange国际标准是对MARCXML的修订,原说是今年完成的,参见差不多一年前写的“ISO 25577: 2709格式的XML兄弟即将问世”。
最新进展是,7月24日结束了投票,不知结果如何。可下载 ISO/DIS 25577 Information and documentation – MarcXchange 的正式投票版(PDF文件)。
【作者: cat wizard】【访问统计:】【2006年09月9日 星期六 22:28】【注册】【打印】
你可以使用这个链接引用该篇文章 http://publishblog.blogchina.com/blog/tb.b?diaryID=5635793
|
- 评论人:cat wizard
2007-02-07 15:06:50
|
|||
有理啊! |
||||
|
- 评论人:学生
2007-01-27 17:22:56
|
|||
馆藏格式是用于馆藏记录的机读格式,与书目记录没有关系。制定一个标准的馆藏格式,有利于馆藏记录的集成处理。
|
||||
|
- 评论人:cat wizard
2007-01-25 18:47:53
|
|||
馆藏格式是用于馆藏记录的机读格式,与书目记录没有关系。制定一个标准的馆藏格式,有利于馆藏记录的集成处理。
|
||||
|
- 评论人:学生
2007-01-25 18:15:44
|
|||
最令人痛心的是,MARC记录格式众多。比如目前国内一般中文用源自UNIMARC的CNMARC,西文用MARC 21;而在日文,CALIS用CNMARC,国图似乎用MARC 21。
|
||||
|
- 评论人:过客
2007-01-18 16:26:58
|
|||
我来长知识了,我也是做编目的,但太不专业了
|
||||
|
- 评论人:cat wizard
2006-09-14 19:32:44
|
|||
两位高手相继光临指点,不胜荣幸。主要是不关注马克以外的元数据,所以了解太少,很惭愧。
|
||||
|
- 评论人:观众
2006-09-13 23:47:13
|
|||
过客本想用不同代码帮观众将文中英文显示出来,结果弄巧成拙,小弟在此替过客赔个不是了。要是能显示英文,偶倒知道几个使用元数据物件描述格式的成功范例,这里先点几个:1)加州大学出版社的电子图书(加州大学数字图书馆下的电子学术),2)美国国会馆的数字图书馆中的几个项目,特别是网站档案,3)音乐澳大利亚。以后使用这个格式的项目会更多,特别是要采用(这几个英文缩写字代表元数据编码和传输标准)时。要是精灵根据这些提示查询有困难,偶可以将英文网址发到精灵的邮箱。 |
||||
|
- 评论人:cat wizard
2006-09-13 20:49:03
|
|||
笃悠悠:什么叫被杀?最近更新少,一则刚开学、部门新开张,事情还没理出个头绪,要花心思一一清理。二则博客中国不争气,首页等均不能更新,打交道无数次还不解决,想搬家又没找到合适的,弄得人没兴致写。 |
||||
|
- 评论人:cat wizard
2006-09-13 20:40:23
|
|||
谢谢远洋过客指点MODS的应用,原来一直没有关注过MODS都用在什么地方了。
|
||||
|
- 评论人:笃悠悠
2006-09-13 15:32:44
|
|||
不能更新?怪不得我在想,最近精灵是不是新岗位太辛苦了?怎么不写些东东了?近十年的做下来,已经习惯了,也有些感情了。如果真被杀,还真有些舍不得 |
||||
|
- 评论人:anonymous
2006-09-13 05:44:40
|
|||
|
||||
|
- 评论人:远洋过客
2006-09-13 05:29:07
|
|||
(以下英文字母可能不显示):您对马克的弊端,特别是非统一的格式问题有深刻理解和独到见解,很赞同。我认为马克的问题不是要去死,而是要新生。(英文指马克用可扩充标记语言)是一个不得而已的折衷形式,解决转换问题,即解决2709的问题,并用一种通用格式得到永久的不受硬软件限制的交流和保存形式。(英文指国会馆的元数据物件描述格式)可能才是能使马克或这种丰富的表述格式能发挥余热的产品,当人们希望重新利用原来的马克数据,或者利用其丰富的描述格式,或者正因为在图书馆干久了,瞧不起都柏林核心元数据时,(英文指国会馆的元数据物件描述格式)正好能发挥作用。国会馆这些年用它做的虚拟档案全是用的它,但其检索界面没有一点原来的(英文指联机公众目录)的影迹,可以说充分利用了其丰富格式中包含的语义内容。 |
||||
|
- 评论人:86
2006-09-12 16:44:08
|
|||
经常来这里,受益匪浅,非常感谢另外,我的确不喜欢那个闪物。 |
||||