编目精灵II -- On the Fly

    AACR2是伴随着MARC而生的，随着RDA将替代AACR，似乎MARC也将随之消亡，但目前并没有替代MARC的标准出现。并且从MARC的发展历史来看，其演变或进化能力还是很强的，不会那么轻易地退出历史舞台。

    10月14日，美国信息标准组织(NISO)举办了一次网络会议(Webinar)，Bibliographic Control Alphabet Soup: AACR to RDA and Evolution of MARC。会议主题是“AACR到RDA及MARC的演进”，Alphabet Soup不知如何翻译，大概算是扫盲吧？
    三个演讲（PDF下载）分别是：
Barbara Tillett: AACR2, RDA, VIAF, and the Future: From There to Here to There
Diane Hillmann: RDA Elements and Vocabularies: a Step Forward from MARC
William Moen: Data-driven Evidence for Core MARC Records（介绍2006年对5600万条WorldCat记录进行的MARC字段、子字段统计分析）

    会上有问答环节（Bibliographic Control Webinar Q&A），以下录有回复的问题，并摘录与MARC相关的回答：

1、有了RDA，MARC记录是否终将消失？如果是这样，MARC记录还会用多久？
Diane Hillman：我想MARC记录最终消失要很长时间（如我在会上提到的，未来会有一个地方放经专门交换的有损耗的格式）。关键是我们要开始展望一个真正好的结果，在MARC世界之外普遍化的、以RDA元素及词汇作为数据交换基础。
Barbara Tillett：RDA希望用于任何（元数据）方案或显示，因此RDA对MARC格式本身并不意味着什么。但是，RDA提供了到MARC21及其他方案的映射（对照表）……。RDA初版只有少数对照表（附录D是ISBD、附录E是MARC21，可能链接MODS/MADS及DC对照表），未来我们希望增加更多。
如今很多ILS厂商内部并不使用MARC21，只用于输入/输出书目与规范（有时还有馆藏）数据。只要OCLC及ILS厂商需要MARC格式交换数据，它就会存在，只是许多时候已经在用ONIX XML、MARCXML，也能够以XML处理MODS及MADS。IFLA正在为ISBD元素创建RDF XML元数据方案，很可能RDA元素也会以XML形式提供。如Diane所说，映射MARC21数据到未来的XML方案，在转换过程中无疑会丢失某些数据，但大部分仍是可用的。MARC21结构局限于建立什么关系与链接。

2、如何鼓励厂商利用RDA及FRBR的优势？

3、目前在图书馆学课程中是否教授RDA和FRBR？MARC还会教多久？
Diane Hillman：我想只要我们交换MARC数据，就会继续教MARC，只是多半不会像现在这样教。
Barbara Tillett：至于继续教MARC21，它是编目史上一个绝对重要的部分，因此我希望未来很长时间内会被涉及，但希望编目员不必花太久时间继续学习MARC21编码。

6、（针对Moen的MARC字段调查）本研究是否考虑了记录创建日期相比较于核心（记录）标准出版日期？似乎许多记录是在核心标准制订前创建的。
Barbara Tillett：很重要的一点！很奇怪的是，未来什么元素对用户重要这样的决定，要基于以前我们做了些什么。（以下对656字段统计数据有疑问）

7、MARC很大的一个原因是，它发展多年，为适应各界编目员的变迁与需求。RDA词汇如何回应改变需求？

10、RDA是否比MARC与AARC2更适应编目现实？

11、RDA与书目本体(Bibliographic Ontology)关系？

