３.１ 概述

３. １. １　元数据是结构化数据， 它提供信息支持资源的更高效的操作， 如保 存、格式转换、分析、发现和利用。虽然元数据在网络环境中应用 最佳， 但在任何数字存储和保存环境中也必不可少。元数据告诉终 端（人员和计算机程序） 如何理解数据。元数据对处于生命周期 中任何时刻的存档对象， 及任何与该存档对象相关或从中派生的对 象的理解、一致性和成功运行都至关重要。

３. １. ２　把元数据在功能方面视为“关于资源的系统化说明” ［之所以 “系统化” 是因为机器可理解（和人类易于阅读一样）； 之所以 称其为“说明” 是因为包含特定代理人对资源的声明； 之所以是 “资源”， 因为任何可识别的对象都可能具有与之相关联的元数 据］ （Ｄｅｍｐｓｅｙ， ２００５） 将是有帮助的。这种系统化的（或编码 的） 说明（也称为元数据“实例”） 可能非常简单， 单个统一资 源标识符（ＵＲＩ） 在一对尖括号＜ ＞ 中作为容器或包装及命名空 间。通常， 它们也可能会不断扩展并且模块化， 容器内嵌套有容 器， 包装内嵌套有包装， 每个都运行在一系列的命名空间模式 上， 并且在工作流程的不同阶段和较长时间内得到封装。一个人 不可能在某一个阶段中为任何给定的数字对象创建一个确定的、 完整的元数据实例且不再发生任何变化。

３. １. ３　无论随着时间可能创建多少个版本的音频文件， 具有归档状态 的文件的所有重要属性必须保持不变。同样的原则适用于嵌入 对象中的任何元数据（ 见３. １. ４）。然而， 任何对象的数据 （本身） 都可能随着时间的推移而变化： 新信息的发现、意见 和术语发生变化、贡献（ 捐赠） 者死亡、权利过期或重新协 商。因此， 通常建议将音频文件和所有或部分元数据文件分开 保存， 并在它们之间建立适当的链接， 并在产生新信息和新资 源时更新元数据。编辑文件中的元数据虽然烦琐， 而且不适合 大规模藏品， 却具有可能性。因此， 数据嵌入文件及独立数据 管理系统中的程度取决于藏品的大小、特定数据管理系统的复 杂性以及归档人员的能力。

３. １. ４　元数据可与音频文件集成， 实际上也建议将其作为小规模数字 存储系统的解决方案（见７. ４）。由欧洲广播联盟（ ＥＢＵ） 标 准化的广播波形格式（ＢＷＦ） 是这种音频元数据集成的示例， 其允许在. ｗａｖ 文件中存储有限数量的描述性数据（ 见２. ８）。 在文件中存储元数据的一个优点是它避免了丢失元数据和数字 音频之间链接的风险。ＢＷＦ 格式支持获取过程元数据， 并且与 该格式相关的许多工具都可以获取数据并填充广播扩展 （ＢＥＸＴ） 块的适当部分。因此， 元数据可能包括编码历史， 并 能够记录创建数字音频对象的过程， 这在ＢＷＦ 标准中没有明确 定义， 这与保存元数据实施战略（ ＰＲＥＭＩＳ） 中的事件实体亦 有相似之处（见３. ５. ２， ３. ７. ３ 和图１）。当对模拟源进行数字 化时， ＢＥＸＴ 块也可用于存储有关音频内容的定性信息。当从 数字源（如ＤＡＴ 或ＣＤ） 创建数字对象时， ＢＥＸＴ 块可用于记 录编码过程中可能发生的错误。

图１ 澳大利亚国家图书馆使用数据库和自动化系统将盘式磁带 原件转换为ＢＷＦ 的编码历史实例

