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

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

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

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

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

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

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

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

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

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

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

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

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

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

３. ２. １ 本章的余下部分假设在大多数情况下， 音频文件和元数据文件是 被分别创建和管理的。在这种情况下， 元数据的产生涉及传 输———通过网络低成本高效地移动信息、材料和服务。然而， 小 规模馆藏或在早期发展阶段的档案馆， 可能会发现在ＢＷＦ 中直 接嵌入元数据并选择性地填充后文描述的信息的一个子集， 具有 一定的优势。如果充分理解了本章讨论的标准和方案并遵照执 行， 那么这种方法是可持续的， 并且可以迁移到后文所述的完全 实施的系统中。尽管档案馆可以决定在文件的头文件（数据）中嵌入所有或某些元数据， 或只单独管理某些数据， 但本章中的 内容仍会对工作实务产生帮助（见第７ 章“小规模数字存储系 统的解决方案”）。

３. ２. ２ 直到最近， 录音信息的制作者或者在编目小组工作， 或者在技术 团队工作， 他们的产出很少融合。网络空间模糊了传统分工。不 用说， 在成功的工作流中实现传输也需要了解网络空间运作和连 接的专业人员的参与。因此， 元数据的产生涉及音频技术人员、信息技术（ＩＴ） 和其他领域专家之间的紧密合作。它还需要专 注于管理工作， 以确保工作流程的可持续性， 并能适应与生产元 数据相关的快速发展的技术和应用。

３. ２. ３ 元数据就像利息， 会随着时间的推移而增加。如果创建了完整 的、一致的元数据， 则可预测， 该资产将以几乎无限的新方式 来满足各类用户多版本化和数据挖掘的需求。但元数据开发和 管理涉及的资源、知识资本和技术设计问题并非微不足道。例 如， 任何元数据系统的管理者都必须解决的关键问题包括以下 几个方面。

３. ２. ３. １ 确定应用哪个元数据方案或扩展方案， 以更好地满足生产团队、存储库本身和用户的需求。

３. ２. ３. ２ 确定元数据的哪些方面对于预期目标的实现至关重要， 并确定每 种类型元数据的粒度。由于元数据是长期产生的， 因此开发和管 理元数据的成本可能总是需要权衡， 在满足当前需求的同时， 也 需要创建足够多的元数据， 以服务未来， 满足未预料到的需求。

３. ２. ３. ３ 确保正在应用的元数据方案是最新版本。

３. ２. ３. ４ 互操作性是另一个因素。在数字时代， 没有一个档案馆再是孤 岛。为了成功地将内容发送到另一个档案馆或机构， 那么通用的 结构和语法就是必需的。这是ＭＥＴＳ 和ＢＷＦ 背后的原则。

３. ２. ４ 在责任共享的网络环境中， 成功管理数据文件预计有一定的复 杂性。 如果我们继续采用旧的工作方式， 像图书馆和档案馆早期的 电脑一样———在出现Ｗｅｂ 和ＸＭＬ 之前， 坚持这种复杂性将是 无法控制的。正如理查德·费曼（Ｒｉｃｈａｒｄ Ｆｅｙｎｍａｎ） 的物理 学原则所述， “不能指望旧的设计一劳永逸”。因此， （网络 环境元数据管理） 需要一套新的系统要求和有关文化变革的 措施。这反过来也会促进适用于音视频档案馆的元数据基础
架构的发展。

３. ３. １　　不需要“唱片分类学” 那样的元数据标准： 在某一特定领域的解 决方案将会是不可行的约束条件（限制）。现阶段需要一个可以和 其他领域共享核心组件的元数据基础架构， 每个核心组件都允许 适用于任何特定音视频档案工作的局部变量（如采取扩展模式的 形式）。以下是有助于定义结构和功能需求的一些基本特征。

３. ３. １. １　多功能性 （Ｖｅｒｓａｔｉｌｉｔｙ） 对于元数据而言， 系统必须能够从描述各种对象的各种来源中获 取、合并、索引、增强， 以及向用户呈现元数据信息。还必须能 够定义逻辑和物理结构， 其中逻辑结构表示知识实体， 例如馆藏 和作品， 而物理结构表示构成数字化对象来源的物理介质（或 载体）。系统不得与一个特定的元数据模式相关联（绑定）： 必 须在不影响互操作性的前提下， 将元数据模式和适合档案特殊需 求的应用程序配置文件（见３. ９. ８） 混合使用。建立一个可以适 应这种多样性的系统是相关人员面临的挑战， 而且同时要求不会 对入门级用户产生不必要的复杂性， 也不会为那些需要更多操作 空间的人避免更复杂的活动。

３. ３. １. ２　可扩展性 （Ｅｘｔｅｎｓｉｂｉｌｉｔｙ） 能够容纳广泛的对象、文件类型（如图像和文本文件） 和商业 实体（如用户认证、使用许可、获取策略等）。允许扩展、开发 和应用或（全部） 忽略， 而不会破坏整体， 换句话说， 适合实 验———实施元数据解决方案———仍然是不成熟的科学。

３. ３. １. ３　可持续性 （Ｓｕｓｔａｉｎａｂｉｌｉｔｙ） 能够进行迁移， 在维护方面具有成本效益、可利用、可随时间相 关和相适应。

