OCLC关于MARC的最新报告

Implications of MARC Tag Usage on Library Metadata Practices / Karen Smith-Yoshimura … Dublin, Ohio : OCLC, March 2010. 72 p. ISBN: 1-55653-378-0 (978-1-55653-378-5)
PDF下载 (778KB):http://www.oclc.org/research/publications/library/2010/2010-06.pdf

OCLC近年大量发布研究报告,才3月中旬,关于MARC的这份报告编号已是2010-06。
本报告是OCLC研究部活动“搜集证据说明MARC元数据实践需要改变”的成果,由RLG Partnership MARC Tag Usage Working Group在2008-2009年研究完成。2009年9月OCLC曾发布报告《联机目录:用户和馆员需要什么》,本报告是其延续。与其他OCLC报告不同的是,本报告由五个独立论题组成,每个论题由不同人撰写。[以下方括号中为本人观点]

1. Requirements for Enhanced Library Data Mining
OCLC首席科学家研究部Timothy J. Dickey撰写的报告引论,强调需要强化图书馆数据挖掘。[这也是OCLC近年来一直在做的事]

2. MARC Tag Usage in WorldCat
OCLC研究部的Karen Smith-Yoshimura分析2009年9月时,WorldCat数据库中1.45亿条书目记录中MARC 21字段的出现情况。[记得某大牛曾说过我很认同的话,不能根据现有记录中MARC使用情况,确定用户需要什么,决定未来用什么]

3. MARC Fields and Subfields Used in Machine Matching
剑桥大学的Hugh Taylor建立了五个集成数据库,即检索记录用的英国研究图书馆联合目录(RLUK)、COPAC(由RLUK数据库衍生的公共联合目录)、WorldCat、前RLG联合目录及澳大利亚图书馆目录(Libraries Australia),分析进行记录匹配的MARC字段的使用,并与合作编目计划(PCC)的BIBCO与CONSER标准、OCLC编目级别3(简编)记录规定的必备字段进行比较。[机器处理是未来的重点,不仅有大量载入或上传判重需要的联合目录需要关心]

4. Comparison of Search Interfaces and Data Elements
澳大利亚国家图书馆的Catherine Argus分析了五个集成数据库的MARC索引字段,包括AMICUS(加拿大全国联合目录)、COPAC、澳大利亚图书馆目录(Libraries Australia)、WorldCat.org及OCLC的FirstSearch。[传统的检索系统中不是所有MARC字段都做索引]

5. Encoding Level and Tag Occurrences in WorldCat
明尼苏达大学的Chew Chiat Naun按不同的编目等级,分析了WorldCat记录中的MARC字段。[简化编目?]

6. Relator Terms and Form/Genre Designations in MARC Tagging
OCLC研究部的Timothy J. Dickey与纽约公共图书馆(NYPL)的Peter Hirsch合作,比较了NYPL本地目录与WorldCat中形式/类别指示词(655$a)及责任关系词(1xx/7xx$e)的使用。[这两方面有助于目录实现FRBR化。责任关系词在MARC 21实践中曾被舍弃但现在又想重拾]

报告最前部分照例是Executive Summary,除介绍五个论题外,点出研究的主要发现[很多已经是老生常谈了]。列举部分如下:
WorldCat中只使用很小的MARC 21字段子集
即使包括非书格式常用字段,出现在10%以上记录中的仅21-30个字段
在基于MARC数据元素对记录进行机器匹配时,大家各行其事
用于记录匹配的共同字段只有:头标5个元素,4个定长字段(008,010,020,022),核心书目数据(1XX,245,246,250,260)。
尽管机器匹配系统一般使用核心字段与子字段,但某些时候需要超过核心范围,以验证匹配的准确性
不可低估使用MARC数据进行匹配算法的复杂性。[做过匹配的机构如CALIS对此肯定深有体会]
一般图书馆检索系统仅对字段的一个子集做索引
许多与某一类型文献相关的字段,对检索可能很有用,但未被本研究中的主要图书馆系统索引。[这是编目员的悲哀]
附注字段常用,但机器不一定擅长解释文本内容
大量使用通用附注500…其他附注字段5XX相对用得少。[机器无法识别是关于什么的附注。当要提高效率、简化编目时,不区分5XX、改入500是最常见的]
用编目等级作为依据选择“最完整”记录全然不可靠
[很多时候原始编目就用一个模板,编目员并不根据记录完整性更改头标]
目前图书馆系统抓取的检索日志数据,通常不能对用户行为提供足够信息
许多系统不能提供用户的检索字段,以及结果是否满足其提问。[命中情况,命中后点击详细记录情况,最终借阅情况?]