３.１.５ 美国国会图书馆一直致力于规范和扩大ＢＷＦ 文件中的各种数据块： 《数字音频文件和对象的嵌入式元数据和标识符： ＷＡＶＥ 和ＢＷＦ 文件的建议》（Ｅｍｂｅｄｄｅｄ Ｍｅｔａｄａｔａ ａｎｄ Ｉｄｅｎｔｉｆｉｅｒｓ ｆｏｒ Ｄｉｇｉｔａｌ Ａｕｄｉｏ Ｆｉｌｅｓ ａｎｄ Ｏｂｊｅｃｔｓ： Ｒｅｃｏｍｍｅｎｄａｔｉｏｎｓ ｆｏｒ ＷＡＶＥ ａｎｄ ＢＷＦ Ｆｉｌｅｓ Ｔｏｄａｙ）。 以下是其最新草案征求意见稿的链接地址， ｈｔｔｐ：／／ｈｏｍｅ.ｃｏｍｃａｓｔ.ｎｅｔ／～ｃｆｌｅ／ＡＶｄｏｃｓ／Ｅｍｂｅｄ＿Ａｕｄｉｏ＿０８１０３１.ｄｏｃ。ＡＥＳ－Ｘ０９８Ｃ 标准 是记录过程和数字来源元数据的另一项成果。

３.１.６ 分别维护元数据和内容也有许多优点， 例如可以通过元数据编 码和传输标准（ＭＥＴＳ， 参见３.８） 的框架标准来实现。在独立 的元数据存储库中更新、维护和更正元数据要简单得多。扩展 元数据字段以便涵盖新的需求或信息只能在那些可扩展、独立 的系统中进行， 而且要创建各种新的信息共享方式， 也需要独 立的存储库来创建可被这些系统使用的元数据。对于大规模的 藏品来说， 仅在ＢＷＦ 文件的头文件中维护元数据， 这种负担同 样将无法被承受。虽然可替代的音频数据片段可以多次复用数 据描述（元数据）， 但是ＭＰＥＧ － ７１ 要求分离音频内容和描述性 元数据。

３.１.７ 当然， 可以用更为详尽的元数据来包装ＢＷＦ 文件， 如果保存在 ＢＷＦ 之中的信息是固定和有限的， 那么这种方法兼具（上述） 两种方法的优点。集成的另一个例子是需要在访问文件中设置标 签元数据， 以便用户可以验证下载对象或以流媒体的形式传输的 对象， 即查找和选择对象。ＩＤ３ 是ＭＰ３ 文件中使用的标签， 描述 了大多数播放器容易解释的内容信息， 是允许描述性元数据的最 小集合。而ＭＥＴＳ 本身已被视为可用于将元数据和内容一起打包 的容器， 尽管这些文档的潜在大小表明这可能不是一个可行的 选择。

３.１.８ 目前几所大学正与ＳＵＮ Ｍｉｃｒｏｓｙｓｔｅｍｓ、Ｈｅｗｌｅｔｔ － Ｐａｃｋａｒｄ ［ （惠普 公司（ＨＰ）］ 和ＩＢＭ 等主要行业供应商合作， 研究将元数据从 内容中分离出来的一般性解决方案（如果内容包含某些元数据， 可能会有冗余）。秉承的理念是将一个（数据） 资源的表示始终 存储为两个捆绑文件： 一个包含“内容（ｃｏｎｔｅｎｔｓ）”， 另一个包 括与该内容所关联的“元数据（ｍｅｔａｄａｔａ）”。第二个文件包括以 下几个方面。

３.１.８.１ 基于所有涉及的基本原理的标识符列表。实际上它是一系列有关 统一资源名称（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｎａｍｅ， ＵＲＮ） 和资源的本地表 示（ＵＲＬ） 的“别名”。

３.１.８.２ 技术性元数据（每个样本的位数／ 采样率； 准确的格式定义； 可 能还有相关的本体）。

３.１.８.３ 事实元数据（ＧＰＳ 坐标／ 世界时间码／ 设备序列号／ 操作员／ ……）。

３.１.８.４ 语义元数据。

３.１.９ 总而言之， 大多数系统会采用一种实用的方法， 允许将元数据嵌 入文件中或将元数据单独维护， 并同时确定优先级（即哪些是 信息的主要来源） 和协议（维护数据的规则） 以确保资源的完 整性。