３. ３. １. ４　模块化 （Ｍｏｄｕｌａｒｉｔｙ） 用于创建或获取、合并、索引、导出元数据的系统， 本质上应该 是模块化的， 以便可以用不同的组件替换执行特定功能的组件， 而不会破坏整体。

３. ３. １. ５　粒度 （Ｇｒａｎｕｌａｒｉｔｙ） 元数据必须具有足够的粒度来支持所有预期用途。元数据很容易 粒度不足， 但元数据粒度太细以致不能支持某个特定目的的情况 也极少见。①

３. ３. １. ６　流动性 （Ｌｉｑｕｉｄｉｔｙ） 一次写入， 多次使用。流动性将使数字对象和这些对象的表示随 着时间的推移而自我记录， 元数据将在许多网络空间中更加努力 地工作， 并为原始的时间和金钱的投资提供高回报。

３. ３. １. ７　开放性 （Ｏｐｅｎｎｅｓｓ） 和透明度 （ｔｒａｎｓｐａｒｅｎｃｙ） 支持与其他系统的互操作性。为了促进诸如可扩展性的要求， 所 引入的标准、协议和软件应尽可能公开和透明。

３. ３. １. ８　关系（层次／ 序列／ 来源） 必须表达亲子关系， 正确排序———例如戏剧表演的场景———派生 关系。对于数字化项目， 可以支持原始载体及其信息内容文件的 准确映射和实例化。这有助于确保归档对象的真实性 （Ｔｅｎｎａｎｔ，２００４）。

３. ３. ２　　这种多样性的方法本身就是一种开放的形式。如果选择了一个开 放的万维网联盟 （Ｗ３Ｃ ） 标准， 如可扩展标记语言 （ＸＭＬ） ———这是一种已广泛采用的标记语言———那么这不会阻 止特定的实现方式包括诸如“媒体交换格式 （ＭＸＦ）” 和微软  （Ｍｉｃｒｏｓｏｆｔ） 的高级制作格式 （ＡＡＦ） 间的格式变换。

３. ３. ３　　尽管ＭＸＦ 是一个开放标准， 但实际上将元数据包含在ＭＸＦ 中通 常会以其专有的方式进行。 ＭＸＦ 对于广播行业更有优势， 因为 它可以以专业的流媒体形式传输内容， 而其他包装仅支持下载完 整的文件。使用ＭＸＦ 打包内容和元数据只能在以开放元数据格 式替换以专有格式表示的元数据后再进行归档。

３. ３. ４　　关于ＸＭＬ 的资料已经写了很多， 很容易将其视为灵丹妙药。 ＸＭＬ 本身不是一个解决方案， 而是一种关于内容如何组织和 重复使用的方式， 其巨大的功能通过与一系列相关工具和技 术的结合而得到广泛的应用， 这些工具和技术是为了经济上 的重复使用和再利用而继续开发数据。因此， ＸＭＬ 已经成为 表示互联网上描述资源的元数据的事实标准。由于开发了许 多开源的和商业的ＸＭＬ 编辑工具 （见３. ６. ２）， 可将ＸＭＬ 的 十年发展与现在的处理手段相匹配。

３. ３. ５　　尽管本章对本指南中使用的特定元数据格式进行了介绍， 或 者将来也可能会有更有用的特定元数据格式， 但这并不意味 它们都是规范性的。通过回顾３. ３. １ 中的关键因素， 并维护 清晰、充分、分散的所有技术细节的记录， 数据创建和政策 变更， 包括日期和责任， 未来迁移和翻译， 都不需要对基础 架构进行实质性的更改。一个健壮的元数据基础架构应该能 够通过创建或应用特定于该格式的工具来适应新的元数据格 式， 例如采用元数据转换 （ｃｒｏｓｓｗａｌｋｓ） 或以有效和准确的方 式将元数据从一个编码方案转换到另一个编码方案的算法来 适应新的元数据格式。已经存在许多种元数据转换格式， 如 ＭＡＲＣ， ＭＯＤＳ， ＭＰＥＧ － ７ 路径， ＳＭＰＴＥ 和都柏林核心元数 据 （Ｄｕｂｌｉｎ Ｃｏｒｅ） 格式， 等等。除了使用元数据转换将元数 据从一种格式移动到另一种格式之外， 它们还可以将两个或 多个不同的元数据格式合并到第三个或一组可搜索的索引中。 给定适当的容器／ 传输格式 （如 ＭＥＴＳ）， 实际上可以容纳诸 如 ＭＡＲＣ-ＸＭＬ， Ｄｕｂｌｉｎ Ｃｏｒｅ， ＭＯＤＳ， ＳＭＰＴＥ 之类的元数据 格式。此外， 这种开放的基础架构将使档案馆能够部分或全 部地从其遗留系统中吸收目录著录， 同时基于它们提供新的 服务， 例如使可用的元数据收割———参见开放档案元数据收 割协议 （ＯＡＩ － ＰＭＨ）②。

---

① 信息粒度（ｇｒａｎｕｌａｒｉｔｙ ｏｆ ｉｎｆｏｒｍａｔｉｏｎ） 有粗细之分。

② 开放档案元数据收割协议（Ｏｐｅｎ Ａｒｃｈｉｖｅｓ Ｉｎｉｔｉａｔｉｖｅ Ｐｒｏｔｏｃｏｌ ｆｏｒ Ｍｅｔａｄａｔａ Ｈａｒｖｅｓｔｉｎｇ， 简称“ＯＡＩ 协议”） 是一种独立于应用的、能够提高Ｗｅｂ 上资源共享范围和能力的互操作协议标准。

