| 创作者： | DCMI使用董事会 |
| 发行日期： | 2007-12-03 |
| 最新版本： | //www.voudr.com/specifications/dublin-core/grammiation-principles/ |
| 发布历史: | //www.voudr.com/specifications/dublin-core/grammational-principles/release_history/ |
| 描述： | 本文档描述了2003年和2004年度管理使用董事会决策的语法原则。通过DCMI抽象模型，这些原则在2005年被取代。此版本几乎与2003年的早期版本相同。第一个版本在2002年发布。 |
该语法介绍了DCMI元数据术语的类型，并描述了它们的定义和使用基础原则。正如“Dublin Core™的名称空间策略”中定义的那样，DCMI术语是“DCMI元素、DCMI限定符或来自DCMI维护的受控词汇表的术语”。而DCMI名称空间则是“DCMI术语的集合”[2]。
元素是资源的属性。正如这里的意图，“属性”是资源的属性——资源可能“拥有”的特征，比如Title、Publisher或Subject。
2.2。限定者
“限定符”是传统上用于术语的通用标题，现在通常被称为元素细化或编码方案。
元素细化是资源的属性，其属于特定DCMI元素的含义，但具有较窄的语义。在某些应用环境（特别是基于HTML的编码）中，元素细化与自然语言“限定符”（即形容词）的方式一起使用元素[3]。然而，由于元素改进是资源的属性（如元件），因此元素细化可以替代地用于独立于它们细化的属性[9]的元数据记录。在DCMI实践中，元素细化只会改善一个父DCMI属性。
编码方案提供了有助于解释术语价值的上下文信息或解析规则。这些上下文信息可以采用受控词汇表，正式符号或解析规则的形式。如果客户或代理商不了解编码方案，则该值仍然对人类读者有用。有两种类型的编码方案：
词汇编码方案表明该值是来自受控词汇的术语，例如来自国会主题标题库的价值“中国历史”。
语法编码方案表明该值是根据正式表示法格式化的字符串，例如“2000-01-01”作为日期的标准表达式。
２.３.镜像下的原则
Dublin Core™元素的资格是通过称为愚蠢原理的规则引导。根据这条规则，客户端应该能够忽略任何限定符并使用该值，就像它不合格一样。虽然这可能导致某些特异性损失，但剩余的术语值（减去限定符）必须继续对发现进行纠正和有用。因此，符合要求的资格仅限于，不扩展元素的语义范围。
2.4。适当的价值观
特定元素或限定符的最佳实践可能因上下文而异。定义可能提供一些指导;可以在使用指南[6]中找到其他信息。
使用板维护DCMI类型词汇表[7] - 推荐条款的一般跨域列表，该术语可以用作资源类型元素的值来识别资源的类型。DCMI类型词汇的成员项称为词汇术语。
如果词汇术语与另一个词汇项进行分层相关，则在其期限声明中相互使用“更广泛”和“比”和“窄于”和“更窄的”。
在DCMI使用情况下，应用程序配置文件是其中的Metadata术语的声明，组织，信息资源，应用程序或用户社区在其元数据中使用[10]。
参考文献
［1］使用董事会进程
[2]DCMI命名空间策略
[3]RFC 2731.
[4]DC-XML指南
[5]在RDF / XML中表达合格的Dublin Core™
[6]使用指南
[7] DCMI类型词汇表
[8]词汇表
[9]从前者,后者体现在名称使用委员会分配给元素细化,以摆脱adjective-like名称如“创建”(2000年7月批准)对noun-phrase-like名称如“dateCopyrighted”(2002年7月批准)。独立于Elements使用Element Refinements的一个后果是，关于它们之间关系的信息将驻留在独立模式的元数据记录之外，需要执行简化等操作的应用程序将需要咨询这些模式。
[10] DCMI使用董事会审查应用程序配置文件