标签： MARCXML

2.0时代究竟是让MARC安乐死还是让MARC继续活？

    “2.0时代究竟是让MARC安乐死还是让MARC继续活？”这是刚刚开过的Web2.0/Lib2.0第三次研讨会上，“技术酒徒PK人文烟鬼”的话题之一。其实“MARC安乐死”在第二次会议上就曾列为话题，但最终未加讨论。
    海峡对岸的Debra对此议题颇为关注，在预告此次会议的博文中，专门列出了十来篇前二年讨论此话题的博文。会前看到Debra博文，依链接重温了相关文章，算做会前功课。看完确信PK的二位对手──技术酒徒Keven和人文烟鬼竹帛斋主对此议题根本无须PK，因为事实上他们的观点是完全一致的，都不想让MARC好好活。
    会上的PK规则是先陈述话题的一方为正方，另一方必须是反方。当Keven重申他关于让MARC安乐死的一贯立场后，斋主就迫不及待地表达他想要MARC速死的立场，引得Keven缴械投降──印证我的看法不虚。Keven知道实际上是无法让MARC速死的，才退而求其安乐死──其实医学上的安乐死，虽然名称看着温柔，相对于自然死亡而言正是一种“速死”。
    当明确只能在“安乐死”和“继续活”中择一后，作为反方的斋主观点马上来了个180度大转变，陈述一通必须让MARC继续活的陈芝麻烂谷子的理由。

    《列子·说符》中的故事：“人有亡斧者，意其邻之子。视其行步，窃斧也；颜色，窃斧也；言语，窃斧也；运作态度，无为而不窃斧也。”我就是那个亡斧者，看那些新出现的元数据，怎么看都是偷了元数据的老祖宗──咱家的MARC。最典型的就是DC──Keven称之为MARC的阴魂──元素相当于字段（栏位），限定词相当于子字段，等等。如果MARC死去，有什么元数据可以代替吗？DC语法不断地修修补补，显示其即使对文献描述也不尽适应。ONIX？比MARC更复杂呢。
    其实对于文献描述，需要质疑的不仅仅是MARC。大部分人只看到用MARC做成的书目记录，把MARC当成了文献描述存在问题的症结。雨僧在“图书馆2.0和MARC之安乐死”中提到了问题的两个方面：语法孤立性(2709)和语义模糊性(AACRII)，可惜对后者只列了个标题，没有展开。AACRII将发展为RDA，可视为文献编目在互联网时代的一种自救，结局如何尚不可知。
    如果就事论事，只谈MARC的未来，就是我在会上表达的意思，MARC还会继续活下去，但是要变──（内容）简化，（交换格式）XML化。

    很多对MARC不适应网络时代的争议，都集中在其2709格式。但2709格式不过是一种交换格式，XML化正是现阶段适应Web的一种必然趋势。美国国会图书馆(LC)早些年即已建立了基于MARC21格式的XML化交换格式MARCXML，并有了一些相当不错的应用，现在很多新型OPAC也基于此。而适应所有MARC格式的XML交换格式MarcXchange，早在2005年即已走上成为国际标准ISO 25577之路。原来由丹麦图书馆机构承担联系的ISO 25577，自从2007年3月进入成为正式标准的最后阶段（40.99状态），似乎主要由于嵌套字段方面的问题，止步不前。但2007年11月，LC成为该标准的维护机构，让人看到了本标准的良好前景。
    我的观点是：MARC还要继续活。我的结论是：MARC还会活得比较好。
 
参见：
秋声Blog：大陆Web2.0/Lib2.0研讨会及MARC议题
ISO 25577: 2709格式的XML兄弟即将问世 (2005-09-05)
MARC、MARC，为什么不死？(2006-09-09)

关于ISO 25577，参见：
ISO/DIS 25577: Information and documentation — MarcXchange
Status: Under development      Stage: 40.99 (2007-03-30)

The Library of Congress: ISO 25577 Maintenance Agency
http://www.loc.gov/standards/iso25577/

Danish Library Agency: MarcXchange
http://www.bs.dk/marcxchange/

关于Web2.0/Lib2.0第三次研讨会，参见：
“Web/Lib2.0”第三次研讨会参会侧记（上午）
“Web/Lib2.0”第三次研讨会参会侧记（下午）

ISO 25577: 2709格式的XML兄弟即将问世

ISO 2709用于MARC数据的交换已有三十多年历史。虽经多次修订，但孕育于数据顺序读取的磁带环境下的2709格式，对网络环境明显不适应。有鉴于此，美国国会图书馆在几年前开发了MARCXML，即MARC 21 XML Schema，以XML格式表示MARC记录。现在，以MARCXML为基础，一种与2709格式兼容的新的MARC数据交换格式正在研制的最后阶段，预计将于2006年正式成为ISO标准，它目前的名称是：
ISO/CD 25577 Information and documentation ?C MarcXchange

该标准由丹麦在2004年发起，丹麦国家图书馆规范部的Leif Andresen和丹麦图书馆中心的Tommy Schomacker是开发该标准委员会的共同主席。丹麦国家图书馆规范部维护着MarcXchange的主页，称MarcXchange是对ISO 2709格式的补充。网站上有相关资料，英语为主。

美国国会图书馆网络开发与MARC标准办公室主任Sally H. McCallum在MARC邮件组中，对MarcXchange、2709格式及MARCXML之间的异同，作了很好的说明。大致是这样的（非完全翻译，带本人理解）：

  • MARCXML依照图书馆通用的MARC格式，规定字段指示符为2位、子字段标识符为1位（不含$），但修订后的2709格式对字段指示符与子字段标识符的规定均为最高9位。MarcXchange修订MARCXML，与2709格式兼容，但并不因此与MARCXML冲突。
  • 与ISO 2709不同的是：
    1. 对<记录>元素附加“格式”属性，标识机读目录的执行格式，如MARC21、Unimarc、CNMARC等。（无需看记录字段，就可以知道记录的格式了；避免人工判断。ISO2709修订时为何未考虑这一点？头标中空位还有着呢。）
    2. 对<记录>元素附加“类型”属性，标识记录的种类。如MARC21格式有书目、规范、馆藏、分类与社团五种类型。MARCXML已经附加了此属性。（无需分析记录头标，就可以知道记录的类型了；避免人工判断。对ISO2709的疑问同上。）
    3. 00X字段除可置于<控制字段>元素外，也可作为<数据字段>元素。

可以预计，今后图书馆计算机集成系统及编目软件不但要支持2709格式的导入、导出，而且还要支持25577格式。或许出现直接使用25577格式的书目数据库也未可知。

参见：

