注意:从2001年到2005年，该文档一直被维护，作为希望为信息资源(例如，电子文档)创建简单描述性记录的Dublin Core™新用户的入口点，并作为专家的现成参考文档。它已经被最新的指导材料．
| 创造者: | 黛安娜Hillmann |
|---|---|
| 发行日期: | 2005-11-07 |
| 标识符: | //www.voudr.com/specifications/dublin-core/usageguide/2005-11-07/ |
| 替换: | //www.voudr.com/specifications/dublin-core/usageguide/2005-08-15/ |
| 取而代之的是: | 不适用 |
| 最新版本: | //www.voudr.com/specifications/dublin-core/usageguide/ |
| 翻译: | //www.voudr.com/resources/translations/ |
| 文档的状态: | DCMI推荐资源 |
| 描述文档: | 本文旨在作为Dublin Core™用户的一个入口点。对于非专业人员，它将帮助他们为信息资源(例如电子文件)创建简单的描述性记录。随着Dublin Core的变化和增长，专家可能会发现该文档是都柏林核心文档的有用参考点。 |
3.元素内容和受控词汇表
4.的元素
5.都柏林核心™限定符
6.附录、角色
7.术语表
8.参考书目
自从第一个图书管理员在一书架的手写卷轴上列出条目清单以来，元数据就一直伴随着我们。“meta”这个词来自于一个希腊单词，意思是“旁边，与，之后，下一个”。最近的拉丁语和英语使用“meta”来表示超越自然的事物。元数据可以被认为是关于其他数据的数据。它是互联网时代的术语，指的是图书馆员传统上编入目录的信息，通常指的是关于Web资源的描述性信息。
元数据记录由描述相关资源所需的一组属性或元素组成。例如，图书馆中常见的元数据系统——图书馆目录——包含一组元数据记录，其中包含描述一本书或其他图书馆项目的元素:作者、标题、创建或出版日期、主题覆盖范围，以及指定项目在书架上位置的索书号。
元数据记录和它描述的资源之间的链接可以采用以下两种形式之一:
与资源本身一起携带的嵌入式元数据的例子包括印刷在书籍扉页背面的出版物编目(CIP)数据;或电子文本中的TEI标题。目前使用的许多元数据标准(包括Dublin Core™标准)都没有规定任何一种类型的链接，将决定权留给每个特定的实现。
尽管元数据的概念早于Internet和Web，但随着电子出版和数字图书馆的增加，以及在线上可获得的大量无区别的数字数据带来的随之而来的“信息过载”，世界范围内对元数据标准和实践的兴趣已经爆发。任何试图使用当今流行的Web搜索服务在网上查找信息的人都可能经历过这样的挫折:检索数百个(如果不是数千个的话)“点击”，而改进或进行更精确搜索的能力有限。广泛采用电子资源的描述性标准和做法将改善在任何对信息检索至关重要的场所对相关资源的检索。正如Weibel和Lagoze这两位元数据开发和数字图书馆领域的领导者所指出的:
标准化的描述性元数据与网络对象的关联有可能通过支持基于字段(例如，作者，标题)的搜索，允许非文本对象的索引，并允许访问替代内容，这与访问资源本身的内容不同，从而大大提高资源发现能力。”(Weibel and Lagoze, 1997)
在过去的几年里，我们还看到了在更封闭的环境中应用Dublin Core™元数据的增加。在某些实现中，Dublin Core™元数据用于描述公司、政府和国际组织持有、拥有或生产的资源，以支持门户服务或内部知识管理。还有一些实现将Dublin Core™元数据用作支持元数据集合聚合的通用交换格式，例如Open Archive Initiative的情况。在这些情况下，就像在Web的开放环境中一样，标准化的描述性元数据的概念提供了一种强大的机制来改进特定应用程序和特定用户社区的检索。Dublin Core™解决的正是这种对“标准化描述性元数据”的需求。
Dublin Core™元数据标准是一个简单而有效的元素集，用于描述广泛的网络化资源。都柏林核心™标准包括两个级别:简单和合格。Simple Dublin Core™包含15个元素;Qualified Dublin Core™包括三个额外的元素(Audience、Provenance和RightsHolder)，以及一组元素细化(也称为限定符)，以可能在资源发现中有用的方式细化元素的语义。都柏林核心™的语义是由来自图书馆学、计算机科学、文本编码、博物馆社区和其他相关学术和实践领域的专业人员组成的一个国际、跨学科的小组建立的。
看待Dublin Core™的另一种方式是，它是一种“用于生成关于资源的特定语句类的小语言”。在这种语言中，有两类术语——元素(名词)和限定词(形容词)——它们可以被安排成一种简单的陈述模式。资源本身是该语言中的隐含主体。(有关Dublin Core™语法的更多讨论，请参见“DCMI语法原则”在多元化的互联网世界中，“都柏林核心™”可以被视为“数字游客的元数据混杂语”:容易掌握，但不一定能胜任表达复杂关系或概念的任务。
都柏林核心™基本元素集概述在第四节．每个元素都是可选的，可以重复。大多数元素也有一组限定符或细化，这些属性可用于进一步细化(而不是扩展)元素的含义。都柏林核心元数据计划(Dublin Core™Metadata Initiative, DCMI)建立了细化元素的标准方法，并鼓励使用编码和词汇表方案。全套的元素和元素细化符合DCMI“最佳实践”是可用的，并有一个正式的注册表可用。
这里需要提到另外三个Dublin Core™原则，因为它们对于理解如何考虑元数据与它们所描述的底层资源之间的关系至关重要。
- 一对一的原则。一般来说，Dublin Core™元数据描述资源的一种表现形式或版本，而不是假设各种表现形式相互替代。例如，jpeg格式的《蒙娜丽莎》与原画有很多共同点，但与真迹却不一样。因此，数字图像应该被描述为自己，最可能的是数字图像的创作者作为创造者或贡献者，而不仅仅是蒙娜丽莎的原画画家。原作的元数据和复制品的元数据之间的关系是元数据描述的一部分，它帮助用户确定他是否需要去卢浮宫寻找原作，或者他/她的需求是否可以通过复制品来满足。> 2。镜像下原则。Dublin Core™特性的鉴定遵循一个通俗的Dumb-Down原则。根据该规则，客户端应该能够忽略任何限定符，并将该值当作不限定符使用。虽然这可能会导致一些特异性的损失，但剩余的元素值(减去限定符)必须继续保持一般正确和有用的发现。因此，限定只被认为是细化，而不是扩展属性的语义范围。> 3。 Appropriate values. Best practice for a particular element or qualifier may vary by context, but in general an implementor cannot predict that the interpreter of the metadata will always be a machine. This may impose certain constraints on how metadata is constructed, but the requirement of usefulness for discovery should be kept in mind.
尽管Dublin Core™最初开发时着眼于描述类文档对象(因为传统的文本资源已经很好地理解了)，但DC元数据也可以应用于其他资源。它是否适合用于特定的非文档资源，在某种程度上取决于它们的元数据与典型文档元数据的相似性，以及元数据的用途。(鼓励对将Dublin Core™用于各种资源感兴趣的实现者浏览Dublin Core™Projects页面获取使用Dublin Core™元数据作为资源的想法。)
Dublin Core™的目标是:
创建和维护的简单性
Dublin Core™元素集被保持得尽可能小和简单，以允许非专业人员轻松和廉价地为信息资源创建简单的描述性记录，同时提供在网络化环境中对这些资源的有效检索。
通常理解的语义
跨越互联网的广大公地的信息发现被从一个知识领域到下一个知识领域的术语和描述实践的差异所阻碍。都柏林核心™可以通过支持一组通用的元素(其语义得到普遍理解和支持)来帮助“数字游客”(非专业搜索者)找到他或她的方式。例如，科学家关心的是定位某一特定作者的文章，艺术学者感兴趣的是某一特定艺术家的作品，可以同意“创作者”元素的重要性。这种对公共的(如果稍微更通用的话)元素集的聚合提高了所有资源的可见性和可访问性，包括给定规程内的和超出规程的资源。
国际范围内
Dublin Core™Element Set最初是用英文开发的，但现在正在创建新的版本许多其他的语言，包括芬兰语、挪威语、泰国语、日语、法语、葡萄牙语、德语、希腊语、印度尼西亚语和西班牙语。DCMI本地化和国际化特殊兴趣小组协调在分布式注册表中链接这些版本的工作。
尽管在万维网上国际化的技术挑战还没有被都柏林核心开发社区直接解决，来自几乎每个大陆的代表的参与已经确保了标准的发展考虑到电子信息宇宙的多语言和多文化的性质。
可扩展性
在平衡描述数字资源的简单性和精确检索的需求的同时，Dublin Core™开发人员已经认识到提供一种机制来扩展DC元素集以满足额外的资源发现需求的重要性。预计其他元数据专家社区将创建和管理额外的元数据集，专门满足其社区的需要。这些集合中的元数据元素可以与Dublin Core™元数据一起使用，以满足互操作性的需要。DCMI使用委员会目前正在研究一种在“应用程序概要文件”上下文中实现这一目标的模型。
Rachel Heery和Manjula Patel在他们的文章中写道应用程序概要文件:混合和匹配元数据模式定义应用程序概要文件如下:
“…由来自一个或多个名称空间的数据元素组成的模式，由实现者组合在一起，并针对特定的本地应用程序进行优化。”
本文旨在成为Dublin Core™用户的一个入口点。对于非专业人员，它将帮助为信息资源(例如，电子文档、JPEG图像、视频剪辑)创建简单的描述性记录。随着Dublin Core的变化和增长，专家可能会发现该文档是都柏林核心文档的有用参考点。
“使用都柏林核心™”将以非技术的方式展示任何人如何使用都柏林核心™元数据，使其材料更易于访问。它讨论了Dublin Core™元数据元素的原则、结构和内容，如何使用它们来组成一个完整的Dublin Core™元数据记录，以及如何限定元素以支持各种各样的社区使用。
本文的另一个重要目标是推广使用Dublin Core™元素集描述资源的“最佳实践”。Dublin Core™社区认识到，创建元数据的一致性是跨不同的描述性记录源实现最佳检索和可理解显示的重要关键。不一致的元数据有效地隐藏了所需的记录，导致不均匀、不可预测或不完整的搜索结果。
作为一般介绍，本文必须简短，不能解决实现者在计划使用元数据时可能遇到的所有问题。对于那些在本指南中提到的问题之外还有其他问题的人，还有几个途径可供选择。
都柏林核心抽象模型提供了一个参考模型，可以独立于任何特定的编码语法对特定的DC编码准则进行比较。这样的参考模型允许实现者更好地理解他们试图编码的描述类型，并促进不同语法之间更好的映射和转换的开发。尽管该文档主要针对支持Dublin Core™元数据的软件应用程序的开发人员，但任何考虑实现Dublin Core™的人——特别是那些考虑以任何方式扩展DC的人——都可以有用地查看该文档。那些参与开发新的都柏林核心™元数据语法编码准则或基于都柏林核心™开发元数据应用程序概要文件的人员还应该熟悉DC抽象模型。
在本指南中，我们选择以“通用”形式(Element="value")表示Dublin Core™示例。其他语法的例子，包括:HTML或XHTML (Web的超文本标记语言格式)、RDF/XML(使用可扩展标记语言的资源描述框架)和纯XML，都可以在特定语法中找到可在DCMI网站上找到的文件．在本文档和参考文献部分本指南。
语法的选择取决于许多变量，“一刀切”的规定很少适用。在考虑适当的语法时，需要注意的是，Dublin Core™概念和语义被设计为独立于语法的，在各种上下文中都同样适用，只要元数据的形式适合搜索引擎和人类解释。
HTML或XHTML可以用来表示简单的或限定的Dublin Core，尽管在表示HTML中的改进方面存在固有的限制。用HTML表示Dublin Core™的具体说明可以在以下DCMI文档中找到:
RDF(资源描述框架)允许人工读取多个元数据模式，也允许机器解析多个元数据模式。它使用XML(可扩展标记语言)来表示结构，从而允许元数据社区定义实际的语义。这种分散的方法认识到，没有一种模式适合所有情况，而且模式需要独立于中央权威的链接机制来帮助描述、识别、理解、可用性和/或交换。
RDF允许描述多个对象，而不需要指定所需的细节。底层粘合剂XML只要求定义所有名称空间，一旦定义，就可以根据元数据提供者的需要使用它们。
例如: