跳转到内容

开放元数据手册/数据集成

Add links
来自维基教科书，开放世界中的开放书籍

本章将介绍如何获取数据、将其集成到项目中，然后呈现数据。

获取数据

[编辑 | 编辑源代码]

数据存储

[编辑 | 编辑源代码]

数据和元数据可以在各种来源中找到。“数据存储”是指存储和提供数据访问的在线资源的通用术语。从广义上讲，这可以是任何在线服务器，例如提供以网页形式表示数据的 Web 服务器。在本手册中，我们将重点关注旨在允许以可重复使用形式自由开放访问书目元数据的數據存储。

数据中心

[编辑 | 编辑源代码]

Thedatahub充当各种数据的中心。可以过滤数据集，例如，仅获取开放数据。

主要书目目录

[编辑 | 编辑源代码]

群众贡献数据

[编辑 | 编辑源代码]
  • 维基媒体
  • 内容共享网站
    • 一些网站不仅提供用户生成的内容，例如图片、视频或音乐，还提供元数据和API来访问这些元数据和搜索内容。

访问数据

[编辑 | 编辑源代码]

大量可用的开放数据集以可下载文件形式提供。这是检索数据的最简单方法，因为它只需要先找到正确的数据集，然后单击将其下载。但是，此类下载通常无法很好地集成到自动化流程中，并且通常没有其他方法可以确保数据是最新的，除非手动检查更新。

通过API访问数据

[编辑 | 编辑源代码]

“API”代表“应用程序编程接口”。顾名思义，API 允许比下载更复杂的交互。

在大多数开放知识 API 中，访问数据的接口基于 HTTP 协议，这与浏览器用于访问网页的协议相同，这保证了几乎任何互联网连接都能轻松访问。

就像打开网页一样，要从基于 Web 的 API 请求数据，您需要调用 URL（统一资源定位符），即此网页的地址（或者在第二种情况下，是此 API 端点的地址，因此使用中性术语“资源”来表示两者）。

大多数 API 遵循 REST（表征性状态转移）体系结构，其中参数（例如数据集的名称、数据集内的特定范围）在 URL 中传递。这使得 API 非常容易测试，因为您可以在浏览器中尝试它们并查看结果。

API 世界的范围从比可参数化下载略多到完全复制在线服务的函数（从用户身份验证到内容创建），允许在这些服务之上构建自定义客户端。

一个例子

[编辑 | 编辑源代码]

维基百科 API 的端点是 http://en.wikipedia.org/w/api.php，这意味着任何以这种方式开始的 URL 都将重定向到 API。

如果您在没有其他参数的情况下打开维基百科的端点 URL，您将看到一个包含有关 API 语法的详细信息的网页，即如何构建 URL 以访问维基百科内部的数据。大多数 API 不会通过其端点提供文档，但会提供开发人员资源，例如Mediawiki API 页面

添加参数将提供对特定操作的访问权限。例如，http://en.wikipedia.org/w/api.php?format=xml&action=query&titles=Mexico_City&prop=revisions&rvprop=content将返回墨西哥城维基百科文章的最新修订版的内容，封装在 XML 文件中。

您可以轻松地随意更改参数：将titles=Mexico_City部分替换为titles=London|Paris，您将获得伦敦和巴黎两篇文章。将format=xml替换为format=json，您将获得不同的封装。

API工具

[编辑 | 编辑源代码]
  • 诸如 APIgee 之类的 API 控制台提供工具来构建和测试 API 请求。
  • JSON 是 API 数据中最流行的格式之一，我们推荐使用 Firefox 扩展程序 JSON View，它有助于探索此类数据的嵌套结构。

自动获取数据

[编辑 | 编辑源代码]

元数据互操作性

[编辑 | 编辑源代码]

不同的元数据模式用于不同的目的。因此，同一资源可以根据上下文由补充或辅助模式描述。由于存在如此多的元数据标准，有时很难理解如何在一种格式和另一种格式之间实现互操作性。元数据互操作性是指能够在没有或很少丢失信息的情况下交换元数据。它允许元数据在不同系统之间转移，而不管这些系统的独特特征如何。鉴于可互操作的元数据可以在多个系统上存储和处理，互操作性使得关于特定资源的元数据能够被不同系统访问和理解，并且可以与来自不同系统或关于不同资源的元数据聚合或集成。

可互操作元数据的主要优点如下：

  • 通过标准化工具更容易从不同系统导入元数据。
  • 在多个系统之间转移不同的数据集。
  • 能够通过多个目录搜索元数据。