Executive Summary的第二部分:对图书馆MARC元数据实践的意义。对目前的编目实践有指导意义,摘录部分如下:
√ 满足本地用户的需求。用户希望你花时间点图版数,还是链接到目次或全文?[人人都明白,但…]
√ 未来几年网上提供全文的文献数量将持续增加,对“描述性元数据”的需要将减少。应专注于全文关键词检索不会提供的规范名称、分类和控制词汇。
√ 使用合适的字段反映资源。对特定类型附注使用特定的MARC字段,而不是通用的500附注。[目前CNMARC在实践中做得比较好,MARC 21由于LC的示范作用未能践行]
√ MARC数据不仅用于用户检索与识别,还用于出版物的机器匹配、链接、机器操作、收割、内容分析、排序、系统视图。在使用关联数据利用其他来源生成的更完整描述及其他相关信息的环境中,机器匹配用字段的精确性正变得越来越重要。[参看前述机器匹配字段,未来机器利用数据是重点]

Executive Summary的第三部分:MARC’s Future? 2009年末与Nalsi合写了一篇MARC未来的文章(预计将于3月刊出),因而对此特别关注。本报告或者说工作组的观点已由标题中的那个问号显示,但未来仍不明朗:
√ MARC是特定领域的数据通讯格式,正接近其生命周期的终点。
[此句经典,值得原文抄录:MARC is a niche data communication format approaching the end of its life cycle.]
√ 未来的系统,如果能够在FRBR所述方法上满足用户需求,并利用新的RDA标准所设想的关联数据的优势,将需要更关联的方法存储数据。MARC不是解决办法。
√ 未来的编码方案需要有一个强大的MARC转换对照表,以摄入现有成百上千万记录。
√ 自问:如果我们不必使用MARC,如果我们不局限于以MARC为中心的图书馆系统,我们会如何创建、抓取、建构、存储、检索及显示对象与元数据?
√ 考虑如何最佳利用关联数据的优势,避免创建相同冗余元数据。考虑传统图书馆环境外的来源。
√ 与其强化MARC及基于MARC的系统,不如与其他编码方案和系统互操作。我们必须满足其他信息体产生的信息需求。

参见:
新闻报道:New Report, “Implications of MARC Tag Usage on Library Metadata Practices” (2010-3-12)
工作组活动主页:OCLC Research activity: Gather Evidence to Inform Changes Needed in MARC Metadata Practices

参见:OCLC报告——联机目录:用户和馆员需要什么 (2009-04-25)

update 2010-05-14
OCLC网络会议主页(Webinar)有3月17日关于此报告的网络会议音频及文字记录,报告的几位撰写者与会。

简化图书元数据工作流程

    2009年3月18-19日,OCLC举办“出版者与馆员会议”(Symposium for Publishers and Librarians),讨论图书元数据问题。美国信息标准化组织(NISO)和OCLC委托Informed Strategies总裁Judy Luther就此撰写白皮书,于会后出版,名《简化图书元数据工作流程》:

Streamlining Book Metadata Workflow / Judy Luther. Baltimore, MD : NISO, 2009. ISBN: 978-1-880124-82-6 (PDF, 22p)                   

    白皮书分析了图书供应链中,元数据创建、交换与使用的现状,以及未来的机会:

Stakeholder Perspectives
    图书供应链中元数据的利益相关人,也就是拥有图书元数据的机构,包括出版社、元数据供应商、批发商、书商、国家图书馆、本地图书馆与Google。
· 出版社:由于按需印刷技术的发展,出版社需要数字化其出版书目。大社提供XML化的ONIX数据,小社可能就是EXCEL表。
· 元数据供应商:包括图书登记机构(如Bowker和Nielsen Book)、编目服务机构(如英国的BDS)、成员组织(如OCLC和CrossRef)。
    Bowker年增加30万条记录,50%是ONIX,45%是EXCEL或其他电子格式,5%仍来自提交的纸质信息。
    英国的BDS外包了大英图书馆的CIP业务,每年提供7.5万记录,并提供ONIX到MARC21的对照。
    OCLC在美加两国有70个元数据专家与编目员,为特藏及出版社、书商创建记录。
    另外主要拥有期刊元数据的CrossRef有160万图书DOI,Serials Solution有100万电子图书记录。
· 批发商:最大的批发商Baker & Taylor和Ingram数据库年增长10%以上。虽然年出版新书约20万种,但新记录估计达70万,因为不同格式与版本要有独立的记录。
· 国家图书馆:LC专业编目员创建或升级了其35万记录中的80%,BL则为26万记录中的55%。据估计,WorldCat记录的65%是简编记录(难怪OCLC要开放“专家社区”,让更多编目专家帮助提升WorldCat的质量)。
· Google:Google数字化成百上万图书,在ONIX与MARC中取质量高的记录。有不少图书馆员在Google工作,Google也与OCLC合作。Google还在开发区分相关作品的算法