13、给Diane Hillmann的三个问题
1）在“为什么不是MARC”，你谈论的是MARC21句法（即ISO2709）还是MARC元素集？MARC元素集也可以用RDF/OWL。
Diane Hillman：当然是前者，但也是后者，我觉得很难把二个问题当作完全独立的问题。一个困难是MARC设计为平面记录，不易翻译到图书馆之外所用的那种数据结构与编码。比如已经有很多尝试把URL加入MARC，但作为一种策略并不完全成功。还有其他限制也苦恼着MARC（比如每字段的子字段数）。面对MARC数据的遗产，对MARC元素集进行大修是个很困难的过程，有点像毁坏一所旧房子的内部却仍住在其中（我曾试过一间间房修，并不是只在这儿考虑！）我认可你关于RDF/OWL的观点，但不认为是一个特别令人满意的策略，并且在我所见的业界，对此并无多少热忱。
2）对不使用RDA的机构，未来的书目格式会是什么样的？MARC一直独立于特定的编目规则（尽管最初以AACR开发并常与之关联），CCO（编目文化对象）就是一个例子。
Diane：我想永远不会有“一个”用于所有人的书目格式，但非常有意思的未来会包含这样的想法：我们不必局限于只用一个，我们可以根据所需、选取所用。图书馆已经使用多种格式（及变体），但仍未解决围绕这种多样性所产生的数据交换问题，而RDA元素与词汇的策略就是为此设计的。当然，CCO并非严格的书目格式，但我想它肯定会从RDA所采用的这种面向未来的策略（主要是注册并开放可得的RDA词汇）中获益。
Barbara Tillett：这个提问似乎混淆了交换书目数据的格式/方案与编目指引──编目指引独立于任何编码方案的任何显示格式。即使现存的基于AARC2的数据也可不用MARC编码。可以遵循AACR2、CCO指引或RDA指引，把书目数据放入MARC21记录，或者一种XML方案，或者其他。对于DACS、CCO、DCRM及其他指引的开发者，肯定有机会与RDA开发者合作，形成共享原则基础上的结果，共享概念模型并兼容未来。每个专业团体会有更颗粒化的方法适应自己的对象。
3）新的RDA格式如何与图书馆馆藏数据交互？使用不同类型的MARC信息使我们集成数据（即书目、规范、馆藏、分类、社区信息）。
Diane Hillman：我对馆藏数据很有兴趣（我职业生涯的早年曾任期刊馆员和法律馆员）。不幸的是RDA并不能应付MARC用到的馆藏层次。我知道Extensible Catalog项目在转换大量MARC数据到RDA建立服务时，正试图加以解决，馆藏肯定是已得到关注的领域。考虑到大量的数据，我想你所提到的其他种类信息也会得到关注（或正被关注）。我会觉得，在基于更广泛结构与编码标准的世界，使用“家族式”集成书目标准的MARC概念或许并不理想。如LC的LCSH新网站使用SKOS（简单知识组织系统）作概念词汇，如同OCLC的新DDC顶层，以及NSDL注册。FRAD正在出现，表达名称规范。我一直是MARC社区信息格式的粉丝，悲哀的是它不大看到被采用。一个问题是它本质上并非“书目”，因而使其未来不那么确定。我很乐意看到它在Web世界中“被重新发现”并重设想。
Barbara Tillett：RDA不是一种格式，它是一套编目指引，用以识别我们希望在书目中控制事物的特征。如果你仍使用ILS，而开始根据RDA描述事物，那么在可预见的未来，你仍会用MARC书目记录及MARC馆藏记录（及MARC规范记录）。

14、RDA是否/如何提高编目效率？
Diane Hillman：如同最初MARC格式通过扩大目录记录的可获得性与复用，为图书馆提高效率，通过走出图书馆寻求数据与共享机会，RDA同样具有再次为图书馆提高效率的潜力。我认为用MARC，数据几乎全部由人工创建，我们已经达到了所能达到的极限，如果近距离看看我们之外的世界所做的，就可以看到我们有潜力既做数据提供者，也能做数据的用户。如地理名称服务（http://www.geonames.org/），图书馆可以方便地发现经纬度数据以提供地图服务，取代目前MARC数据中提供的仅人工可读的地理名称串。考虑在一个更现代的数据环境下，我们如何使用像这样已经存在的服务，事实上我们正面临经济挑战，需要重新思考使用昂贵的人力资源，这正是转向RDA所意味的。
Barbara Tillett：实现RDA的主要益处会随着基于FRBR系统的新编目系统开发而实现……

    苏西(Suzie)在博客上写了她对AACR, LOC, DDC, FRBR, CCO, MARC, RDA的理解，每种都有一串提纲契领式的描述。撷取部分关于MARC的：

    * 自1960年代LC开发出来后，目前是第21次修订 [指书目格式吧：MARC21 Format for Bibliographic data, 1999 edition, update no.9 (October 2008)]
    * Pre-web, pre-a lot of things.
    * 从001到880，有200个字段 [计算了一下，目前有效的书目数据字段从001到887共212个，加上以前曾经有的，大致是249个]
    * 800 subfields [显然不止这个数]
    * 4%的字段占80%的记录 [出处待考。还算正常分布吧，尾巴可能长了点]
    * OCLC的一项研究，每5600万记录才有一条使用856字段 [按Thomas Hickey的2007年数据是3.64%，2009年数据是7.79%，有链接的记录远不止这个数]
    * OCLC高级程序经理Roy Tennant说“MARC必须死” [最近他老人家又说了：MARC不必要的复杂。但LibraryThing的Tim显然不这么认为，参看他在Tennant博文下的留言]
    * 除图书馆外，没有机构用它 [Tim显然很喜欢它]
    * “有损耗的输出格式”（Lossy Output Format）[出处未知]
    * 原打算作为传输格式(a transfer format)!!!最终成了元数据方案(a metadata scheme) [近来正在想这个]

    Keven在元数据讨论组上转发Suzie博文时用了mindmap一词，借来用做标题了。

