| 创作者： | 汤姆贝克 Makx Dekkers 托马斯·菲舍尔 雷切尔的喜爱 |
| 发行日期: | 2005-09-03 |
| 最新版本: | //www.voudr.com/specifications/dublin-core/application-profile-guidelines/ |
| 发布历史: | //www.voudr.com/specifications/dublin-core/application-profile-guidelines/release_history/ |
| 描述: | 这些指南指定了都柏林核心应用程序配置文件的结构和内容，用于记录给定应用程序在其元数据中使用的形式，其中包含哪些扩展或适配，以及指定这些术语如何与都柏林核心等正式标准相关联到较少标识的元素集和词汇表。其中基于该基础的文件最初在CEN / ISSS研讨会上制定了CEN的CEN / ISSS研讨会 - 欧洲标准化委员会的Dublin Core（WS / MMI-DC），并于2003年作为CEN公布工作协议CWA 14855.此版本的文本与CWA 14855的文本基本相同（与CEN程序以及目录相关的介绍性文本），从中，未来的修订将越来越多地分歧。 |
Dublin Core™应用程序配置文件（DCAP）是指定组织，信息提供者或用户社区在其元数据中使用的元数据。根据定义，DCAP识别所用元数据项的源 - 无论它们是否已在正式维护的标准中定义，如都柏林核心，在不太正式定义的元素集和词汇表中，或者由DCAP本身的创建者在应用程序中用于本地使用．可选地，DCAP可以提供关于如何为特定于应用的目的约束，编码或解释的术语的附加文档。
DCAP旨在促进Dublin Core™模型约束条件下的互操作性，并鼓励使用的统一和围绕其边缘的“新兴语义”的收敛。从历史上看，应用程序概要文件是出于在特定的应用程序社区中共享Dublin Core™的本地域或特定于应用程序的细化或扩展的需要而出现的，而不必寻求由Dublin Core™元数据计划(DCMI)维护的核心标准的扩展。应用程序概要文件记录了实现者如何使用来自Dublin Core™的元素以及来自其他词汇表的元素，为本地需求定制标准定义和使用指南[HEERY]。
在实践中，为广泛的目的创建了应用程序配置文件：记录用于一组元数据记录（“实例元数据”）的语义和约束;帮助实施者的社区协调自己之间的元数据实践;确定新兴语义作为正式标准化可能的候选人;作为语义人行横道和格式转换的指南;作为形式编码结构的规范，如文档类型定义（DTD）;用于在广泛理解的标准方面解释或呈现遗留或专有元数据;或者为了记录根据该规则和标准，根据该规则和标准创建了一组元数据。应用程序配置文件通常代表“正在进行的工作”，提供焦点以持续努力逐步改进和阐明特定用户社区内的共享元数据语义的身体。
在缺乏指导方针的情况下，应用程序概要文件的创建者迄今已经发明了广泛的表示格式。本文件将许多现有概要文件的突出特点提炼成一种尽可能简明和简单的格式，同时又尽可能精确和详细，这是支持上述各种用途所必需的。
语义互操作性 - DCAP等文件的最终目的是追求的长期目标，作为元数据词汇表，以及随着时间的推移和相关的能够实现技术。在其目前的形式中，DCAPS旨在以归一化形式记录元数据使用，该标准形式将归因于将其作为诸如RDF的常见模型（例如RDF）以自动处理以自动处理以自动执行此类互操作性。
机器可理解的表示将在可以使用稳定的，记录良好的标识符引用元数据项的范围内实现这一目标。如下所述，使用统一资源标识符（URI）识别元数据项的实践当前正在获得动量。然后，维持DCAP随着时间的推移，可以涉及逐步提高其精度，通过将其术语与URIS可用时，通过URIS识别其术语;这在此称为适当识别的原则。
同时，这些指导方针的目标是为系统开发人员和信息专家提供基于dublin - core的元数据模型的规范化和可读视图。DCAP应该包含足够的信息，以便对其目标受众具有最佳用途——可读性原则——即使这需要包含冗余的信息，在一个机器可处理模式的正式系统中，这些信息可能会从外部源动态获取。
考虑到可读性原则所要求的表示的灵活性，没有假设dcap可以在不使用特别启发式或人工干预的情况下转换为未来机器可理解的形式。创造者的DCAPs应当记住,一种规范化的文档本身不能解决互操作性的更深层次的问题在这样一个世界的多样性基础元数据模型——的问题将继续挑战的元数据社区作为一个整体,尤其是™都柏林核心元数据倡议,在可预见的未来。
本文档为如何在Dublin Core™应用程序概要中构建和呈现信息提供了指导。定义并解释了作为声明性元数据构造的dcap底层的原则和概念。
指南不授权DCAPS的特定文档格式。DCAPS可以作为纯文本文件或网页，文字处理文件，PowerPoint或实际上作为墨水作为墨水。通过为这些文件提供一致的演示结构，这些指南旨在使人们更容易理解别人在他们的元数据中做了什么。该指南要求足够的结构，以确保DCAPS将尽可能直接地转换为使用架构语言（例如RDF）的表达式，以便通过机器自动处理。从这个意义上讲，DCAPS的正常化文献形式是迈向更加雄心勃勃，长期目标的第一步，可以在广泛的信息来源中自动化语义互操作性。
Dublin Core™应用程序概要(DCAP):DCAP是一种声明，它指定组织、信息提供者或用户社区在其元数据中使用哪些元数据术语，以及这些术语是如何定制或适应特定应用程序的。根据定义，DCAP部分基于Dublin Core™，并遵循DCMI语法原则[DCMI- Principles]。一个DCAP由一个描述性标题和一个或多个术语用法组成。
DCMI语法原则：正如Dublin Core™元数据计划所维护的那样，DCMI语法原则指定了元数据术语的一种类型——元素、元素细化、编码方案和词汇表术语——以及它们的相互关系和功能[DCMI- principles]。DCAP基于用一组简单的属性描述的资源的简单模型。这与DCMI语法原则是一致的，DCMI语法原则本身并没有指定更精细的模型。
描述性的标题:描述性报头通过指定DCAP的最小标题，创建者，日期，标识符和描述，将DCAP放置到解释上下文中。可选的前导码可以对DCAP中遵循的任何技术或文主约定发表评论。
术语用法：术语用法是元数据术语的描述，它至少根据适当标识原则标识元数据术语，使用一个或多个标识属性(术语URI、定义对象、名称、标签)，如第3节所述。可以选择的是，术语用法也可以通过提供额外的定义属性、关系属性或约束来更详细地描述或注释术语，如第4节所述。
适当认定原则:适当识别原则要求尽可能精确地识别元数据术语。正如2002年12月所谓的core Resolution所建立的那样，识别元数据术语的首选方法是引用它的统一资源标识符(URI)。所有DCMI元数据术语都是用uri标识的，uri目前被分配给其他主要语义标准的术语，如MARC21和IEEE/LOM [CORES-RESOLUTION]。每当这样的URI可用时，它们都应该作为术语用法(其“术语URI”)的属性被引用。还没有(或还没有)分配uri的术语应该使用适当的其他属性来标识，如第3节所述。
可读性原则：可读性原则规定DCAP应该包括足够的信息在术语用法的最优效用的目标受众DCAP——即使这需要冗余的信息,在一个正式的系统的计算机可处理的模式,否则可能会获取动态地从外部来源。相反，可读性原则允许未使用的属性简单地从显示中删除。
应用程序概要文件用于澄清谁在声明和维护组想要共享的元数据语义。本节描述如何以适当的精度识别术语用法中使用的元数据术语(适当识别原则)。
目前，识别元数据术语的首选方法是引用它的统一资源标识符(Uniform Resource Identifier, URI)(如果有的话)。URI是根据通用和灵活的语法[URI]构造的“用于标识抽象或物理资源的紧凑字符串”。万维网联盟提倡“所有重要的资源都应该由URI标识”的概念[WEBARCH]，并特别提倡使用URI来标识元数据元素。在2002年12月的Core决议中，七个领先元数据标准——Dublin Core、IEEE/LOM、DOI、CERIF、MARC21、ONIX和GILS——的维护人员承诺将uri分配给它们的元素，并阐明这些uri的持久性策略[CORES- Resolution]。(请注意，当使用URI标识元数据术语时，URI通常充当Web地址，用于访问关于该术语的信息，例如Web页面或机器可处理的模式。然而，CORES Resolution并不要求这些标识符解析到这些资源，并且导致“文件未找到”消息的uri也不一定作为标识符被“破坏”。)
对于URI已正式分配的元数据术语 - 例如，由DCMI或核心分辨率的另一个签字人 - 该URI应该在Field“术语URI”中引用。例如，Dublin Core™元素“受众”应被引用为“http://purl.org/dc/terms/daudience”。由于这种形式的识别是精确且自行充分的，可以留空其他识别字段：
| 术语URI | http://purl.org/dc/terms/autience. |
|---|---|
| 的名字 | - |
| 标签 | - |
| 被定义为 | - |
根据可读性原则，可以在这里添加Name、Label等标识属性，使DCAP更加“可读性强”。如果DCAP的目的是作为处理元数据记录的指南，那么可能确实需要提供Name(即元数据记录中实际使用的字符串)。如果术语的Name或Label作为术语用法的标题比术语URI更“便于阅读”，则可以更改这些属性的顺序，将它们放在前面。请参阅5.4节(“从外部来源复制的属性”)和5.2节(“术语用法的可读性”)进行进一步讨论。
已在某处宣布或记录的术语，但未分配URI（只要通过提供所定义的声明文档或架构，尽可能准确地识别您的术语（就像一个知道）一样确定。声明文档或架构应引用URI，Web地址或“由”字段中的“书目”参考。术语本身可以使用字符串标识符或令牌（在字段“名称中”，默认情况下被假定为区分大小写）或自然语言标签（在现场“标签”中），或两者，取自陈述文件或架构：
| 术语URI | - |
|---|---|
| 的名字 | 出席贴图 |
| 标签 | 出席率模式 |
| 被定义为 | http://someones-project.org/schema.html. |
对于还没有在任何其他声明性文档中定义的术语，字段defined By应该简单地引用DCAP本身的URI(与DCAP描述头中的Identifier一起分配)。例如，在URI为“http://my-project.org/profile.html”的DCAP中，一个新的本地术语Star Ratings可以定义如下:
| 术语URI | - |
|---|---|
| 的名字 | StarRatings |
| 标签 | 星级评级 |
| 被定义为 | http://my-project.org/profile.html. |
希望以使其具有精确度的方式声明当地创建的术语的DCAP的创造者，从而可以通过其他方式重新使用，可以进行分配URI的额外步骤。目前，有关URI的技术惯例和“网络礼仪”尚未以常见的做法建立自己，尽管最小似乎有礼貌和明智，不要促进新的URI，除非预计他们将被维持。出于DCAP的目的，DCMI本身提供了实践模型，并且可能出现进一步的选项，因为核心解决方案已经实现了[DCMI-命名空间，DCMI-Quard，DCMI-Schemas]。请注意，核心分辨率本身仅解决使用URIS作为标识符，并且沉默于URI是否应解析为信息网页或模式[核心分辨率]。
下面列出了描述DCAP中“使用”的元数据项的属性。请注意，它们在这里被称为“属性”，简单地避免困惑递归的配方，例如“描述术语的术语”。
在术语用法中标识属性的使用(见4.1节)受适当标识原则的约束。根据这一原则,一个术语的使用应该使用一个或多个四识别属性来识别一个术语精确适当的——也就是说,与正式分配URI如果可用,或者通过引用一个术语的名称或标签以及文档的引用,模式,或Web页面中定义这个词。
术语用法的所有其他属性都是可选的，应用作本地需求可能决定。如第5.4节中所讨论的，可以根据需要区分“本地”和“源”属性。
| 术语URI | 用于识别术语的统一资源标识符。 |
|---|---|
| 的名字 | 分配给术语的唯一令牌。 |
| 标签 | 分配给术语的人类可读标签。 |
| 被定义为 | 定义术语的文档的名称空间、模式指针或书目引用的标识符。 |
| 定义 | 代表该术语概念和基本性质的陈述。 |
|---|---|
| 评论 | 有关术语或其应用的其他信息。 |
| 术语类型 | 术语（例如“元素”，“元素细化”或“编码方案”）的语法类别。 |
| 改进 | 所描述的术语在语义上细化了引用的术语。 |
|---|---|
| 精制而成 | 所描述的术语由引用的术语在语义上进行精炼。 |
| 编码方案 | 所描述的术语，编码方案，限定了引用的术语。 |
| 有编码方案 | 所描述的术语由引用的编码方案限定。 |
| 相似 | 所描述的术语具有与参考术语相同或类似的术语。 |
| 义务 | 指示元素是否需要始终或有时会存在（即，包含值）。示例包括“强制性”，“条件”和“可选”。） |
|---|---|
| 条件 | 描述根据该条件或条件，该值应存在值。 |
| 数据类型 | 表示可以在元素的值中表示的数据类型。 |
| 发生 | 表示元素可重复性的任何限制。 |
根据定义，DCAP由描述性标题和一个或多个术语用法组成（参见第2节）。说明标题应包括以下内容：
缺省情况下，应使用自己的术语用法描述DCAP中引用的每个术语 - 一个表，其中包含左侧的左侧的全套属性和右侧的属性值。按照可读性的原则，但是，预期使用DCAP可能决定不同的表象风格：虽然dCAPS特异性专供软件开发人员使用将需要明确和详细，dCAPS特异性主要用作供人食用的资料文件即可（而且经常应该是多么陶犯。以下是几种方式可以格式化使用术语用法以获取可读性：
根据DCMI语法原理，词汇项是价值的受控词汇的成员，并且由编码方案[DCMI-Protialiple]命名的值（整个值）的受控词汇。
一般来说，无论是创建潜在值的列表，还是为该列表(作为一个整体)提供名称和URI，应用程序概要文件的角色都不是声明受控的值词汇表。最适合在DCAP外部的单独可引用文档中声明词汇表术语集。
但是，如果DCAP的创建者仅仅希望指定一个可能值的简短列表(例如，“动物、蔬菜或矿物”)，那么可以简单地在“Comment”字段中列出这些值。
在DCAP中引用编码方案有三种方法：
元素细化的选项类似于编码方案的选项：
理想情况下，应用程序配置文件将以与直接从Web上的模式一起使用的术语动态上限，此信息将与本地注释集成到用于方便用户的“一站式”文档中。使用机器可理解的DCAPS可能会有一天可以实现这一点。
然而，与此同时，如果dcap的创建者希望在术语用法中包含来自原始源文档的定义或其他此类信息，那么他们别无选择，只能从源文档中复制这些信息。虽然可读性原则特别允许这样做，但dcap的作者应该记住，复制的信息，如果不维护，可能会与官方源不一致。
如果提供了从外部来源复制的信息，则应在序言中按第5.1节所述报告这一事实。当需要在DCAP中区分本地定义的属性和从外部源复制的属性时，DCAP应该建立自己的文档内部约定，例如区分本地定义和源定义;参见第6.3.2节中的示例。
过去曾为Dublin Core™的应用程序配置文件创建者发明了许多类型的注释，最受欢迎的是注释，最佳实践，使用，范围，打开问题，示例，目的，指导方针，并不混淆。虽然本指南将上述所有指南均匀地纳入一般命名的评论字段，但DCAP的创建者可能希望根据需要使用不同的标签重复此字段。未来机器处理的需求现在似乎在该领域的更严格的均匀性。
从这里的意义上讲，Qualified Names是“经过限定的”元数据术语的名称，其前缀代表与这些术语相关联的名称空间(“名称空间前缀”)。例如，Dublin Core™元素“Title”有时在元数据记录和使用文档中使用名称空间前缀(如“DC.”或“DC:”)引用。标题”或“dc:名称”。虽然这种引用方法看起来很简单，但它是基于对“名称空间”性质的假设，而不能假设“名称空间”跨不同的应用程序环境(例如，HTML、RDF和关系数据库)或元数据社区(例如，引用来自都柏林核心以外的标准的元素)。无论如何，它都预先假定了一种附加的机制或声明，以便将前缀与适当的名称空间关联起来。
出于这样的原因，引用具有完整URI的元素更好 - 实际上，这是核心分辨率和DCMI策略支持的唯一方法[核心分辨率，DCMI-命名空间]。根据适当识别的原则，在这些指导方面遵循，必须在可用时引用术语URI。
另一方面，像“http://purl.org/dc/elements/1.1/title”这样的长字符串可读性不强，可能会被DCAP的普通读者误解。按照可读性原则,因此,作者DCAP可以选择使用限定名称(例如,“dc:标题”)在“名称”字段中,只要使用任何前缀DCAP的序言中解释,只要uri引用任何可用的术语。
没有什么可以抑制DCAP的创建者从创建新的URIS作为当地创作元数据项的标识符。由于上面讨论的原因在第3节中，一个人应该在采取此步骤之前暂停反射，如果宣布URI，则此步骤应分别记录，而不是将“传递”中的一个充满术语用途的DCAP。Any URIs declared for use in a DCAP might best be formed by following the DCMI algorithm and concatenating the URL of the DCAP (e.g., "http://myproject.org/profile/") and the Name of the term (e.g., "starRatings") into a single string (e.g., "http://myproject.org/profile/starRatings") [DCMI-NAMESPACE]. Other models for forming URIs as identifiers for metadata elements are emerging with the implementation of the CORES Resolution [CORES-RESOLUTION].
为了在不同的应用程序环境中都可用，Dublin Core™被设计为描述资源的一组属性。然而，在实现实践中，Dublin Core™元素可以嵌入到更精细的模型中，这些模型以本地特定的方式对元素进行分组或嵌套。
在缺乏一个清晰的和被广泛接受的数据模型之外的平面组属性,然而,申请将元数据从许多不同的来源可以只提取和解释都柏林核心元数据的简单,失去任何特定于应用程序的建模环境。应用程序设计师希望文件嵌套或分组构造DCAP需要扩展这里描述的指导方针以这样做,而应当记住,记录这样的结构本身不会保证他们正确理解或由其他应用程序进行处理。
出于历史和便利的原因，大量应用程序具有基于Dublin Core™模型解释的元数据，从今天的语法原则的角度来看，这些元数据是不合理的。例如，应用程序可能使用CreatorDateOfBirth—一个表示资源创建者的出生日期的元素，然而，它并没有像其名称所暗示的那样在语义上“精炼”创建者。
而不是错误地断言“CreatorDateOfBirth”为元素细化细化http://purl.org/dc/elements/1.1/creator，DCAP中的术语用法应简单地记录元素的本地名称，并将DCAP本身的URI标识为其源。例如，如果DCAP本身由“http://myproject.org/profile/2003/03/17/”识别，则使用术语使用应声明以下内容，留下空的任何字段（例如“术语URI”和“细化“）将对元素产生不正确的断言：
| 术语URI | - |
|---|---|
| 本地名称 | CreatorDateOfBirth |
| 被定义为 | http://my-project.org/profile.html. |
| 改进 | - |
“错误”等“CreatorDateFabri胎”是对互操作性的负面后果，取决于它们如何解释并在特定应用程序的上下文中使用。创建DCAP中所涉及的分析努力实际上是一个重要的第一步，迈向更互操作的基础。
| 标题 | RDN OAI应用程序概要 |
|---|---|
| 贡献者 | 安迪•鲍威尔 |
| 日期 | 2003-03-23 |
| 标识符 | 此文档的URL - 要分配 |
| 描述 | 本文档表达了由资源发现网络(RDN)建立的应用程序概要文件，供RDN合作伙伴使用元数据收集开放档案倡议协议(OAI-PMH)收集记录。申请概要是根据CEN/ISSS发布的指南来表达的[参考]。应用程序概要文件的完整用户文档，以及相关的XML模式，可以在以下网站获得http://www.rdn.ac.uk/oai/rdn_dc/． 所有Dublin Core™条款均在//www.voudr.com/documents/dcmi-terms/． |
| 的名字 | 主题 |
|---|---|
| 术语URI | http://purl.org/dc/elements/1.1/subject |
| 有编码方案 | DC主题编码方案 |
| 有编码方案 | RDN主题编码方案 |
| 评论 | RDN主题编码方案可从中获得http://www.rdn.ac.uk/publications/cat-guide/subject-schemes/ |
| 义务 | 受到推崇的 |
英国资源发现网络的DCAP采用尽可能简洁的格式[RDN]。特别注意以下内容：
| 标题 | 雷纳德申请档案 |
|---|---|
| 贡献者 | 元数据工作组SUB Göttingen |
| 日期 | 18-04-2002 |
| 标识符 | http://renardus.sub.uni-goettingen.de/renap/renap.html |
| 描述 | 交叉搜索和交叉浏览欧洲质量控制主题网关。 |
| 术语URI | http://purl.org/dc/elements/1.1/language. |
|---|---|
| 的名字 | 语言 |
| 标签 | 语言 |
| 被定义为 | - |
| 定义 | - |
| 评论 | Renardus:语言代码是ISO 639-2，三字母代码。SUB将提供两个字母和三个字母语言代码之间的映射，但这也可以在LoC网站- ISO 639-2上找到:http://lcweb.loc.gov/standards/iso639-2/englangn.html |
| 术语类型 | 元素 |
| 改进 | - |
| 精制而成 | - |
| 编码方案 | - |
| 有编码方案 | http://purl.org/dc/terms/ISO639-2 |
| 相似 | - |
| 义务 | 强制的 |
| 条件 | - |
| 数据类型 | 细绳 |
| 发生 | 可重复的 |
雷达勒斯项目的DCAP已以稍微冗长的方式格式化（雷达勒）。特别注意：
| 收件人 | 元数据工作组，互操作性工作组 |
|---|---|
| 贡献者 | 由互操作性和元数据分析师，电子特使，内阁办公室，英国的办公室起草(电子邮件保护) |
| 贡献者 | 元数据工作组 |
| Coverage.spatial | 英国 |
| 创造者 | 英国内阁办公室电子特使办公室互操作性和元数据高级政策顾问 |
| Date.issued | 2003-08-05. |
| 描述 | 为英国公共部门使用的元数据提供结构的元素和改进，旨在补充电子gms。 |
| 格式 | 文本/ MS Word 2003 |
| 标识符 | http://purl.oclc.org/NET/e-GMS-AP_v1 |
| 语言 | 英格 |
| 出版商 | 电子特使，内阁办公室，英国办公室。 |
| Rights.copyright | http://www.hmso.gov.uk/docs/copynote.htm.皇冠版权 |
| 来源 | http://purl.oclc.org/net/e-gms_v2. |
| 地位 | 版本1.0用于发布 |
| 主题 | 元数据 |
| Subject.category | 信息管理 |
| 标题 | 英国电子政府元数据标准应用程序配置文件版本1 |
英国电子政务元数据标准的DCAP在最详细和具体的可能样式[EGMS]中格式化。虽然这导致比RDN和雷达卢斯的DCAP更长的文档，但这些特异性可能对需要基于DCAP创建或处理元数据的应用程序的开发人员有所帮助。特别注意以下内容：
DCAP本身应该用Dublin Core™元数据描述，要么在报头中描述，要么在单独的元数据记录中描述。至少，该描述应包括:
| 标题 | 应用程序概要文件的名称。 |
|---|---|
| 贡献者 | 概要文件的创建者或维护者。 |
| 日期 | 最后修改的日期。 |
| 标识符 | 对概要文件的明确引用。最佳实践是提供一个URL，通过该URL可以在Web上检索文档或模式的副本。 |
| 描述 | 简明描述了轮廓。酌情酌情详细说明在其中旨在使用DCAP的上下文和目的;参与其发展的组织或个人;关于未来发展和维护DCAP的任何安排，政策或意图;或描述的实例元数据或数据库的技术特征。 |
DCAPS可以以机器可解释的模式语言表示，并且可以通过软件应用程序操纵此类机器可解释模式。本CWA没有详细建议，就如何构建此类模式，因为一些问题仍然是辩论。该CWA的范围仅限于推荐应用程序如何表达为文本文档。下面概述了机器可解释DCAP的未来选择。
目前，可以考虑W3C指定的两种模式语言:XML schema [XML- schema]和RDF schema [RDF- schema]。模式语言的选择将受到模式打算支持的功能的影响——例如，是否需要它作为数据交换的可预测格式，或是否打算支持对现有元数据的推断。如此不同的目标意味着两种模式语言之间的不同选择。关于如何结合XML模式和RDF模式来更充分地表达应用程序概要文件[HUNTER]的特征，已经有一些讨论。最近，W3C内部开始尝试将RDF Schema作为词汇表描述语言，而将XML Schema作为提供结构化数据交换的基础。
XML模式提供了一种结构化表达式，支持实例元数据的验证。实际上，XML模式提供了一个文档“模板”，它充当元数据实例的交换格式。XML架构与XML DTD的功能相同，具有可扩展性和命名空间处理的额外功能。
RDF架构在术语之间表达关系，为表示术语的语义 - 它们的属性，类和定义提供数据模型。结合使用唯一标识符的底层RDF数据模型允许软件推断术语之间的关系并执行数据聚合。
RDF模式对于表达应用程序概要文件的语义很有效，而XML模式对于表达基数、数据类型和约束更有效。在SCHEMAS [BAKER]和MEG [MEG- registry]等项目中，已经探索了在RDF中表达应用程序概要文件的可能方法。
[BAKER] Thomas BAKER, Makx Dekkers, Rachel Heery, Manjula Patel, Gauri Salokhe，你的元数据使用了什么术语?应用程序概要作为机器可理解的叙述。《数字信息学报》2:2(2001年11月)，http://jodi.ecs.soton.ac.uk/articles/v02/i02/baker.．
[核心分辨率] Thomas Baker，Makx Dekkers，用URI识别元数据元素：核心分辨率。D-lib杂志（2003年7月），http://www.dlib.org/dlib/july03/baker/07baker.html．
[DC-Library]库应用程序配置文件，//www.voudr.com/documents/2002/09/24/library-application-profile/．
[DCMI-NAMESPACE] Andy Powell, Harry Wagner, Stuart Weibel, Tom Baker, Tod Matola, Eric Miller, Dublin Core™元数据计划的命名空间策略，//www.voudr.com/documents/dcmi-namespace/．
[DCMI原理] DCMI语法原则，//www.voudr.com/usage/documents/principles/．
DCMI-SCHEMAS DCMI模式,//www.voudr.com/schemas/．
[DCMI-术语] DCMI元数据项，//www.voudr.com/documents/dcmi-terms/．
[egms]电子特使办公室 - 内阁办公室，英国电子政务元数据标准应用个人资料版本1，http://purl.oclc.org/NET/eGMSAPv1．
[HEERY] Rachel HEERY, Manjula Patel, Application profiles: mix and matching metadata schemas, Ariadne 25, September 2000，http://www.ariadne.ac.uk/issue25/app-profiles/intro.html．
[猎人]简猎人，Carl Lagoze，结合RDF和XML模式，增强元数据应用程序配置文件之间的互操作性。WWW10，2001年5月1日至5日，香港，http://www10.org/cdrom/papers/572/index.html．
[Meg-Registry] Rachel Heery，Pete Johnston，Dave Beckett，Damian Steer，Meg Registry和Scart：用于创建，发现和重复使用元数据模式的互补工具。在：2002年佛罗伦萨：佛罗伦萨：佛罗伦萨：2002年，第125-132页，佛罗伦萨：佛罗伦萨：佛罗伦萨：佛罗伦萨：125-132，http://www.bncf.net/dc2002/program/ft/paper14.pdf．
[RDF-SCHEMA] Brickley, Dan和Guha, R.V，编辑。RDF词汇描述语言1.0:RDF Schema W3C工作草案2003年1月23日，http://www.w3.org/TR/rdf-schema/．
[RDN] Powell, Andy, RDN OAI Application Profile，[待分配的URL]。
[雷纳德]元数据工作组子Goettingen，雷纳德申请资料，http://renardus.sub.uni-goettingen.de/renap/renap.html．
[Uri] T.Berners-Lee，R. Fielding，L. Masinter，统一资源标识符（URI）：通用语法，1998年8月，http://www.ietf.org/rfc/rfc2396.txt．
[WEBARCH] Ian Jacobs主编，《万维网架构》，http://www.w3.org/TR/webarch/．
[XML-Schema] Thompson，Henry S.等人。，编辑。XML架构第1部分：结构。W3C建议2001年5月2日，http://www.w3.org/tr/xmlschema-1//．