３. ４. １　　满足这些顶级要求后， 可靠的元数据设计将从信息模型或本体中 形成。这取决于要进行操作的数量， 几个本体可能是相关的。其 中国际文献工作委员会的概念参考模型 （ＣＩＤＯＣ ＣＲＭ） （ｈｔｔｐ：／／ｃｉｄｏｃ.ｉｃｓ.ｆｏｒｔｈ.ｇｒ） 被推荐给文化遗产部门（博物馆、图 书馆和档案馆）； 书目记录的功能要求（ ＦＲＢＲ， ｈｔｔｐ：／／ｗｗｗ.ｌｏｃ.ｇｏｖ／ｃｄｓ／ＦＲＢＲ. ｈｔｍｌ） 将适用于主要由录音表演的音乐 或文学作品构成的档案， 其影响力与资源说明和访问 （ＲＯＡ） 和都柏林核心元数据倡议（ＤＣＭＩ） 密切相关。如果权限管理至 关重要， 上下文本体架构 （ＣＯＡ， ｈｔｔｐ：／／ｗｗｗ.rｉｇｈｔｓｃｏｍ.ｃｏｍ／Ｐｏｒｔａｌｓ／０／Ｆｏｍａｌ＿ｔｏｌｏｇｙ＿ｆｏr＿Ｍｅｄｉａ＿Ｒｉｇｈｔs＿Ｔａｎｓａｃｔｉｏｎｓ. ｐｄｆ） 将适用于目标， 运动图像专家组权限管理标准 ＭＰＥＧ-２１ 也 是如此。资源描述框架 （ＲＤＦ， ｈｔｔｐ：／／ｗｗｗ.ｗ３.ｏｒｇ／ＲＤＦ） 是一个通用且相对轻量级（ 简单） 的规范， 应该是一个组 件， 特别是在从存档库创建Ｗｅｂ 资源的过程中： 这反过来允 许流行的应用程序例如简易信息聚合 （ＲＳＳ） 进行信息馈送 （联合）。可以在使用Ｗｅｂ 本体语言 （ＯＷＬ） 创建的本体的 新兴“家族” 中找到改进元数据的机器处理和解释的其他合 适的候选者。在 ＯＷＬ 中表达本体定义和本体阅读可以很容易 地使用 “Ｐｒｏｔéｇé” （斯坦福大学的开放工具， ｈｔｔｐ：／／ｐｒｏｔｅｇｅ.ｓｔａｎｆｏｒｄ.ｅｄｕ）。 ＯＷＬ 可以从简单的术语定义到在复杂的面向 对象进行建模。

３. ５. １　　元数据元素集合在下面的整体设计中。通常分为三类或三组元数 据进行描述， 如下：

３. ５. １. １　描述性元数据（Ｄｅｓｃｒｉｐｔｉｖｅ Ｍｅｔａｄａｔａ）
用于发现和识别对象。

３. ５. １. ２　结构性元数据（Ｓｔｒｕｃｔｕｒａｌ Ｍｅｔａｄａｔａ）
用于显示和浏览用户的特定对象， 并包括关于该对象的内 部组织的信息， 例如事件的预期顺序以及与其他对象间的 关系， 例如图像或访问脚本。

３. ５. １. ３　管理性元数据（Ａｄｍｉｎｉｓｔｒａｔｉｖｅ Ｍｅｔａｄａｔａ）
代表对象的管理信息（例如授权元数据本身的命名空间）， 创建 或修改对象的日期， 技术性元数据（其验证的内容文件格式、 持续时间、采样率等）， 权利和许可信息。该类别包括对保存至 关重要的数据。

３. ５. ２　　所有三类元数据： 不管操作被如何支持， 描述性、结构性和管理 性都必须存在， 尽管在任何文件或实例中可能存在不同的数据子 集。因此， 如果元数据支持保存“支持和记录数字保存过程的 信息（ＰＲＥＭＩＳ）”， 那么它将丰富关于对象来源的、其真实性和 对其执行的操作的数据。尽管阐述和强调描述性、结构性和许可 数据将更加重要， 但如果它支持发现某些部分或全部的保存元数 据对于最终用户（即作为真实性的保证人） 将是有用的， 那么 将提供使原始元数据转换为直观的显示或准备好由网络外部用户 进行收割或交互。不用说， 无法找到的项目既不能被保存也不能 被倾听， 因此对于这些操作， 元数据越具包容性将越好。

３. ５. ３　　这三组元数据中的每一组都可以单独编制： 作为大规模数字化的副 产品的管理性（技术） 元数据； 从遗留数据库导出的描述性元数 据； 作为清关的权利元数据已完成， 并且许可证已签发。然而， 这 些各种编译的结果需要汇集在一起， 并保存在单个元数据实例或一 组链接文件， 及其与保存有关的相关语句中。将所有这些元数据片 段与模式或文档类型定义（ＤＴＤ） 相关联将是至关重要的， 否则元 数据将仅保留为“二进制大型对象（ＢＬＯＢ）”。而数据的积累， 对 于人类来说是清晰可辨的， 但对于机器来说却是难以理解的。

