建议

本节的目的是帮助 GLAM 机构决定为其作品描述使用哪种最佳标准。元数据格式的建议应反映实际问题，而不是自描述模式的抽象理想。

建议不要选择一种元数据模式，而是建议选择可互操作的模式。永远不会存在一种适用于所有需要描述的资源类型的模式。基于图形的设计优势在于，各种元数据用户可以共享核心数据，但每个专业社区可以轻松地添加其需要的术语，而不会中断整体。

截至目前，争论似乎集中在

基于 RDF 的元数据模型 + 与书目作品最佳集成的本体列表（例如 foaf、bibo 等）
为一个或多个特定目的而设计的不定元数据格式。由于它们更简单，因此可能会降低参与开放书目数据提供的门槛。关键是捕获足够的书目元数据结构，以用于开放书目目的，从而实现简单、低成本和低技术的基本书目元数据的交换。

两者都具有各自的优点和缺点，必须予以考虑，以确定应在该特定应用领域中使用哪种标准。决定将取决于

可用于数据交换和显示的工具
用于转换和创建元数据的有限资源

实施成本

尽管制作元数据可能很昂贵且耗时，但元数据会为书目记录增加价值。记录资料的详细描述通常受限于对每件物品已知信息的多少，这可能需要大量的研究才能完成。

详细、灵活和可扩展

RDF/Sparql 为开放书目数据的描述/识别/管理提供了高级工具。但是，如果没有对时间和成本的重大投资，就无法完成适当的 RDF 数据库。

简单、快速和低成本实施

尽管需要更精确地描述数字资源，以便可以搜索和识别它们，但对于许多大规模数字化项目而言，这并不现实。为开放书目数据的快速普及而设计的轻量级不定元数据格式。（例如，BibTeX 提供了一个简单的元数据方案，可能对于大多数当前目的而言几乎足够，并有一些用于处理标识符的约定。此方案和适当的约定已纳入 BibJSON，BibJSON 提供了一种轻量级与 RDF/LD 兼容的格式。BibJSON 到 RDF/LD 的完整映射可以由其他感兴趣的方完成，而不是最初的数据提供者。由于很多原因，不建议使用 BibTeX 作为元数据格式。）

互操作性

元数据是否需要与其他系统交互或交换？需要查看数据交换格式，然后根据所做决定确定元数据格式。

互操作性需要记录元数据的标准化方式。元数据还必须存储在或组装成一种文档格式中（例如 XML），这种格式可以促进数据的轻松交换。[例如，符合 METS 标准的数字对象通过其标准化、“打包”格式促进互操作性。]

统一标准化

确保最大互操作性和高度一致性的最佳方法是让每个人都同意使用相同的模式，例如 MARC（机器可读编目）格式或都柏林核心 (DC)。但是，在异构环境中，不同资源由各种专用模式描述，因此统一标准方法并非总是可行或实用的。

架构层面的互操作性

确保根据给定模式处理的数据能够与其他数字馆藏互操作。在架构级别，互操作性操作通常在操作级别元数据记录创建之前进行（EX-ANTE INTEROPERABILITY）。在此阶段使用的方法主要包括：推导、应用配置文件、交叉对照表、切换、框架和注册表。

推导

从现有模式派生出新的模式：例如，可以将现有的复杂模式（如 MARC 格式）用作“源”或“模型”，从中派生出新的更简单的单个模式。推导方法包括调整、修改、扩展、部分调整、翻译等。示例

TEI Lite 从完整的文本编码倡议 (TEI) 推导而来。
MODS（元数据对象描述模式）和 MARC Lite 从完整的 MARC 21 标准推导而来。
将 DC 元素集翻译成不同的语言。
为都柏林核心元数据元素集 [DCMI 元数据术语] 提出的额外元素。
电子论文和学位论文元数据标准 (ETD-MS)。该标准使用 15 个都柏林核心元素中的 13 个，以及一个额外的元素：thesis.degree [ETD-MS]。
教育材料门户网站 (GEM) 对都柏林核心的扩展。附加元素包括：编目、基本资源、教学法、标准和持续时间 [GEM 元素集]。
北京大学图书馆开发的稀有材料描述性元数据。它使用 12 个 DC 元素，以及版本和物理描述作为两个本地核心元素，以及用于第三级扩展的馆藏历史元素 [Yao 等，2004]。

应用配置文件

应用配置文件由一个或多个元数据模式中的元数据元素组成，并组合成一个复合模式。它们确保了类似的基本结构和通用元素，同时允许不同程度的深度和细节以及不同的用户社区。例子

澳大利亚虚拟工程图书馆的 AVEL 元数据集包含 19 个元素。除了支持 14 个 DC 元素（不包括 dc.source 元素）外，它还支持一个 AGLS（澳大利亚政府定位服务）元数据元素（AGLS.Availability）、一个 EDNA（澳大利亚教育网络）元素（EdNA.Review）和三个管理元素（AC.Creator、AC.DateCreated 和 AVEL.Comments）。

应用配置文件也可以基于单个模式，但针对不同的用户社区进行定制。例子

DC-Library 应用配置文件 (DC-Lib) 阐明了 DC 元数据元素集在图书馆和图书馆相关应用和项目中的使用。
DC 政府应用配置文件阐明了 DC 在政府环境中的使用。
国家生物信息基础设施 (NBII) 的生物数据配置文件基于联邦地理数据委员会 (FGDC) 的数字地理空间元数据内容标准 (CSDGM)。

互操作

将一个元数据模式中的元素、语义和语法映射到另一个元数据模式。通常通过图表或表格来完成，该图表或表格表示一个数据标准（源）中的数据元素与另一个标准（目标）中的数据元素的语义映射，基于元素的功能或含义的相似性。它们使异构集合能够使用单个查询同时搜索，就好像它们是单个数据库一样（语义互操作性）。从一个模式中的元素映射到另一个模式中的类似元素，需要确保数据的含义和结构在两个模式之间是可共享的，以确保转换后的元数据的可用性。几乎所有现有格式都可以很容易地映射到 ad-hoc 格式（但通常是信息丢失的转换） - 例子

几乎所有模式都创建了到流行模式（如 DC、MARC、LOM 等）的互操作。
VRA Core 3.0，它列出了目标模式 VRA 2.0（早期版本）、CDWA 和 DC 中的映射元素。

互操作的一个问题是等效程度的不同：一对一、一对多、多对一和一对零。这意味着在映射单个元素时，通常没有完全等效的元素。同时，发现许多元素在含义和范围上重叠。因此，基于互操作的数据转换可能会造成质量问题。

MARC、Z39.50、SRLI/SRW、BibJSON？
ad-hoc 格式之间的转换需要定义可扩展性机制和词汇对齐方法（例如，解释您的“标题”与 dc:title 或其他模式的标题相同）。

切换

使用切换模式（新的或现有的）在多个模式之间进行互操作。与其在组中的每一对之间进行映射，不如将每个单独的元数据模式仅映射到切换模式。例子

Getty 的互操作，其中七个模式都与 CDWA 互操作。

元数据框架

框架可以被认为是一个骨架，各种对象在该骨架上被集成到给定的解决方案中。构建元数据框架有两种方法：1）在开发单个模式和应用程序之前建立框架，以及 2）基于现有模式构建框架。例子

开放档案信息系统 (OAIS) 参考模型，由国际空间数据系统咨询委员会 (CCSDS) 发布为一项建议。它建立了一个包含开放档案信息系统的术语和概念的通用框架，为档案环境中的进一步标准化提供了基础。
DLESE（地球系统教育数字图书馆）发现系统目前使用的元数据框架。经过几年探索基于 IMS（教学管理系统）学习资源元数据规范为 DLESE 元数据建立框架后，亚历山大数字地球原型 (ADEPT) 项目、DLESE 和 NASA 的联合数字图书馆 (JDL) 在 2001 年 6 月决定创建 ADN 元数据框架，所有三个组织都可以使用该框架。正如其网页上所述，ADN 框架的目的是“描述通常在学习环境中使用的资源（例如，课堂活动、课程计划、模块、可视化、一些数据集），供地球系统教育界发现。”

元数据注册表

元数据注册表的目的相当直接：收集有关元数据模式的数据。预计元数据注册表将“提供识别和引用已建立的模式和应用配置文件的方法，可能包括在不同模式之间进行机器映射的方法。”

跨域和跨模式注册表。例如，UKOLN（英国图书馆网络办公室）的 SCHEMAS 注册表（现已用于新的 CORES 项目）包含多个元数据元素集和相关文档。通过 Web 界面，可以根据机构、元素集、元素、编码方案、应用配置文件和此注册表中包含的元素用法进行搜索或浏览。目前，注册表包含来自 10 个机构的 12 个元素集 [CORES]。
特定于域的跨模式注册表。例如，UKLON 的 MEG（教育元数据组）注册表促进教育领域内的模式注册 [MEG 注册表]。
特定于项目的注册表。欧洲图书馆 (TEL) 元数据注册表 [TEL] 是为了记录与 TEL 相关的所有元数据活动而建立的。注册表包含不同语言的元素名称翻译，并声明元素是否可重复、可搜索和强制性 [Van Veen and Oldroyd, 2004]。
特定于模式的注册表，例如都柏林核心元数据倡议 (DCMI) 的注册表或开放数据注册表 [都柏林核心元数据注册表]，用于记录 DC 模式中的有效元素。目前，注册表提供了有关元素、元素细化、受控词汇术语 (DCMI-Type Voc.) 以及词汇和编码方案的详细信息。

记录级别的互操作性

通常，在仔细考虑互操作性问题之前，已经采用了一种特定的元数据模式，并且已经创建了元数据记录。转换元数据记录成为集成已建立的元数据数据库的几种选项之一。有时希望将特定于域的元数据标准与彼此结合使用。数据提供者应该能够组装某些特定功能集所需的组件，即使这意味着利用不同元数据标准中指定的组件。数据提供者还应确保结果可以由独立设计的应用程序解释。

元数据记录的转换

以记录为中心的方法：传统上自上而下的图书馆数据方法（即生成 MARC 记录作为图书馆资料的独立描述）：成本较低，实施更容易。ad-hoc 格式为数据提供者提供了一个简单的交换格式来转储他们的记录，这些记录可以很容易地提取和聚合在一起。[重点在于记录，这是我们想要获取并使其公开访问的东西。] 根据最小公分母进行的事后转换，但存在信息丢失的风险：数据丢失，而不是丰富。主要挑战是如何最大程度地减少数据丢失或失真。例子

美国国会图书馆提供了在 MARC 记录和 MODS 记录之间进行转换的工具（可在 <http://www.loc.gov/standards/mods/> 获取），以及在 DC 记录和 MODS 记录之间进行转换的工具。
澳大利亚图片项目是数据转换的一个很好的例子。这是一个数字图书馆项目，涵盖了各种机构，包括图书馆、国家档案馆和澳大利亚战争纪念馆，其中许多机构都带有根据不同标准编制的旧元数据记录。来自参与者的记录被收集到一个中央位置（澳大利亚国家图书馆），然后被翻译成“通用记录格式”，该格式中的字段基于都柏林核心。
国家科学数字图书馆 (NSDL) 元数据存储库，从各种馆藏中收集元数据记录。例如，当 NSDL 元数据存储库收集 ADL（亚历山大数字图书馆）元数据记录时，必须将这些记录转换为 Dublin Core 记录。在将 ADL 记录转换为基于 DC 的记录以供显示时，ADL 元素中的值字符串将显示在等效的 DC 元素中。例如，记录在 ADL 边界坐标中的坐标现在显示在 DC 覆盖范围中，而制作人则变为来源。

