图书馆在操作系统中实现数字信息长期保存的技术探讨

●张 莉 （宁夏回族自治区图书馆，银川 950001）

图书馆数字信息的长期有效保存一直是图书馆管理的难点，也吸引了越来越多图书馆机构和学者的关注。在该领域中，一系列国际会议iPRES［1］更推动了从理论研究到实践推广的进程，为数字信息的长期保存提供了指导。本文就图书馆数字信息长期保存中存在的问题进行探讨，明确提出解决这些问题的一个可持续的方式，即通过改变操作系统处理的方式，为用户提供一个处理数字内容的接口，以一种普及的文档格式保存文件，以便于文档的长期保存。

鉴于微软拥有最大的操作系统市场份额，国内大多数图书馆都在使用，因此本文以微软Windows操作系统为例进行讨论。

1 图书馆保存数字信息时遇到的问题

当图书馆需要持久和准确地保存大量数字对象时，会遭遇一些特定的问题，这些问题增加了保存的难度。

1.1 文件格式大多不是“保存”格式

通常情况下，文件格式的过期速度非常快，［2］远远超出我们的预期。有些格式在设计时可能就是过时的，比如一个格式的最后版本跟新软件的格式有冲突，新格式可能会不支持旧的格式。如果这些旧格式存放在长期访问的知识库中，甚或这种旧格式的文件正在用户的计算机中被使用，这将产生严重的问题，即随着新软件的运用，旧格式文件将无法使用。如果因为某种原因，用户无法访问源格式的文件，就可能丢失该格式保存的文件。但这并不是说没有可供长期保存使用的格式。例如，对源内容（例如音频、视频、静态图像）就有专门设计的用于长期保存的格式。然而，在这些源格式与相对普及便利的格式之间存有差距。因为，通常这些源格式很少大范围使用。这就是为什么我们更有可能会遇到一个Word 97格式的文件，而不是PDF/A格式的文件（Word格式比PDF格式更加便利）。

1.2 机构有时比用户更重视格式

对于许多用户来说，文件格式只不过是暂时承载特定内容的一个载体，但是对于保存机构而言，有时收集来的文件的格式却有些神圣不可侵犯。因此，大量的理论研究和资源都耗费在确保文件收到时的格式可以能够使用上。

1.3 保留关联背景信息很困难

为了有意义地保护数字对象（例如，保存在Word 97格式的手稿），不仅要了解文件格式，而且也要了解数字对象的数据以及元数据中没有的大量信息。例如作者之类的信息，应当以元数据呈现，而实际上在许多情况下，这种信息嵌入在文件中。在图书馆里，我们可以发现很多旧文档只有很少的关联背景的信息，但它却很重要。

即使可以一直准确地识别数字对象的文件格式，并且可以从文件中提取元数据，但仍然有一些信息是无法在文件的元数据中体现出来的。例如，一张照片的元数据描述了摄影者使用的相机以及照片的拍摄地点，但可能无法显示这个文件是否是原始文件，还是其他文件的复制文件。同样，也无法知道这个文件是否有多个版本，还是就只有这一个版本。对于文档，我们很难知道接收的是草稿，还是最终的版本。给定一个文件夹，其中的文件命名都类似，我们自然不能知道这些文件之间的关系。还有，在许多领域，这样的文档也无法提供相应的背景资料。在许多情况下，获得这些背景信息有助于保存对象，但是一般都很难找到。

1.4 文件格式很难识别

目前，识别文件格式的工具正变得愈加可靠。比如DROID［3］之类的工具，能够很好地识别很大范围内的格式。然而，虽然通过这种软件的功能，我们能总体知道现在文件都使用了什么样的格式，但是，由于消费者使用文件格式的方式以及目前正在使用的文件格式的数量众多，对于一些要求准确识别的并要求基本上进行自动保存的大规模的文件我们通常都不能识别。

1.5 元数据可能存储不一致或不完全

尽管一些程序实际上已在文件格式中存储了元数据，但是，由于各种原因，检索这些数据将会遇到问题。不同的文件格式存储的元数据不同（即使对同一个文件格式的不同实例，不同的软件也有可能会储存不同的元数据）。另外，对于某些文件格式，拥有者未必愿意披露如何存储元数据。这意味着，在许多情况下，即使该文件可以识别，可能也没有办法准确地提取所有可用的元数据。目前有一个新机制是让每个新的文件格式包含所有形式的元数据。但面对众多的格式，以其排列组合以及增长率来看，意味着这根本是一个不具有可持续性的做法。

1.6 识别文件格式需要较长时间

即使文件格式识别及确认的程序的性能是最先进的，但仍然存在瓶颈。例如，澳大利亚图书馆从PANDORA网络档案馆中采集了一大组样本数据，并运用了DROID系统来处理和识别。这些样本数据的文件都相当小（网站的片段），却花了近40天来处理大约17万份文件，这样的效率显然是不可接受的。

2 图书馆数字信息资源的长期保存能力

