<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>数图研究笔记 &#187; MARC</title>
	<atom:link href="http://www.kevenlw.name/archives/tag/marc/feed" rel="self" type="application/rss+xml" />
	<link>http://www.kevenlw.name</link>
	<description>When you have a hammer, everything looks like a nail.</description>
	<lastBuildDate>Fri, 27 Aug 2010 06:40:16 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>也谈如何让MARC安乐死</title>
		<link>http://www.kevenlw.name/archives/368?utm_source=subscriber&amp;utm_medium=rss&amp;utm_campaign=rss</link>
		<comments>http://www.kevenlw.name/archives/368#comments</comments>
		<pubDate>Thu, 05 Apr 2007 15:36:04 +0000</pubDate>
		<dc:creator>keven</dc:creator>
				<category><![CDATA[专业评论]]></category>
		<category><![CDATA[元数据]]></category>
		<category><![CDATA[MARC]]></category>

		<guid isPermaLink="false">http://www.dlresearch.cn/keven/index.php/archives/368</guid>
		<description><![CDATA[
耄耋少年陈老师在博客中谈及&#8221;如何使MARC安乐死&#8220;，图情散记在前些日子也论述了&#8221;后MARC时代图书馆信息服务的设想&#8220;，都提出了一些很好的想法，我这里也想提一点自己的看法，求教于大家。
1、想以一种新的MARC取代旧的MARC是不现实和不足取的，也是不可能的；
2、在分布式异构环境（说白了即因特网环境）下，多种元数据方式并存是必然的和必需的；
3、元数据方案的标准化并非必需，除非需要与外界进行数据交换或共享（即互操作）；
4、MARC只有在所有系统都支持，但又不依赖时才能死的安乐，死得其所；
5、使多种元数据方式在同一系统中并存的解决方案有很多，建立描述对象的属性关系模型是最基本和最可靠的，这个模型实际上是作为一种本体提供服务；
6、元数据方案的标准化不仅仅是属性元素集的标准化，也包括语法和结构的标准化，但更重要的是描述模型的标准化；
7、标准化并非是刚性的、绝对的，可以有不同级别和层次；
8、未来的MARC将是一套元数据描述从语义到语法结构到模型及著录规范和算法的完整体系，这套体系是固化在网络应用的人机界面中，无需用户和任何非专业人士掌握和直接面对的。
Powered by ScribeFire.

	Tags: MARC, 专业评论, 元数据

	Related posts
	
	让MARC安乐死 (0)
	愿MARC“永垂不朽” (0)


]]></description>
			<content:encoded><![CDATA[<abbr class="unapi-id" title="http://www.kevenlw.name/?p=368"><!-- &nbsp; --></abbr>
<p>耄耋少年陈老师在博客中谈及&#8221;<a title="如何使MARC安乐死" href="http://blog.sina.com.cn/u/4bd4c87b010007un">如何使MARC安乐死</a>&#8220;，图情散记在前些日子也论述了&#8221;<a title="后MARC时代图书馆信息服务的设想" href="http://blog.edu.cn/user1/22631/archives/2007/1606266.shtml">后MARC时代图书馆信息服务的设想</a>&#8220;，都提出了一些很好的想法，我这里也想提一点自己的看法，求教于大家。</p>
<blockquote><p>1、想以一种新的MARC取代旧的MARC是不现实和不足取的，也是不可能的；<br />
2、在分布式异构环境（说白了即因特网环境）下，多种元数据方式并存是必然的和必需的；<br />
3、元数据方案的标准化并非必需，除非需要与外界进行数据交换或共享（即互操作）；<br />
4、MARC只有在所有系统都支持，但又不依赖时才能死的安乐，死得其所；<br />
5、使多种元数据方式在同一系统中并存的解决方案有很多，建立描述对象的属性关系模型是最基本和最可靠的，这个模型实际上是作为一种本体提供服务；<br />
6、元数据方案的标准化不仅仅是属性元素集的标准化，也包括语法和结构的标准化，但更重要的是描述模型的标准化；<br />
7、标准化并非是刚性的、绝对的，可以有不同级别和层次；<br />
8、未来的MARC将是一套元数据描述从语义到语法结构到模型及著录规范和算法的完整体系，这套体系是固化在网络应用的人机界面中，无需用户和任何非专业人士掌握和直接面对的。</p></blockquote>
<p class="poweredbyperformancing">Powered by <a href="http://scribefire.com/">ScribeFire</a>.</p>

	Tags: <a href="http://www.kevenlw.name/archives/tag/marc" title="MARC" rel="tag nofollow">MARC</a>, <a href="http://www.kevenlw.name/archives/category/%e4%b8%93%e4%b8%9a%e8%af%84%e8%ae%ba" title="专业评论" rel="tag nofollow">专业评论</a>, <a href="http://www.kevenlw.name/archives/category/%e7%9f%a5%e8%af%86%e7%bb%84%e7%bb%87/%e5%85%83%e6%95%b0%e6%8d%ae" title="元数据" rel="tag nofollow">元数据</a><br />

	<h4>Related posts</h4>
	<ul class='st-related-posts'>
	<li><a href="http://www.kevenlw.name/archives/359" title="让MARC安乐死 (三月 18, 2007)">让MARC安乐死</a> (0)</li>
	<li><a href="http://www.kevenlw.name/archives/242" title="愿MARC“永垂不朽” (九月 9, 2006)">愿MARC“永垂不朽”</a> (0)</li>
</ul>

]]></content:encoded>
			<wfw:commentRss>http://www.kevenlw.name/archives/368/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>让MARC安乐死</title>
		<link>http://www.kevenlw.name/archives/359?utm_source=subscriber&amp;utm_medium=rss&amp;utm_campaign=rss</link>
		<comments>http://www.kevenlw.name/archives/359#comments</comments>
		<pubDate>Sun, 18 Mar 2007 05:45:00 +0000</pubDate>
		<dc:creator>keven</dc:creator>
				<category><![CDATA[专业评论]]></category>
		<category><![CDATA[图书馆2.0]]></category>
		<category><![CDATA[MARC]]></category>

		<guid isPermaLink="false">http://www.dlresearch.cn/keven/index.php/archives/359</guid>
		<description><![CDATA[
2006年11月12日，全世界最大的联合书目数据库，OCLC的WorldCat起用了9位数的记录号，意味着它的第一亿条记录的诞生[4]。这家总部 位于美国俄亥俄州的图书馆会员制机构，可以说是伴随着20世纪60年代书目数据格式MARC的诞生而诞生，随着MARC的发展而发展，目前已拥有全世界 112个国家5万7千多会员图书馆和超过十亿条的馆藏数据（Items）[5]，虽然是非盈利机构，依靠向全世界的图书馆和会员图书馆提供服务，全年的营收逾2亿美元。
MARC是我们这个职业的最重要核心竞争力之一，如同OCLC一样，甚至是我们行业赖以生存的基础。全世界的书目数据基本上反映了当前人类非&#8221;实物&#8221;文化 遗产的概貌，在迄今为止所生产的所有人类知识中也占有相当比例，如果时间倒退四分之一个世纪，可以说占有绝大的比例。在目前一年的信息产量相当于过去 5000年的总和，而其中绝大多数为数字资源的情况下，这个比例正大幅减少，可能用不了多久，我们所掌控的&#8221;知识&#8221;记录，就会被复制拷贝，而使我们的 MARC变得微不足道。
MARC最大的价值在于标准化而适于机器处理，从而有利于规模化应用，并极大地提高了系统效率。以历史的眼光来看，MARC领导了图书馆行业最辉煌的时 代，至少说明我们的信息技术应用曾领先于绝大多数行业。然而也是碍于当时的技术，严格的形式化并不是为了读者而设计的，而是为了传统的业务流程（例如卡片 或印刷目录输出）而设计，甚至仅仅为了机器而设计（定长不定长的考虑），造成MARC的七宗罪：

字段众多，且重复严重。真正对读者有意义的字段（主要指与内容描述有关的字段）很少，因此真正作索引的字段也并不多。据最新的研究统计，80%的书目记录只使用了36个字段或子字段[7]，国图数据的抽样中多于30个字段的记录只占0.09%[8]，几乎可以忽略不计。
技术严重过时。格式设计所依赖的是以磁带为主要存储介质的技术，在目前各种集成系统的技术实现中早已采用了关系数据库技术，乃至其它更为先进的全文索引、面向对象技术甚至XML技术（在与其它数据格式进行数据交换时）等，MARC格式可以是一个动态映射的用户视图。
规范乃至著录规则很不统一，语义含糊。特别是不同国家地区和不同版本的MARC，即便不是不能互操作，也绝难互操作。从各家系统对于多MARC的支持情况就可以看出来。
字段、子字段标识和结构复杂。书目记录的描述主体、客体及关系模型不清晰，格式规定琐碎、不统一。例如新引入的数字资源链接856字段，著录方式千差万别千奇百怪，造成系统实现方式也难以统一。况且这个字段随着新的链接机制的应用普及，其本身的必要性也值得怀疑。
数据加工成本巨大，专业门槛高，难以普及。
数据生产的周期较长，时间滞后，不利于服务开展。
语义与语法及结构捆绑，适应性和灵活性差，难以适应新媒体和新技术发展的需要。具体表现在难以应用于电子资源编目，以及难以进行无损失的元数据映射。

我们最大的财富正在成为我们最大的包袱。头脑清醒的人没有认为MARC对数字资源还能继续有用，而一旦我们的书目宝库不能融入互联网庞大的信息库中，成为 前朝遗老，我们就有极大的可能被信息社会边缘化。令人振奋的是我们已经看到OCLC（当然这也是为了它自身的生存）正在引领整个行业走在一个正确的方向上，例如DC元数据的提出、FRBR化、&#8221;元数据&#8221;（XML）化等；美国国会图书馆等业界大佬，虽然步履蹒跚，也并未止步不前；许多图书馆或图书馆联盟，也在积极研究，寻求合作，采取行动。
近年来兴起的一些研究（特别是元数据研究）对书目数据的功能进行了较为全面的梳理，如果把MARC看成一种元数据的话，满足要求的MARC可以完全不必如 此，而且MARC也可以仅作为图书馆集成管理系统中的&#8221;一种&#8221;元数据而已，而且是粗粒度的、着眼于与历史数据兼容的元数据形式。新的图书馆系统即便仍然以&#8221;元数据&#8221;为核心，也应该能够灵活地支持多种元数据格式。
MARC面临改造是必然的，然而这一步究竟应该走得多大，才能保护图书馆行业半个世纪以来在MARC上的投资，才能实现平稳过渡？我们依然不清楚。目前编目界围绕RDA的争论就反映了这个问题。换句话 说，我们目前面临的问题，不是MARC该不该死，而是如何使其安乐死？

	Tags: MARC, 专业评论, 图书馆2.0

	Related posts
	
	愿MARC“永垂不朽” (0)
	也谈如何让MARC安乐死 (0)


]]></description>
			<content:encoded><![CDATA[<abbr class="unapi-id" title="http://www.kevenlw.name/?p=359"><!-- &nbsp; --></abbr>
<p>2006年11月12日，全世界最大的联合书目数据库，OCLC的WorldCat起用了9位数的记录号，意味着它的第一亿条记录的诞生[4]。这家总部 位于美国俄亥俄州的图书馆会员制机构，可以说是伴随着20世纪60年代书目数据格式MARC的诞生而诞生，随着MARC的发展而发展，目前已拥有全世界 112个国家5万7千多会员图书馆和超过十亿条的馆藏数据（Items）[5]，虽然是非盈利机构，依靠向全世界的图书馆和会员图书馆提供服务，全年的营收逾2亿美元。</p>
<p>MARC是我们这个职业的最重要核心竞争力之一，如同OCLC一样，甚至是我们行业赖以生存的基础。全世界的书目数据基本上反映了当前人类非&#8221;实物&#8221;文化 遗产的概貌，在迄今为止所生产的所有人类知识中也占有相当比例，如果时间倒退四分之一个世纪，可以说占有绝大的比例。在目前一年的信息产量相当于过去 5000年的总和，而其中绝大多数为数字资源的情况下，这个比例正大幅减少，可能用不了多久，我们所掌控的&#8221;知识&#8221;记录，就会被复制拷贝，而使我们的 MARC变得微不足道。</p>
<p>MARC最大的价值在于标准化而适于机器处理，从而有利于规模化应用，并极大地提高了系统效率。以历史的眼光来看，MARC领导了图书馆行业最辉煌的时 代，至少说明我们的信息技术应用曾领先于绝大多数行业。然而也是碍于当时的技术，严格的形式化并不是为了读者而设计的，而是为了传统的业务流程（例如卡片 或印刷目录输出）而设计，甚至仅仅为了机器而设计（定长不定长的考虑），造成MARC的七宗罪：</p>
<ol>
<li>字段众多，且重复严重。真正对读者有意义的字段（主要指与内容描述有关的字段）很少，因此真正作索引的字段也并不多。据最新的研究统计，80%的书目记录只使用了36个字段或子字段[7]，国图数据的抽样中多于30个字段的记录只占0.09%[8]，几乎可以忽略不计。</li>
<li>技术严重过时。格式设计所依赖的是以磁带为主要存储介质的技术，在目前各种集成系统的技术实现中早已采用了关系数据库技术，乃至其它更为先进的全文索引、面向对象技术甚至XML技术（在与其它数据格式进行数据交换时）等，MARC格式可以是一个动态映射的用户视图。</li>
<li>规范乃至著录规则很不统一，语义含糊。特别是不同国家地区和不同版本的MARC，即便不是不能互操作，也绝难互操作。从各家系统对于多MARC的支持情况就可以看出来。</li>
<li>字段、子字段标识和结构复杂。书目记录的描述主体、客体及关系模型不清晰，格式规定琐碎、不统一。例如新引入的数字资源链接856字段，著录方式千差万别千奇百怪，造成系统实现方式也难以统一。况且这个字段随着新的链接机制的应用普及，其本身的必要性也值得怀疑。</li>
<li>数据加工成本巨大，专业门槛高，难以普及。</li>
<li>数据生产的周期较长，时间滞后，不利于服务开展。</li>
<li>语义与语法及结构捆绑，适应性和灵活性差，难以适应新媒体和新技术发展的需要。具体表现在难以应用于电子资源编目，以及难以进行无损失的元数据映射。</li>
</ol>
<p>我们最大的财富正在成为我们最大的包袱。头脑清醒的人没有认为MARC对数字资源还能继续有用，而一旦我们的书目宝库不能融入互联网庞大的信息库中，成为 前朝遗老，我们就有极大的可能被信息社会边缘化。令人振奋的是我们已经看到OCLC（当然这也是为了它自身的生存）正在引领整个行业走在一个正确的方向上，例如DC元数据的提出、FRBR化、&#8221;元数据&#8221;（XML）化等；美国国会图书馆等业界大佬，虽然步履蹒跚，也并未止步不前；许多图书馆或图书馆联盟，也在积极研究，寻求合作，采取行动。</p>
<p>近年来兴起的一些研究（特别是元数据研究）对书目数据的功能进行了较为全面的梳理，如果把MARC看成一种元数据的话，满足要求的MARC可以完全不必如 此，而且MARC也可以仅作为图书馆集成管理系统中的&#8221;一种&#8221;元数据而已，而且是粗粒度的、着眼于与历史数据兼容的元数据形式。新的图书馆系统即便仍然以&#8221;元数据&#8221;为核心，也应该能够灵活地支持多种元数据格式。</p>
<p>MARC面临改造是必然的，然而这一步究竟应该走得多大，才能保护图书馆行业半个世纪以来在MARC上的投资，才能实现平稳过渡？我们依然不清楚。目前编目界围绕RDA的争论就反映了这个问题。换句话 说，我们目前面临的问题，不是MARC该不该死，而是如何使其安乐死？</p>

	Tags: <a href="http://www.kevenlw.name/archives/tag/marc" title="MARC" rel="tag nofollow">MARC</a>, <a href="http://www.kevenlw.name/archives/category/%e4%b8%93%e4%b8%9a%e8%af%84%e8%ae%ba" title="专业评论" rel="tag nofollow">专业评论</a>, <a href="http://www.kevenlw.name/archives/category/%e5%9b%be%e4%b9%a6%e9%a6%8620" title="图书馆2.0" rel="tag nofollow">图书馆2.0</a><br />

	<h4>Related posts</h4>
	<ul class='st-related-posts'>
	<li><a href="http://www.kevenlw.name/archives/242" title="愿MARC“永垂不朽” (九月 9, 2006)">愿MARC“永垂不朽”</a> (0)</li>
	<li><a href="http://www.kevenlw.name/archives/368" title="也谈如何让MARC安乐死 (四月 5, 2007)">也谈如何让MARC安乐死</a> (0)</li>
</ul>

]]></content:encoded>
			<wfw:commentRss>http://www.kevenlw.name/archives/359/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>愿MARC“永垂不朽”</title>
		<link>http://www.kevenlw.name/archives/242?utm_source=subscriber&amp;utm_medium=rss&amp;utm_campaign=rss</link>
		<comments>http://www.kevenlw.name/archives/242#comments</comments>
		<pubDate>Sat, 09 Sep 2006 07:56:00 +0000</pubDate>
		<dc:creator>keven</dc:creator>
				<category><![CDATA[专业评论]]></category>
		<category><![CDATA[数字图书馆]]></category>
		<category><![CDATA[MARC]]></category>

		<guid isPermaLink="false">http://www.dlresearch.cn/keven/index.php/archives/242</guid>
		<description><![CDATA[
多次被问及对于图书馆自动化系统未来发展方向的看法，心中总有一种企图，很狂妄的、不知深浅的企图，所以一直没敢说出来。心中总想，应该是图林中老一辈无产阶级革命家例如曾民族、徐如镜、张琪玉等先生，抑或新生代中坚力量张晓林、吴建中等同志提出，或者哪怕是海外学子曾蕾、秦健等来点这把火，甚至编目精灵说这话也比我有分量。本人实在没有这个资历，从理论、实践与技术各个角度来看都显得底气不足。然而等了这许多年，朋友们不断追问，看看好像没人愿意捅破这层窗户纸，俺就猫叫一声吧，等着被大家的口水淹没，就算成了烈士，也不枉来人世走一遭！
这句话就是：哪一天图书馆自动化系统挣脱了MARC的束缚，就称得上是&#8221;下一代&#8221;了。用张甲曾经的同事，美国图书馆界的名嘴Roy Tennant的话说，就是&#8221;MARC必须去死 (MARC must die)&#8221; (四年前他就说了这句话！这里还有一篇&#8221;谋杀MARC&#8220;)。
想一想现在谁最把MARC当回事？实际上一个也没有。有先生把MARC看成我们专业的核心竞争力，那是担心剪了辫子革命无法成功，因而不敢剪辫子。谁不清楚眼下还有多少信息管理学院教授这门课？还有多少图书馆完全依靠自己编目数据？
抛弃MARC最大的阻力应该来自图书馆所拥有的书目数据，以及业已装机的、成千上万的图书馆自动化系统。书目系统可能是人类知识财富中最大的遗留系统，在Google、Yahoo！们计划把所有流传下来的图书都数字化时，这个依附于图书的遗留系统还会成为问题吗？软件开发商们可能更多的以《失落的世界》中科学家看到恐龙的眼神向MARC致敬。MARC已经成为一种裹小脚一般的习俗，对数字图书馆来说是一种束缚，甚至灾难。
&#8220;王小石&#8221;在网络图苑中发帖说弄不懂为什么数字图书馆非要转换MARC数据，业界大家似乎讳莫如深，其实说出来也没什么丢人的，实在是因为数字图书馆玩不转这样一种格式。你想想，伴随磁带格式而生的MARC标准，还有哪个行业有如此史前怪物？看到Lib2.0的许多应用了吗？那些以OPAC开刀的例子无不让我们欢呼雀跃，啧啧称奇（看看北卡州立大学NCSU图书馆的例子。这里 张甲有介绍(pdf)，把MARC数据彻底地转化为XML）。想想亚马逊是如何处理书目数据的？想象出版行业为什么提出PRISM元数据格式？OCLC近年来对OWC做了哪些动作(frbrizing)？LOC又发生了哪些激烈的争吵？根源无一不在MARC。
我们行业最大的财富，正在成为我们行业最大的绊脚石。然而事情是可以转化的。以书目数据的处理为核心的图书馆自动化系统，也是数字图书馆集成系统的核心，而不是可以并行的系统，这一点得到越来越多的图书馆软件开发商的认可。于是问题就转化为：数字图书馆集成系统的成败，与能不能玩得转书目数据直接有关。元数据格式都是相通的，但是只是在相通的体系架构中的相通是无缝的、最优的。书目系统的功能需求已经成熟得不得了、也明白得不得了，图书馆员和读者需要的是功能而不是内部数据，不管你葫芦里卖什么药，只要能治病，就能得到认可。实际上我不知道现在SirsiDynix、Endeavor、ExLibris、Innovative等ILS系统中还有多少&#8221;纯MARC&#8221;，MARC只是一个临时拼凑出来的影子（虚拟视图）罢了，其作用与Blyberg做的虚拟书目卡片一样，可以让我们的老图书馆员们聊以自慰吧。

（在一个纪念日里写这篇博文纯属巧合。也算一种纪念吧。）
update：编目精灵 MARC、MARC，为什么不死？

	Tags: MARC, 专业评论, 数字图书馆

	Related posts
	
	让MARC安乐死 (0)
	也谈如何让MARC安乐死 (0)


]]></description>
			<content:encoded><![CDATA[<abbr class="unapi-id" title="http://www.kevenlw.name/?p=242"><!-- &nbsp; --></abbr>
<p>多次被问及对于图书馆自动化系统未来发展方向的看法，心中总有一种企图，很狂妄的、不知深浅的企图，所以一直没敢说出来。心中总想，应该是图林中老一辈无产阶级革命家例如曾民族、徐如镜、张琪玉等先生，抑或新生代中坚力量张晓林、<a href="http://wujianzhong.bokee.com/">吴建中</a>等同志提出，或者哪怕是海外学子曾蕾、秦健等来点这把火，甚至<a href="http://catwizard.bokee.com/">编目精灵</a>说这话也比我有分量。本人实在没有这个资历，从理论、实践与技术各个角度来看都显得底气不足。然而等了这许多年，朋友们不断追问，看看好像没人愿意捅破这层窗户纸，俺就猫叫一声吧，等着被大家的口水淹没，就算成了烈士，也不枉来人世走一遭！</p>
<p>这句话就是：哪一天图书馆自动化系统挣脱了MARC的束缚，就称得上是&#8221;下一代&#8221;了。用张甲曾经的同事，美国图书馆界的名嘴<a href="http://roytennant.com.nyud.net:8090/">Roy Tennant</a>的话说，就是&#8221;MARC必须去死 (<a href="http://www.libraryjournal.com/article/CA250046.html">MARC must die</a>)&#8221; (四年前他就说了这句话！这里还有一篇&#8221;<a href="http://kcoyle.blogspot.com/2006/09/murdering-marc.html">谋杀MARC</a>&#8220;)。</p>
<p>想一想现在谁最把MARC当回事？实际上一个也没有。有先生把MARC看成我们专业的核心竞争力，那是担心剪了辫子革命无法成功，因而不敢剪辫子。谁不清楚眼下还有多少信息管理学院教授这门课？还有多少图书馆完全依靠自己编目数据？</p>
<p>抛弃MARC最大的阻力应该来自图书馆所拥有的书目数据，以及业已装机的、成千上万的图书馆自动化系统。书目系统可能是人类知识财富中最大的遗留系统，在Google、Yahoo！们计划把所有流传下来的图书都数字化时，这个依附于图书的遗留系统还会成为问题吗？软件开发商们可能更多的以《失落的世界》中科学家看到恐龙的眼神向MARC致敬。MARC已经成为一种裹小脚一般的习俗，对数字图书馆来说是一种束缚，甚至灾难。</p>
<p>&#8220;王小石&#8221;在网络图苑中<a href="http://210.34.4.17/tiki-view_blog_post.php?blogId=24&amp;postId=355">发帖</a>说弄不懂为什么数字图书馆非要转换MARC数据，业界大家似乎讳莫如深，其实说出来也没什么丢人的，实在是因为数字图书馆玩不转这样一种格式。你想想，伴随磁带格式而生的MARC标准，还有哪个行业有如此史前怪物？看到Lib2.0的许多应用了吗？那些以OPAC开刀的例子无不让我们欢呼雀跃，啧啧称奇（看看北卡州立大学<a href="http://www.lib.ncsu.edu/catalog/">NCSU</a><a href="http://www.lib.ncsu.edu/catalog/">图书馆</a>的例子。<a href="http://elib.lib.tsinghua.edu.cn:8080/meeting/ppt/zhangjia2.pdf">这里</a> 张甲有介绍(pdf)，把MARC数据彻底地转化为XML）。想想<a href="http://www.amazon.com/">亚马逊</a>是如何处理书目数据的？想象出版行业为什么提出<a href="http://www.prismstandard.org/">PRISM</a><a href="http://www.prismstandard.org/">元数据格式</a>？<a href="http://www.oclc.org/">OCLC</a>近年来对<a href="http://www.worldcat.org/">OWC</a>做了哪些动作(frbrizing)？<a href="http://www.loc.gov/marc/">LOC</a>又发生了哪些激烈的争吵？根源无一不在<a href="http://www.loc.gov/marc/">MARC</a>。</p>
<p>我们行业最大的财富，正在成为我们行业最大的绊脚石。然而事情是可以转化的。以书目数据的处理为核心的图书馆自动化系统，也是数字图书馆集成系统的核心，而不是可以并行的系统，这一点得到越来越多的图书馆软件开发商的认可。于是问题就转化为：数字图书馆集成系统的成败，与能不能玩得转书目数据直接有关。元数据格式都是相通的，但是只是在相通的体系架构中的相通是无缝的、最优的。书目系统的功能需求已经成熟得不得了、也明白得不得了，图书馆员和读者需要的是功能而不是内部数据，不管你葫芦里卖什么药，只要能治病，就能得到认可。实际上我不知道现在<a href="http://www.sirsidynix.com/index.php">SirsiDynix</a>、<a href="http://www.endinfosys.com/">Endeavor</a>、<a href="http://www.exlibrisgroup.com/">ExLibris</a>、<a href="http://www.iii.com/">Innovative</a>等ILS系统中还有多少&#8221;纯MARC&#8221;，MARC只是一个临时拼凑出来的影子（虚拟视图）罢了，其作用与Blyberg做的<a href="http://www.blyberg.net/2006/01/19/creating-a-virtual-card-catalog/">虚拟书目卡片</a>一样，可以让我们的老图书馆员们聊以自慰吧。</p>
<p><img src="http://static.flickr.com/12/88738517_87c2025ffb_m.jpg" alt="" width="240" height="145" /></p>
<p>（在一个纪念日里写这篇博文纯属巧合。也算一种纪念吧。）</p>
<p>update：编目精灵 <a href="http://catwizard.blogbus.com/logs/2006/09/3324167.html">MARC、MARC，为什么不死？</a></p>

	Tags: <a href="http://www.kevenlw.name/archives/tag/marc" title="MARC" rel="tag nofollow">MARC</a>, <a href="http://www.kevenlw.name/archives/category/%e4%b8%93%e4%b8%9a%e8%af%84%e8%ae%ba" title="专业评论" rel="tag nofollow">专业评论</a>, <a href="http://www.kevenlw.name/archives/category/%e6%95%b0%e5%ad%97%e5%9b%be%e4%b9%a6%e9%a6%86" title="数字图书馆" rel="tag nofollow">数字图书馆</a><br />

	<h4>Related posts</h4>
	<ul class='st-related-posts'>
	<li><a href="http://www.kevenlw.name/archives/359" title="让MARC安乐死 (三月 18, 2007)">让MARC安乐死</a> (0)</li>
	<li><a href="http://www.kevenlw.name/archives/368" title="也谈如何让MARC安乐死 (四月 5, 2007)">也谈如何让MARC安乐死</a> (0)</li>
</ul>

]]></content:encoded>
			<wfw:commentRss>http://www.kevenlw.name/archives/242/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
