３.７ 管理性元数据—保存元数据

３. ７. １　本节中描述的信息是管理性元数据的一部分。它类似于音频文件中 的头文件信息， 并对必要的操作信息进行编码。以这种方式， 计算 机系统通过首先将文件扩展名与特定类型的软件相关联， 并且读取 文件的头文件中的编码信息来识别文件以及如何被使用。此信息也 必须在单独的文件中引用， 以便于管理和帮助后续访问， 因为文件 扩展名是关于文件功能的最大的不明确指标。描述此显性信息的字 段（包括类型和版本） 可以从文件的头文件中自动获取， 并用于 填充元数据管理系统的字段。如果现在或将来的操作系统不包括播 放 .ｗａｖ 文件或读取 .ｘｍｌ 实例的功能， 那么该软件将无法识别文件 扩展名， 并且无法访问文件或确定其类型。通过将此信息显示在元 数据记录中， 我们使未来用户可以使用保存管理数据并解码信息数 据。ＡＥＳ － Ｘ０９８Ｂ （ 标准） 中开发的标准将由音频工程协会 （ＡＥＳ） 发布， 作为ＡＥＳ ５７ 标准《ＡＥＳ 音频元数据标准———用于 保存和恢复音频对象结构》编写了这个内容。

３.７.２　现在已有格式注册表， 但仍在开发中， 这将有助于将文件格式 分类和验证作为预先获取的任务： 在线技术注册表（ ＰＲＯＮＯＭ）， 包括由英国国家档案馆（ＴＮＡ） 维护的文件格式， 可与 另一个ＴＮＡ 工具ＤＲＯＩＤ （数字记录对象标识———可执行文件格 式的自动批量识别和输出元数据） 结合使用。美国哈佛大学的 全球数字格式注册表（ＧＤＦＲ） 项目和ＪＳＴＯＲ／ 哈佛对象验证环 境ＪＨＯＶＥ 系统（ＪＨＯＶＥ 的功能是进行特定格式的数字对象的 识别、验证和鉴定、最初由哈佛大学图书馆和ＪＳＴＯＲ 于２００３ 年开发。） 提供了可比较的服务， 以支持保存元数据编译。关 于文件格式的准确信息是长期成功保存的关键。

３.７.３　最重要的是， 对音频文件保存和迁移的所有方面， 包括所有技 术参数进行了仔细的评估和保存。这包括在其生命周期内保护 音频文件的所有后续措施。尽管此处讨论的大部分元数据可以 在稍后安全填充， 但数据音频文件的创建记录及其内容的任何 更改都必须在事件发生时创建。该历史元数据跟踪音频项目的 完整性， 如果使用ＢＷＦ 格式， 则可将其作为文件的一部分记录 为ＢＥＸＴ 中的编码历史模块。此信息是ＰＲＥＭＩＳ 保存元数据建 议的重要组成部分。经验表明， 电脑能够从数字化过程中产生 大量的技术数据。这可能要在需要保存的元数据中进行解析提取。 ＡｕｄｉｏＭＤ （ｈｔtｐ：／／ｗｗｗ.ｌｏｃ.ｇｏｖ／ｒｒ／ｍｏｐｉｃ／ａｖｐｒｏｔ／ａｕｄｉｏＭＤ＿ｖ８.ｘｓｄ） 提 出了有用的“元素集” 概念， 这是由美国国会图书馆开发的扩 展模式， 而ＡＥＳ ａｕｄｉｏＯｂｊｅｃｔ 的ＸＭＬ 模式正在作为标准进行 编写。

３. ７. ４　如果从传统藏品进行数字化处理的角度来看， 这些元数据模式不仅 用于描述数字文件， 也包括物理原件。需要注意， 避免在元数据中 描述对象时引起歧义： 必要的描述工作有， 其原始表现和后续数字 版本， 这对于能够区分每个实例中描述的内容来说至关重要。 ＰＲＥＭＩＳ 通过将变更顺序与事件相关联来区分变更序列中的各种组 件和通过时间链接生成的元数据。