问题在于，从丰富的结构转换为简单的结构时，可能会丢失数据值。其他复杂的情况包括转换与某些元素关联的值字符串，这些元素需要使用受控词汇表。

数据重用和集成

链接数据：不是转换，而是一种机制，允许在不同的数据库中识别共同的概念：艺术家、事件等 - 而不局限于最小公分母。在模块化元数据环境中，来自不同模式、词汇表、应用程序和其他构建块的不同类型的元数据元素（描述性、管理性、技术性、使用和保存）可以以互操作的方式组合在一起。乐高积木的隐喻可以恰当地描述这个过程：应用程序设计人员应该能够从不同元数据标准提供的“套件”中“拼凑”选定的“构建块”，以构建满足其要求的结构，即使提供这些构建块的套件是独立创建的。元数据记录的组件可以被视为拼图的不同部分。它们可以通过组合来自不同过程（人工或机器）的元数据源的部分来拼凑在一起。当需要由人或机器生成新的记录时，它们也可以逐件使用和重用。示例

元数据编码和传输标准 (METS) 提供了一个框架，用于将来自不同来源的各种组件整合到一个结构中，并且还使得将这些部分“粘合”在一个记录中成为可能。METS 是一个将描述性、管理性和结构化元数据打包到一个 XML 文档中的标准，用于与数字存储库进行交互。METS 记录中的描述性元数据部分可能指向 METS 文档外部的描述性元数据，例如在线公共访问目录 (OPAC) 中的 MARC 记录或在万维网服务器上维护的编码档案描述 (EAD) 查找帮助。或者，它可能包含内部嵌入的描述性元数据。因此，它可以为数字图书馆对象在馆藏或存储库之间交换提供一个有用的标准。
万维网联盟 (W3C) 的资源描述框架 (RDF) 是另一个“提供了一种机制来集成多个元数据方案”的模型。它是一种数据模型，提供了一个框架，在这个框架内，独立的社区可以开发适合其特定需求的词汇表，并与其他社区共享词汇表。可以定义多个命名空间，以允许来自不同模式的元素组合到一个单一的资源描述中。RDF 记录将可能在不同时间出于不同目的创建的多个描述链接到一起。RDF + 来自语义网社区的有用原则有助于元数据的互操作性和扩展 - 正确的词汇表对齐需要通过 RDF 本体进行准确的映射。

RDF 可以与用于将数据链接在一起的特定协议组合在一起，以允许更好的

标准化：链接数据方法支持以一致的方式检索和重新混合来自所有元数据提供者的数据。
互操作性：链接数据通过在多个特定领域知识库之间进行链接来丰富知识，从而有利于跨学科研究：即使用 RDF 和 URI 的所有数据集的总和呈现为一个全局信息图，用户和应用程序可以无缝浏览。
分散化：使用链接数据，不同参与者可以以分散的方式生产关于同一资产的不同类型的数据，然后将其聚合到一个图中。可以与其他 GLAM 机构合作描述资源，并将这些资源链接到其他社区甚至个人贡献的数据。
效率：GLAM 机构可以创建一个开放的、全球的共享数据池，这些数据可以用于描述资源并重复使用。链接开放数据使机构能够集中精力于其本地专业领域的专业知识，而不是重新创建他人已经详细说明的现有描述。
弹性：链接数据比依赖于特定数据结构的元数据格式更持久、更健壮，因为它将数据的含义（“语义”）与特定数据结构（“语法”或“格式”）分开描述。

存储库级别的互操作性

当通过单个搜索引擎搜索多个来源时，主要问题之一是检索到的结果很少以一致、系统或可靠的格式呈现。元数据存储库通过维护一种一致且可靠的数据访问方式，为这类互操作性问题提供了一种可行的解决方案。存储库面临的一个问题是，是否允许每个原始元数据源保持其自己的格式。如果不是，它将如何将所有元数据记录转换为标准化格式？如果是，它将如何支持跨馆藏搜索？