当我们讨论数字资源的长期保存的解决方案时，通常是聚焦在解决问题的结果方面，由此产生了大量的数字资源长期保存系统，例如基于OAIS模型［4］的成熟系统 Fedora、DSpace、EPrint和开源系统DAITSS。［5］不过，这些解决方案是否能够解决所有问题的根源，还有待验证。另外，单从图书馆等收集机构的技术系统入手，是无法解决长期保存数字资源的所有问题的。有研究者提出，问题的解决需要数字信息长期保存的相关主体，包括数字信息创造者、出版商、保存机构、软硬件开发者、非盈利组织和政府部门等系统合作。

本文着眼于数字信息长期保存问题的一个特别方面，即一个保存机构长时间接收和保存外部来源文件的能力。例如，一个图书馆需要数字保存一份著名作家捐赠的手稿，虽然有许多理论上可行的长期保存数字对象的解决方案，如仿真或迁移，但大部分长期保存的解决方案依赖于该机构的能力。该机构必须具有准确地识别数字对象使用的文件格式并记录这些数字对象的背景含义的能力。本文重点介绍通过改进图书馆操作系统的功能来解决数字信息长期保存问题。这种改进系统不仅是让图书馆等保存机构使用，也可以让终端用户使用。

3 在操作系统上的改进办法

为了长期保存图书馆接收到的文件的数字对象，需要做到以下三点：①文件格式是一直普及的格式；②元数据可以随时提取；③关联的背景信息始终可以提取。

正如前面所述，处理后继的问题是数字信息长期保存时必要的工作，但我们无法试图让工程师解决所有出现的问题。从上面提出的解决方案来看，均需要投入更多的资金和资源到我们已经开拓的领域，如文件标识或元数据提取。不过，至少现在，对于图书馆之类的机构，应该可以预见到，这种方案的实现和支撑有许多的技术障碍。

即使人们不会为了长期读取而预先分类排序他们所得的数据，但通常至少会为了短期的查找和使用而组织自己的文件。例如，许多人都会确保当前使用的文档在本地磁盘上保存，甚至手工做一份不同名字的备份。不过，一旦该文件结束了使用期，人们就会将内容复制到一个CD中，或者全部删掉。总之，如果数字对象包含了用户能够感受到的价值，那么用户还是希望确保它依然可以访问。这就表明，在某一个时间段，上面提到的三点要求在任何类型的文件中都可以体现到。具体来说，当文件正在使用时，最容易找到这些信息。

此外，在许多情况下，当文件正在使用时，用户不仅需要拥有更多关于文件的知识，同时也需要更多关于操作系统的知识。对于用户常用的大多数文件类型，操作系统会通过其内部注册机制来关联相应的应用程序。比如说，用户双击一个.DOC文件，它就会直接在Word中打开并可编辑，而不需要用户首先加载Word程序，然后再从中打开该.DOC文件。尽管这些关联关系是基于一个基础范围的，而且在个体层面上不太可靠（可以将一个DOC文件的扩展名改为PDF），这仍然在理论上是一个潜在的宝贵的资料。但是，此信息只保存在操作系统内。如果这些文件转移到其他介质，比如转移到一张备份CD光盘上，那么在用户的非当前工作环境中使用时，这种信息可能会丢失。

因此，解决问题需要了解文件格式是如何构建的。作为一个自我包含的对象，设计者将其认为最重要的元数据直接嵌入了这个对象。虽然这足以让一般用户利用文件进行工作，但只有少数文件格式详细记录了其保存类型。例如，很难遇到一个文件格式，其中包含该文件的历史事件。对于收集机构，这意味着除非伴随文件有一些人们可读的描述文档，否则这种信息是根本没有存储的。

在收集机构之外，也有很多实际案例表明，文件中存储的元数据并不能充分满足用户的需求。例如，用户可以在一张CD上再次存储他们的文件备份。假设他们可能卸载许多应用，甚至更换一台新计算机，在需要看那张CD的内容之前，他们不再知道存储的文档是什么。有时用户可能还记得他们以前使用的软件，并通过手动重新安装来访问。另外，在某些情况下，内部存储的元数据处理复杂信息时效率不高，即使文件格式中数据非常丰富，如使用的ID3的MP3文件；即使ID3包含了有关文件本身的信息范围非常大，一定程度上还包含一组给定文件的属性，如“专辑”字段等的背景信息，它并没有明确包含单一的文件与其他关联文件的信息。因此，如果用户要建立一个更复杂的歌曲队列，比如一系列的播放列表，这样的信息需要在MP3之外生成、维护和说明。

真正的问题是在文件离开原作者的环境中后如何维持这些信息。例如在闪存设备上，当文件被带到一个新的计算机上时，由于新计算机没有与相应应用的关联关系或者有完全不同的关联关系，文件间的关联将会丢失。因此，使其在单个应用或者多个应用组合上不适用。不过，理论上，操作系统通过文件系统，其实是能够负责这类信息的。微软之前曾以各种题目探讨过这个概念，例如前一阵的WinFS文件系统，［6］是个小型的半公开测试版，而且未被发布。尽管WinFS似乎主要关注如何返回丰富的搜索结果，而不是集中提供背景数据，但它仍可能维护一个终端用户电脑上所有的文件环境，并且在技术上它是朝这个方向发展的。

