都柏林核心
都柏林核心
关于DCMI 主题 成员 董事会 使用板 理事会
推特 YouTube GitHub RSS提要

都柏林核心™元数据的互操作性水平

创造者: 米凯尔尼尔森
KMR集团，NADA, KTH(皇家理工学院)，瑞典
汤姆贝克
DCMI
皮特·约翰斯顿
Eduserv基金会，英国
发行日期: 2009-05-01
最新版本: //www.voudr.com/specifications/dublin-core/interoperability-levels/
发布历史: //www.voudr.com/specifications/dublin-core/interoperability-levels/release_history/
描述: 本文档讨论了为不同类型的互操作性设计应用程序所涉及的设计选择。在第1级，应用程序使用具有共享自然语言定义的数据组件。在第2级，数据基于W3C资源描述框架的形式语义模型。在第3级，数据被结构化为描述集(记录)。在级别4，数据内容受制于一组共享的约束(在Description set Profile中描述)。每个级别都提供了一致性测试和示例。作者期望本文档随着对不同层次互操作性的利弊的探讨而不断发展，并欢迎读者提供反馈。

目录表

  1. 介绍
  2. 第1级:共享术语定义
  3. 级别2:正式语义互操作性
  4. 级别3:描述集语法互操作性
  5. 级别4:描述集概要文件互操作性
  6. 参考文献
  7. 致谢

介绍

在过去的十年中，从15个元素[RFC2413]到都柏林核心™应用程序概要的新加坡框架[DCAP]的不断发展的假设可以在互操作性的分层模型中捕获。这里提供的级别模型解决了许多社区对各种项目的需求，这些项目与Dublin Core™具有不同程度的互操作性，但缺乏适当的术语。

其目的是提供一个“互操作性阶梯”，指定为提高互操作性级别而设计应用程序所涉及的选择、成本和收益。本文档描述了与规范(或应用程序)的Dublin Core™元数据的可能互操作性级别。这些级别有助于确定希望“与都柏林核心兼容”的项目范围，并为“与都柏林核心兼容”规范的用户设定期望。

这些级别附带简单的石蕊测试，作为确定互操作性级别的指导方针。这些级别相互建立，因此符合第3级的规范自动符合第1级和第2级，而符合第4级的规范符合前3级。在这一点上，在这些层面上没有更广泛的共识。作者期望本文档随着对不同层次互操作性的利弊的探讨而不断发展，并欢迎读者提供反馈。

互操作性水平

级别1:共享术语定义

包含15个元素的Dublin Core™(与NISO、ISO和IETF标准一样)提供了具有自然语言定义的概念词汇表。撇开机器可处理性(“正式”语义)的考虑不提，这样的词汇表提供了在人群内部和人群之间共享含义的基础——一种“非正式”的互操作性，它不需要使用uri来引用术语、正式指定的领域和范围，或者像DCMI抽象模型[Abstract - Model]这样的高阶结构。例如，IEEE学习对象元数据提供的DCMI术语定义和到DCMI术语的映射的重用可以被视为提供了与Simple Dublin Core™的“非正式一致性”。

这个级别对应于使用Dublin Core™术语的自然语言定义。

  • 术语uri的使用并不是必需的——术语可以以任何方式引用。
  • 不要求与术语的指定域和范围保持一致。
  • 与DCMI抽象模型的一致性不是必需的。
  • 从历史上讲，与“Dublin Core™”的非正式互操作性意味着使用这15个元素，尽管非正式互操作性的概念原则上适用于用自然语言定义的任何元数据术语。

测试

  • 是否有部分映射到简单都柏林核心，定义为“遗留的15个元素，可重复，与文字字符串一起使用”?如果是，则该规范可以非正式地与Dublin Core™元数据互操作。

例子

  • IEEE LOM重用DC术语定义，并提供到Simple Dublin Core™的映射。

级别2:正式语义互操作性

“语义”互操作性基于对RDF图数据模型和基于RDF的词汇表(如DCMI Metadata Terms)中所包含的正式RDF语义的精确和正确的使用。这种意义上的“语义”并不指格式良好的自然语言定义(这就是“语义”一词在Dublin Core™社区中的传统用法)。相反，它指的是术语和规则之间正式陈述的关系，以便使用这些语句自动得出结论(逻辑推理)。这包括uri的使用(或可推断性)以及与正式指定的域、范围和子属性关系的一致性。无论其原生编码格式如何，如果规范提供了到RDF三元组的完整映射(例如通过GRDDL转换)，则可以说它是“语义上可互操作的”。