主页：MarcXchange (http://www.bs.dk/marcxchange/)

相关报道：ISO Standard for MarcXchange In Development. NISO Newsline (August 2005)

MARC邮件组中的有关讨论：
(1) Karen Coyle. ISO standard for MARC in XML. MARC Archives — August 2005 (#3)
(2)William E. Moen. Re: ISO standard for MARC in XML. MARC Archives — August 2005 (#4)
(3)Sally H. McCallum. MarcXchange. MARC Archives — August 2005 (#8)

 

FRBR化：在我国实施的难点

   FRBR作为一个概念模型，用以指导实践，出现了如题所示的新名词――FRBR化（Google目前搜索结果：FRBRize，动词112项；FRBRizing，动名词182项；FRBRization，名词183项）。
    定义？“FRBR化”还是个非正式的称呼。OCLC如是说：

examine the issues associated with the conversion of a set of bibliographic records to conform to FRBR requirements.
This process sometimes is informally referred to as “FRBRization”. （转换书目记录集以符合FRBR需求的过程）

    RLG（美国研究图书馆集团）的“红绿灯”RedLightGreen，可以说是最早实用的FRBR化大型WEB书目数据库。通过将FRBR的“作品――内容表达――载体表现――个别资料”四级实体简化为二级“作品――版本（载体表现）”，RLG把自己的联合目录放到了互联网上。在搜索结果显示页面，显示的是作品，而非一般OPAC的“载体表现”。对大部分用户，感兴趣的是作品而非某一个版本；如果只对某一版本感兴趣，再继续看相关版本不迟。对于高产作家的作品，此种显示方式尤能显示出其优点（请参见“红绿灯RedLightGreen”及“FRBR影响之OPAC应用”）。

    从RLG及LC、OCLC等的FRBR化成果看，以“作品”这一实体集中书目记录，可以说是FRBR化的一种基本形式。但这一方式，在我国实施起来似乎还麻烦多多。试分析原因：

一、文献原题名的著录问题

    MARC 21记录普遍采用原题名作统一题名，为作品的集中创造了良好的条件。而中文编目中并没有规则要求以原题名作统一题名，目前CNMARC一般将“在编文献中出现的”原题名著录于510并列题名中。
    并列题名并不一定是原题名，还包括自译题名。有些译著，并列题名与原题名并不一致。此时，或者做二个并列题名，或者著录时根本就省略了原题名，这就为集中同一文献留下隐患。

    《新版中国机读目录格式使用手册》中有个实例，在编图书《来自地狱的女人》为“If tomorrow comes”的某个译本，统一题名采用另一个译名《假如明天来临》，而非原题名（此书还有一译名《假若明天来临》）。如此一来，没有题名规范记录即无法著录统一题名，增加了问题的复杂程度。
    原题名可以不著录，而要著录另一个被选为“统一题名”的译名。是不是有些奇怪？于是“统一题名”的选择面对疑惑：为什么选这个译名而不选另一个译名？
    这种做法还增加了统一题名维护的工作量，每出版一个不同题名的译本，就要维护一下题名规范记录。
    直接用原名不好吗？为什么要自己累自己呢？

    另外，图书出版不规范，有意无意“省略”原题名的情况随处可见。从另一方面为实施原文统一题名增加了不小的难度。
    记得一次用MARC 21做某中文译著合集的记录，费了九牛二虎之力才找齐全部原题名。虽然很有成就感，毕竟只能当作消遣，如果当工作来做，死路一条。

二、名称规范问题

    要确认是否同一作品，单靠题名显然是不够的，还需要责任者名称。中文编目中人名规范不普及，编目中缺乏足以信赖的名称规范档，责任者名称经常照录图书题名页。图书翻译、出版中各译各名的现象本就普遍，于是，同一作者各种译法，五花八门。
    有了规范意识后，又存在盲目依据人名翻译辞典的现象，有时就把有名的作者“规范”成了无人知晓的责任者名称。

    与题名一样，翻译图书还经常不提供原作者名称，造成名称规范工作有心无力。

三、不同语种名称标目形式不同问题

    这或许是集中不同语种同一作品的最大障碍。
    “红绿灯”的做法是全部使用拉丁字母，对于非拉丁语名称（题名与责任者）采用音译，如中文图书用汉语拼音。这当然是计算机技术发展早期无法处理其它语种字符时留下的后遗症，虽然现在“红绿灯”已将字符集转换为Unicode，原来已经编目的文献是无法逐一更改的了。韦氏音标可以用计算机批量改成汉语拼音，要由拼音改成汉字则是不可能的。

    我们自然不会全部用拼音。但因为用户不习惯用作者原名查，或者根本不知道作者原名拼写，我们反其道而行之，将作者原名全部音译成汉字。
    不过，既然同名异译现象如此普遍，使用名称规范档已不可避免。那么，我们何不在书目记录中直接使用原名？而通过名称规范将读者输入的汉译名导向书目记录？

    日本对作者标目即采用原文。以“If tomorrow comes”为例，NII（国立情报学研究所）的WebCat中某日文译本“明日があるなら”，作者标目为“Sheldon, Sidney”，而非题名页中的“シドニィ?シェルダン”。

    目前CALIS设计的名称规范库是各语种统一的，对同一作者不同语种记录间的连接无疑是十分有益的。但同一责任者采用不同标目形式的通行做法，在进行数据处理时，无疑为集中同一作品（哪怕是OPAC显示）增加了相当大的困难。

四、书目数据库、MARC格式、CNMARC/XML转换表

    Last but not least，在我国，常见的情况是中西文（或者还有日文、俄文等等）书目数据库各自独立，还采用不同的机读目录格式。各语种书目数据库分列，对于依“作品”集中所有语种书目记录的不便显而易见。不同的MARC格式，又增加了问题的复杂性。
    这种状况不是著录问题，不是修改一下编目条例/著录规则、机读目录手册就可以得到改善的。基本上可以说其本身是不会改变的，只能信赖外部技术。

    就现在来看，通过为不同MARC类型分别定义索引字段的方式，一些图书馆自动化系统已经较好地解决了不同MARC格式书目记录合库问题。现在需要解决的主要问题就是不同数据库各自独立的问题。
    只能寄希望于跨库检索技术的发展。集中同一作品的问题不是简单的重复结果去重，首先需要判定出各库中的同一作品，然后再对所有检索结果重新组合显示。

    不过，如果采用“红绿灯”的方式――他们实际上是将所有记录重新转换成XML格式――那么一个库还是多个库的问题就不存在了。
    我们需要做的，是建立一个CNMARC到XML的转换表，与LC已有的MARC/XML转换表（MARCXML: MARC 21 XML Schema）一起使用，一举解决多库、多MARC问题。

参见本人FRBR相关博客文章：

红绿灯RedLightGreen （2005年02月28日）

FRBR影响之OPAC应用 （2005年05月10日）

书目记录四种实体的汉译 （2005年05月20日）

FRBR博客 （2005年06月30日）