确保最大互操作性和高一致性的最佳方法是让每个人都同意同一个模式，例如 MARC (Machine-Readable Cataloging) 格式或 Dublin Core (DC)。然而，统一标准方法并不总是可行或实用，特别是在异构环境中，不同的资源由各种专门的模式描述。具有不同需求的不同机构可能会开发“临时”元数据格式，这些格式通常彼此不互操作，因为它们不符合相同的标准。

因此，必须开发特定工具以允许不同格式之间互操作。可以使用各种机制来组装不同的数据集，即使这意味着借用不同元数据标准中指定的部分。然而，数据提供者应确保结果可以被独立设计的应用程序解释。互操作性可以在创建元数据记录之前（事前互操作性）或之后（事后互操作性）实现。

本节旨在说明如何合并、集成或聚合不同的元数据标准和本体。


转换

[edit | edit source]

通常，在仔细考虑互操作性问题之前，已经采用了一种特定的元数据模式，并且已经创建了元数据记录。有时希望将特定领域的元数据标准与彼此结合使用。转换元数据记录成为集成已建立元数据数据库的少数选择之一。转换是图书馆数据传统的自上而下的方法（即生成 MARC 记录作为图书馆材料的独立描述）：。临时格式为数据提供者提供了一个简单的交换格式来转储他们的记录，这些记录可以很容易地提取并聚合在一起。

优点

  • 以记录为中心的方法：重点在于记录，这是我们想要获取并公开访问的内容。
  • 低成本和易于实施

缺点

  • 根据最小公分母进行事后转换，但存在转换损失的风险：从丰富结构转换为简单结构时会丢失数据（与丰富相比）。
  • 主要挑战是如何最大限度地减少数据丢失或扭曲。其他复杂情况包括转换与某些元素关联的值字符串，这些元素需要使用受控词汇表。

示例

  • 美国国会图书馆提供工具（可在<http://www.loc.gov/standards/mods/>获取）来在 MARC 记录和 MODS 记录之间，以及在 DC 记录和 MODS 记录之间进行转换。
  • 澳大利亚图片项目是一个很好的数据转换示例。这是一个数字图书馆项目，涵盖了各种机构，包括图书馆、国家档案馆和澳大利亚战争纪念馆，其中许多机构带有根据不同标准准备的遗留元数据记录。来自参与者的记录被收集在一个中心位置（澳大利亚国家图书馆），然后翻译成“通用记录格式”，其字段基于 Dublin Core。
  • 国家科学数字图书馆 (NSDL) 元数据存储库，从各种集合中收集了元数据记录。例如，ADL (Alexandria Digital Library) 元数据记录在 NSDL 元数据存储库收集这些记录时必须转换为 Dublin Core 记录。在将 ADL 记录转换为基于 DC 的记录以进行显示时，ADL 元素中的值字符串将以等效的 DC 元素显示。
  • BibJSON

映射与交叉映射

[edit | edit source]

从一个元数据模式到另一个元数据模式的元素、语义和语法的映射通常通过一个表格完成，该表格表示基于元素的功能或含义的相似性，将一个数据标准（源）中的数据元素的语义映射到另一个标准（目标）中的数据元素。映射使异构集合能够使用单个查询同时进行搜索，就好像它们是一个数据库一样（语义互操作性）。

从一个模式中的一个元素到另一个模式中的一个类似元素的映射将要求数据在两个模式之间具有可共享的含义和结构，以确保转换后的元数据的可用性。临时格式可以非常容易地映射到大多数现有格式（但通常是损失转换）。示例

  • 几乎所有模式都创建了到流行模式（如 DC、MARC、LOM 等）的交叉映射。
  • VRA Core 3.0，列出了目标模式 VRA 2.0（早期版本）、CDWA 和 DC 中的映射元素。
  • BibJSON 提供了一种轻量级的 RDF/LD 兼容格式。BibJSON 到 RDF/LD 的完整映射可以由其他感兴趣的方完成，不一定是由最初的数据提供者完成。

也可以使用特定的元数据模式（新模式或现有模式）来引导多个模式之间的交叉映射。不是在组中的每一对之间进行映射，而是将每个单独的元数据模式仅映射到切换模式。示例

  • Getty 的交叉映射，其中七个模式都交叉映射到 CDWA