这个级别对应于对DCMI术语基础上的RDF语义的隐式或显式使用。因此，术语的任何用法都需要精确地符合RDF模型以及术语的域和范围。

  • 虽然规范/应用程序不需要使用uri显式地对数据进行编码，但必须能够推断出术语uri。
  • 要求与术语的指定域和范围保持一致。
  • 与所使用属性的子属性语义一致。
  • 与DCMI抽象模型的一致性不是必需的。

测试

  • 是否存在与所使用术语的指定域和范围一致的到RDF的“完整”映射?如果是，则该规范在语义上可与Dublin Core™元数据互操作。

例子

  • 根据定义，所有RDF数据都可以与Dublin Core™元数据在语义上互操作。
  • 所有使用GRDDL转换为RDF的数据在语义上都可以与Dublin Core™元数据互操作。
  • 使用2008年规范“用XHTML和HTML元标记表示Dublin Core™元数据”的数据在语义上可与Dublin Core™元数据互操作。

级别3:描述设置语法互操作性

在RDF指定的无界图之上，DCMI抽象模型将有界描述和描述集的概念分层，为元数据记录的验证和交换提供了基础。根据DCMI抽象模型构建的元数据——例如，使用DCMI最近的语法指南创建的数据——可以说是“DCMI抽象模型可互操作的”。在RDF抽象语法之上，DCMI抽象模型提供:

  • “描述集”作为具有特定标识的有界实体的概念——就像库和存储库社区对可管理的“记录”的概念一样。
  • “描述”作为具有特定标识的有界实体的概念，即使描述嵌入在记录中。
  • “语句”作为图形的扩展模型，使用值uri、值字符串和词汇表编码方案uri的各种组合。(词汇编码方案的正式概念是特定于DCMI抽象模型的。)
  • 用于区分所描述资源的“表示”和使用URI对该资源进行“标识”的约定。
  • 用多个值字符串“表示”单个值资源的约定。

这个级别对应于在元数据中显式使用DCMI抽象模型。

  • 元数据必须使用描述和描述集的DCMI抽象模型概念进行结构化。
  • 描述中的语句必须使用DCMI抽象模型定义的结构。

测试

  • 有没有完整的映射到DC-TEXT [DC-TEXT]?如果是，则该规范与DCMI抽象模型兼容。

例子

  • 所有数据使用DCMI发布的与DCMI抽象模型兼容的元数据表达式。

级别4:描述集概要文件互操作性

规范“描述集概要文件:都柏林核心™应用概要文件的约束语言”[DC-DSP]提供了描述集结构约束的信息模型和XML表达式。如果一个应用程序，如学术著作(Eprints)应用程序概要文件，提供了与描述集概要文件规范兼容的描述集的正式约束，那么它可以说是“描述集概要文件可互操作”的。

一个相关的规范，都柏林核心™应用程序概要的新加坡框架[DCAP]，概述了为了最大限度地实现互操作性和可重用性而呈现元数据应用程序所需的文档元素包——诸如功能需求、领域模型和覆盖完整元数据集的描述集概要等元素。

测试

  • 是否有“完整”的“描述集”配置文件?如果是，则该规范在Description Set Profile规范的级别上是可互操作的。

例子

  • 学术作品申请档案

参考文献

(抽象模型)鲍威尔，A.， M.尼尔森，A.纳夫，P.约翰斯顿，T.贝克。DCMI抽象模型。DCMI推荐标准。//www.voudr.com/specifications/dublin-core/abstract-model/2007-06-04/

(DC-DSP)尼尔森,M。描述集配置文件:都柏林核心™应用程序配置文件的约束语言。DCMI工作草案。//www.voudr.com/specifications/dublin-core/dc-dsp/2008-03-31/

(DC-TEXT)约翰斯顿(P。使用DC-Text格式表达Dublin Core™元数据DCMI推荐资源。//www.voudr.com/specifications/dublin-core/dc-text/2007-12-03/

(DCAP)尼尔森，M.， T.贝克，P.约翰斯顿。都柏林核心™应用配置文件的新加坡框架。DCMI推荐资源。//www.voudr.com/specifications/dublin-core/singapore-framework/2008-01-14//

(RFC2413)韦贝尔，S.， J. Kunze, C. Lagoze, M. Wolf。都柏林核心™元数据资源发现。IETF征求意见。<http://www.ietf.org/rfc/rfc2413.txt>

(交换)学术作品申请简介。http://www.ukoln.ac.uk/repositories/digirep/index/SWAP