参见：
How to Catalog a Hiccup: The difference between AACR, LOC, DDC, FRBR, CCO, MARC and RDA（需备梯）
WorldCat书目记录2009统计分析 (2009-10-14)
Tennant: Digital Libraries: The Unused Complexity of MARC (October 14, 2009)
MARC Must Die / By Roy Tennant. Library Journal, 10/15/2002

    OCLC首席科学家Thomas Hickey在博客上发布了2009年10月1日的WorldCat书目记录统计（Bibliographic Statistics 2009，无轻功免点），2007年3月他也做过同样的统计。
    在这二年半中，WorldCat书目记录从0.83亿条飞升到近1.46亿条（不包括worldcat.org所含文摘索引数据库中的记录），增加了80%。如此发展，当然不是靠人一条条做进去的。近年WorldCat批量加入了很多国家图书馆（包括中国国家图书馆）与大型书目库的记录，今天还看到"Credo Reference is adding MARC records to WorldCat"，一加就是300多万条，当然不全部是新增，其中一些WorldCat中已有的，只是在记录中加一个可检索的来源标记。
    与之相比，馆藏从11.2亿增长至14.7亿，3.5亿也是一个惊人的数字。

    特别有意思的另两组数字：MARC平均记录长度从803字节下降到785字节，每记录字段数从15.4个下降到14.9个。恐怕大多数人看到这两组对比数字，都会想到这体现了书目的简化趋势。或许Hickey当初也是这么想的，但他还提供了另一组数字：不同的MARC子字段数从1670上升为3278，几乎番翻。Hickey认为，虽然增加了6300万条记录，也不至于会有这个结果。想来原因正是很多非美国编目记录的加入，或许原来所用MARC子字段与MARC21不尽相同，或许原来用UNIMARC家族的，转换为MARC21后对应到非常用的MARC21子字段。
    在关于MARC的争论中，曾经有一点是MARC有那么多字段、子字段没什么人用。WorldCat的这个统计或许说明，如果放大到全球，那么使用的子字段或许更多些。放着不用或没有用，总强过要用而无可用──这是编目员在分类或编目时经常头痛的事。

    由于今日失却最后的上网护身符洋葱头(Tor)，武功尽失。今做托钵僧，乞轻功高手下载WorldCat2009年统计数据表(Bibstats2009)后赠予本人。阿弥陀佛，善哉善哉！

    当机读目录(MARC)被介绍进来的时候，我们还处于集体主义时代。于是我知道MARC是由美国国会图书馆(LC)开发的，却不知道、也没有想过了解它的开发者是谁。直到今天，才后知后觉，原来是一位女士──亨丽埃特·艾弗拉姆(Henriette Avram, 1919.10.7-200***.22)。
(本图来自《纽约时报》)
    艾弗拉姆1950年代在美国国家安全局(NSA)工作，成为第一代编程员。后来在私企做系统分析与编程时，经由一个设计计算机科学图书馆的项目而了解图书馆，并被引介至LC卡片部(Card Division Service）。她还为OCLC之父Frederick Kilgour做过咨询，当时OCLC开始尝试计算机化书目信息。
    1965年艾弗拉姆得知LC有一个空缺，最终得以受雇为信息系统专家办公室的系统分析员。她的第一个任务是分析如何用计算机处理编目数据。凭借在国安局的训练，“在提出计算机解决方案前，彻底理解主题是首要条件”，她和二个图书馆员一起，仔细检查卡片记录中包含的信息，过目数百种不同语言的百万级条目；她也研究ALA规则（当时还没有AACR2）及LC排片规则，尽可能了解书目控制的方方面面。在彻底检查了书目记录的每个部分后，她将之翻译为一套字段，具有名称（标签，也就是3位数字）、处理方式（指示符）及部分（子字段）──MARC由此诞生。

    有了MARC，得以把卡片目录转换为计算机目录，使千里之外联网查询目录成为可能。艾弗拉姆也因此成为图书馆界迈向信息科学的关键人物。
    为使MARC得到广泛采用，艾弗拉姆致力于使之成为标准。先是与美国图书馆协会(ALA)和美国国家标准协会(ANSI)一起，使MARC在1971年成为国家标准；继之继续游说，在1973年MARC成为国际标准(ISO2709)。由于她的努力，“MARC现在成为全球图书馆自动化与书目交流的基础”。尽管她从未打算做一名图书馆员，却成了“图书馆自动化和书目控制方面的杰出人物”。
    艾弗拉姆还是关联系统项目(Linked Systems Project)的最初规划者之一，孜孜不倦地推行以国际标准，连接存储于离散计算机系统的数据库的理念──不知道这种概念现在叫什么，是否还存活？

    艾弗拉姆在1967年成为LC的信息系统副协调员，继续领导MARC试验项目(MARC Pilot Project)直至1968年6月结束。1969年3月起领导MARC发行部，并开始回溯转换试验项目(RECON Pilot Project)──MARC的回溯转换工作至今仍未完成，是她职业生涯中“唯一失望的经验”。尽管如此，凭借其工作热情、外交手腕及领导能力，她在LC逐渐高升，至1983年成为副馆长，直到1992年退休。
   
    艾弗拉姆也是国际图联(IFLA)的积极参与者。她参加了大名鼎鼎的1969年国际编目专家会议，成为开发专著国际标准书目著录ISBD(M)的一员。1970年代，她还是ILFA内容标识符工作组(IFLA Working Group on Content Designators)主席，采用ISBD开发MARC格式的国际版UNIMARC──是她的外交手腕让她兼容并包，没有主张用统一的MARC格式，还是她觉得随着计算机技术的发展，LC的MARC有点落伍了？

    自1971年到退休次年(1993年)，她获得了众多奖项和荣誉，1986年台湾还给她授了奖(Appreciation Award from the National Central Library of Taipei, Taiwan)。除了图书馆界的奖项，她还是1974年联邦妇女奖获得者(Federal Women's Award)。
    按照美国图书馆界惯例，只有拥有图书馆学位的人才是librarian，其他专业人员只能是准图书馆员。作为一名计算机编程专家，当1971年ALA授予她第一个奖项“玛格利特·曼分类编目奖”时，她的获奖感言是：“从一开始……你们就欢迎并支持我。今天你们进了一步──你们接纳了我。”她后来对此的解释是，“在那一刻及其后，我视自己为图书馆员”。很自豪的口吻。
    她的语录：“我相信互联网是伟大的技术成就。但是，在组织信息，使我们能够定位、选择并区分严肃研究的书目项方面，互联网还有很长的路要走。”是的，但互联网走得比图书馆快。
    她的另一条语录：“在我看来，现在比以往更需要图书馆和图书馆员……在开发MARC过程中，我们需要二个天才，即计算机专家和图书馆专家，没有一个天才可以独自成功……图书馆员必须成为计算机学者，这样才能理解应用的技术及其与专业的关系。”可以视为一位计算机专家对图书馆员的期望吧。

    艾弗拉姆2006年4月22日逝世，《华盛顿邮报》纪念文章的标题是“改革图书馆”(Henriette D. Avram; Transformed Libraries, April 28, 2006)，《纽约时报》纪念文章的题目是“现代化图书馆者”(Henriette D. Avram, Modernizer of Libraries, Dies at 86, May 3, 2006)。早在四十多年前，图书馆就是由计算机专家来改革，并使之现代化的。不知道当年想到要雇佣计算机专家的，是什么样的Librarian？
   
    一直说自己是个没有历史感的人，此事又是一个例证。那年自己已经写博一年加半载，竟然不知道这位MARC之母辞世的消息，真有点不可思议。
   
PS：基本信息编译自维基百科：Henriette Avram（文中含本人观点，请看官自行辨别）

    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)