问题

  • 虽然目前交叉映射为模式和数据的相对有效的交换和共享铺平了道路，但还需要有效的交叉映射来解决日常问题，即确保由来自多个来源的记录构建的大型数据库的一致性。
  • 交叉映射的主要问题之一是等效性的不同程度：一对一、一对多、多对一和一对零。这意味着在映射单个元素时，通常没有完全的等效项。同时，发现许多元素在含义和范围上重叠。因此，基于交叉映射的数据转换可能会造成质量问题。
  • 临时格式之间的转换需要定义扩展机制和词汇对齐方法（例如，解释你的“标题”与 dc:title 或其他模式的标题相同）。

示例

媒体资源本体

媒体资源本体 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”。然后在本体中定义映射的“类型”：“精确”、“更具体”、“更通用”和“相关”。使用仅限媒体本体的机制来纠正使用来自不同模式的属性在属性之间来回映射时可能发生的语义丢失，超出了媒体本体工作的范围。本体在语义 Web 语言 RDF 和 OWL 中的语义 Web 兼容实现也可用，并在<http://www.w3.org/TR/mediaont-10/>文档的第 7 节中介绍。

BibJSON

BibJSON 是一种用 JSON 表示书目元数据的约定；它使在线共享和使用书目元数据变得容易。它是一种 JSON 格式——一种简单、实用且通用的在网络上表示数据的格式，可用于在应用程序之间传递信息。BibJSON 的设计宗旨是简单实用。它几乎没有要求，你可以使用自己的命名空间来扩展它。通过使用 BibJSON（或转换为 BibJSON）数据可以很容易地在线显示、搜索、嵌入、合并和共享。可以将 X 解析为 BibJSON 再解析为 Y，很快就能通过 BibJSON 进行翻译。解析器可以通过以下 API 调用访问：http://bibsoup.net/parse

链接数据

[edit | edit source]

链接数据提供了一种机制，可以在不同的数据库中识别通用概念，而不会局限于最小公分母。它不涉及任何类型的转换；而是创建了一个模块化的元数据环境，其中来自不同模式、词汇和应用程序的不同类型的元数据元素（描述性、管理性、技术性、使用和保存）可以以互操作的方式组合在一起。元数据记录的组成部分可以被视为拼图的各个部分。它们可以通过组合来自不同过程的元数据源的各个部分来组合在一起，并且在需要生成新记录时，它们也可以逐部分使用和重复使用。乐高积木的比喻可以用来描述这个过程，即任何人都可以从不同的元数据标准提供的“工具包”中“拼凑”选定的“积木”，即使这些积木是独立创建的。

随着链接开放数据 (LOD) 目前在信息世界中越来越受欢迎，欧洲数字图书馆 (Europeana) 刚刚推出了一个动画<http://vimeo.com/36752317> 来解释关于链接开放数据的相关信息及其对用户和数据提供者的益处。

示例

METS：元数据编码和传输标准 (METS) 提供了一个框架，用于将来自不同来源的各个组件整合到一个结构中，并且还使将各个部分“粘合”到一个记录中成为可能。METS 是一种将描述性、管理性和结构性元数据打包到一个 XML 文档中的标准，用于与数字存储库进行交互。METS 记录中的描述性元数据部分可以指向 METS 文档外部的描述性元数据，例如在线公共访问目录 (OPAC) 中的 MARC 记录或在 WWW 服务器上维护的编码档案描述 (EAD) 查找辅助工具。或者，它可能包含内部嵌入的描述性元数据。因此，它可以为数字图书馆对象在不同馆藏或存储库之间交换提供一个有用的标准。

RDF：资源描述框架 (RDF) 是另一种提供将多个元数据方案集成到一起的机制的模型。可以定义多个命名空间，以允许来自不同模式的元素组合到一个单独的资源描述中。不同的命名空间由一个 URL 定义，该 URL 定义用于描述特定资源的元数据方案。因此，单个 RDF 记录可以包含多个资源描述，这些描述可能是在不同时间和出于不同目的创建的。因此，RDF 提供了一个框架，在这个框架内，独立的社区可以开发适合他们特定需求的词汇表，并与其他社区共享词汇表。结合语义网社区提出的有用原则，它可以有助于提高互操作性和元数据的扩展——尽管适当的词汇对齐需要通过 RDF 本体进行准确的映射。


优势

链接可以与特定的协议结合使用，将数据链接在一起，以便更好地

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

元数据注册表和存储库

[edit | edit source]

当通过单个搜索引擎搜索多个来源时，其中一个主要问题是检索到的结果很少以一致、系统或可靠的格式呈现。元数据存储库通过维护一种一致且可靠的数据访问方式，为这类互操作性问题提供了一种可行的解决方案。