因此，相比储存标签信息，或分析哪些歌曲属于同一艺术家，文件系统本身可以存储更复杂的信息，例如事件的跟踪以及用户定义或者生成的一组文件之间的关系（例如，同一个图片的重复版本）。

如果我们可以找到有效的方法在用户的操作环境外来传播元数据，并将其和数据记录方法结合，那么收集机构不必进行鉴定或元数据提取，就能直接存档和保存大多数接收的文件。

4 改进方案的优势

从文件系统的发展中可以看到，这种解决方案的实现是有价值的，但这需要我们重新思考该如何对待和设计操作系统上的文件，也需要改变应用程序和操作系统之间的交互。另外，操作系统的这种改进也不是某一个公司单独实施后传播给其他人，而是要在所有操作系统一致性地实现这种改进。

对于保存机构以及供应商和最终用户，这样改进产生的显著好处，远远超过其弊端。

（1）针对我们迁移的文件，一个包含元数据的附属文件（也许类似XML），即使在不支持附加元数据的文件系统上也能够在迁移过程中生成包含元数据的附属文件。如果这是通过标准方式实现的，那么图书馆及其他收集机构就可以方便地利用这一应用来支持其收集文档。

（2） 如果给一个易用的API（应用接口），在用户拥有这个文件的同时，翻译和写作程序可以帮助其检查文件的完整性。这样有助于减少由于接受损坏信息引起的相关问题（比如定期生成文件的校验码）。

（3）当用户无法访问其计算机上的文件时（例如，用户的文件相对于处理软件已经超出有效使用期），文件系统可以通知他们，促使他们将文件的格式转换为可以访问的格式，同时提醒用户是否会丢失一些文件元数据或文件格局。这可能会让某些迁移更为特殊。例如，同一个供应商文件格式之间的迁移可能使信息损失最少，这对于用户来说非常重要，尤其是那些闭源文件。

（4）通过网络检索浏览路径。即当用户正在使用的电脑没有一个可用的文件浏览路径，但他可以通过共享其使用过的其他计算机上的浏览信息找到可用的浏览路径。即使用户的任何一台计算机上浏览路径都不可用，仍然有其他途径可以访问，比如可以通过在线服务，或者购买新软件。

（5）对于用户提交的文件，在提交之前，需要确认提交的文件是否已经使用了最合适的格式。这需要图书馆及其他收集机构制定严格的数字文件提交标准与政策，这将减少图书馆需要处理的未知文件的数量。

（6）图书馆应使用用户将更有可能使用的操作系统。这将降低保持旧文件的复杂性，对陈旧内容的获取更加容易。对于保存大量数字化信息资料的图书馆，这种改进将促进特定供应商提供更有价值的解决方案，其吸引力将远远超过没有提供这种附加信息存储的其他方案。

（7）如果图书馆及其他收集机构能够更加严格地定义其接收的文件格式，并在文件提交之前的任何标准化工作都由内容的作者代为实现，这样可以确保重要数据不会丢失。

5 结语

如何解决旧的文献资料永远都会是一个问题。对现代操作系统的这种改进，不可能解决已接收到的所有材料的问题，也不能完全解决目前一些用户的计算机上的旧文件格式的问题。然而，这种解决方案可以做的是，帮助我们摆脱目前这种困难的局面。事实上，如果对操作系委统不着手做一些改进，以促进实现长期的数字保存，那么我们就将会一直需要处理前面所提到的那些问题。从根本上讲，这并不在于文件格式的识别程序有多好，它们不可能永远保持更新到最新的状态，它们只能以当前标准来处理接收的文档。对图书馆及文献信息收集机构来说，已经投入了大量的资金来处理这类问题，但是如果我们只是不断地进行被动的补救工作，那我们所做的一切最终将是徒劳的。我们应该把工作重点放在真正重要的东西上——确保我们拥有的数据能够长期读取，这样我们可以将我们的精力和资金用于实现能够真正保存这些内容的方案上。

［1］李丹，向菁. 协作与实践：数字资源长期保存工具及方法——2008年数字资源长期保存国际会议（iPRES2008） 综述 ［J］.图书馆理论与实践，2009 （11）： 70－72.

［2］ Pearson D,Webb C.2008,Defining file formatobsoles cence:A risky journey ［J］.The International Journal ofDigitalCuration， 2005， 1（3）： 89 106.

［3］ DROID （DigitalRecordObjectIdentification） ［EB/OL］.［2010－01－20］.http://droid.sourceforge.net/wiki/index.php/Introduction.

［4］吴振新.开源长期保存系统DAITSS研究 ［J/OL］.现代图书情报技术，2009（7/8）： 18－22 http://www.dlib.org/dlib/november04/stanescu/11stanescu.html.

［5］李克征.数字信息长期保存的技术方法分析 ［J］.图书馆工作与研究， 2006（2）： 58－60.

［6］ Rizzo,T.WinFS101:IntroducingtheNewWindowsFileSystem ［J/OL］ .MicrosoftCorporation， 2004 （3） ［2010-01－20］ .http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnwin-fs/html/winfs03112004.asp.