３. ６. １　　音频信号的编码方式与ＷＡＶ 文件相同， 它具有一个已发布的规 范， 元素集将需要编码： ＸＭＬ， 建议（可能） 与上述的ＲＤＦ 结 合。该规范将在任何元数据实例＜？ ｘｍｌ ｖｅｒｓｉｏｎ ＝ Ｍ１. ０Ｍ ｅｎｃｏｄｉｎｇ ＝ ＭＵＴＦ －８Ｍ？ ＞ 的第一行中声明。这本身就提供了 很少的智能支持： 就像告诉听众， 他们正在阅读的ＣＤ 小册 子的页面是由纸制成的， 将以某种方式进行。下一步将提供 关于在文件的其余部分中遇到的数据的可预测模式和语义的 情报（请记住， 机器以及人员）。元数据文件的头文件的其 余部分通常由设计调用的其他标准和模式（通常称为“扩展 模式”） 的命名空间序列组成。

图２　在英国图书馆 ＭＥＴＳ 配置文件中使用的一些用于录音的命名空间

３. ６. ２　　在ＸＭＬ 中， 这种“智能” 规范被称为ＸＭＬ 模式， 属于ＤＴＤ 的 继承者。考虑到编译的相对容易程度， ＤＴＤ 仍然是常见的。该 模式将驻留在扩展名为. ｘｓｄ （ＸＭＬ Ｓｃｈｅｍａ Ｄｅｆｉｎｉｔｉｏｎ） 的文件 中， 并将具有其自己的命名空间， 其他操作与实现可以引用。模 式需要专业知识来编译。幸运的是， 开放源代码工具可用于使 计算机从格式良好的ＸＭＬ 文件中推断出其模式。工具也可用于将 ＸＭＬ 转换为其他格式， 例如 .ｐｄｆ 或 .ｒｔｆ （Ｗｏｒｄ） 文档转换为ＸＭＬ。 该模式还可以包含用于将数据显示为ＸＳＬＴ 文件的理想化装置。描述 性元数据的架构（和命名空间） 在“３. ９ 描述性元数据———都柏林 核心（ＤＣ） 元数据应用程序概要” 中有更详细的介绍。

３. ６. ３　为了总结上述关系， ＸＭＬ 模式或ＤＴＤ 格式描述了以ＸＭＬ 编码文件 格式标记文本内容的ＸＭＬ 结构。文件（或实例） 将包含一个或多 个表示扩展程序模式的命名空间， 进一步限定要部署的ＸＭＬ 结构。

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

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

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

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

３. ８.１　　　基于时间的媒体通常是多媒体格式的， 而且是复杂的。现场录 音可能由一系列事件（歌曲、舞蹈、仪式） 伴随着图像和现 场笔记组成。一个冗长的口述历史访谈占据多个 . ｗａｖ 档案， 可能伴有演讲者的照片和书面记录或语言分析。结构性元数据 提供了有关外部和内部关系的所有相关文件和情报的清单， 包 括优先顺序， 例如歌剧录音的行为和场景。 ＭＥＴＳ （元数据编 码和传输标准， 当前版本为１.７） 的结构图 （ｓｔｒｕｃｔＭａｐ） 和文 件组 （ｆｉｌｅＧｒｐ）， 在视听环境中需具有近期成功应用且经过良 好检验的记录 （见图３）。

 

图３　ＭＥＴＳ 实例的组件和它们之间的一组可能的关系

３.８.２　　　ＭＥＴＳ 实例的组件有以下几个方面。

３.８.２.１　　头文件描述了ＭＥＴＳ 对象本身， 比如谁创建了这个对象， 在何 时， 为了什么目的。标题头文件信息应支持ＭＥＴＳ 文件的 管理。

３.８.２.２　　描述性元数据部分包含描述性的、由数字对象表示的信息资源 并使其能够被发现的信息。

３.８.２.３　　结构图由独特的叶片和细节来表示， 将对象的数字文件命令为 可浏览的层次结构。

３.８.２.４　　内容文件部分， 见图１ ～ 图５， 声明了数字文件的构成对象。 文件可能被嵌入对象中或被引用。

３.８.２.５　　管理性元数据部分， 包含在内容文件部分中声明的数字文件 信息。

３.８.２.５.１　技术元数据， 即说明文件的技术特性。

３.８.２.５.２　来源元数据， 即说明捕获的来源（例如， 直接捕 获或以４ｘ５ 透明度重新格式化）。①

３.８.２.５.３　数字起源元数据， 即说明文件自诞生以来的更改 经历。

３.８.２.５.４　权利（权限） 元数据， 说明合法访问的条件。

３.８.２.６　　技术元数据、来源元数据和数字起源元数据包含的与数字保存 有关的信息。

３.８.２.７　　鉴于完整性考虑， 行为部分未在图２ 中显示。即将可执行文件 与ＭＥＴＳ 对象相关联。例如， ＭＥＴＳ 对象可能依赖于某段代码 进行实例化以供查看， 并且行为部分可以引用该代码。

３.８.３　　　结构性元数据可能需要代表的其他业务对象。

３.８.３.１　　用户信息（认证）。

３.８.３.２　　权利和许可证（如何使用对象）。

３.８.３.３　　策略（归档对象如何选择）。

３.８.３.４　　服务（复印和权限清除）。

３.８.３.５　　组织（合作、利益相关者及资金来源）。

３.８.４　　　这些可以由引用到特定地址或ＵＲＬ 的文件表示。可以在人类 读者的元数据中提供解释性注释。

