３.９ 描述性元数据—都柏林核心 （ＤＣ） 元数据应用程序概要
３.９.１ 传统文化遗产部门的大部分努力都集中在把描述性元数据作为 传统编目的分支上。然而， 显而易见的是， 在这个领域中有太 多的关注（如描述性标签和受控词汇的局部改进） 以牺牲上 述其他考虑为代价， 这将会导致整体的系统缺陷。图４ 演示了 需要考虑到位的各种相互依赖关系， 而描述性元数据标签只是 播放的所有元素的一个子集。
图４ 简单的描述性元数据 （Ｄｅｍｐｓｅｙ ＣＬＩＲ／ＤＬＦ， ２００５）
３.９.２ 互操作性必须是任何元数据策略中的关键组成部分： 由一个专 门团队为某一个档案库独立精心设计的系统将成为生产率低、 成本高且影响最小的方法。其结果是元数据行业将无法发展。 描述性元数据确实是理查德·加布里埃尔 （Ｒｉｃｈａｒｄ Ｇａｂｒｉｅｌ） 的“简单之美” 的经典案例。比较两种程序语言， 一种优雅 而又复杂， 另一种笨拙但简单， 加布里埃尔正确地预测， 更简单 的语言将更快地传播， 结果是， 更多的人会去关心改善那种简单 的语言， 而不是去使用复杂的另一种。都柏林核心 （ＤＣ） 元数据 的广泛采用和成功证明了这一点， 由于其严格的简单性， 最初还 被专业人士视为不太适宜的解决方案。
３.９.３ ＤＣＭＩ 的使命是更容易找到资源， 并通过开发用于跨域发现的 元数据标准来使用互联网， 为元数据集的互操作性定义框架， 进而促进与这些目标一致的联盟或学科特定元数据集进行开 发。资源描述中仅使用了 １５ 个元素方面的词汇， 并经济地为所 有三类元数据提供基础。没有一个元素是强制性的： 所有这些 都是可重复的， 尽管实施者可能在应用程序配置文件中另有说 明 （见 ３.９.８）。“都柏林” 的名字源于１９９５ 年俄亥俄州都柏 林的一个邀请研讨会； “ 核心”， 因为它的元素是广泛和通用 的， 可用于描述广泛的资源。 ＤＣ 已被广泛使用十多年， １５ 个 元素的描述已经在以下标准中得到正式认可： ２００３ 年２ 月的 ＩＳＯ 标准１５８３６ － ２００３ ［ＩＳＯ １５８３６ ｈｔｔｐ：／／ｄｕｂｌｉｎｃｏｒｅ.ｏｒｇ／ｄｏｃｕｍｅｎｔｓ／ｄｃｅｓ／＃ＩＳＯ１５８３６］， ２００７ 年 ５ 月的 ＮＩＳＯ 标准 Ｚ３９.８５－ ２００７ ［ＮＩＳＯ Ｚ３９８５ ｈｔｔｐ：／／ｄｕｂｌｉｎｃｏｒｅ.ｏｒｇ／ｄｏｃｕｍｅｎｔｓ／ｄｃｅｓ／＃ＮＩＳＯＺ３９８５］ 和２００７ 年８ 月的ＩＥＴＦ 标准 ＲＦＣ ５０１３ ［ＲＦＣ ５０１３ ｈｔｔｐ：／／ｄｕｂｌｉｎｃｏｒｅ.ｏｒｇ／ｄｏｃｕｍｅｎｔｓ／ｄｃｅｓ／＃ＲＦＣ５０１３］。
| ＤＣ 元素 | 官方定义 | 视听解释 |
|---|---|---|
| 标题 （Ｔｉｔｌｅ） | 给予资源的名称 | 与记录相关联的主标题 |
| 主题 （Ｓｕｂｊｅｃｔ） | 资源的主题 | 主题涵盖范围 |
| 描述 （Ｄｅｓｃｒｉｐｔｏｎ） | 资源的账户 | 解释性说明访谈摘要环境或文化背景的描述 内容清单 |
| 创造者（Ｃｒｅａｔｏｒ） | 主要负责制作资源的 实体 |
不是录音作品的作者或作曲家， 而是档案的 名称 |
| 发布者（Ｐｕｂｌｉｓｈｅｒ） | 负责使资源可用的实体 | 不是已经数字化的原始文档的发布者。通 常， 发布商将与创作者相同 |
| 贡献者（ Ｃｏｎｔｒｉｂｕ⁃ ｔｏｒ） |
负责为资源做出贡献的 实体 |
任何命名的人或声源。将需要适当的限定 词， 如角色（例如表演者、录音师） |
| 日期（Ｄａｔｅ） | 与资源生命周期中的事 件相关的点或时间段 |
不是原始的记录或日期， 而是与资源本身有 关的日期 |
| 类型（Ｔｙｐｅ） | 资源的性质或类型 | 资源的领域， 而不是音乐的流派。所以是某 种声音而不是爵士乐 |
| 格式（Ｆｏｒｍａｔ） | 资源的文件格式 | 物理介质或维度。是文件格式而不是原始的 物理载体 |
| 标识符（Ｉｄｅｎｔｉｆｉｅｒ） | 给定上下文中对资源的 明确引用 |
可能是音频文件的ＵＲＩ |
| 源（Ｓｏｕｒｃｅ） | 从其导出的描述资源的 相关资源 |
对从其导出当前资源的引用 |
| 语言 (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) |
图５ 英国图书馆声音ＤＣ （ＢＬＡＰ-Ｓ） 应用简介的一部分
注： Ｎａｍｅｓｐａｃｅｓ ｕｓｅｄ ｉｎ ｔｈｅ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｆｉｌｅ；
ＤＣＭＩ Ｍｅｔａｄａｔａ Ｔｅｒｍｓ ｈｔｔｐ：／／ｄｕｂｌｉｎｃｏｒｅ.ｏｒｇ／ｄｏｃｕｍｅｎｔｓ／ｄｃｍｉ-ｔｅｒｍｓ／；
ＲＤＦ ｈｔｔｐ：／／ｗｗｗ.ｗ３.ｏｒｇ／ＲＤＦ／；
ＭＯＤＳ ｅｌｅｍｅｎｔｓ ｈｔｔｐ：／／ｗｗｗ.ｌｏｃ.ｇｏｖ／ｍｏｄｓ；
ＴＥＬ ｔｅｒｍｓ ｈｔｔｐ：／／ｗｗｗ.ｔｈｅｅｕｒｏｐｅａｎｌｉｂｒａｒｙ.ｏｒｇ／ｍｅｔａｄａｔａｈａｎｄｂｏｏｋ／ｔｅｌｔｅｒｍｓ.ｈｔｍｌ；
ＢＬ Ｔｅｒｍｓ ｈｔｔｐ：／／ｌａｂｓ.ｂｌ.ｕｋ／ｍｅｔａｄａｔａ／ｂｌａｐ／ｔｅｒｍｓ.ｈｔｍｌ；
ＭＡＲＣＲＥＬ ｈｔｔｐ：／／ｗｗｗ.ｌｏｃ.ｇｏｖ／ｌｏｃ.ｔｅｒｍｓ／ｒｅｌａｔｏｒｓ。
３.９.１２ 应用程序配置文件包含或编制数据字典（定义数据库基本组 织到其各个字段和字段类型的文件） 或几个数据字典， 可由 单个存档维护或与档案社区同保存有关的ＰＲＥＭＩＳ 数据字典 （ｈｔｔｐ：／／ｗｗｗ.ｌｏｃ.ｇｏｖ／ ｓｔａｎｄａｒｄｓ／ｐｒｅｍｉｓ／ｖ２／ｐｒｅｍｉｓ-２-０.ｐｄｆ， 目前的版本号是２） 维护， 预计将大量使用它的众多 元素作为“语义单位”。保存元数据提供关于出处、保存活 动技术特征的智能， 并有助于验证数字对象的真实性。 ＰＲＥＭＩＳ 工作组于 ２００５ 年 ６ 月发布了其保存元数据的数据字典， 并建议在所有保存库中使用， 不论存档材料的类型和采用的 保存策略为何。
３.９.１３ 通过定义应用程序配置文件， 最重要的是通过声明它们， 实现者 可以共享有关其模式的信息， 以便广泛地进行诸如长期保存等普 遍任务方面的协作。