开放档案倡议 (OAI) 协议

开放档案倡议元数据收集协议 (OAI-PMH) 是一种协议，其目标是提供和推广一个与应用程序无关的互操作性框架，该框架可以被各种参与在 Web 上发布内容的社区使用。

无需记录转换的多种格式

地球系统教育数字图书馆 (DLESE) 采取了一种不同的方法，绕过了在集成服务中转换元数据记录的必要性。从这项努力中产生的机制——DLESE 集合系统 (DCS)——是一种工具，允许参与者构建他们自己的地球系统项目级元数据记录集合，并开发、管理、搜索和共享这些集合，所有这些都无需将每个元数据记录转换为统一的格式。每个集合的元数据记录都按照 XML 模式进行结构化，该模式指定了特定元数据字段的必填和可选元数据（以及在某些情况下法律值）。DLESE 集合系统目前支持 ADN（ADEPT/DLESE/NASA）的 DLESE 元数据框架，用于典型地在学习环境中使用的资源。其他基于 XML 模式的元数据框架可以通过配置 DLESE 集合系统指向 XML 模式文件来支持。

聚合

NSDL 元数据存储库采用基于 OAI-PMH 的自动化“摄入”系统，元数据以最少的人工干预流入元数据存储库。从这个角度来看，NSDL 本质上充当元数据聚合器。这种过程背后的理念是，每个元数据记录都包含关于特定资源的一系列语句，因此可以聚合来自不同来源的元数据来构建更完整的资源概况。因此，多个提供者可能会为增强的元数据记录做出贡献。这些增强功能通过 OAI-PMH 公开，元数据存储库可以收集它们。

基于元素和基于值的交叉映射服务

虽然目前交叉映射为相对有效的模式和数据交换和共享铺平了道路，但还需要有效的交叉映射来解决在由来自多个来源的记录构建的大型数据库中确保一致性的日常问题。OCLC 的研究人员开发了一个模型，将三部分信息联系起来：交叉映射、源元数据标准和目标元数据标准。这项工作基于这样一个假设，即“可用的交叉映射必须具有以下特点：（1）一组在利益相关者社区认可的元数据标准之间的映射。（2）机器可处理的编码。（3）与源和目标元数据标准之间明确定义的关系，该关系必须引用特定版本和语法编码”。

用于跨数据库搜索的基于值的映射

多语言主题访问 (MACS) 项目说明了另一种基于值的映射方法，用于实现现有元数据数据库之间的互操作性。MACS 是一个欧洲项目，旨在允许用户跨不同语言的合作伙伴图书馆的图书馆编目数据库进行搜索，目前包括英语、法语和德语。具体来说，该项目旨在通过建立三个主题词列表之间的等效链接来提供多语言主题访问图书馆目录：SWD/RSWK（Schlagwortnormdatei / Regeln für den Schlagwortkatalog）用于德语，Rameau（Répertoire d'autorité-matière encyclopédique et alphabétique unifié）用于法语，LCSH（国会图书馆主题词表）用于英语。

基于值的共现映射

关于搜索，共现映射类似于上面讨论的 MACS 项目中所做的操作。但是，这种方法使用主题字段中已有的值，并将同一记录的主题字段中注册的不同语言的主题词视为等效。当元数据记录包含来自多个受控词汇表的词语时，主题词的共现能够在词汇表之间进行自动、松散的映射。作为一个整体，这些松散映射的词语可以回答特定的搜索查询或一组问题。现有的元数据标准和最佳实践指南为使用共现映射方法提供了机会。