---

① ４ｘ ５ ｔｒａｎｓｐａｒｅｎｃｙ ｐｈｏｔｏｇｒａｐｈ ＦＯＲＭＡＴ： ４ｘ５ Ｃｏｌｏｕｒ Ｔｒａｎｓｐａｒｅｎｃｙ

３.９.１　　　传统文化遗产部门的大部分努力都集中在把描述性元数据作为 传统编目的分支上。然而， 显而易见的是， 在这个领域中有太 多的关注（如描述性标签和受控词汇的局部改进） 以牺牲上 述其他考虑为代价， 这将会导致整体的系统缺陷。图４ 演示了 需要考虑到位的各种相互依赖关系， 而描述性元数据标签只是 播放的所有元素的一个子集。

 

图４　简单的描述性元数据 （Ｄｅｍｐｓｅｙ ＣＬＩＲ／ＤＬＦ， ２００５）

３.９.２　　　互操作性必须是任何元数据策略中的关键组成部分： 由一个专 门团队为某一个档案库独立精心设计的系统将成为生产率低、 成本高且影响最小的方法。其结果是元数据行业将无法发展。 描述性元数据确实是理查德·加布里埃尔 （Ｒｉｃｈａｒｄ Ｇａｂｒｉｅｌ） 的“简单之美” 的经典案例。比较两种程序语言， 一种优雅 而又复杂， 另一种笨拙但简单， 加布里埃尔正确地预测， 更简单 的语言将更快地传播， 结果是， 更多的人会去关心改善那种简单 的语言， 而不是去使用复杂的另一种。都柏林核心 （ＤＣ） 元数据 的广泛采用和成功证明了这一点， 由于其严格的简单性， 最初还 被专业人士视为不太适宜的解决方案。

３.９.３　ＤＣＭＩ 的使命是更容易找到资源， 并通过开发用于跨域发现的 元数据标准来使用互联网， 为元数据集的互操作性定义框架， 进而促进与这些目标一致的联盟或学科特定元数据集进行开 发。资源描述中仅使用了 １５ 个元素方面的词汇， 并经济地为所 有三类元数据提供基础。没有一个元素是强制性的： 所有这些 都是可重复的， 尽管实施者可能在应用程序配置文件中另有说 明 （见 ３.９.８）。“都柏林” 的名字源于１９９５ 年俄亥俄州都柏 林的一个邀请研讨会； “ 核心”， 因为它的元素是广泛和通用 的， 可用于描述广泛的资源。 ＤＣ 已被广泛使用十多年， １５ 个 元素的描述已经在以下标准中得到正式认可： ２００３ 年２ 月的 ＩＳＯ 标准１５８３６ － ２００３ ［ＩＳＯ １５８３６ ｈｔｔｐ：／／ｄｕｂｌｉｎｃｏｒｅ.ｏｒｇ／ｄｏｃｕｍｅｎｔｓ／ｄｃｅｓ／＃ＩＳＯ１５８３６］， ２００７ 年 ５ 月的 ＮＩＳＯ 标准 Ｚ３９.８５－ ２００７ ［ＮＩＳＯ Ｚ３９８５ ｈｔｔｐ：／／ｄｕｂｌｉｎｃｏｒｅ.ｏｒｇ／ｄｏｃｕｍｅｎｔｓ／ｄｃｅｓ／＃ＮＩＳＯＺ３９８５］ 和２００７ 年８ 月的ＩＥＴＦ 标准 ＲＦＣ ５０１３ ［ＲＦＣ ５０１３ ｈｔｔｐ：／／ｄｕｂｌｉｎｃｏｒｅ.ｏｒｇ／ｄｏｃｕｍｅｎｔｓ／ｄｃｅｓ／＃ＲＦＣ５０１３］。

 

ＤＣ 元素	官方定义	视听解释
标题 （Ｔｉｔｌｅ）	给予资源的名称	与记录相关联的主标题
主题 （Ｓｕｂｊｅｃｔ）	资源的主题	主题涵盖范围
描述 （Ｄｅｓｃｒｉｐｔｏｎ）	资源的账户	解释性说明访谈摘要环境或文化背景的描述 内容清单
创造者（Ｃｒｅａｔｏｒ）	主要负责制作资源的 实体	不是录音作品的作者或作曲家， 而是档案的 名称
发布者（Ｐｕｂｌｉｓｈｅｒ）	负责使资源可用的实体	不是已经数字化的原始文档的发布者。通 常， 发布商将与创作者相同
贡献者（ Ｃｏｎｔｒｉｂｕ⁃ ｔｏｒ）	负责为资源做出贡献的 实体	任何命名的人或声源。将需要适当的限定 词， 如角色（例如表演者、录音师）
日期（Ｄａｔｅ）	与资源生命周期中的事 件相关的点或时间段	不是原始的记录或日期， 而是与资源本身有 关的日期
类型（Ｔｙｐｅ）	资源的性质或类型	资源的领域， 而不是音乐的流派。所以是某 种声音而不是爵士乐
格式（Ｆｏｒｍａｔ）	资源的文件格式	物理介质或维度。是文件格式而不是原始的 物理载体
标识符（Ｉｄｅｎｔｉｆｉｅｒ）	给定上下文中对资源的 明确引用	可能是音频文件的ＵＲＩ
源（Ｓｏｕｒｃｅ）	从其导出的描述资源的 相关资源	对从其导出当前资源的引用
语言 (Language)	资源的语言	资源的语言
关系 (Relation)	相关资源	参考相关对象
覆盖 (Coverage)	资源的空间或时间主题， 资源的空间适用性或与 资源相关的管辖权	录音， 例如传统歌曲或方言等文化上的特色
权利 (Rights)	关于在资源中和资源上 持有的权利的信息	关于在资源中和资源上持有的权利的信息