存储库面临的一个问题是，是否允许每个原始元数据源保留自己的格式。如果不是，它将如何将所有元数据记录转换为标准化格式或整合到标准化格式中？它将如何支持跨馆藏搜索？三种常见的方法是

通用格式

[edit | edit source]

其想法是创建一个存储库，将元数据记录存储到简单且可互操作的格式中，从而鼓励机构将他们的元数据发布到该格式中，以减少转换和去重工作。

Bibsoup / Bibserver

BibSoup 方法鼓励在贡献时间不进行去重的条件下贡献开放书目。我们预计，随着它的发展，将开发出帮助用户和维护者管理信息的服務。去重到中央存储库可能是一个解决方案（假设 STM 书目条目具有柏拉图式的同一性），但我们也预计基于 RDF 的软件将允许工具管理书目数据的替代表示，让用户选择他们要采取的策略。简而言之，当前的 STM 书目是一个分布式的混乱。BibSoup 将此作为起点，在有政治意愿和资金支持的情况下，提供整理这些信息的方法。BibSoup 由多个书目集合组成（最初在 STM 领域），这些集合由通用语法统一。人类和机器可以开发这些集合组件之间的注释和等价关系。因此，例如，可以在 arXiv、DBLP 甚至 Medline 中找到关于“同一篇论文”的各种记录。确定两个记录是否与“同一对象”相关的问题很困难且有争议，BibSoup 有意避免这个问题。它只是一个以 BibJSON 表示的书目记录集合，提供给其他人使用。它可能在 BibServer 的一个实例中，在一个文件中，或者所有这些的组合；这只是一个范围问题。有关更多详细信息，请参阅 http://bibserver.org/about/bibsoup/ 和 http://bibserver.org

[edit | edit source]

增加不同元数据格式之间互操作性的一个常见方法是提供跨系统搜索（元搜索）。虽然元数据保留在本地存储库中，但本地搜索系统接受来自远程搜索系统的查询。

Z39.50 国际标准 Z39.50 是最著名的跨系统搜索协议。该协议不需要共享或复制元数据，而是提供特定的搜索功能，这些功能映射到通过 Z39.50 协议理解的一组通用搜索属性。

示例

  • 美国国会图书馆，SRU：通过 URL 网页搜索/检索 http://www.loc.gov/standards/sru/。一种在 URL 中传递类似 Z39.50 的搜索查询的标准协议，使用通用查询语言。

元数据收集协议

[edit | edit source]

增加不同元数据格式之间互操作性的另一种方法是通过实施特定的收集协议，例如开放档案倡议元数据收集协议 (OAI/PMH)。与这些协议兼容的系统可以将元数据公开，供外部搜索服务使用和/或包含在联合数据库中。

开放档案倡议 (OAI) 协议 开放档案倡议元数据收集协议 (OAI-PMH) 是一种协议，其目标是提供和促进一种与应用程序无关的互操作性框架，可供各种参与在网络上发布内容的社区使用。开放档案倡议要求每个元数据提供者将其元数据转换为一组共同的关键元素，以便进行收集。然后将这些元数据收集到一个具有统一元数据格式的中心索引中，以便允许跨存储库搜索，而不管元数据提供者在其自身存储库中使用的原生元数据格式。有关更多信息，请访问 http://www.openarchives.org/。另请参阅有关 OAI 数据提供者实施最佳实践和可共享元数据的更多信息，请访问 http://webservices.itcs.umich.edu/mediawiki/oaibp/index.php/Main_Page（数字图书馆联盟和国家科学数字图书馆的联合倡议）。

示例

  • NSDL 元数据存储库采用基于 OAI-PMH 的自动化“摄取”系统，元数据以最少的人工干预流入元数据存储库。从这个角度来看，NSDL 本质上充当元数据聚合器。此过程背后的理念是，每个元数据记录包含关于特定资源的一系列语句，因此来自不同来源的元数据可以聚合在一起以构建该资源更完整的配置文件。因此，多个提供者可能会为增强的元数据记录做出贡献。这些增强功能通过 OAI-PMH 公开，元数据存储库可以随后收集它们。
  • 密歇根大学的 OAIster 搜索服务包含数百万条记录，这些记录来自数百个通过 OAI-PMH 收集的数字化文化遗产资料。请访问 OAIster 网站 http://www.oaister.org/。

多语言主题访问 (MACS)

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

检索自 "https://wikibooks.cn/w/index.php?title=Open_Metadata_Handbook/Data_Integration&oldid=3262679"
华夏公益教科书