艺术和图像相关元数据标准 VRA 核心类别 3.0 版要求使用艺术与建筑词典 (AAT) 来表示类型、材料和风格/年代元素；对于文化和主题元素，推荐使用 AAT、LCSH、图形材料词典 (TGM)、ICONCLASS（国际图像学研究和图像记录分类系统）和西尔斯主题词表。
另一个共同出现映射来源是亚历山大数字图书馆的 Gazetteer 标准报告。在要素类别下，记录了来自两个受控词汇的术语。

结论

RDF

RDF 提出了一种强大而灵活的架构来支持元数据。其目标是通过提供一个通用框架来描述任何具有统一资源标识符 (URI) 的项目，从而支持互操作性。RDF 规范提供了大量的本体，以支持在网络上交换知识。--- 需要包括一系列针对不同类型书目作品的 OWL。

Dublin Core

Dublin Core (DC) 是一种流行且被广泛接受的元数据标准，用于描述物理资源（如书籍）、数字材料（如视频、音频、图像或文本文件）以及复合媒体（如网页）。DC 是一种灵活的标准，其特点是简单、可扩展和互操作性。Dublin Core 的主要优势在于它可以潜在地整合到各种元数据模型中，包括但不限于 RDF/OWL。这意味着它可以被任何 GLAM 机构使用，无论它们是否愿意投入资金和时间来建立基于 RDF 的数据库。DC 标准通过充当大量社区特定格式之间的中介，支持跨资源发现。

Schema.org

谷歌、微软和雅虎推出了“schema.org”计划，旨在允许以非常简单的方式对网页进行注释，这些注释会被主要的搜索提供商识别。Schema.org 的特别之处在于它并非设计用来很好地描述事物，而是提供更好的搜索结果。Schema.org 的优势在于它基于一组非常简单且易于包含在任何来自 OPAC 的页面中的微数据元数据。

[CG：很好，但这不是推荐的形式，所以不应该放在上一章吗？]

媒体资源本体

媒体资源本体 1.0 (http://www.w3.org/TR/mediaont-10/) 目前是“W3C 候选推荐” (W3C = 万维网联盟)。一旦关于相应 API 的工作完成（参见媒体资源 API 1.0，http://www.w3.org/TR/mediaont-api-1.0/），该 API 提供对所有元素的统一访问，它将发展成为完整的“W3C 推荐”。该媒体本体既是 i) 核心词汇，即描述媒体资源的一组属性，这些属性是在考虑到当前使用的元数据格式的基础上选择的；又是 ii) 其属性集与当前在 Web 上发布的一些元数据格式的元素之间的映射，例如 Dublin core、EXIF 2.2、ITPC、Media RSS、MPGE-7、QuickTime、XMP、YouTube 等。映射的目的是提供一套可互操作的元数据，供不同的应用程序共享和重用。理想情况下，映射应该在不同的元数据格式之间保留元数据项的语义。在现实中，由于相关值的定义存在差异，因此无法普遍做到这一点，例如，来自 Dublin Core 的属性“dc:creator”和在可交换图像文件格式 (EXIF) 中定义的属性“exif:Artist”——这两者都映射到媒体本体中的属性“creator”。然后在本体中定义了“类型”的映射：“精确”、“更具体”、“更通用”和“相关”。使用仅限于媒体本体的机制来纠正使用来自不同模式的属性在映射前后可能出现的语义丢失超出了媒体本体工作的范围。本体在语义网络语言 RDF 和 OWL 方面的语义网络兼容实现也可用，并在 http://www.w3.org/TR/mediaont-10/ 文档的第 7 节中介绍。

BibJSON

如果我们想要认可 BibJSON 的使用，我们可能应该在指南中总结两种替代方法： - 简单的做法是采用 BibJSON 模型 - 性能更高但更复杂的做法是采用 RDF，这种方法可以轻松映射到 bibjson 并通过 bibserver 管理。（这是 Bibliographica 目前采用的方法，如果我没记错的话？）列表中的任何人都可以编辑 wiki 以提供有关该方法的更多详细信息吗？马克？ ;)