表１　１５ 个ＤＣ 元素的官方定义和对视听的解释

 

３.９.４　ＤＣ 元素已经扩大到包括更多的属性。它们被称为 ＤＣ 术语。一 些附加元素（术语） 对于描述基于时间的媒体将是有用的： 如 资源的创建日期、录制日期和录制生命周期中的任何其他重要 日期。

 

DC 术语	官方定义	视听解释
替代物 （Ａｌｔｅｒｎａｔｉvｅ）	任何形式的标题或用作 资源的正式标题的替 代品	替代标题， 例如翻译的标题， 假名， 通用标 题中元素的替代排序
范围 (Extent)	资源的大小或持续时间	文件大小和持续时间
范围源 (extentOriginal)	资源的物理或数字表现	原始来源记录的大小或持续时间
空间 (Spatial)	资源的知识内容的空间 特征	记录位置， 包括支持地图界面的地形坐标
时间 (Temporal)	资源的知识内容的时间 特征	录制的场合
创建 (Created)	资源的创建日期	录制日期和录制生命周期中的任何其他重要 日期

表２　６ 个经选择的ＤＣ 术语

３.９.５　ＤＣ 的实施者可以根据应用的具体要求， 选择在传统的 ｄｃ： ｖａｒｉａｎｔ （例如ｈｔｔｐ：／／ｐｕｒｌ.ｏｒｇ／ｄｃ／ｅｌｅｍｅｎｔｓ／ｌｌ／ｃｒｅａｔｏｒ） 或新的 ｄｃｔｅｒｍｓ： ｖａｒｉａｎｔ （例如ｈｔｔｐ：／／ｐｕｒｌ.ｏｒｇ／ｄｃ／ｔｅｒｍｓ／ｃｒｅａｔｏｒ） 中使用１５ 个元素。 这取决于应用程序的要求。然而， 随着时间推移， 特别是如果 ＲＤＦ 是元数据策略的一部分， 预期实施者（被 ＤＣＭＩ 鼓励） 使用 语义上更精确的术语： 属性， 因为它们更加完全符合机器可处理元 数据的最佳实践。

３.９.６　即使在这种扩展形式中， 都柏林核心元数据可能缺乏专门的视 听档案所需的细粒度。例如， 贡献者元素通常需要提及贡献者 在录音中的作用， 以避免例如将表演者与作曲家或将演员与剧 作家混淆。美国国会图书馆已经设计了人类代理人的常见角色 （或“相关者”） 清单 （ＭＡＲＣ 相关人员）。这里有两个例子说 明如何实现它们。

作为作曲家 （ＣＭＰ） 和表演者 （ＰＲＦ） 的第一个例子标记了“贝 多芬”。作为演讲者 （ＳＰＫ） 的第二个标签虽然不能确定谁是访问 者， 谁是受访者， 却表明了能够在元数据的什么地方进行传达， 例如在说明或标题。

３.９.７　在这方面， 其他模式可能是优选的， 或者可以被包括进附加扩展模 式（见图２）。例如， 元数据对象著录方案 （ＭＯＤＳ， ｈｔｔｐ：／／ｗｗｗ.ｌｏｃ.ｇｏｖ／ｓｔａｎｄａｒｄｓ／ｍｏｄｓ） 允许更多的粒度和更多的权限文件 的链接， 以反映其按照 ＭＡＲＣ 标准进行的推导。

３.９.８　使用 ＭＥＴＳ 可以允许包含适用于不同目的的多套描述性元数据， 例如都柏林核心元数据集［适用开放档案采集元数据收集协议 （ＯＡＩ － ＰＭＨ）］ 和更复杂的旨在符合其他举措的 ＭＯＤＳ， 特别是 与ＭＡＲＣ 编码系统交换记录。这种融入其他标准方法的能力是 ＭＥＴＳ 的一个优点。

３.９.９　ＤＣ 在都柏林核心元数据倡议的管理下继续发展。一方面， 通过 与ＲＤＦ 等语义网络工具（参见 Ｎｉｌｓｓｏｎ 等， ＤＣＭＩ， ２００８） 维持更 紧密的联系来加强网络资源的价值， 另一方面， 则旨在通过与 ＲＤＡ （ｈｔｔｐ：／／ｗｗｗ.ｃｏｌｌｅｃｔｉｏｎｓｃａｎａｄａ.ｇｃ.ｃａ／ｊｓｃ／ｒｄａ.ｈｔｍｌ） 的正式 联系来提高其与遗产部门的相关性， 该协议将于 ２００９ 年发布。由 于ＲＤＡ 被视为英美资源编目规则的及时继承者， 这一特定发展可 能具有重大战略意义， 对国家和大学图书馆的部分视听档案有所 影响。对于广播档案， 基于 ＤＣＭＩ 的其他发展在撰写本文时值得 留意， 欧洲广播联盟 （ＥＢＵ） 正在完成基于兼容都柏林核心的 ＥＢＵ 核心元数据集的开发。