Metadata Workflow
    元数据工作流程,包括ONIX及MARC标准,以及书业与图书馆界在元数据质量控制方面的努力。

Opportunities
    未来的机会,包括标识符、主题表及最佳实践

· 标识符:包括作者、个别作品、丛编与相关作品,相当于编目界的名称规范、丛编题名规范,以及FRBR中的作品概念。
    唯一标识文本作品的“国际标准文本码ISTC – International Standard Text Code已是国际标准ISO 21047。
    作者标识符目前有“国际标准名称标识符ISNI – International Standard Name Identifier,还是草案(Draft ISO 27729)。
· 主题表:美国书业采用BISAC,50大类3000多小类;英国书业采用BIC;图书馆界采用LCSH、Sears及MeSH。
· 最佳实践:14项建议,特别注意的是:
第一条:使用ONIX与MARC的对照,方便创建CIP,并向出版社提供XML的MARC数据。
最后一条:探索把目前的ISTC和未来的ISNI标准集成到当前工作流程的方法,促进其被采纳。前者可用于创建作品间关联,后者可提供作者的规范控制。(或许未来的MARC书目记录中会加入ISTC,规范记录中会加入ISNI

    集中同一作品的不同内容表达、载体表现,对于出版发行者来说,可能比图书馆更为重视。因为多卷书(整套或各单册)、不同载体(如电子或纸质)、甚至不同装帧形式(如精装或平装),由于销售方式、销售价格不同,对书商来说需要使用不同的记录。这是以前没有想到过的ONIX数据与MARC数据的一个重要差别。

    无论如何,充分利用供应链上游的数据,将会是未来图书馆编目工作的发展方向。LC对书目控制未来工作组报告的回应,表明LC计划继续参与ONIX开发,并将关注从ONIX中抓取数据的机会。而OCLC的出版社ONIX元数据强化服务,从形式上看是为出版社提供服务,实质上也为WorldCat取得了大量由ONIX元数据转换而来的MARC数据。

    白皮书正文末是Judy Luther与30位业内代表交谈后,绘出的图书元数据交换图(p.17),反映图书供应链中各方及与ONIX、MARC、DOI三种元数据的关系,标示出对数据进行质量控制的部分。


参见:OCLC News Releases, 7 July 2009
Streamlining Book Metadata Workflow – NISO and OCLC Publish White Paper that Reveals Opportunities in the Book Supply Chain

圣诞老人的名称规范

八十年代初,洋节还没有在上海流行。到八十年代中风气突变,自己也曾在圣诞夜跟同学去过衡山路的国际礼拜堂,装模做样地做了一次礼拜。还有一个圣诞夜玩过通宵,因为那个不是节假日,本地同学不回家,比元旦更适合迎新年活动。离开学校的同时成了家,不信教,再也不会在圣诞夜外出参加什么活动了。
初写博时曾写“中国人为什么过圣诞?”,那是应景杂文,以后再也不曾涉及。前几天看到WorldCat博客介绍圣诞老人的名称规范Searching for Santa,想着留到圣诞夜应景不错。

如2007年初所说的设想,现在WorldCat Identity已经有了虚拟人物的规范,下面就是圣诞老人的身份档页面:Santa Claus
有35种语言的2,434种作品、4,203个出版物,收藏馆282,961。
页面显示语言为中文的有28,但点击链接到WorldCat,却显示有63个结果,看来数据不同步。

相关人物(Related Identities)应该都是责任者。
相关链接(Useful Links)的LC规范记录,有交替名称Father Christmas,不知为何WorldCat Identity没有如个人名称那样提供交替名称。
相关主题(Associated Subjects)应该直接取自书目记录,电影、诗比较多,故事也不少。读者对象儿童为主不出意外,但听障者用的视频、电影也有不少,是不是弱智了点?
最奇怪的就是地点“纽约”(New York (State)–New
York)出奇地多,又不是圣诞老人的居住地?点击链接到WorldCat再次出错,因为主题检索su:不接受那两个短横。无论如何此处是需要改进的,或许两难,因为同名的缘故,从主题抽取地理位置如果没有前面的限定,就可能是另一个地点,有限定就要有标识──主题词间用破折号分隔是卡片年代的用法,在
MARC中用子字段分隔,在Web时代,要重新考虑。

参见:规范档2.0:WorldCat身份档 (2007-02-14)

另推荐OCLC的Andrew Pace的圣诞歌:Jingle Books