３.９.１０　归档文件可能希望修改（扩展） 核心元素集。利用一个或多个现 有命名空间模式（例如 ＭＯＤＳ 和／ 或 ＥＥＥ ＬＯＭ 以及 ＤＣ） 的修改 集合被称为应用简档。来自不同命名空间模式的应用程序配置文 件中的所有元素都从其他地方绘制。如果实现者希望创建在其他 地方没有图案化的“新” 元素， 例如在 ＭＡＲＣ 相关器集合（例 如， 非人类代理， 如物种、机器、环境） 中不可用的贡献者角 色， 那么他们必须创建自己的命名空间模式， 负责“声明” 并维 护该模式。

３.９.１１　应用程序配置文件包括管理命名空间及其当前 ＵＲＬ （最好是 ＰＵＲＬ———永久 ＵＲＬ） 的列表。它们在每个元数据实例中被复制， 然后跟随每个数据元素的列表以及允许的值和内容样式。这可能 是指内部或附加规则和受控词汇。例如， 叙词表的名称和流派， 个人名称和科目的权威档案。该配置文件还将为特定元素［如日 期 （ＹＹＹＹ-ＭＭ-ＤＤ） 和地理坐标］ 规定强制性方案， 并且位 置和时间的这种标准化表示将能够使地图和时间线显示支持为非 文本检索设备。

 

术语名称 (Name of Term)	标题 (Title)
术语 (Term URI)	http://purl.org/dc/elements/1.1/title
标签 (Label)	标题 (Title)
定义 (Defined By)	http://dublincore.org/documents/dcmi-terms/
源定义 (Source Definition)	给予资源的名称
ＢＬＡＰ － Ｓ 定义(BLAP-S Definition)	工作或工作组件的标题
源注释 (Source Comments)	通常， 标题将是正式知道来源的名称
ＢＬＡＰ － Ｓ 注释 (BLAP-S Comments)	如果没有可用的标题， 则构造一个源自资源或提供［无标题］的标题。遵循正常的编目实践， 使用“替代” 细化来记录其他 语言的标题。如果数据来自声音档案 (Sound Archive) 的目录，则这将等同于以下层次结构顺序中的以下标题字段之一： ①工 作标题 (Work title), ②项目标题 (Item title), ③收藏标题 (Collection title), ④ 产品标题(Product title), ⑤ 原始种类 (Original species), ⑥ 广播标题 (Broadcast title), ⑦ 简称 (Short title), ⑧出版系列 (Published series), ⑨未出版系列 (Unpublished series)
术语的类型 (Type of term)	元素 (Element)
提炼 (Refines)
提炼于 (Refined by)	替代品 (Alternative)
有编码方案 (Has encoding scheme)
义务 (Obligation)	强制性的 (Mandatory)
事件 (Occurrence)	不可重复的 (Not repeatable)

图５　英国图书馆声音ＤＣ （ＢＬＡＰ-Ｓ） 应用简介的一部分

注： Ｎａｍｅｓｐａｃｅｓ ｕｓｅｄ ｉｎ ｔｈｅ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｆｉｌｅ；
ＤＣＭＩ Ｍｅｔａｄａｔａ Ｔｅｒｍｓ　ｈｔｔｐ：／／ｄｕｂｌｉｎｃｏｒｅ.ｏｒｇ／ｄｏｃｕｍｅｎｔｓ／ｄｃｍｉ-ｔｅｒｍｓ／；
ＲＤＦ ｈｔｔｐ：／／ｗｗｗ.ｗ３.ｏｒｇ／ＲＤＦ／；
ＭＯＤＳ ｅｌｅｍｅｎｔｓ　ｈｔｔｐ：／／ｗｗｗ.ｌｏｃ.ｇｏｖ／ｍｏｄｓ；
ＴＥＬ ｔｅｒｍｓ　ｈｔｔｐ：／／ｗｗｗ.ｔｈｅｅｕｒｏｐｅａｎｌｉｂｒａｒｙ.ｏｒｇ／ｍｅｔａｄａｔａｈａｎｄｂｏｏｋ／ｔｅｌｔｅｒｍｓ.ｈｔｍｌ；
ＢＬ Ｔｅｒｍｓ　ｈｔｔｐ：／／ｌａｂｓ.ｂｌ.ｕｋ／ｍｅｔａｄａｔａ／ｂｌａｐ／ｔｅｒｍｓ.ｈｔｍｌ；
ＭＡＲＣＲＥＬ　ｈｔｔｐ：／／ｗｗｗ.ｌｏｃ.ｇｏｖ／ｌｏｃ.ｔｅｒｍｓ／ｒｅｌａｔｏｒｓ。

３.９.１２　应用程序配置文件包含或编制数据字典（定义数据库基本组 织到其各个字段和字段类型的文件） 或几个数据字典， 可由 单个存档维护或与档案社区同保存有关的ＰＲＥＭＩＳ 数据字典 （ｈｔｔｐ：／／ｗｗｗ.ｌｏｃ.ｇｏｖ／ ｓｔａｎｄａｒｄｓ／ｐｒｅｍｉｓ／ｖ２／ｐｒｅｍｉｓ-２-０.ｐｄｆ， 目前的版本号是２） 维护， 预计将大量使用它的众多 元素作为“语义单位”。保存元数据提供关于出处、保存活 动技术特征的智能， 并有助于验证数字对象的真实性。 ＰＲＥＭＩＳ 工作组于 ２００５ 年 ６ 月发布了其保存元数据的数据字典， 并建议在所有保存库中使用， 不论存档材料的类型和采用的 保存策略为何。

３.９.１３　通过定义应用程序配置文件， 最重要的是通过声明它们， 实现者 可以共享有关其模式的信息， 以便广泛地进行诸如长期保存等普 遍任务方面的协作。

３.１０.１　档案不应该期望从头开始（旧的方式） 自己创建所有的描述性元 数据。事实上， 鉴于资源和元数据之间的内置生命周期关系， 这 样的主张将是不可行的。有几种元数据来源， 特别应该利用描述 性类别来减少成本， 并通过扩展投入手段来提供丰富的资源。主 要有三个来源： 专业、贡献和意图（Ｄｅｍｐｓｅｙ， ２００７） ———它们 可能会相互部署。

３.１０.２　专业来源， 意味着利用对已发布或复制的资料有价值的遗留数据 库， 授权文件和受控词汇的锁定值。它包括行业数据库， 以及归 档目录。这些来源， 特别是归档目录， 是众所周知的不完整的， 不具备复杂的转换程序和复杂协议的互操作。录音广播行业和音 像遗产部门的数据标准与数据库不同。缺少ＡＶ 的普遍解析器， 例如印刷的ＩＳＢＮ， 是一个持续的障碍， 经过几十年的唱片创作 后， 对于什么构成目录记录仍然存在分歧： 是一个单独的轨道， 还是组成一个知识单元轨道序列， 如多段音乐或文学作品？ 是单 个运营商还是一组运营商的轨道总和， 换句话说， 是目录单位的 物理载体吗？ 显然， 选择了更精细定义之一的代理机构将会更容 易将其遗留的数据成功导出到元数据基础架构中。基于Ｚ３９.５０ （信息检索协议， ｈｔｔｐ：／／ｗｗｗ.ｌｏｃ.ｇｏｖ／ｚ３９５０／ａｇｅｎｃｙ） 和ＳＲＷ／ ＳＲＵ （通过标准化ＵＲＬ 进行搜索和检索的协议） 的数据导出和带 宽方法响应将继续提供一定程度的成功， 以及计算机从中央资源 获取元数据的能力。但是， 在共同生产资源的同时， 要更有效地 投入资源， 确定和描述名称、科目、地点、时间和作品。

３.１０.３　贡献来源， 意味着用户生成的内容。近年来的一个主要现象是 出现了许多网站的邀请、汇总和挖掘用户贡献的数据， 并调动 数据进行排名， 推荐和关联资源。其中包括ＹｏｕＴｕｂｅ 和ＬａｓｔＦＭ。这些网站有价值， 它们揭示了人与人之间及人与资源之 间的关系以及资源本身的信息。图书馆已经开始尝试这些方 法， 通过允许用户增加专业来源的元数据， 可以获得真正的优 势。支持用户贡献和联合的所谓Ｗｅｂ ２.０ 功能正在成为可用 内容管理系统的常见功能。

３.１０.４　意图来源， 是指收集关于可以增强资源发现和使用的数据。该概 念来自亚马逊商业部门的建议， 例如， 基于总购买选择， 可以使 用类似的算法对资源中的对象进行排序。这种类型的数据已经成 为成功网站的核心因素， 通过数量令人生畏的复杂信息提供有用 的途径（大数据分析）。

３.１１.１　尽管本章已经证明了大量实质性的构造模块（数据字典、模式、 本体和编码） 现在已经就绪， 可以开始满足研究人员对更容易访 问的视听内容的兴趣， 以及维持其持久性的职业夙愿。对于最近 的工作和发展而言， 元数据仍然是一门不成熟的科学。为了实现 更快的进展， 有必要在公共和商业部门之间以及不同类别的视听 档案之间找到共同点， 每个视听档案都在忙于设计自己的工具和 标准。

３.１１.２　通过资源元数据的自动推导， 已经取得了一些成功。我们需要做 更多的工作， 特别是因为现有的手工流程不能很好地扩展。此外， 元数据生产看起来并不可持续， 除非更多的成本被淘汰。“我们 不应该增加成本和复杂性， 这是发展通过多个共同制定渠道来应 对一部分服务环境的必要条件。” （Ｄｅｍｐｓｅｙ， ２００５）

３.１１.３　数据库协调的问题， 即系统理解项目的能力在语义上是相同的， 尽管它们可能以不同的方式来表示， 但仍然是一个公开的问题。 目前正在进行重要的研究来解决这个问题， 但一个广泛适用的一 般解决方案尚未出现。这个问题对于管理开放档案信息系统 （ＯＡＩＳ） 中的持久性也非常重要， 比如， 与简单的ＤＣＭＩ 语句列 表相比， 沃尔夫冈·阿马多伊斯·莫扎特是“安魂曲” （Ｋ ６２６） 的作曲家的语义表达方式和ＦＲＢＲ 模型的表达方式完全不同。在 ＤＣＭＩ “作曲家” 中， “贡献者” 是一个改进， “莫扎特” 是其财 产； 而在ＦＲＢＲ 模型中， “作曲家” 是物理人物与作品之间的关 系。使用受控词表是要确保 Ｗ.Ａ. 莫扎特与莫扎特代表同一 个人。